#snappy 2015-06-08
<dholbach> good morning
<fgimenez> good morning
<seb128> hey
<seb128> mvo, howdy, question for you ... do you know why the docker group is added to the ubuntu-core image? is docker needed for some snappy features to work? or it's just to enable the docker snap to be installed since groups can't be added later?
<seb128> context is snappy personal/desktop and knowing if that group is needed there
<mvo> seb128: yes, its needed for docker and we can not yet add groups later
<mvo> seb128: it won't be needed on desktop
<seb128> mvo, k, why is docker special cased? Just because it's a popular demo?
<seb128> or is it needed for snappy features to work?
<mvo> seb128: because it was the only way to get docker working :) and its a important package for us
<seb128> mvo, but it's not on the personnal desktop image?
<seb128> just making sure :-)
<seb128> well, let's start without it
<seb128> we can do similar hack later if needed
<mvo> seb128: yeah, just go without it for now
<seb128> but I guess we are going to need a solution to this groups problem
<mvo> seb128: we sort of have, we have libnss-extrasusers on the image, we just have no mechanism that can write to it
<seb128> ah, I see
<seb128> mvo, thanks :-)
<mvo> and yeah, its a known issue, we need to solve that and add adduser support for extrasusers plus a snappy extension that can add additional user
<ogra_> ppisati, do you have an image anywhere with the working 1G RAM on the RPi2 ? i have tried all combos of uboot and kernel that i can find and cant ever get more than 256M
<ppisati> ogra_: yes i do
<ppisati> ogra_: https://github.com/piso77/ubuntu-embedded
<ppisati> ogra_: sudo ./make_img.sh -b raspy2 -d 14.04
<ogra_> all i found was the early version on p.u.c
<ppisati> ogra_: or i can build one for yo
<ppisati> ogra_: and put it somewhere
<ogra_> oh, i meant a binary, no i can build it myself ... is that buildin an actual snappy image ?
<ppisati> ogra_: nope, vanilla ubuntu
<ppisati> ogra_: but i'm using uboot, ppa kernel, etc
<ogra_> ok
<ogra_> seems to me like the kernel does not actually get to change any memory settings with the current setup i have ... it always only shows whatever the start.elf initialized
<ppisati> ogra_: do you have a dmesg of your kernel?
<ppisati> ogra_: or a log of the entire boot?
<ogra_> several, yes, my screen is set to auto-logging :)
<ppisati> ogra_: but try that img, has 1G of ram
<ogra_> i will
<ogra_> ppisati, (sorry, was dragged into a meeting) here is the screen log of various boots http://people.canonical.com/~ogra/scree-rpi.log
<zyga> ogra_: do we know what this is https://www.raspberrypi.org/downloads/snappy/
<zyga> ogra_: my colleague installed it and it's some version of vivid
<ogra_> (the third last is your old 3.18 image from people.u.c, which was the only one i had 1G with yet, all other boots have either 128 or 256M depending on which start.elf i use)
<ogra_> zyga, it should be some old snappy version of vivid
<ogra_> i'm just trying to get an updated image together (but struggle with it a little)
<zyga> ogra_: for rpi2?
<ogra_> yes
<zyga> ogra_: thanks, I have kissiel here who will gladly use one when available
<kissiel> zyga, I missed some of your conversation, are you talking about the image?
<ogra_> i'll send a mail announcement once it is done ...
<zyga> kissiel: yes
<kissiel> zyga, cool
<zyga> kissiel: it seems that there is no updated image yet, just wait for ogra_'s announcement
<zyga> ogra_: thanks, I owe you way too many beers, perhaps at fosdem :)
<kissiel> zyga, I'll build it from scratch then
<ogra_> heh :)
<ppisati> ogra_: what you see if you do a cat /proc/meminfo?
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /proc/meminfo |grep Total
<ogra_> MemTotal:         119468 kB
<ogra_> SwapTotal:             0 kB
<ogra_> VmallocTotal:    1941504 kB
<ogra_> CmaTotal:           8192 kB
<ogra_> with the most recent boot ...
<ppisati> ubuntu@raspy2:~$ uname -a
<ppisati> Linux raspy2 3.19.1-11-generic-bcm2709 #11-Ubuntu SMP PREEMPT Tue May 26 10:34:36 UTC 2015 armv7l armv7l armv7l GNU/Linux
<ogra_> (do you need all of it ?)
<ppisati> ubuntu@raspy2:~$ cat /proc/meminfo
<ppisati> MemTotal:         947020 kB
<ppisati> ...
<ppisati> ogra_: i can put the img somewhere if you want
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ uname -a
<ogra_> Linux localhost.localdomain 3.19.1-11-generic-bcm2709 #11-Ubuntu SMP PREEMPT Tue May 26 10:34:36 UTC 2015 armv7l armv7l armv7l GNU/Linux
<ppisati> same kernel
<ppisati> it's definitely the binary blob or uboot
<ogra_> do you have anything special on the cmdline ?
<ppisati> wait
<ppisati> ubuntu@raspy2:~$ cat /proc/cmdline
<ppisati> earlyprintk console=tty0 console=ttyAMA0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd
<ppisati> ogra_: do you?
<ogra_> console=tty0 console=ttyAMA0 root=/dev/disk/by-label/system-a init=/lib/systemd/systemd ro panic=-1 fixrtc
<ogra_> nothing :)
 * ogra_ grumbles about /var/log/dmesg being empty 
<ppisati> ogra_: i'm uploadinf that img
<ogra_> ppisati, thanks, i'll try mine with your bootloader
<ogra_> i wonder if it is the uboot.env that loic created
<ppisati> ogra_: all the bootloader binaries i'm using
<ppisati> ogra_: are here, btw
<ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/tree/master/boards/raspy2/bootloaders
<ogra_> well, i tried them
<ogra_> didnt make any difference
<ogra_> you dont load an initrd ...
<ogra_> perhaps our load address is wrong and we trash something when loading it
<ppisati> ogra_: but the initrd is discarded by the kernel
<ppisati> ogra_: one thing that i noticed in your bootlog
<ppisati> ogra_: is that the kernel can actually see the entire mem
<ppisati> ogra_: bullshit
<ogra_> where do you see that ?
<ppisati> ogra_: i read it wrong
<ogra_> [    0.000000] Memory: 95036K/131072K available (6873K kernel code, 437K rwdata, 1972K rodata, 448K init, 782K bss, 27844K reserved, 8192K cma-reserved)
<ogra_> yeah
<ppisati> [    0.000000] Memory: 938380K/966656K available (6873K kernel code, 437K rwdata, 1972K rodata, 448K init, 782K bss, 20084K reserved, 8192)
<ppisati> that's my img
<ogra_> yup+
<ppisati> ogra_: you should try to load the initrd with my img
<ogra_> will do
<ppisati> ogra_: http://people.canonical.com/~ppisati/disk-2015-06-04-14.04-raspy2.img.gz
<mvo> jdstrand: hi, for later when you are online - now that we have a private /tmp via the ubuntu-core-launcher I proposed to simplify our /tmp handling (bug https://bugs.launchpad.net/snappy/+bug/1462916). apparmor would need to be updated and /tmp would have to be allowed. do you have any concerns about this approach? i.e. shifting the security from apparmor to the launcher (I put some info into the description)
<ubottu> Ubuntu bug 1462916 in Snappy 15.04 "Simplify TMPDIR handling" [Undecided,New]
<mvo> jdstrand: would love to hear your opinion on this :)
<longsleep> Hi folks, is there a way to solve "Failed to start Load/Save Random Seed." error on boot?
 * ogra_ has been wondering that for ages :)
 * longsleep will investigate
<JamesTait> Good morning all; happy Monday, and happy Upsy Daisy Day! ð
<D_Cent> hi - can anyone tell me which devices are officially supported by Snappy Ubuntu and which of those have stable images?
<longsleep> So the problem on the systemd-random-seed service is that it tries to write to /var/lib/systemd/random-seed which is read only. That is very bad as essentially all snappy devices boot up with little to no entropy, at least if the Kernel does not have http://lkml.iu.edu/hypermail/linux/kernel/1312.1/04772.html
<ogra_> longsleep, can you file a bug ?
<ogra_> we should definitely shipo that dir writable
<longsleep> well random-seed is a file - i am not sure if the whole /var/lib/systemd should be writeable
<ogra_> mvo, ^^^ i guess you agree
<ogra_> not sure we can make the whole dir writable ...  but surely that file
<longsleep> ok - i file a bug
 * mvo nods
<ogra_> (for the dir we'd need to ask the security team about possible impact)
 * longsleep thinks the security team should think about entropy and randomness
<longsleep> Snappy bugs go here: https://bugs.launchpad.net/snappy ?
<ogra_> yep
<longsleep> What Kernel version is the default for Snappy images if no device tree is provided?
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ free
<ogra_>              total       used       free     shared    buffers     cached
<ogra_> Mem:        947012     120888     826124      12768       6684      81884
<ogra_> ppisati, ^^^
<ogra_> \o/
<ppisati> yo!
<ppisati> what was that?
<ogra_> but i blindly copied your whole dir into my image
<ppisati> ogra_: so it was the bootloader
<ogra_> i'll now start removing file by file and see when it drops back to 128M
<ppisati> ogra_: cool, nice find
<ogra_> well, we dont ship any of the fixup files ... or any extra config.txt or cmdline.txt
<ogra_> i suspect it is related to that
<longsleep> Random seed service bug report here: https://bugs.launchpad.net/snappy/+bug/1462954
<ubottu> Ubuntu bug 1462954 in Snappy " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [Undecided,New]
<ogra_> longsleep, thanks
<ogra_> jdstrand, can we get some security team opinion on bug 1462954 if we can make the whole dir writable or not
<longsleep> ogra_: I think a real solution would be to make the random-seed file available to both system-a and -b (it should be shared).
<ogra_> yeah, that should happen automatically ...
<ogra_> the writable partition is shared between them ...
<longsleep> ogra_: ah i see - thats cool then
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo snappy install webdm
<ogra_> Installing webdm
<ogra_> ....
<ogra_> operation not supported
<ogra_> webdm failed to install: unpack /tmp/webdm683385157 to /apps/webdm/0.8 failed with exit status 1
<ogra_> (RaspberryPi2)ubuntu@localhost:~$
<ogra_> grmpf ...
<ogra_> Jun  8 10:06:31 localhost snappy[857]: main.go:62: DEBUG: [snappy internal-unpack /tmp/webdm683385157 /apps/webdm/0.8 /] failed: operation not supported
<ogra_> Jun  8 10:06:31 localhost snappy[824]: main.go:62: DEBUG: [snappy install webdm] failed: webdm failed to install: unpack /tmp/webdm683385157 to /apps/webdm/0.8 failed with exit status 1
<ogra_> hmm, not so informative ...
<ogra_> dang ... and i get that for every snap it seems
<ogra_> ppisati, are we sure the kernel has all necessary options set ?
<ogra_> (apparmor and systemd etc ...)
<longsleep> So, now that i have a base image. How can i modify the image after build? Are there some post hooks or something?
<ppisati> ogra_: it's the same kernel + config options since...
<ppisati> ogra_: months?
<ppisati> ogra_: wait
<ogra_> i used your latest deb for this image
<ppisati> ah, i forgot to push it
<ppisati> ogra_: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_raspi2
<Chipaca> mvo: really, TMPDIR is cleared in setuid?
<Chipaca> daaarn
 * Chipaca has one of those "how did this ever work then" moments
 * kissiel is away: lunch
<mvo> Chipaca: yep - but all under control we just need to decide what approach to take
<mvo> Chipaca: its only cleared for users, i.e. when running as root its fine
<ogra_> wow, so removing all new files but fixup.dat gets me a completely messed up boot
<ogra_> mvo, sergiusens, Chipaca, so i have a working edge RPi2 image now ... but i cant install any snaps ... all info i get in syslog is the line above (operation not supported) ... any hint how i can debug that a bit more detailed than from syslog
<mvo> ogra_: is that edge? or 15.04 ?
<ogra_> sudo ubuntu-device-flash core --channel=edge --oem pi2_0.12_all.snap --developer-mode --device-part=device-pi2-0.12.tar.xz -o pi2.img rolling
<Chipaca> ogra_: is this a wily snappy?
<ogra_> thats what i used to build it
<Chipaca> ogra_: if so it's build with go 1.4
<mvo> yeah, wily
<Chipaca> ogra_: and something is busted there
<ogra_> oh, so it is also broken on BBB ?
<Chipaca> ogra_: in wily, yes
 * mvo looks
 * ogra_ has no recent BB image around, else i would have cross checked
<Chipaca> ogra_: and amd
<ogra_> ah, phew
 * ogra_ goes and builds a 15.04 image then
<longsleep> ogra_: that is the 'rolling' parameter to your ubuntu-device-flash command from above?
<ogra_> it picks the rollin channel from http://system-image.ubuntu.com/ubuntu-core/
<ogra_> +g
<ogra_> sudo ubuntu-device-flash core --channel=stable --oem pi2_0.12_all.snap --developer-mode --device-part=device-pi2-0.12.tar.xz -o pi2.img 15.04
<ogra_> thats builds from the release channel ...
<ogra_> -s
<longsleep> i see thanks - still a lot i dont know about :)
<ogra_> well, system-image will be going away
<ogra_> images will be fully built from snaps
 * longsleep is trying to build rolling edge image for ODROID C1 now
<longsleep> ogra_: that sounds awesome
<longsleep> Channel: edge, Version: 63 - does that sound good?
<ogra_> yes, but it will be broken as you can see above :)
<ogra_> wont allow you to install snaps
<longsleep> ogra_: thats what i wanted to confirm
<ogra_> ah
<longsleep> to verify that the image i build behaves the same as yours
<ogra_> the release image works fine :)
<longsleep> yes here too
 * ogra_ installs chatroom to test
<ogra_> GRRR
<ogra_> ERROR: chatroom.ogra failed to install: unpack /tmp/snaps/webdm/0.8/tmp/chatroom275084212 to /apps/chatroom.ogra/0.1-8 failed with exit status 1
<ogra_> so this is with 15.04 now
<ogra_> tryin to install chatroom from webdm
<longsleep> mhm it was not yesterday
 * ogra_ tries from cmdline
<longsleep> ogra_: ok ok edge rolling it fails for me too
<ogra_> ha, cmdline works fine
<ogra_> seems to be a bu in webdm
<ogra_> *bug
<longsleep> mhm i just tried from cmdline
<ogra_> http://paste.ubuntu.com/11647904/
<ogra_> worked fine for me
<ogra_> and i can reach the chatroom at port 6565 in chromium
 * ogra_ tires another package from webdm
<longsleep> http://paste.ubuntu.com/11647909
<longsleep> (thats on edge though)
<ogra_> yeah, there it seems to be expected
<longsleep> so cmdline works in 15.04 but not in webdm?
 * longsleep tries that
<ogra_> only for the chatroom package it seems ... go-example-webserver installed just fine
 * ogra_ tries pastebinit 
<ogra_> hmm, weird, works too
<longsleep> i will be trying to build a snappy release https://github.com/strukturag/spreed-webrtc next weekend so i get familiar with these things too.
 * ogra_ uninstalls chatroom and tries again
<ogra_> ah, nice
<ogra_> chatroom in a more complex way :)
<longsleep> yeah - i didnt know about chatroom since yesterday
<ogra_> well, its just a hacked together example to test node-snapper :)
<ogra_> webrtc stuff makes a good show if your snappy install is in the local LAN when you hold talks ... you can involve the audience easily ;)
<mattyw> hey folks, is this a good place to be asking stupid questions about making snaps?
<ogra_> mattyw, only if you promise they are really stupid :)
<longsleep> mattyw: if you start ask stupid questions too i do not feel so alone :)
<mattyw> awesome, I'll do some typing and we'll see where we end up
<ogra_> ha
<ogra_> woah !
<ogra_> Jun  8 12:24:32 localhost ubuntu-core-launcher[962]: open /apps/chatroom.ogra/0.1-8/amd64/node_modules/express/lib/middleware/init.js: permission denied
<ogra_> Jun  8 12:24:32 localhost ubuntu-core-launcher[962]: 2015-06-08 12:24:32 ERROR snappy logger.go:199 chatroom.ogra failed to install: unpack /tmp/snaps/webdm/0.8/tmp/chatroom031296173 to /apps/chatroom.ogra/0.1-8 failed with exit status 1
<ogra_> WTF !
<mattyw> so - I'm trying to make a tmux snap - because why not. After it's installed I run tmux.tmux and I get told ERROR: profile "tmux_tmux_1.9.6" does not exist.
<mattyw> my next question is - tmux requires libevent - so I need to install that somewhere, what should I be doing with SOs?
<ogra_> mattyw, did you check for apparmor denials in syslog ?
<longsleep> mattyw: not sure if that qualifies for a stupid question - but if you want a stupid answer - i guess its related to apparmor profiles :)
<ogra_> libs should go into your snap with LD_LIBRABRY_PATH pointing to their dir
<mvo> ogra_: Chipaca is debugging that on wily - or do you get the above error on 15.04?
<ogra_> mvo, yes ... note the "amd64" in that error
<ogra_> (i'm obviously on armhf)
<mattyw> longsleep, ogra_ awesome, just as an experiment can we talk about apparmor profiles and LD_LIBRARY_PATH as if I don't know anything about those things? ;)
<ogra_> mvo, it looks like an ownership error with the file to me ... though installing from commandline with snappy install doesnt show that error
<longsleep> ogra_: chatroom installs just fine here: http://paste.ubuntu.com/11648126/
<ogra_> longsleep, yeah, for me too if i use the commandline
<ogra_> just not from webdm
<longsleep> ok let me try
<ogra_> webdm generates the permission denied error above in syslog
<ogra_> bah, now it also fails from cmdline :(
<ogra_> open /apps/chatroom.ogra/0.1-8/amd64/node_modules/express/node_modules/cookie-signature/.npmignore: permission denied
<ogra_> another permission error ... different file though
<ogra_> and i also get:
<ogra_> 2015/06/08 12:33:52 Warning: failed to remove /apps/chatroom.ogra/0.1-8: %!s(<nil>)
<ogra_> chatroom.ogra failed to install: unpack /tmp/chatroom360659173 to /apps/chatroom.ogra/0.1-8 failed with exit status 1
<ogra_> hmm
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls /apps/
<ogra_> bin  chatroom.ogra  go-example-webserver.canonical  pastebinit.mvo  webd
<ogra_> and in fact i have an empty chatroom.ogra dir under apps
<ogra_> snappy remove chatroom.ogra doesnt remove the dir
<mvo> ogra_: if that is still wily, then I think Chipaca found the issue, setgid does no longer work with go 1.4
<ogra_> mvo, no, thats still 15.04
<longsleep> ogra_: failed for me too with webdm
<longsleep> plenty of errors in syslog
<sergiusens> mvo: hey, any reason we update-grub on updates?
<ogra_> mvo, i gave up on rolling for now, need to get that Pi image to work
<mvo> ogra_: *ick* do you get that on bbb/kvm?
<ogra_> surely not on kvm
<ogra_> i developed the new chatroom package in kvm, there it always worked fine
<mvo> sergiusens: well, thats what updates grub.cfg? or am I misunderstanding the question?
<ogra_> and one out of three install attempts on the 15.04 RPi image worked too
<sergiusens> mvo: yes and it causes a nice bug
<ogra_> (resulting in a working chatroom)
<mvo> sergiusens: *autsch* which one? the one you reported friday?
<longsleep> ogra_: My syslog when installing chatroom though webdm on 15.04 http://paste.ubuntu.com/11648298/
<sergiusens> mvo: yes
<ogra_> Jun 08 12:36:28 odroid systemd[1]: [/lib/systemd/system/snappy-workaround-apparmor.service:5] Unknown lvalue 'WantedBy' in section 'Unit'
<ogra_> wow
<mvo> ogra_: meh
<ogra_> longsleep, are you sure you have all ubuntu apparmor patches in your kernel ?
<mattyw> ogra_, ah, I just have to do LD_LIBRARY_PATH=my_snap_lib_dir ./myapp, that's what you mean right? there's no magic other than that?
<mvo> longsleep: (I like you nick!) - he "'WantedBy'" is my bug, sorry for that
<longsleep> ogra_: no i have not all the patches - currently running unmodifed hardkernel tree
<ogra_> longsleep, ah, then your issue is different
<ogra_> mvo, http://paste.ubuntu.com/11648369/
<sergiusens> mvo: https://bugs.launchpad.net/snappy/+bug/1462501
<ubottu> Ubuntu bug 1462501 in Snappy trunk "Updates on grub systems lose track of panic=-1" [Critical,New]
<longsleep> mvo: no worries - i am new to snappy and trying to figure out the ecosystem
<sergiusens> mvo: removing update-grub solves the azure problem
<ogra_> longsleep, the systemd kernel config options and apparmor are both essential
<longsleep> ogra_: ok i have "look at kernel patches" on my list :)
<ogra_> longsleep, ppisati can most likely help you
<longsleep> ogra_: problem is that i am on Kernel 3.10 + messy patches. I hope the patches required are small :)
<ogra_> in fact it is the whole of apparmor you need to replace
<longsleep> mvo: Do you want me to file a bug for the "'WantedBy'" problem?
<ogra_> and there is a bunch of cgroups options that snappy uses
<ogra_> for systemd
<longsleep> some work for tonight then :)
<mvo> longsleep: feel free, but I think I know the reason and work on a fix
<sergiusens> longsleep: https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels for easy apparmor instructions
<longsleep> sergiusens: thanks!
<rsalveti> ogra_: are you using 15.04/edge?
<rsalveti> guess that only stable will get you 15.04/stable
<ogra_> rsalveti, edge is obviously completely broken
<rsalveti> rolling you mean?
<ogra_> which made me switch to 15.04 stable 1h ago
<ogra_> well, edge/rolling
<rsalveti> 15.04/edge should be good
<rsalveti> rolling/edge is known to be broken
<ogra_> 15.04 stable is broken for me too
<ogra_> let me try 15.04 edge then
<rsalveti> right, 15.04/edge is what we're trying to release :-)
<rsalveti> but currently blocked by the grub issue
<rsalveti> ogra_: did you find out the reason why you can now access the entire 1gb ram on rpi2?
<ogra_> rsalveti, bootloader
<ogra_> took me 4 days but i finally found the working combo of files :)
<rsalveti> oh, great then
<ogra_> using kernel7.img without config.txt makes the bootloader ninary fall back to some weird bits
<ogra_> *binary
<ogra_> my oem snap now uses uboot.bin again with a confi.txt pointing to it
<ogra_> and you need the fixup.dat file apparently
<ogra_> once i found a working combo that actually doesnt break when installing snaps i'll push that to people.u.c
<rsalveti> great
<ogra_> well, not so great that on all images i tried yet the snap installation has issues
 * ogra_ boots 15.04 edge and crosses fingers
<rsalveti> wonders if the 'WantedBy' is also in 15.04/edge
<ogra_> no, we were both tryin stable
<ogra_> +g
<sergiusens> ogra_: it's g+
<ogra_> :P
<longsleep> ogra_: no i was trying 15.04/edge
<ogra_> oh
<longsleep> i was not aware about the distinction
<mvo> sergiusens: meh
<longsleep> i am now :)
<mvo> sergiusens: I look at the bug now, it looks a bit like its not going to be fun
 * mvo makes a extra big cup of tea
<ogra_> ok, webdm installed
 * ogra_ tries installing chatroom via UI again
<longsleep> ogra_: that even works for me without the kernel patches
<ogra_> right, but your apps wont be confined
<longsleep> saying that i just wonder what the difference is regarding installing from webdm and commandline one fails because of missing kernel patches while the other works fine
<ogra_> yay
<ogra_> chatroom installed fine
<longsleep> nice
<rsalveti> mvo: guess we'd also need to upload ubuntu-core-config to wily
<rsalveti> just saw your change
<sergiusens> mvo: rsalveti well I have the workaround fix
<mvo> rsalveti: yes, also lp:~chipaca/snappy/muppets needs to land to unblock will
<sergiusens> mvo: but we are indeed crippled
<ogra_> rsalveti, ok, looks like this image works, i'll push it to my people.u.c account and mail a call for testing
<mvo> sergiusens: oh, the workaround to use the core config?
<sergiusens> mvo: yeah, as mentioned in the bug https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/panic/+merge/261378
<mvo> neat
<sergiusens> mvo: but I also extended u-d-f to be able to add a grub.cfg in the oem snappy package, it would work fine if update-grub was not part of a snappy update
<sergiusens> mvo: it also breaks the semantics for when we truly decouple kernel and os
<ogra_> snake works too !
<rsalveti> ogra_: great
<mvo> sergiusens: yeah, I think we need a static grub.cfg just like uboot
<ogra_> :q
<rsalveti> I'll be triggering a new rootfs in a few (once ubuntu-core-config) gets published
<sergiusens> mvo: I have this azure one alreay :-)
<ogra_> rsalveti, oh, then i'll wait for that
<rsalveti> then wait for the grub fix
<mvo> sergiusens: post it!
<sergiusens> mvo: I'm just looking for blessings to remove update-grub
 * ogra_ needs to mow the lawn before it rains anyway 
<sergiusens> rsalveti: https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/panic/+merge/261378
 * rsalveti wondering what would be the side effect of removing update-grub
<mvo> sergiusens: +1 from me for this, we "just" need to expand handleAssets() for grub
 * ogra_ afk
<sergiusens> mvo: expand or reduce? :-)
<mvo> sergiusens: well, expand as its empty right now ;) and then remove 20_snappy from grub config
<mvo> sergiusens: let me know if you want help with that, I look forward to simplify this area of the code
<mvo> sergiusens: I cherry pick you azure fix in the meantime for vivid, ok?
<sergiusens> mvo: sure, but this doesn't fix azure
<mvo> sergiusens: it does not?
<sergiusens> mvo: only the fact that we lose panic=-1 on snappy updates
<sergiusens> mvo: if I remove update-grub from snappy update's code path there is no work in handleAssets (immediate at least) as grub.cfg sits in the common area
<sergiusens> which makes the fact that we are running update-grub slightly worse ;-)
<sergiusens> as rollbacks are endangered
<rsalveti> indeed
<mvo> sergiusens: I'm confused, but let me try to work it out after I cherry-picked your workaround fix
<sergiusens> mvo: update-grub creates a grub.cfg in /boot/grub/grub.cfg based out of what is in system-a or system-b
<mvo> sergiusens: fix for vivid uploaded
<mvo> sergiusens: I guess we mean the same. so if we would stop calling update-grub today, what would write /boot/grub/grub.cfg?
<sergiusens> mvo: u-d-f on device provisioning
<sergiusens> mvo: or ... (one sec)
 * sergiusens commits and pushes
<mvo> sergiusens: and if the kernel is updated to a new ABI version?
<mvo> sergiusens: oh, are you suggesting to use /vmlinuz, /initrd.img for this?
<sergiusens> mvo: so this may need more thought
<rsalveti> links should help yeah
<sergiusens> mvo: but I would standarize the names
<rsalveti> as long we're covering the update and rollback with them
<mvo> meh, yeah, the rollback is a problem with that, I think we need handleAssets for this
<mvo> sergiusens: +100 for the idea though, I think that will make things much easier
<sergiusens> mvo: ok, I'll start with this
<sergiusens> and here https://code.launchpad.net/~sergiusens/snappy/noUpdateGrub/+merge/261381
 * sergiusens needs to run some errands
<mvo> sergiusens: looks like a good start :) will you continue once you are back from errands or shall I look at what is needed for handleAssets() ?
<jdstrand> tyhicks: would you mind commenting on the TMPDIR conversation ^ (this is also bug https://bugs.launchpad.net/bugs/1462916)
<ubottu> Ubuntu bug 1462916 in Snappy trunk "Simplify TMPDIR handling" [Undecided,New]
<tyhicks> jdstrand: sure - give me a bit to finish reading email and then read backscroll in here
<jdstrand> tyhicks: I think they are proposing what we understood to be the plan
<sergiusens> mvo: I can continue
<mvo> sergiusens: cool, please merge the bits I couldn't resist removing
<barry> mvo: what do you think about unforking si client 3.0?
<mvo> barry: I meant to file a bug (but haven't yet), there is one tiny regression compared to the forked version. if there is a error during the apply step it seems 3.0 does not pass that error to the machine readable progress
<barry> mvo: ah, yes please do file a bug.  i will fix that asap and get it into wily.  i'd really like to unfork snappy.
<mvo> barry: does that sound possible? I have not looked further and pushed it on my todo instead but I remember something like "update failed, see syslog for details". for snappy and the progress fd I would love to get the actual backtrace for log and display
<mvo> barry: ok, let me file a bug
<barry> mvo: is this still the right snappy fork branch: bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/system-image-snappy/
<barry> (if so, i see the divergence - should be an easy fix)
<ogra_> jdstrand, did you see my ping from a few hours ago ?
<ogra_> jdstrand, bug 1462954 - would be nice to get a security team opinion if we could just make the whole dir writable
<ubottu> bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged] https://launchpad.net/bugs/1462954
<jdstrand> ogra_: honestly, I think that is a question better suited for pitti
<ogra_> oh, ok
<ogra_> jdstrand, it was more a "ship an empty writable file vs make the whole systemd dir writable"
<ogra_> i guess pitti will just say "do it, so we get working random seeds" :)
<mvo> barry: bug #1463061
<nothal> Bug #1463061: Please report errors via --progress as well <Ubuntu system image:New> <http://launchpad.net/bugs/1463061>
<pitti> ogra_, jdstrand: hmm -- I sent patches for the two failing units to mvo in Austin
<ubottu> bug 1463061 in Ubuntu system image "Please report errors via --progress as well" [Undecided,New] https://launchpad.net/bugs/1463061
<pitti> mvo: so I suppose they didn't land yet? can we land them now?
<ogra_> +1
<mvo> pitti: meh, I was sure I landed them, one sec
<barry> mvo: ack
<jdstrand> ogra_: well, random_seed is only one thing that is in that directorty. eg, 'catalog' is in there. the other stuff I don't really know about. random-seed should be writable. I would think we would solve for the lack of entropy how we do with cloud-- I think cloud-init may do something
<kyrofa> sergiusens, ping
<pitti> jdstrand: /var/lib/systemd/random-seed is just the place where the seed is saved on shutdown and restored on boot; it's not a magic thing to initialize the seed on first boot
<mvo> pitti: this was added  https://launchpad.net/ubuntu/+source/ubuntu-core-config/0.6.12
<mvo> pitti: is this maybe used before the writable paths are ready?
<sergiusens> kyrofa: hey
<pitti> mvo: ah, possibly -- I thought these got initialized in initramfs
<pitti> but I remember now that this isn't the case actually
<pitti> mvo: systemd-random-seed.service should order itself after mounting /var/lib/systemd/random-seed, though
<elopio> good morning
<pitti> oh wait -- these aren't in fstab, are they? so systemd can't detect that
<pitti> mvo: but either way, it waits for systemd-remount-fs.service
<ogra_> pitti, writable paths should be in fstab
<kyrofa> sergiusens, hey! So I'm in the planning stage for adding more details to the snappy scope. Initially I just figured I'd wait until webdm/the snappy service implemented it, but I've been asked to move forward with it
<mvo> pitti: I think they are in fstab
<kyrofa> sergiusens, so I wanted to talk to you about your vision for how that should be done. Can I do it in such a way that you can make use of it?
<pitti> ogra_, mvo: ok, then I need to look at a current snappy image
 * pitti keeps the bug open
<sergiusens> kyrofa: can you set something up? I guess we can work together, but I need to get this release behind me
<kirkland> jdstrand: I was kind of thinking the same thing -- connected Internet-of-Things things are almost necessarily connected to the internet :-)
<ogra_> rsalveti, when do you plan that image build ?=
<rsalveti> ogra_: sorry, was waiting another package upload
<rsalveti> ogra_: let me trigger that now
<ogra_> cool,. thanks
<kyrofa> sergiusens, sure I can. My desire is you save you work-- if you feel like my doing it in a way that you can use would take more effort than it's worth, I totally understand!
<kyrofa> sergiusens, also, this can wait a few days
<sergiusens> kyrofa: we just need to sync
<kyrofa> sergiusens, alright :) . When would be a good day/time?
<sergiusens> kyrofa: later today, invite rsalveti too so he can juggle the tasks around :-P
<kyrofa> sergiusens, sounds good
<Chipaca> ogra_: don't hate me for being right :-p
<ogra_> no no, you are totally right :)
<Chipaca> tedg: why would we need socket activation in upstart? /me no follow
<tedg> Chipaca, For handing Mir sockets to a specific job for trusted prompt sessions.
<Chipaca> tedg: we == snappy i mean :)
<tedg> Chipaca, Here we is Ubuntu App Launch.
<Chipaca> tedg: anyway, cool that we don't :)
<Chipaca> tedg: ah! makes more sense
<Chipaca> ogra_: what's needed for uboot on x86?
<Chipaca> ogra_: and on amd64
<Chipaca> and uefi
<Chipaca> and
 * Chipaca feels sick already
<ogra_> Chipaca, lol, no idea, iirc there was a linaro project for x86 support
<elopio> ogra_: once you have a working raspi image, throw it this way to give it a try.
 * tbr knows of actual x86_64 embedded hardware being designed right now that will ship with uboot
<ogra_> tbr, yeah, i was actually joking in a meeting 20min ago ... i think this approach is rather to get your laptop use uboot :)
<fgimenez> elopio, i forgot to mention you this bug  https://bugs.launchpad.net/snappy/+bug/1461487 on friday, it's very rare, i've already pasted it to the doc
<ubottu> Ubuntu bug 1461487 in Snappy "snappy list error if executed during a snappy-autopilot update" [Undecided,New]
<elopio> fgimenez: right, I saw it. I will try to reproduce.
<ogra_> elopio, yeah, i'm just waiting for the next rootfs
<kyrofa> sergiusens, rsalveti I sent you both an invite for later this afternoon. Please let me know if that doesn't work-- I'm pretty open today
<fgimenez> elopio, should we move the notes in the pad to the Snappy Image Tests doc?
<rsalveti> elopio: fgimenez: ogra_: sergiusens: new image should be out
<elopio> fgimenez: we should make a summary once we finish the testing. Collect all the important bits in bug reports, guides or docs. And send an email with that.
<ogra_> rsalveti, weird, i didnt see LP even start a build
<Chipaca> mvo: sergiusens working on grub be like https://youtu.be/A52p9jc-gOo
<rsalveti> ogra_: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
<elopio> fgimenez: I'm moving some things to the top, to make that easier. Please check it out so we don't forget anything.
 * ogra_ wonders if his watcher script is buggy
<ogra_> rsalveti, ah, amd64 failed
<ogra_> it wont import
<fgimenez> elopio, ok
<ogra_> hmm, no
 * ogra_ curses arm64 for being so similar !
<rsalveti> oh, hm
<ogra_> rsalveti, ignore me
<rsalveti> ogra_: yeah
<rsalveti> that also annoys me
<ogra_> but the importer can nowadays take 1h
 * ogra_ checks where system-image stands
<mvo> jdstrand: sorry for naging, but do you see any risks with https://code.launchpad.net/~mvo/ubuntu-core-launcher/tmpdir-simplify-lp1462916/+merge/261419 (and the also required apparmor change)?
<mvo> Chipaca: lol
<ogra_> yeah, nothing new in http://system-image.ubuntu.com/ubuntu-core/15.04/edge/ yet
<plars> I realized that for some reason snappy on my bbb does not have webdm installed and tried to install it, but it seems to fail. Is this a known breakage?
<plars> operation not supported
<plars> webdm failed to install: unpack /tmp/webdm954724051 to /apps/webdm/0.8 failed with exit status 1
<plars> or maybe I just need to reinstall?
<plars> I did update ubuntu-core before trying this
<plars> I'm currently on ubuntu-core/rolling/edge rev 63
<rsalveti> ogra_: yeah, still importing
<rsalveti> yeah, rolling/edge is still not yet in proper shape
<ogra_> rsalveti, yup, the new phones made it really slow ... will be fun once we have even more phones :)
<plars> rsalveti: ah, ok. So use 15.04/edge for now I guess?
<ogra_> plars, yeah, with the next image
<sergiusens> Chipaca: pretty much :-)
<ogra_> (which should be done soon)
<plars> ogra_: you mean the next image in 15.04 or in rolling?
<ogra_> plars, 15.04/edge is currently building
<plars> ogra_: ack
<plars> thanks!
<ogra_> :)
<tyhicks> jdstrand, mvo: I looked at the design described in bug #1462916 and like it
<nothal> Bug #1462916: Simplify TMPDIR handling <Snappy:New> <Snappy 15.04:New> <Snappy trunk:New> <http://launchpad.net/bugs/1462916>
<ubottu> bug 1462916 in Snappy trunk "Simplify TMPDIR handling" [Undecided,New] https://launchpad.net/bugs/1462916
<tyhicks> jdstrand, mvo: before reading that bug description, I don't believe that I ever heard the long term plans for /tmp... but I don't see anything wrong with that design
<mvo> tyhicks: cool, that sonds promising. It seems ok to me as well, *but* you/your team are the security experts and I was wrong too many times to fully trust my judgement here. it certainly would make it easier for packaging apps as /tmp would just be availalbe like on "normal" systems
<mvo> (expect for the isolation of course)
<tyhicks> I agree
<tyhicks> mvo: I can review the two MPs that you have proposed this afternoon (I am booked with meetings until then)
<sergiusens> Chipaca: that youtube link started what seems to be a nice playlist ;-)
<mvo> Chipaca, sergiusens: I leave in a bit to play hockey, if https://code.launchpad.net/~mvo/ubuntu-core-launcher/tmpdir-simplify-lp1462916/+merge/261419 and https://code.launchpad.net/~mvo/ubuntu-core-security/private-tmpdir-update/+merge/261396 gets a +1 it would be great if you could merge/upload them :)
<mvo> (sorry for dumbing work on you!)
<sergiusens> mvo: enjoy the game!
<Chipaca> mvo: crack some skulls! or curse mildly under your breath.
<ogra_> or both !
 * Chipaca didn't say xor
<Chipaca> sergiusens: you're welcome :)
<ogra_> aha ... there is the new image
<longsleep> nice, my ODROID told me that its going to update in 9 minutes
<Chipaca> longsleep: to reboot?
<longsleep> err it just updated - seems the clock is wrong :)
<longsleep> yes
<longsleep> going down for reboot now
<longsleep> how does that work. how does it detect new images that quickly?
<ogra_> i didnt know it does !
<ogra_> woah !
<longsleep> some thing called snappy autopilot
<ogra_> Broadcast message from root@localhost.localdomain (Mon 2015-06-08 16:02:03 UTC):
<ogra_> snappy autopilot triggered a reboot to boot into an up to date system-- temprorarily disable the reboot by running 'sudo shutdown -c'
<ogra_> The system is going down for reboot at Mon 2015-06-08 16:12:03 UTC!
<longsleep> yeah :D
<ogra_> without even asking me !!!
<Chipaca> longsleep: autopilot polls
<Chipaca> longsleep: it's got a systemd timer unit
<ogra_> thats pretty rude !
<longsleep> i see - can it be turned off? Privacy problem too :)
<damjan> systemctl disable ?
<ogra_> i didnt have any chance to stop it doing that
<Chipaca> longsleep: yes, i think you can disable it from u-d-f at least, but not entirely sure
<longsleep> i mean turn it off by default when building an image
<Chipaca> longsleep: what's the privacy issue?
<ogra_> oh, it tells me that over and over
<Chipaca> sergiusens: how did one disable autopilot?
<longsleep> whoever controls the server it polls from, knows about the snappy instance and the from address and whatever else is sent with the poll
<sergiusens> Chipaca: with snappy config
<Chipaca> ah, there ya go
<sergiusens> ogra_: longsleep Chipaca https://gist.github.com/sergiusens/8d4d2b99b2e5d87c7a50
<longsleep> sergiusens: great thanks!
<ogra_> sergiusens, lol, yeah ... here docs ...
<ogra_> so insane
<rsalveti> argh, my first router went down
 * ogra_ still doesnt get why we cnt just do: snappy config ubuntu-core autopilot=false
<Chipaca> ogra_: patches welcome ;)
<ogra_> but instead have to create a here doc to pipe into the command
<ogra_> Chipaca, well, i heard it was wanted like that
<longsleep> i would prefer to have it disabled by default / can be controlled on image building
<Chipaca> ogra_: actually i'd expect it to be something more like "snappy set ubuntu-core autopilot=false"
<Chipaca> although to me snappy $pkg set $blah makes more sense than the way it is now, but still
<ogra_> Chipaca, yeah !
<sergiusens> longsleep: just set it in the oem snap
<longsleep> sergiusens: i do not know enougth of that stuff yet - my package.yaml is https://github.com/longsleep/snappy-odroidc/blob/master/oem/meta/package.yaml
<longsleep> sergiusens: where would i set it?
<longsleep> sergiusens: a i think i get it
<longsleep> config: -> ubuntu-core: -> autopilot: false
<ogra_> snappy config
<ogra_> yeah
<sergiusens> longsleep: right under hostname
<longsleep> sergiusens: understood - thanks!
<ogra_> aha, my reboot just happened
<longsleep> my ODROID rebooted fine and is now on 80
<sergiusens> longsleep: just proposed the change
 * ogra_ waits to see what the RPi comes up with
<ogra_> *sniff* ... 79
<ogra_> and the reboot mmessage comes up right after reboot
 * ogra_ runs snappy update manually to see if that changes anything 
<ogra_> root=/dev/disk/by-label/system-a grmpf
<longsleep> ogra_: must be your u-boot
<ogra_> damn and now i'm in an autopilot reboot loop
<ogra_> sergiusens, is there a waqy to disable autopilot at image build time ?
<ogra_> this wont work for RPi users
<ogra_> oh superweird !
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep ^snappy_ab /boot/uboot/snappy-system.txt
<ogra_> snappy_ab=b
<longsleep> ogra_: why won't this work RPi users? It should if the U-Boot has all the features.
<Chipaca> sergiusens: https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 ready for a re-review
<longsleep> ogra_: check the snappy_mode value. If it is try, it can set snappy_ab to a before booting.
<ogra_> longsleep, yes, it can
<ogra_> longsleep, the issue is "why does it"
<ogra_> :)
 * ogra_ guesses that needs another day of inspecting ... sigh 
<ogra_> i thought i was done
<longsleep> because it finds the snappy_stamp file or your u-boot does not support test -e
<ogra_> i suspect the latter
<ogra_> but i wont dig into that today anymore
<longsleep> It was added quite recently
 * ogra_ will just roll an image now 
<longsleep> cmd_test: implement -e test for file existence (e5e897c01b1cd496187ca56a38ff5559d27f951c)
<ogra_> right and i cant use mainline on the RPi yet
<longsleep> I had the same issue with ODROID. Overwrote some of the commands from snappy-system.txt with commands from legacy U-Boot
<longsleep> See https://github.com/longsleep/snappy-odroidc/blob/master/oem/boot-assets/boot.ini#L31 - I use if fatexist instead of test -e
<longsleep> Check for this commit in your U-Boot http://git.denx.de/?p=u-boot.git;a=commit;h=e5e897c01b1cd496187ca56a38ff5559d27f951c
<ogra_> oh, even from stephen warren
<ogra_> and trivial too
<longsleep> yeah - but it might require another commit to the fat drivers, which are not trivial.
<longsleep> especially not if you do not have fs: add filesystem switch libary, implement ls and fsload commands (045fa1e1142552799ad3203e9e0bc22a11e866ea)
<ogra_> Unknown command 'fatexist' - try 'help'
<ogra_> gah
<longsleep> Thats implemented here: fat: implement exists() for FAT fs (b7b5f3195fa5a31ab1505e0c87054dc6dc71627b)
<ogra_> well, i uess i could just fall back to fatread
<ogra_> iirc we used that before
<longsleep> What U-Boot are they based on for the RPI2? Seems like its similar old than the one for ODROIDC. You might want to read my thread at http://forum.odroid.com/viewtopic.php?f=111&t=13924 where i list all the U-Boot features required to support snappy-system.txt
<ogra_> https://github.com/swarren/u-boot/tree/rpi_dev
<ogra_> not upstreamed yet
<ogra_> hmm, even though it spiled an error it switched me over
<ogra_> *spilled
<ogra_> anyway
<ogra_> thats for tomorrow ...
 * ogra_ rolls an image for now ... still better than what we had before 
<ogra_> i'll fix the rest tomorrow
<longsleep> i will be happy to learn how the snappy-system.txt can be improved to work better for old U-Boot's :)
<ogra_> longsleep, well, convince lool to not always use edge features of uboot :P
<longsleep> well, i had to port fatwrite which was total pain in the a.. - The ODROID u-boot is just hopeless. But the test -d change might not be in any U-Boot provided by hardware vendors as it is from 3 Feb 2014 and they tend to use much older stuff ..
<ogra_> but the test -e patch is tiny
<longsleep> on the other side i am not sure if a change from beginning of last year qualifies as edge feature
<ogra_> heh, for many boards it will :)
<longsleep> right, but most ARM U-Boots which are not upstreamed are based on 2011 U-Boot - which has none of these features.
<ogra_> yep
<longsleep> in any case, i suggest to add variables for the load save and exists commands to snappy-system.txt so the things can be customized seperately without having to overwrite the whole snappy_boot as i am currently doing.
<lool> longsleep, ogra_: hmm I dont remember using edge "features", more like "recent bugfixes"!  :-)
<lool> fatwrite was broke on some MMCs impls IIRC
<lool> but outside of that, it just a bunch of CONFIGs to turn on
<ogra_> lool, and test -e is brandnew :)
<lool> ogra_: ah did I use that in snappy-system?
<ogra_> hmm, or not
<ogra_> yeah
<ogra_> iirc we used to just have a fatload there initially
<lool> hmmm
 * ogra_ will have to dig up older images
<ogra_> anyway, thats for tomorrow ... i'm pushing the new image to my people.c.c now
<rsalveti> ogra_: cool, guess you're using image 80
<rsalveti> since I noticed it is already published
<ogra_> rsalveti, right ... just finishing the upload
<ogra_> rsalveti, but see above, needs more work to make snappy update work (and to make you not end up in an autopilot initialized reboot loop)
<longsleep> lool: Yes fat driver in older U-Boots has some problems. But those can be fixed easily while forward porting all the "new" commands is a lot of work, if you have to start from a totally messed up U-Boot from 2011. See my changes at https://github.com/longsleep/snappy-odroidc/blob/master/oem/boot-assets/boot.ini#L25 what i had to change.
<ogra_> longsleep, well, it would be nice to make porting easy for people ... i.e. without having to patch their bootloader
<longsleep> ogra_: yeah - as i suggested above, put the commands into variables and make these easily overwritable. Otherwise i suggest to use fatload, fatwrite and fatexist by default. I also could not use ${bootpart}.
<ogra_> yeah, i had that issue as well
 * ogra_ did the first odroid port ages ago
<longsleep> Also my u-boot requires uImage rather than vmlinuz which means the bootz needs to be a variable as well.
<ogra_> yep
<longsleep> ogra_: Why did you stop working with the odroid ?
<ogra_> because i had to stop my snappy work and go back to the phone
<ogra_> i recently changed teams and can now officially work on snappy :)
<longsleep> ogra_: i see :) - So maybe we see more and better ARM device support for snappy soon
<ogra_> hopefully :)
<ogra_> http://people.canonical.com/~ogra/snappy/odroidc/ that was my port from feb
<ogra_> (if you go one level up there are more)
 * longsleep takes a look
<ogra_> they all come from a pre-oem-snap time though
<lool> longsleep: problem is how would we support an old u-boot
<ogra_> not much useful anymore
<ogra_> lool, we dont need to support it
<lool> longsleep: if you know of backwards compatible alternatives to the commands we used, perhaps we could use these
<longsleep> ogra_: i was about to ask where is the OEM is
<ogra_> we just need to offer alternatives for people using older ones
<ogra_> ... when they port themselves
<ogra_> so it becomes easy for them to hack around missing features
<longsleep> lool: well - i pretty much like the new commands. But as i suggested, put them in variables so they can be easily replaced.
<longsleep> ogra_: a you are using something called flashtool-assets to split up the bootcode. I read somewhere about this but was not able to figure it out - do you have a link on this?
<ogra_> longsleep, that died with the invention of the oem snap
<ogra_> it nowadays is boot-assets in the snap iirc
<longsleep> ogra_: i see - i am now splitting up the bootcode on oem build and added it as raw-files with the correct locations. Felt a bit strange but seems like the way to go.
<Chipaca> sergiusens: you've got a conflict in lp:~sergiusens/snappy/noUpdateGrub
<longsleep> ogra_: Can you check on your RPi2 if any of the /var/lib/systemd mounts are writeable? mount |grep /var/lib/systemd
<sergiusens> Chipaca: no worries, we won't land this just yet :-P I'll merge trunk in any case
<Chipaca> awww
<Chipaca> was getting all exited here
<Chipaca> or excited
<Chipaca> on of those
<sergiusens> rsalveti: can you get https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/panic/+merge/261378 into wily?
<sergiusens> rsalveti: it seems it's already in the ppa for vivid
<ogra_> GODDAMNED !
<rsalveti> sergiusens: sure
<ogra_> did anyone else notice that opening paste.ubuntu.com in firefox nowadays flushes your paste buffer ?
<ogra_> so if i want to middle-click-paste in it i always end up with ".ubuntu.com"
<sergiusens> ogra_: no, I stopped using firefox ever since it started to randomly fail for me
<ogra_> heh
<Chipaca> pitti: when you have a moment, could you take a look at https://code.launchpad.net/~mterry/snappy/systemd-restart/+merge/261266 ?
<ogra_> seems the URL bear claims focus and highlights automatically now
<ogra_> which makes my selected text unselected in the terminal window ... and my middle click pastes whats in the URL bar
<ogra_> so annoying
<longsleep> how do i answer to Ubuntu store feedback? Buy mail? Or can i do it here as well? I do not seem to find a way to do it in the web portal.
<ogra_> longsleep, http://paste.ubuntu.com/11652938/
<ogra_> a bunch of systemd dirs are writable
<longsleep> ogra_: oh yours is actually there
<Chipaca> sergiusens: what's the state of https://code.launchpad.net/~sergiusens/snappy/frameworkPath/+merge/260202 ?
<ogra_> longsleep, mine ?
<longsleep> ogra_: oh no you posted the content of writeable-pahts
<Chipaca> ogra_: i too want a browser with a URL bear
<longsleep> ogra_: check which are actually mounted
<ogra_> longsleep, all of them i would hope :)
<longsleep> ogra_: none of them for me
<sergiusens> Chipaca: if I merge that we have a point of no return and need to introduce the backward<->forward hooks
<Chipaca> sergiusens: so, after .1
<ogra_> longsleep, hmm, right and they are also not in fstab
<ogra_> might be an initrd bug,m not sure
<longsleep> ogra_: Ok - thanks so thats the problem for https://bugs.launchpad.net/snappy/+bug/1462954
<ubottu> Ubuntu bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged]
<ogra_> longsleep, well, i thinnk there was more to that bug as i understood from pitti and mvo today
<ogra_> like ordering of the unit etc
<ogra_> (if it runs before fstab gets processed it wont work ...)
<longsleep> right - i just wanted to confirm that none of the /var/lib/systemd stuff is there - because other writable mounts are there - eg /etc/hosts
<sergiusens> Chipaca: yeah
 * ogra_ calls it a day ... (will write the announcement in a bit though)
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy/cmdline/+merge/261434 can you check if this seems reasonable from what we discussed?
<sergiusens> or rsalveti ^
<longsleep> so i guess the reason for the missing writable mounts is [ ! -e "$dstpath" ] && continue
<longsleep> essentially all writable mounts which not exist are skipped
<ogra_> yes
<ogra_> writable dirs/files are bind mounts ... so the mountpoint needs to exist
<longsleep> right - so this is a problem :) i do not see a quick workaround either
<longsleep> i am glad that i figured out how it works though ;-)
<ogra_> the fix is to ship an empty file :)
<rsalveti> sergiusens: it looks fine, can you also propose that for 15.04?
<rsalveti> if you didn't yet do it
<rsalveti> would probably be nice to have a short explanation why we need rootdelay in there, with a fixme or a bug
<rsalveti> not sure we got a bug for it, guess just the card
<longsleep> ogra_: right - so i hope this will be included with one of the next 15.04 releases.
<ogra_> sure
<sergiusens> rsalveti: I don't until the MP is merged, image is built and tested, but I can
<tedg> Where are the tools that build the OS snap?
 * tedg is trying to crib ideas
<Chipaca> sergiusens: checking...
<Chipaca> sergiusens: it does look sane. Want me to actually review?
<sergiusens> Chipaca: sure
<Chipaca> sergiusens: +1'ed with a suggestion
<rsalveti> Chipaca: if you can review the soon-to-appear-15.04-branch would be nice as well :-)
<Chipaca> rsalveti: NO >_<
<Chipaca> i mean, sure, just give me a shout
<rsalveti> :-)
<Chipaca> typo
<sergiusens> Chipaca: I thought  [ ] is more obvious, I can change if you want
<rsalveti> yeah, like the suggestion
<rsalveti> since grep returns 0/1
<rsalveti> using with $() also opens another shell call just for it
<Chipaca> sergiusens: spawning [ to spawn a shell to spawn grep seemed like a little too spawn-heavy for my test
<Chipaca> taste*
<sergiusens> Chipaca: there
 * Chipaca looks for more nits to pick
<sergiusens> Chipaca: I am not going to redo all of that script if that is your nit pick :-P
<sergiusens> Chipaca: keep in mind it's rm'ed in that other MP ;-)
<Chipaca> sergiusens: we should move to uboot instead
<Chipaca> sergiusens: make it so
<Chipaca> sergiusens: go go go :)
<Chipaca> by which i mean: it's +1'ed
<sergiusens> Chipaca: rsalveti should we test it works correctly in rolling first?
<Chipaca> +1
<Chipaca> +1.33
 * Chipaca used 1/3 of his spare +1
<rsalveti> sergiusens: sure
<rsalveti> I can trigger another image for rolling and we can see
<rsalveti> would be nice to have a test for this guy
<sergiusens> rsalveti: we can have a u-d-f based test that creates, grabs grub.cfg and checks; not sure where that would go though
<rsalveti> right, can't we have this as part of the self tests?
<Chipaca> sergiusens: wrt â// FIXME: we want to get rid of the current symlinkâ, i have no idea the context of that comment
<Chipaca> sergiusens: sounds like crazy talk to me :)
<sergiusens> Chipaca: it was relevant talk a while back :-)
<sergiusens> Chipaca: just remove the fixme :-P
<Chipaca> sergiusens: so i nuke it?
 * Chipaca aligns the satellite's reticle
<sergiusens> rsalveti: Chipaca as soon as this is in place https://code.launchpad.net/~snappy-dev/+recipe/snappy-daily-wily a new image build can be triggered
 * sergiusens needs to walk the dogs
<rsalveti> yeah, will take at least ~20 minutes
<rsalveti> utlemming: mind taking a look at https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/azure-datasource/+merge/260201 ?
<rsalveti> just noticed it's another pending mr we have
<utlemming> rsalveti: +1, looks good
<rsalveti> thanks
<rsalveti> sergiusens: let me know if you want me to land https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/azure-datasource/+merge/260201 into wily as well
<sergiusens> Chipaca: lol, no one spotted the obious mistake :-)
<Chipaca> sergiusens: obviously
<Chipaca> sergiusens: whitespace around =?
<sergiusens> Chipaca: yeah, and extra 's' in channels.ini
<Chipaca> sergiusens: my apolologies
<Chipaca> hmm
<rsalveti> indeed :-)
<rsalveti> sergiusens: merged and uploaded https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/panic/+merge/261378
<rsalveti> sergiusens: are you proposing another mr to fix these issues?
<sergiusens> rsalveti: yeah
<jdstrand> ogra_: hey, curious if the developer docs should be updated to point to your images?
<sergiusens> Chipaca: no need to apologise :-)
<sergiusens> Chipaca: rsalveti https://code.launchpad.net/~sergiusens/snappy/cmdline/+merge/261443
<sergiusens> I gave it a good whirl too on an azure and a regular amd64 image this time
<rsalveti> jdstrand: for rpi2? yes
<Chipaca> sergiusens: sorry for apologising
 * rsalveti waits for it to be merged
<jdstrand> rsalveti: yes, for rpi2
<jdstrand> glad to hear
<rsalveti> jdstrand: he will be publishing the final 15.04.1 image for it tomorrow iirc
<rsalveti> then we can update the docs
<jdstrand> great :)
<sergiusens> Chipaca: this is one of the reasons I don't like shell scripting...
<Chipaca> sergiusens: i *love* shell scripting!
<Chipaca> sergiusens: except for the part where it's cobbled together by drunk, horny monkeys
<Chipaca> or was that perl
<Chipaca> i forget
<sergiusens> rsalveti: triggered another build
<rsalveti> great
<sergiusens> package build that is
<rsalveti> sure
<Chipaca> $ echo | snappy config ubuntu-core -- -
<Chipaca> panic: reflect: call of reflect.Value.Type on zero Value
 * Chipaca having fun
<Chipaca> jdstrand: you around?
<jdstrand> Chipaca: yes
<Chipaca> jdstrand: have you been able to peek at mvo's branches?
<Chipaca> jdstrand: or are you deferring to tyhicks on that?
<jdstrand> for /tmp?
<Chipaca> jdstrand: yaarp
<jdstrand> I asked tyhicks to comment since he talked with you guys about all of it
<tyhicks> I've already reviewed them
<Chipaca> ok
<tyhicks> well, I reviewed the complete fix
<Chipaca> tyhicks: yep
<Chipaca> i saw yours, just wanted to check whether jdstrand was aware
<tyhicks> I don't see the benefit of the simple fix but let me know if I'm missing something
<jdstrand> tyhicks: so, I should upload the change to /tmp for ubuntu-core-security and upload?
<jdstrand> s/and upload$//
<tyhicks> jdstrand: ah, I didn't look at the ubuntu-core-security MP - looking now
<Chipaca> tyhicks: it gets confusing, this simplifies the logic, makes everybody use /tmp/
<Chipaca> tyhicks: that's all
<jdstrand> tyhicks: it basically just says /tmp/**
<jdstrand> tyhicks: I'm fine with the policy review, I just wanted to make sure you were ok with the concept
<jdstrand> where apparmor isn't enforcing the app isolation in /tmp
<tyhicks> jdstrand: I'm fine with it since the launcher will either successfully set up a private /tmp or the snap will not be launched
<rickspencer3> lool, does webcam-webui-snap have uploading capabilities?
<jdstrand> tyhicks: ok, then I'll do the upload
<lool> rickspencer3: no
<tyhicks> jdstrand: ack
<rickspencer3> lool, so, I want to upload a picture every hour or whatever period of time
<rickspencer3> would it make sense for me to just branch your project and add a binary that does that?
<Chipaca> tyhicks: will you be around a bit longer?
<Chipaca> tyhicks: i think i'll branch mvo's branch, fix the strdup check so we can land it
<Chipaca> tyhicks: if you're going to be here :)
<tyhicks> Chipaca: ack - I can do another review after you branch that
<lool> rickspencer3: sure! totally fine; I'm afraid I threw this together in a couple of hours some months ago and didn't touch it, but we should have a nicer and more complete example around this
<Chipaca> tyhicks: https://code.launchpad.net/~chipaca/ubuntu-core-launcher/tmpdir-simplify-lp1462916/+merge/261446
<tyhicks> looking
<Chipaca> ta
<tyhicks> Chipaca: approved :)
<Chipaca> huzzah, etc
<Chipaca> tyhicks: by which i mean: thanks! :)
<jdstrand> Chipaca: are you reading for me to upload ubuntu-core-security with the change in https://code.launchpad.net/~mvo/ubuntu-core-security/private-tmpdir-update/+merge/261396 to wily now?
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy/backportAz/+merge/261449
<jdstrand> ready*
<sergiusens> rsalveti: do we have a rolling image ready?
<Chipaca> jdstrand: i think we need to land https://code.launchpad.net/~chipaca/ubuntu-core-launcher/tmpdir-simplify-lp1462916/+merge/261446 in wily at the same time
<jdstrand> actually, there is no chance of regression
<Chipaca> jdstrand: actually, yeah, land that; the launcher will land later, and all will be well
<jdstrand> no, cause the rules are more open than before
<Chipaca> jdstrand: yeah, nothing will break :)
<jdstrand> right
<jdstrand> :)
<rsalveti> sergiusens: nops, was waiting the package to be published
<rsalveti> which seems to be the case already
<Chipaca> jdstrand: except for that pesky "security" thing
<Chipaca> but, it's wily
<rsalveti> let me build another image
 * jdstrand nods
<rsalveti> and check if the core-config migrated as well
<rsalveti> nah, still in proposed
<rsalveti> sergiusens: I'd assume we want to wait your core-config change as well
<rsalveti> so we can test everything
<sergiusens> rsalveti: which one, the one you set to needs fixing?
<rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-core-config/0.6.20
<sergiusens> that's not needed and not going to go into 15.04
<sergiusens> rsalveti: oh, yeah, that one is needed
<sergiusens> rsalveti: to test different things though
<rsalveti> right, guess I can just trigger an image now
<rsalveti> and trigger another later
<rsalveti> who knows how long it will take for this to migrate
<sergiusens> rsalveti: yeah, let's get things rolling :-)
<sergiusens> rsalveti: and that package is already in our vivid sources ;-)
<rsalveti> alright, just started a build for wily
<Chipaca> jdstrand: how does one _unload_ an apparmor profile?
<jjohansen> Chipaca: apparmor_parser -R <profile file>
<Chipaca> jjohansen: and is there something that'll remove the .json files and unload it all at once?
<jjohansen> or lower level  echo -n "<profile name>" > /sys/kernel/security/apparmor/.remove
<Chipaca> and any other artifacts
<asac> ogra_: pi2 \o/ ...
<Chipaca> ooh, almost RESTful :)
<asac> ogra_: does docker work well?
<jjohansen> Chipaca: .json files I am not sure about, as for all at once? I am not sure what you mean, all profiles, the profile and its children?
<Chipaca> jjohansen: i mean, the .json files, the file that is compiled to (json files are compiled to actual profiles, right?), and unloading from the kernel
<Chipaca> i ask because we don't seem to be doing that, whatever taht is
<Chipaca> maybe it needs doing one by one
<jjohansen> Chipaca: ah right, yes the json files get compiled to actual profiles
<jjohansen> afaik neither aa-clicktool nor aa-easyprof have options to clean out the json and profile files
<jjohansen> jdstrand: is there a packaging hook, or something for this
<ogra_> asac, i havent tried docker
<ogra_> asac, i only installed random snaps to make sure it doesnt break
<asac> ogra_: can you check?
<asac> might need a roundtrip of kernel flags
<ogra_> asac, not tonight ... but surely tomorrow morning
<asac> just install docker + owncloud :)
<asac> cool
<asac> thanks
<ogra_> asac, it isnt done yet anyway, needs a bit more love (as i said)
<ogra_> you end up in an endless reboot loop once autopilot installed an upgrade ...
<ogra_> (until you manually intervene)
<jdstrand> sorry, reading backscroll
<jdstrand> Chipaca: there is nothing to remove the .json file except package uninstall
<jdstrand> Chipaca: click handled all this for us in the past. ie, install a package, and click would drop a symlink in /var/lib/apparmor/clicks and aa-clickhook would handle loading the profile
<jdstrand> Chipaca: on uninstall, click would remove the json file and aa-clickhook would remove the profile. uninstall would *not* unload the profile from teh kernel (it would be gone after the next reboot)
<ogra_> asac, FYI http://paste.ubuntu.com/11656307/
<Chipaca> jdstrand: is there a reason for not removing it from the kernel?
<ogra_> i guess we could add devicemapper support to quieten that message ... installs fine (no idea what to do to check it works)
<Chipaca> sergiusens: thanks for +1'ing the launcher thing
<ogra_> asac, the log ... so yes, devicemapper stuff needed http://paste.ubuntu.com/11656370/
 * ogra_ goes back to watch the womens football world championship ... :) 
<rsalveti> sergiusens: waiting system-image importer
<rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.0.1-0ubuntu1build1 should hopefully unblock ubuntu-device-flash
<jdstrand> Chipaca: because application lifecycle on touch couldn't guarantee that the app was stopped and not running when it was uninstalled
<Chipaca> ah, ok
<Chipaca> we can't guarantee that either, but we can guarantee it'll stop working :-p especially if we unload its apparmor
<asac> ogra_: ack. thanks
<jdstrand> the idea is that if it continues running, all of a sudden the profile is removed and it is unconfined. yes, next start it wouldn't start up (touch guaranteed that too), but it was that window of it potentially continuing to run after uninstall
<Chipaca> jdstrand: ah, no profile == unconfined?
<Chipaca> jdstrand: i thought no profile == no access
<jdstrand> yes
<jdstrand> no
<Chipaca> jdstrand: so we probably don't want to do that then
<jdstrand> you can think of apparmor as targeted policy
<Chipaca> untill we kill everything on uninstall
<jdstrand> only what you define as confined is confined
<Chipaca> a'ight
<jdstrand> we could flip that around with full system confinement, but that is a very difficult prospect. maybe some day
<Chipaca> jdstrand: there are already scenarios that make us want to have a way to kill the app
<jdstrand> removing the cache file and the profile (and the json) but leaving the profile in the kernel is fine
<Chipaca> so we probably want to look into that, and if we do go that route, unloading is an option again
<Chipaca> meanwhile, just removing jsons and such should be enough
<jdstrand> maybe, yes
<jdstrand> we'd have to be super sure we did it right
<Chipaca> jdstrand: at what point during boot do old profiles get loaded?
<jdstrand> leaving it in the kernel isn't a big deal
<jdstrand> Chipaca: the old profiles can't on reboot-- the cache and the profile is gone
<jdstrand> so then the launcher will correctly fail to change profile and bail
<Chipaca> jdstrand: at what point during boot do the .json files get converted to profiles? :)
<jdstrand> and the json, yes
<jdstrand> the json has to be gone too
<jdstrand> but profiles get loaded before apps are allowed to start
<jdstrand> right now, that is via a systemd dependency
<jdstrand> there is more systemd/apparmor work to do that will change things a bit (they will load even earlier if the cache exists)
<sergiusens> rsalveti: it says failed for ppc though :-P https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.0.1-0ubuntu1build1
<rsalveti> sigh
<sergiusens> rsalveti: I'll check when I get back tonight
<rsalveti> *** Test killed with Quit: ran too long (10m0s).
<rsalveti> yeah, still no good
<Chipaca> jdstrand: the thing is i'm looking into regenerating the jsons on boot, for all packages (maybe not on every boot, but)
<sergiusens> rsalveti: ooh, differnet error
<rsalveti> let me retry the build once at least
<jdstrand> Chipaca: why are you looking at that? that will all change once apparmor does something more like seccomp, no?
<Chipaca> jdstrand: so i probably don't need to worry about unloading things at that point anyway
<jdstrand> Chipaca: if you were going to fiddle with apparmor stuff, I'd suggest getting rid of the click compat bits
<jdstrand> :)
<Chipaca> jdstrand: because if we change the way snappy generates some of these artifacts, we need to regenerate them at least the first boot after snappy update
<Chipaca> jdstrand: so i'm looking at regenerating all the artifacts, not just apparmor
<Chipaca> jdstrand: trying very hard not to get side-tracked with big cleanups while doing so (not succeeding entirely)
<jdstrand> Chipaca: you are going to want to be careful with regenerating the json files then. the mtime of the symlink in /var/lib/apparmor/clicks is examined by aa-clickhook to know if it should regenerate the profile
<Chipaca> mhmm
<jdstrand> Chipaca: I'm not sure what really needs to be regenerated here... the only thing that is there is a symlink to something installed by the snap
<Chipaca> jdstrand: so, basically, i'm trying to make sure that deactivating and reactivating a package does everything it should, such that regeneration is no more than deactivating and reactivating everything (in the right order for frameworks and apps)
<jdstrand> (this also all applies to aa-profilehook and the /var/lib/apparmor/snappy directory, which operates like /var/lib/apparmor/clicks, but for profiles)
<jdstrand> what does 'deactivating a snap' mean?
<Chipaca> jdstrand: in particular i'm aware of apparmor because due to a bug wily is not currently generating the .json files
<Chipaca> jdstrand: and we didn't realise because we aren't cleaning them up
<Chipaca> jdstrand: that it's not active :-p
<jdstrand> so installed but not active?
<Chipaca> jdstrand: where active means its bins is in /apps/bin, its services are running, and it's generally ready for use
<jdstrand> I didn't think we supported that
<Chipaca> jdstrand: not user-facing, no
<Chipaca> jdstrand: but when you update, the old version is deactivated, the new one activated
<Chipaca> jdstrand: if the activation fails, rollback is simply reactivating the old one
<jdstrand> I fairly confused by what you want to change wrt apparmor as it exists today
<jdstrand> that said, I was not aware of these wily issues
<jdstrand> I thought we were already doing the things you mentioned
<Chipaca> jdstrand: i'm not sure what i need to do either :) i need that everything that is installed has the apparmor (and other bits) as if the current version had installed it
<jdstrand> so one thing to keep in mind, click-apparmor will remove a dangling symlink in these directories
<jdstrand> ie, it cleans up when a snap is uninstalled
<Chipaca> right
<Chipaca> jdstrand: i think the best thing would be for me to write it down in an email
<Chipaca> jdstrand: i'm not sure how much sense i'm making at this point
<jdstrand> ok
<jdstrand> well, it is probably me lacking context
<jdstrand> actually, I'm not sure click-apparmor will remove the dangling symlink
<Chipaca> jdstrand: possibly. If i were more awake i'd probably be able to muddle through :)
 * jdstrand looks
<Chipaca> jdstrand: but i'll write out the email in the morning
<Chipaca> and we can chat after
<jdstrand> tomorrow is going to be hard to catch me during your core hours
<jdstrand> (meeting and a lot of preparations for it)
<jdstrand> but yeah
<Chipaca> jdstrand: my core hours remain spread wider than usual for people in my timezone :)
<Chipaca> jdstrand: anyway, i'm not blocked (yet), so no worries
<jdstrand> ack
<rsalveti> sergiusens: failed same way even after a rebuild
<rsalveti> slangasek: ubuntu-snappy is still unhappy on powerpc, but failing when executing the tests now: https://launchpadlibrarian.net/208607597/buildlog_ubuntu-wily-powerpc.ubuntu-snappy_1.0.1-0ubuntu1build1_BUILDING.txt.gz
<slangasek> rsalveti: ok.  any reason to not just delete the powerpc binaries for now, given that this isn't a supported arch?
<rsalveti> no specific reason, guess we could just disable the tests for it, that will at least let it building
<longsleep> Can someone please point me to the latest apparmor git tree?
<slangasek> rsalveti: I'd prefer deleting the binaries to disabling the tests :)
<rsalveti> slangasek: fine by me
<rsalveti> sergiusens: ^
<rsalveti> guess we'd need a package change to not build for it then
<slangasek> no
<rsalveti> oh, just to avoid it not being promoted
<slangasek> just leave it FTBFS on powerpc for now
<rsalveti> even better
<rsalveti> forgot we had that option
<slangasek> that won't block it from being promoted, that's why we delete the old binaries
<rsalveti> same for https://launchpad.net/ubuntu/+source/goget-ubuntu-touch then
<rsalveti> since that's blocked waiting ubuntu-snappy
<slangasek> and if this is a toolchain bug, which seems likely, if and when the toolchain is fixed you get the package back for free
<rsalveti> right
<jdstrand> longsleep: I think you may want to talk to ogra_, but he is eod
<jdstrand> longsleep: actually, I see https://developer.ubuntu.com/en/snappy/guides/porting/ references 'Kernel requirements for Snappy (ubuntu and vanilla/android)'
<longsleep> jdstrand: yeah but that seems outdated - http://kernel.ubuntu.com/git/jj/ubuntu-vivid.git/log/?h=apparmor is the latest i could find
<longsleep> but this here has some changes i do not see http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_odroidc and i wonder where these come from
<jdstrand> longsleep: are you wanting to work with a kernel version newer than 3.19?
<jdstrand> yeah, I'm not sure
<longsleep> jdstrand: no - i have Kernel 3.10
<jdstrand> ogra_ has done this a few times. we might need to get https://wiki.ubuntu.com/SecurityTeam/AppArmorForSnappyKernels updated
<longsleep> right, i am tempted to just take the ppisati kernel and rebase it to latest from hardkernel
<longsleep> but i want to understand where the Apparmor comes from too
<jdstrand> longsleep: in short, apparmor is in the upstream kernel, however Ubuntu has a (rather large) delta that we are in the process of upstreaming. the ubunta archive kernels and the phablet kernels on the page should all be up to date
<longsleep> i guess i just found http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/
<jdstrand> I can't speak to the ppisati kernel
<longsleep> which looks promising
<jdstrand> jjohansen: can you tell longsleep where to find the latest apparmor patches or recommend what tree to look at if he is enabling a 3.10 kernel?
<jdstrand> longsleep: jjohansen may be able to make that recommendation, but waiting for ogra_ for how to port for snappy specifically is going to be the best bet
<longsleep> jdstrand: yeah i spoke to ogra_ earlier today already
<slangasek> rsalveti, sergiusens: ok, looking more closely I see that the blocker is that goget-ubuntu-touch won't update, because it builds on powerpc but is uninstallable.  So it seems the version of udf in wily doesn't have this dependency
<slangasek> so for /that/ problem, we don't want to just remove the powerpc binary of udf because the next rebuild will just bring it back.  Options are: make the udf dependency on ubuntu-snappy-cli arch: dependent (omitting it on powerpc); make goget-ubuntu-touch build-depend on ubuntu-snappy-cli so that it will be dep-wait, then remove the old binary; make udf specify its architecture list and remove the old binar
<slangasek> y
<jjohansen> longsleep: it is best to just pull them out of the ubuntu kernel trees atm, that patchset is maintained and gets patches on it, the upstream set is in development
<jjohansen> longsleep: so git://kernel.ubuntu.com/ubuntu/ubuntu-vivid
<jjohansen> just git log security/apparmor
<jjohansen> longsleep: actually you will want s/ubuntu-vivid/ubuntu-willy/
<rsalveti> slangasek: yeah, makes sense, thanks for looking into that
<sergiusens> rsalveti: slangasek if I go with dep-wait
#snappy 2015-06-09
<rsalveti> sergiusens: there should be a new image for both rolling and 15.04
<rsalveti> including your changes
<rsalveti> sergiusens: do we need any extra udf change for azure or is it going to consume the grub data from the rootfs?
<sergiusens> rsalveti: I already tested in the card
<sergiusens> rsalveti: https://trello.com/c/YkdrYyX6/79-rootdelay-300-for-azure-images
<rsalveti> oh, great
<rsalveti> sergiusens: for udf just do one of the options slangasek gave and we should be fine
<sergiusens> rsalveti: I'm going with this one http://paste.ubuntu.com/11659708/
<rsalveti> great, easy enough
<sergiusens> slangasek: rsalveti I think it needs manual intervention still http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<sergiusens> delete the powerpc binaries I guess
<rsalveti> right, hopefully slangasek can give us a hand with that
<slangasek> sergiusens, rsalveti: correct; looking at it now
<slangasek> binaries removed
<trey-gordon> qrl?
<trey-gordon> hello?
<tbr> good moaning
<trey-gordon> how can I begin porting snappy to my desktop
<trey-gordon> not like running it virtualized, but actually standalone, with mir or something
<pitti> Chipaca: replied to the MP, LGTM
<seb128> hey there, does anyone know how to build a working image from device and rootfs tarballs?
<mvo_> seb128: ubuntu-device-flash will do that, but it will use the system-image server, so it needs to be imported there first
<seb128> mvo_, no way to do that locally?
<seb128> mvo_, we got a working desktop-next build
<seb128> mvo_, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29166
<mvo_> seb128: that is a good question
<seb128> not sure what to do from the generated files though now ;-)
<mvo_> seb128: sergiusens will know if thats possible to do it locally you could shove it into system-image (create a temp channel or something)
<seb128> mvo_, well *I* can't I guess, somebody needs to do it for me
<seb128> but it's not very handy for local testing
<mvo_> seb128: agreed
<seb128> mvo_, when is sergiusens usually online?
<mvo_> seb128: sergio will be around in ~4h or so
<seb128> k, thanks
<dholbach> good morning
<seb128> hey dholbach
<seb128> dholbach, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29166 for you
<dholbach> thanks seb128! :)
<dholbach> popey, ^
<seb128> dholbach, here is a first working personnal build, good luck trying to make an image from it to put on a device :p
<seb128> dholbach, joke aside, waiting for sergiusens now to see how to transform those tarballs in an img that one can dd to a stick
<dholbach> cool
<fgimenez> good morning
<dholbach> hi fgimenez, hi willcooke
<fgimenez> hey dholbach
<willcooke> hi dholbach
<mvo_> seb128: we need to talk about how we can share code, I am about to fix a bug in one of the hook scripts for ubuntu core and you will have to do exactly the same fix - maybe you can simplify symlink for hooks that are unchanged?
<dholbach> mvo_, which ppa am I supposed to be using, is it beta?
<dholbach> with beta I get this:
<dholbach>  ubuntu-snappy : HÃ¤ngt ab von: ubuntu-snappy-cli (= 1.0.1-0ubuntu1build1) aber 1.0.1-1+439~ubuntu15.04.1 soll installiert werden
<mvo_> dholbach: yeah ppa:snappy-dev/beta (confusing, right)
<mvo_> dholbach: please only install ubuntu-snappy-cli
<dholbach> ok
<fgimenez> good morning mvo_, have a minute?
<mvo_> fgimenez: sure
<mvo_> fgimenez: good morning!
<fgimenez> mvo_, :) i'm getting today this output from u-d-f http://paste.ubuntu.com/11666666/
<fgimenez> mvo_, not sure if it may be related to some misconfiguration on my side?
<mvo_> fgimenez: *ick* let me see if I can reproduce. what version of ubuntu-device-flash are you using right now? I wonder if there was a new version recently
<mvo_> fgimenez: this looks a lot like "upstream"
<mvo_> fgimenez: I'm curious about the version and the ppa you use so that I can try to figure out more
<seb128> mvo_, yeah, symlink would make sense, Colin had some comments about that on the merge request for desktopnext, unsure why didrocks didn't do it though
<fgimenez> mvo_, http://paste.ubuntu.com/11666692/ no ppa, just wily
<mvo_> fgimenez: aha, I think thats the culprit then, hold on a sec, Chipaca fixed this probably but u-d-f will need a rebuild
<fgimenez> mvo_, ok thx! can i use some ppa in the meantime?
<mvo_> fgimenez: yes - https://launchpad.net/~snappy-dev/+archive/ubuntu/tools should work
<mvo_> fgimenez: I will do a rebuild in the meantime in wily
<fgimenez> mvo_, ack, i'll try it thanks! :)
<mvo_> fgimenez: uploaded, should be in the archve later today
<mvo_> (the fix)
<fgimenez> mvo_, mm i'm not able to install the package from the ppa, it seems that there was a problem with the build https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/+packages
<fgimenez> mvo_, this is what i get from apt-get update after adding the ppa repository http://paste.ubuntu.com/11666876/
<mvo_> fgimenez: one sec, let me see if I ca nfix it
<fgimenez> mvo_, thx, no rush at all
<mvo_> fgimenez: should be in the ppa now
<mvo_> fgimenez: well, might take some minutes until its published but I copied it to the wily pocket now
<longsleep> Morning folks, maybe now somebody here to point me to the head tree of Apparmor3 / latest version / patches?
<JamesTait> Good morning all; happy Cars Day! ð
<ogra_> asac, FYI http://paste.ubuntu.com/11667823/ (needed a depmod run, i need to see why thats not in the package)
<fgimenez> mvo_, ok, i have u-d-f 0.22-1+177~ubuntu15.04.1 properly installed :) but i'm still getting the same error http://paste.ubuntu.com/11667736/
<ogra_> hmm, owncloud has a broken icon in webdm
<asac> ogra_: phenomenal :) ... yay!
<asac> just ping me and ricmm when the new image up :)
<asac> that works great
<ogra_> how do i test it ? i have never used owncloud
<asac> thanks so much
<mvo_> fgimenez: meh, ok, let me try harder
<asac> just check the website is working
<ogra_> on which port ? webdm doesnt show any info
<ogra_> oh
 * ogra_ notes 80 in the docker cmdline
<ogra_> bah, lies
<ogra_> aha 443 works
<ogra_> nice !
<mvo_> fgimenez: hm, odd. this appears to be working for me (wily with u-d-f from ppa:snappy-dev/tools). anything unusual on your system? ecryptfs? tmpfs for /tmp or anything that you could think of thats might give a clue?
<fgimenez> mvo_, nothing special, this was working as of yesterday
<mvo_> fgimenez: ok, maybe you can downgrade to the version in ppa:snappy-dev/beta? thats 0.20-something ? and then we tak to sergiusens if he has a idea
<longsleep> ogra_: can you point me to the git tree i should use for backporting Apparmor3 to my kernel. I would use http://kernel.ubuntu.com/git/jj/ubuntu-vivid.git/log/?h=apparmor , but the tree at http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_odroidc seems to contain a bunch of additional patches. Any idea?
<jjohansen> longsleep: it needs the additional patches
<jjohansen> well the backport does
<longsleep> jjohansen: Thanks! But where do they come from?
<fgimenez> mvo_, ok thanks
<ogra_> longsleep, well, i always used ppisati's tree for that
<ogra_> git clone -b snappy_odroidc git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git
<ogra_> (see http://people.canonical.com/~ogra/snappy/odroidc/README)
<jjohansen> how the apparmor backport works, is it starts with the base apparmor patchset and then on top of that the backport patches are applied
<longsleep> ogra_: Right, but i would prefer to understand where the patches actually come from first.
<ogra_> but i guess that has fallen behind a bit
<ogra_> longsleep, that you have to ask ppisati ... i was only a consumer of his tree
<jjohansen> yes we need to update the backports kernel tree, I just haven't found the time to do it yet
<ogra_> (for my first tests i used unpatched BSP kernels, he added the magic for me)
<longsleep> jjohansen: all right, so the source is somewhere internal for eg apparmor: 3.12 backport mtd: Move major number f83c3838
<jjohansen> longsleep, give me a sec, I have a repo that is the basis of those patches
<jjohansen> and yes it needs to be updated as well
<jjohansen> longsleep: http://kernel.ubuntu.com/git/jj/ubuntu-utopic.git/
 * longsleep takes a look
<jjohansen> you can see there are android kernel branches like goldfish-aa3-backport
<longsleep> yes
<jjohansen> and goldfish-aa3-presquash
<longsleep> so in some of these branches are the backport fixes?
<jjohansen> the presquash branches have the backport patches split out
<longsleep> got it - awesome thanks
<jjohansen> yes, you can see the individual changes, and they document which kernel changes they are adjusting for
<longsleep> i guess i can use that
<longsleep> this means i grab apparmor3 rc1 tag, and the additional patches with numbers greated than the kernel i base on correct?
<jjohansen> longsleep: updating this to a new better tree against an updated 3.1 kernel is on my todo list
<jjohansen> longsleep basically
<longsleep> jjohansen: thanks - i guess i have an idea now. Lets see how it goes :)
<jjohansen> how I usually do a backport, is take the whole apparmor dir with the snapshot I want, say from ubuntu-vivid
<jjohansen> just copy the whole dir, over the old apparmor dir, and git add it
<jjohansen> that avoids all kinds of merge conflicts
<longsleep> jjohansen: yes that is how the docs suggest to do it too.
<dholbach> mvo_, should I be worried: http://pastebin.ubuntu.com/11667946/?
<jjohansen> then I apply the backport patches on top, working my way backwards
<longsleep> jjohansen: meaning you start with newer patches first?
<jjohansen> backwards as in 2.10, then 2.9, then 2.8 backport patches, it is the order that the presquash trees use
<jjohansen> yes
<mvo_> dholbach: it sounds alarming, but should be ok
<longsleep> all right that is really helpful stuff
<jjohansen> longsleep look at the commit messages for the backborts it will be things like revert 2.10 xxx
<mvo_> dholbach: its the error that there is a clickpkg user already
<dholbach> I don't know...
<dholbach> do you need a bug for it or should I ignore it?
<jjohansen> longsleep: so if you backport to 3.2 you will have a longer patch list than say going back to 3.10
<mvo_> dholbach: either is fine, feel free to file a bug
<longsleep> jjohansen: yes i see that. I need to get the stuff in Kernel 3.10 - so there are only two required as i can see
<dholbach> thanks mvo_, will do
<mvo_> ta
<jjohansen> longsleep: hrmm, well that depends on where you start from, vivid and wily have one more patch that needs reverted, I haven't done a backport for that yet
<longsleep> jjohansen: does it matter where i start from, or can i start say from trusty as well?
<jjohansen> longsleep: vivid and wily are the same, vivid is almost the same as utopic and utopic is a big step over trusty
<longsleep> jjohansen: ok - a big step for apparmor? But for snappy i it should be vivid/wily ?
<dholbach> mvo_, bug 1463329
<ubottu> bug 1463329 in ubuntu-snappy (Ubuntu) "/nonexistent does not exist, system user clickpkg exists" [Undecided,New] https://launchpad.net/bugs/1463329
<jjohansen> longsleep: yes for snappy I would start from vivid/wily.
<longsleep> jjohansen: all right - i have the plan then.
<jjohansen> longsleep: if you can wait a day I will try to get a vivid and wily backport up today
<longsleep> jjohansen: yeah - i will continue to work on it tonight CEST
<longsleep> by the way, i suggest that 3.10 upstream Kernel should be a default backport target for apparmor3 as many ARM device Kernel trees are based on 3.10.
<jjohansen> yep
<ogra_> sergiusens, hmm, is there a way to disable autopilot from u-d-f ? that would really be handy when building for unsupported arches
<longsleep> ogra_: i learned you can disable it in the oem snap.
<ogra_> oh
<longsleep> ogra_: just add autopilot: off to ubuntu-core section or something
<longsleep> cant remember the exact details
<longsleep> ogra_: autopilot: false it was
<longsleep> ogra_: below ubuntu-core tree in config section of package.yaml
<pitti> hm, what am I doing wrong with u-d-f? http://paste.ubuntu.com/11668527/
<ogra_> pitti, looks like the wily bug with go i hit yesterday
<ogra_> are you running that on wily ?
<pitti> yes
<ogra_> that might be it then
<mvo_> dholbach: ta
<pitti> . o O { is there anything else? } :)
<ogra_> someone said wily's go is screwed
<pitti> ogra_: ah, I'll try u-d-f from vivid then?
<ogra_> yeah
<pitti> thanks ogra
<pitti> ogra_: that fails differently
<ogra_> weird
<pitti> 2015-06-09 09:57:48 ERROR snappy logger.go:199 generic-amd64 failed to install: snappy package not found
<pitti> generic-amd64 failed to install: snappy package not found
<ogra_> it should be self contained i thought
<pitti> the "snappy" command exists
<ogra_> oh, you might also need the snappy from vivid
<pitti> (I opened a schroot and installed u-d-f
<ogra_> it is go as well :)
<pitti> ah, not just ubuntu-snappy-cli then
<pitti> hm, not the "snappy" package for sure
<pitti> mvo_: ok, if you can tell me how one creates a snappy image these days, I'll look at bug 1462954
<ubottu> bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged] https://launchpad.net/bugs/1462954
<fgimenez> mvo_, i've finally got u-d-f working pheww :) it was related to the version of ubuntu-snappy-cli in wily
<fgimenez> mvo_, downloading and installing it from here http://packages.ubuntu.com/vivid/ubuntu-snappy-cli works again, don't ask me why :)
<pitti> fgimenez: oh, you have that problem as well? how did you flash snappy?
<pitti> fgimenez: (see my backscroll from 5 mins ago)
<pitti> fgimenez: so that's u-d-f from wily plus ubuntu-snappy-cli from vivid?
<fgimenez> pitti, i was unable to use u-d-f in wily, this was the error http://paste.ubuntu.com/11667736/
<pitti> fgimenez: yep, exactly what I got and asked
<fgimenez> pitti, yep, ubuntu-snappy-cli 1.0.1-0ubuntu1build1 seems to be somehow broken
<pitti> fgimenez: I tried u-d-f (and u-snappy-cli) from vivid, and that fails too
<fgimenez> pitti, unstalling u-snappy-cli and installing vivid's deb worked for me
<pitti> I still get "generic-amd64 failed to install: snappy package not found"
<pitti> grep -r 'package not found' in goget-ubuntu-touch doesn't have any results
<fgimenez> pitti, it seems to be a different error, mine was "generic-amd64 failed to install: unpack /tmp/generic-amd64310762128 to /tmp/oem535521461/oem/generic-amd64/1.1.1 failed with exit status 1"
<pitti> fgimenez: right, I got that with wily's ubuntu-snappy-cli, now I downgraded to vivid's
<pitti> ok, I installed parted and ca-certificates, and now it's "generic-amd64 failed to install: exit status 2"
<Chipaca> pitti: what're you doing?
<pitti> Chipaca: I'm trying to build a snappy VM image with u-d-f
<Chipaca> pitti: which u-d-f are you using?
<sergiusens> ogra_: needs to be in the oem config
<pitti> Chipaca: first I tried wily's, which fails with //paste.ubuntu.com/11667736/ (for ogra, fgimenez and me)
<pitti> Chipaca: then I tried in vivid, where it first failed with "generic-amd64 failed to install: snappy package not found"
<Chipaca> sergiusens: is wily's u-d-f the same as the tools ppa's?
<pitti> Chipaca: then I installed parted and ca-certificates which got it a bit further, but now it fails with "exit status 2"; that's even with --verbose
<sergiusens> Chipaca: no, it was let through last night
<Chipaca> pitti: you need the tools ppa's one, i guess
<sergiusens> Chipaca: what fails is snappy unpack which is using go 1.4
<Chipaca> certainly on vivid
<Chipaca> sergiusens: but that's fixed
<pitti> it used to work with vivid's version a few months ago (when vivid was still devel)
<sergiusens> Chipaca: in wily?
<sergiusens> Chipaca: as in, in wily with no ppa?
<Chipaca> sergiusens: oahdunno
<Chipaca> sergiusens: but it was failing with vivid's too
<pitti> ok, which PPA should I add?
<Chipaca> pitti: i don't think it's ever worked with vivid's since i've been on the project
<Chipaca> pitti: which is... ok, a few months, but with few > 3 i think
<pitti> it seemed to work for fgimenez to use vivid's ubuntu-snappy-cli, but I suppose u-d-f is missing a dependency or so
<pitti> for sure it's missing parted and ca-certificates
<ogra_> pitti, not for me, i had the snappy errors on a wily image
<Chipaca> $ cat /etc/apt/sources.list.d/snappy-dev-ubuntu-tools-vivid.list
<Chipaca> deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu vivid main
<pitti> is there a --verboserer?
<Chipaca> pitti: ^^
<pitti> Chipaca: thanks
<ogra_> (i build my images on a trusty machine ... so i have no build issues here)
<sergiusens> pitti: ca-certificates yes, parted no http://paste.ubuntu.com/11669751/
<sergiusens> hmm, ubuntu-snappy-cli also misses the dep on ca-certificates
<fgimenez> Chipaca, sergiusens pitti in my case downgrading ubuntu-snappy-cli from 1.0.1-0ubuntu1build1 (wily) to 1.0.1-0ubuntu1 (vivid) worked, tested with u-d-f from the archive and from the ppa
<sergiusens> fgimenez: thanks for confirming
<pitti> 2015-06-09 11:08:41 ERROR snappy logger.go:199 generic-amd64 failed to install: exit status 2
<pitti> still the same with the PPA
<pitti> $ sudo ubuntu-device-flash core --output=/tmp/snappy.img --developer-mode --channel=edge rolling
<sergiusens> mvo_: can you release a new ubuntu-snappy into wily?
<pitti> same with "--channel=stable 15.04"
<davidcalle> ogra_, hello, do you want us to start updating the raspi2 section with your image on https://developer.ubuntu.com/en/snappy/start/ or do you think it's better to wait a little for user feedback?
<pitti> is there a $DEBUG/--debug or so?
<sergiusens> pitti: only --verbose: u-d-f --verbose core rolling ...
<ogra_> davidcalle, we should wait for the actual release ... i also plan to push it to http://people.canonical.com/~platform/snappy/ instead of hosting it in my homedir
<pitti> sergiusens: I have that already, but it doesn't say much, just http://paste.ubuntu.com/11669805/
<davidcalle> ogra_, actual release as in "official image"?
<sergiusens> pitti: but I suspect you are going to have issues with ubuntu-snappy-cli
<ogra_> davidcalle, as in the 15.04.1 release for the rest of the world :)
<davidcalle> ogra_, yay :)
<gatisp> Hello, I was wondering could somebody clarify steps 2 and 3 from https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/#updating-the-system
<ogra_> davidcalle, BBB and amd64 images will soon have a point release
<sergiusens> seb128: I'm online
<gatisp> "Apply the latest system image to the other root partition."
<gatisp> I assumed the only time when this can be done is from initramfs during boot? because you have to remount read-only partition to read-write
<gatisp> is that correct?
<pitti> [pid 21480] connect(3, {sa_family=AF_LOCAL, sun_path="/run/udev/control"}, 19) = -1 ENOENT (No such file or directory)
<pitti> [pid 21480] close(3)                    = 0
<ogra_> gatisp, that is how it works, yes
<pitti> [pid 21480] exit_group(2)               = ?
<longsleep> pitti: why did you repeat the same comment on bug 1462954 ?
<ubottu> bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged] https://launchpad.net/bugs/1462954
<pitti> sergiusens: ^ ah, this might be it? it used to work in a schroot, but maybe not any more
<sergiusens> seb128: mvo_ no easy mechanism for local testing, but livecd-rootfs local building isn't easy to do either
<pitti> longsleep: sorry, pressed enter accidentally, and firefox still had my last reply in the input box
<longsleep> pitti: ah - i was just wondering if i was wrong about the problem.
<gatisp> ogra_, ok but then docs are are bit confusing, at least when I read it :) because the next steps says "Update the bootloader configuration such that the next boot.."
<gatisp> ogra_, but what it actually means is not the next boot
<gatisp> but the ongoing boot?
<ogra_> gatisp, after "flashing" the bootloader needs to be told to bot from the new partition
<ogra_> *boot
<gatisp> ogra_, but doesn't all the happen from the same boot sequence?
<ogra_> no
<ogra_> oh, wait, the unpacking on upgrade doesnt actually happen from the initrd ... that happens indeed from the running system before the reboot
<ogra_> (sorry, my brain was thinking phone updates :) )
<sergiusens> ogra_: we have inOS updates here
<ogra_> yeah
<gatisp> so it unpacks in some read-write partition first?
<sergiusens> gatisp: it's like solaris' live upgrade mechanism
<ogra_> it uses three partitions
<ogra_> a is the one you run from ... readonly
<ogra_> then you have a rw partition for all the writable bits you need
<ogra_> and then there is b ... b is unmounted when you run from a
<ogra_> so you can mount it and unpack your stuff
<ogra_> then tell the bootloader about that and reboot
<sergiusens> ogra_: it's actually mounter in /writable/cache/system (we are getting rid of 'cache' in that path though)
<ogra_> ah, i didnt know
<ogra_> i thought we dynamically mount it
<pitti> Chipaca, sergiusens: FTR, bind-mounting /run into the schroot helped; now it's working (in vivid)
 * pitti pats strace
<Chipaca> pitti: ot1h, awesome; otoh, why didn't it work wihtout that?
<gatisp> ok, that clarifies some things, in me head I saw A and B both mounted as read-only at all times when system is running
<pitti> Chipaca: I don't know; it used to a few months ago, but not any more
<gatisp> sergiusens, "/writable/cache/system" is that part open sourced somewhere?
<sergiusens> gatisp: what does "open sourced" somewhere mean?
<gatisp> I mean can I see that code :)
<sergiusens> gatisp: lp:snappy
<gatisp> where is that? its my first time here
<ogra_> bzr branch lp:snappy
<sergiusens> gatisp: http://launchpad.net/snappy
<ogra_> running that on an ubuntu system gets you the source
<gatisp> ok, thanks, I will take a look
<ogra_> (or use a browser to browse it with sergiusens' url)
<sergiusens> ogra_: I bet if someone doesn't know what lp: is, less they know of bzr :-P
<ogra_> true true
<sergiusens> these days they are equivalent to the sme thing :-)
<pitti> longsleep: indeed, works perfectly when touching the file, thanks! (<- mvo)
<Chipaca> sergiusens: otoh, typing bzr will tell you how to get it
<sergiusens> Chipaca: if you are on ubuntu ;-)
<Chipaca> sergiusens: no other operating system exists
<sergiusens> Chipaca: what phone do you use again? ;-)
<Chipaca> sergiusens: an ubuntu phone of course
 * Chipaca hides his android
 * ogra_ shakes head
 * Chipaca ides ogra_'s android too
<Chipaca> hides*
<Chipaca> i'm going to have to change this keyboard soon. or maybe my fingers.
<Chipaca> anyway! back to work
<ogra_> i havent run any android in about a year now :)
<Chipaca> ogra_: you are a better person than i
<ogra_> i just dont get along with it anymore after using the ubuntu phone for a while
<ogra_> the UX feels so clunky
<ogra_> and swiping from the right never does what i expect !
<Chipaca> yep
<sergiusens> ogra_: _1
<sergiusens> +1 I meant
<ogra_> heh
<gatisp> I will have to buy Ubuntu phone, its about time to change my Nokia N9 :)
<mvo_> sergiusens: I did some update to your noUpdateGrub branch, did you already push your new grub.cfg somewhere?
<mvo_> sergiusens: I think thats the bit missing at this point :)
<ogra_> hmm our owncloud installation tells me to upgrade it
<sergiusens> mvo_: only thing missing?
<sergiusens> mvo_: sorry haven't checked my email yet, was dealing with irc first :-)
<mvo_> sergiusens: well, the transition too, but its looking promising
<mvo_> sergiusens: no worries, its not urgent at all
<seb128> sergiusens, hey
<sergiusens> mvo_: looking now
<sergiusens> seb128: hello
<sergiusens> seb128: for s-i we should just get ubuntu-personal/rolling/edge in place, we are going to need it anyways
<seb128> sergiusens, we are trying to get a desktop snappy image going, we made cdimage build an image similar to the ubuntu-core one, see https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next
<seb128> sergiusens, well, wfm if you want, but being able to test locally would be convenient
<sergiusens> seb128: you probably want cprov's branch
<seb128> sergiusens, what branch is that and what does it do?
<sergiusens> seb128: https://code.launchpad.net/~canonical-ci-engineering/goget-ubuntu-touch/local_image/+merge/260531
<seb128> sergiusens, thanks
<sergiusens> seb128: I'm not sure it's working yet (given the WiP), the resulting tarball might need some massaging (e.g.; putting the rootfs into /system)
<seb128> sergiusens, any recommendation on what I can do with the tarballs from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29166 to test the output?
<seb128> sergiusens, or where/to who can I request ubuntu-personal/rolling/edge to be configured
<cprov> sergiusens: seb128: it seems to work fine (so far), we mangle the rootfs to install packages from -proposed and josepht can help you with further tweaks
<seb128> cprov, thanks, see ^ for what I'm trying to do
<cprov> seb128: yup, a 'personal' rootfs
<seb128> cprov, right :-)
<rsalveti> morning
<seb128> hey rsalveti
<rsalveti> hm, goget-ubuntu-touch ftbfs for all archs
<rsalveti> seb128: hey!
<gatisp> After running bzr branch lp:snappy
<gatisp> go get -d -v launchpad.net/snappy/...
<gatisp>  I still don't see /writable/cache/system
<sergiusens> rsalveti: that's in the ppa; I'm disabling that building now that wily is working
<gatisp> sergiusens, ogra_ ^ am i missing some step?
<rsalveti> sergiusens: ftbfs in the archive: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.22-0ubuntu3
<rsalveti> after mvo_ uploaded a new version
<sergiusens> rsalveti: that's fine
<sergiusens> rsalveti: this is why I wanted it updated in the archive, to play API change catchup ;)
<rsalveti> sergiusens: how can a ftbfs be fine? :-)
<sergiusens> rsalveti: I never asked you to rebuild u-d-f ;-)
<rsalveti> haha, guess that happened yesterday already once you uploaded a newer version
<sergiusens> oh, mvo_ that u-d-f rebuild isnt' needed
<rsalveti> sergiusens: is this because of go 1.4?
<sergiusens> mvo_: snappy unpack needed fixing and getting a rebuild of ubuntu-snappy-cli is enough for that
<sergiusens> rsalveti: no, because lp:snappy has changed a lot with all the refactor that's going on
<rsalveti> seb128: yeah, would also point you to the ci guys, since they have a way to use the rootfs (from live-build) when flashing with u-d-f
<rsalveti> don't remember if we had an MR for it
<sergiusens> rsalveti: already dealt with ;-)
<rsalveti> seb128: the system-image server was also modifying the image, but ogra pushed the changes into the initrd now
<rsalveti> just don't know if you're using the same initrd
<sergiusens> rsalveti: but would be good for someone to setup ubuntu-personal/rolling/edge in any case
<ogra_> rsalveti, there was nothing to push for core ... only touch
<rsalveti> ogra_: link for mtab?
<ogra_> that wasnt in the initrd :)
<rsalveti> don't remember where you landed that :-)
<ogra_> livecd-rootfs
<rsalveti> then seb128 should already be using that, I'd imagine
 * ogra_ checks before talking nonsense
<ogra_> yeah
<ogra_> 2.304 and 2.305 have the changes
<rsalveti> cool then
<ogra_> mtab, /lib/modules, /lib/formware and /userdata|/writable (depending on the flavour)
<ogra_> *firm
<rsalveti> seb128: and to auto import ubuntu-desktop-next in system-image I guess you'd need to ping slangasek
<ogra_> or sil2100
<seb128> rsalveti, ok, thanks
<rsalveti> mvo_: sergiusens: what is still missing to get https://bugs.launchpad.net/snappy/+bug/1462916 fixed for 15.04.1?
<ubottu> Ubuntu bug 1462916 in Snappy 15.04 "Simplify TMPDIR handling" [High,In progress]
<sergiusens> rsalveti: I'll defer to Chipaca
<rsalveti> iirc this is the last standing bug we have
<Chipaca> mvo_: with lp:~mvo/ubuntu-core-launcher/tmpdir-simplify-lp1462916 merged and the associated u-c-security also in, tmpdir handling is done, right?
<Chipaca> rsalveti: (afaik it's done)
<Chipaca> where done means 'on trunk'
<rsalveti> Chipaca: guess that everything is pushed to trunk, but nothing released yet
<Chipaca> not 'on 15.04'
<rsalveti> right
<Chipaca> mvo_: just checking with mvo_ who was tracking the whole thing, whether there are further branches for trunk
<mvo_> Chipaca: its done but not backported, let me do this now
<Chipaca> mvo_: ok
<Chipaca> mvo_: note i forked your branch and fixed it before merging
<Chipaca> so you want to backport that :)
<mvo_> Chipaca: I noticed, thanks a bunch!
<Chipaca> k
<rsalveti> mvo_: it seems we need a release for both wily and 15.04.1 then, right?
<mvo_> rsalveti: maybe :) why for wily? I'm not sure I follow
<mvo_> rsalveti: or you mean the core-launcher upload? yes, indeed
<rsalveti> mvo_: yeah
<Chipaca> "release" and "wily" seem to be at ends
<kyrofa> sergiusens, installing things using the webdm API is still broken here. I ran a "snappy rollback webdm" to try to get back to a working version (0.7 now), but now it's not running. Did I miss something?
<rsalveti> package upload would probably be a better way to say what I wanted :-)
<mvo_> rsalveti: :) sorry, I'm a bit slow today, I will do both wily and vivid uploads
<rsalveti> mvo_: haha, thanks :-)
<rsalveti> mvo_: then once both are in the ppa we can finally trigger another image for our final RC
<rsalveti> unless we find other issues
<Chipaca> kyrofa: how is it broken?
<rsalveti> and then ask utlemming to test it on the cloud side
<sergiusens> kyrofa: hmm, it works fine here, I guess you hit one of the bugs that was fixed this week in snappy/ubuntu-core-launcher itself
<kyrofa> sergiusens, oh! Yeah, you mentioned that earlier. Do I need to explicitly update ubuntu-core-launcher, then?
<kyrofa> Chipaca, I'm getting stuff like this: ERROR snappy logger.go:199 xkcd-webserver.canonical failed to install: unpack /tmp/snaps/webdm/0.8/tmp/xkcd-webserver428488438 to /apps/xkcd-webserver.canonical/0.5 failed with exit status 1
<Chipaca> kyrofa: rolling edge?
<kyrofa> Chipaca, yessir
<Chipaca> looks like the snappy unpack with go 1.4 problem
<Chipaca> that fix's landed, right?
 * Chipaca checks
<Chipaca> yep, landed in 487
<Chipaca> kyrofa: it might not be in an image yet
<Chipaca> kyrofa: mvo_ will address that in a moment
<kyrofa> Chipaca, ah, very good! Okay, I'll hang out
<Chipaca> kyrofa: meanwhile, you have the following workaround: go for a walkaround :-p
<rsalveti> ogra_: wow, wonder why owcloud takes 10 minutes for the first start
<kyrofa> Chipaca, ha!
<rsalveti> kyrofa: unless you really need rolling/edge, please use 15.04/edge instead
<Chipaca> kyrofa: or if you're in a hurry, you could build snappy from trunk and scp it in
<ogra_> rsalveti, it downloads a ton of stuff on first boot
<ogra_> s/boot/start/
<rsalveti> rolling/edge should be renamed to rolling/probably_broken
<kyrofa> rsalveti, I don't actually. Back when I made it I needed rolling edge to get webdm. Is that no longer the case?
<Chipaca> oh, wait
 * Chipaca checks what he's running
<rsalveti> kyrofa: webdm is also available for 15.04
<Chipaca> sergiusens: you need to rebuild webdm for wily :-(
<ogra_> rsalveti, the package is also outdated ... i get a "please update to the new version" popup all the time ...
<ogra_> and the icon in webdm is broken
<rsalveti> ogra_: oh, got it
<Chipaca> sergiusens: (which is weird; why is it built with 1.4?)
<rsalveti> who owns it?
<ogra_> kikinz i think
<kyrofa> rsalveti, good deal, I'll do that
<ogra_> *kickinz
<ogra_> (at least thats where it downloads all the files from according to syslog)
<rsalveti> ogra_: but nice to see the new image around, waiting for my rpi2 to test
<rsalveti> right :-)
<ogra_> would be nice if something like "snappy install owncloud" would actually automatically install docker
<ogra_> instead of falling over with an error
<tedg> +1, I think it'd be nice for list too, as then it'd look like we have more in the store on initial look.
<mvo_> ogra_: hm, you shouldn't even see owncloud if you don't have docker already
<ogra_> mvo_, i didnt run snappy list ... just executed "snappy install owncloud" after firts boot
<ogra_> so i'm not sure if it was actually offered
<tedg> I think everything should be based on app snaps, whether or not they need frameworks is just a technical detail.
<ogra_> yeah
<mvo_> ogra_: heh, thats funny
<mvo_> ogra_: could you file a bug please?
<ogra_> will do ... but let me verify it again
<gatisp> ok, after installing vm I see /dev/sda3 on / as read-only and /dev/sda4 on /writable/cache/system as read-only. This is exactly what online docs say, that both system partitions are read-only. So they are remounted to read-write whenever needed?
<sergiusens> Chipaca: what wrong with webdm being built with 1.4?
<kyrofa> rsalveti, I downloaded the 15.04 image from the snappy page, and it does appear that webdm is installed, but it doesn't seem to be running. Previously, when I was on rolling, all I had to do was install webdm and snappyd was immediately on port 4200
<Chipaca> sergiusens: nothing, because unpack is still done with snappy itself, right?
<sergiusens> Chipaca: exactly :-)
 * sergiusens has been trying to say that to many people since days now
<Chipaca> then i don't understand why kyrofa's thing is failing
<sergiusens> kyrofa: the image from the page has a webdm snap of type app, remove it and snappy install webdm again
<rsalveti> kyrofa: hm, that's probably the old image
<kyrofa> sergiusens, ah ha
<rsalveti> try sudo ubuntu-device-flash core 15.04 --channel edge --enable-ssh --developer-mode --output x86.img
<rsalveti> or similar
<sergiusens> kyrofa: https://search.apps.ubuntu.com/api/v1/package/webdm (look at the release entry there)
<rsalveti> kyrofa: the pre-built image is super old
<kyrofa> sergiusens, rsalveti ahh, now I'm up and running. Thanks guys :)
<rsalveti> mvo_: should we also try fixing https://bugs.launchpad.net/snappy/+bug/1462954 ?
<ubottu> Ubuntu bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged]
<rsalveti> it seems we're just missing a touch at the right file, so it can be bind-mounted
<longsleep> +1
<longsleep> by the way, on bug #1462954 - the random-seed is not the only file which cannot be bind-mounted because it is missing
<nothal> Bug #1462954:  systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only <Snappy:Triaged> <Snappy 15.04:Triaged> <Snappy trunk:Triaged> <http://launchpad.net/bugs/1462954>
<ubottu> bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Triaged] https://launchpad.net/bugs/1462954
<ogra_> rsalveti, someone (pitti ?) said there would also be an ordering problem (the systemd unit starting before the mount)
<rsalveti> ogra_: thought we'd be bind mounting at the initrd
<pitti> no, this was just a conjecture; the file is simply missing, so it can't be bind-mounted
<rsalveti> right
<pitti> rsalveti: we don't (I thought that too, would be much more robust)
<pitti> so we need to pre-create it; longsleep and I followed up to the bug
<longsleep> initrd just writes to fstab as far as i understand it
<rsalveti> yeah, that should be an easy fix
<ogra_> rsalveti, we dont, we fill the fstab and let systemd's fstab handler do the mounting (like we let mountall do it on phones)
<ogra_> initrd should only mount the very basic bits to get readonly and rw spaces
<rsalveti> right
<ogra_> so if the random seed unit runs before the fstab one we have an issue
<pitti> shouldn't though; that "runs too early" was a conjecture if those bind mounts were *not* in fstab
<rsalveti> easy to check
<ogra_> (and i could imagine it does so you get proper encryption security for encrypted mounts)
<pitti> if they are, the RequiresMountsFor= will take care of it
<ogra_> ok
<ogra_> i just think we culd have a catch22 here ... for encrypted mounts
<ogra_> (not sure we ever plan to support that for the rootfs)
<rsalveti> eventually, yeah
<pitti> why would we ever encrypt the root fs?
<pitti> it's a publically available image, not exactly a secret
<pitti> well, if we do, the initrd needs to unlock it, just like in a desktop install
<pitti> that should be done by /usr/share/initramfs-tools/hooks/cryptroot as usual?
<ogra_> well, but if we want the persisitent entryopy from the file at this point we would have to mount from initrd
<jdstrand> mvo_: it looks like you handled the ubuntu-core-security in the ppa for /tmp, so I will make sure that get incorporated into the eventual vivid sru (like the ppa1 version before it)
<ogra_> s/mount/bind mount/
<mvo_> jdstrand: yeah, I was about to ask if I should propose a branch for this :)
<ogra_> pitti, people encrypt their swap partitions ... so why not the writable partition too :)
<pitti> ogra_: hm, why do you need the seed in the initramfs for unlocking an encrypted device?
<mvo_> jdstrand: do you have a 15.04 branch or is there any other way that I can make your life easier?
<pitti> ogra_: oh yes, encrypting the writable partition makes sense; I thought you literally meant the root partition
<jdstrand> mvo_: nah. I need to prepare a branch for 15.04 still. I'll do that then just pull it in
<ogra_> pitti, dunno, for making use of it ?
<mvo_> rsalveti: if its just a touch we should be good, I add the file to the u-core-config now
<jdstrand> I mean to do it with ppa1, but didn't
<ogra_> doesnt it help to have the entropy available =
<ogra_> ?
<mvo_> jdstrand: ok :)
<pitti> ogra_: you mean for session keys? I suppose that will have to make do without seed init (and I guess it does, as that has worked for ages with encrypted root)
<ogra_> ah, k
<pitti> ogra_: TBH I don't know whether luks uses random session keys
<pitti> for sure you need proper randomness when creating a luks device
<pitti> I thought at that ^ point you create "the" key, and then just encrypt it using the user password in one of the 8 luks key slots
<pitti> it sounded quite deterministic to me
<elopio> good morning.
<elopio> fgimenez: have you been able to build the webcam appliance into the image?
<elopio> ogra_: when I do snappy update on raspberry, it should fail right?
<ogra_> elopio, it wont switch over to the new rootfs, it will update but will never boot into the new system
<sergiusens> elopio: it doesn't today
<ogra_> we need to handle that better
<ogra_> (like blocking the update before it even downloads and tell the user about the unsupported status)
<elopio> +1 to that. While full update is supported anyway.
<ogra_> well, it isnt, thats the point
<elopio> mvo_: should the webcam snap work on raspberry?
<sergiusens> ogra_: elopio we have some unlanded MPs for that
<ogra_> sergiusens, that prevent the download ?
<elopio> sergiusens: for updates in raspberry?
<ogra_> elopio, for avoiding them :)
<mvo_> elopio: I think so, is it not working? and if not, what error do you get?
<elopio> heh :)
<sergiusens> ogra_: elopio basically if you build your image with --developer-mode
<sergiusens> && sideload the "device" tarball it should be blocked
<ogra_> sergiusens, why does --developer-mode have any influence here
<elopio> mvo_: http://paste.ubuntu.com/11672461/ I'll try again with ogra_'s latest image.
<ogra_> i thought as soon as you use an external device tarball it should be blocked, no matter what kind of image you built
<sergiusens> ogra_: oh, I didn't write it, "I'm not sure --developer-mode is the right switch"
<sergiusens> ogra_: but there is also an &&
<ogra_> well, that sounds inconsequent
<sergiusens> ogra_: you shouldn't be able to override these things without --developer-mode though
<ogra_> either we block always if an external device tarball is used or we dont
<ogra_> ah, i didnt know that
<ogra_> i thought you could always roll images
<ogra_> (i never tried without --developer-mode ... seems pointless unless you actually build an appliance)
<elopio> sergiusens: can you give me a link to the branch, please? to add it to the testing report
<mvo_> elopio: try "sudo systemctl status -l webcam-demo_webcam-demo_1.0.2.service"
<mvo_> (notice the *2* in the name)
<mvo_> elopio: I added a task to the trello card that the guide needs to be updated as the version is now 1.0.2 instead of 1.0.1
<elopio> mvo_: hah, right.
 * elopio retries.
<jdstrand> mvo_: fyi only: https://code.launchpad.net/~ubuntu-security/ubuntu-core-security/15.04
<mvo_> ta
<mvo_> rsalveti: just fyi, I triggered a new vivid build now that all packages are in the ppa
<sergiusens> elopio: it's card on trello on todo; all there
<sergiusens> elopio: in doing I mean
<elopio> sergiusens: ack, thanks.
<rsalveti> mvo_: awesome, thanks
<jdstrand> tyhicks: fyi, not adding ping or a child profile to snappy default template-- it requires capset syscall
<sergiusens> mvo_: help! I can't find a branch (the one that records a sidelod for the device)
<mvo_> sergiusens: the one for u-d-f? or the one for snappy?
<sergiusens> mvo_: oh, nvm I think I found it (I followed the link from u-d-f that pointed to the old one)
<mvo_> cool
<ogra_> sergiusens, should my autopilot hack be obsolete then ?
<ogra_> or woould autopilot still remind aboout the update when i enable it again by default
<sergiusens> ogra_: yes
<ogra_> yes ?
<elopio> damn, I burned my tty cable.
 * ogra_ should not ask "or" questions 
<elopio> I did not use the red cable, *I swear*
<ogra_> elopio, how is it broken ?
<ogra_> you dont see ttyUSB0 created in dmesg when you plug it in ?
<ogra_> (on your PC)
<elopio> ogra_: I didn't for a while, and my PC shut down, then it started smelling funny.
<elopio> I gave it some space, now it works again :)
<ogra_> heh
<ogra_> self healing cable :)
<tyhicks> jdstrand: so that increases the urgency to get the unprivileged ping patches uploaded in wily?
<seb128> cprov, sergiusens, mvo_, rsalveti: so I built goget-ubuntu-touch with the change from https://code.launchpad.net/~canonical-ci-engineering/goget-ubuntu-touch/local_image/+merge/260531 and used "u-d-f core rolling --channel edge --device-part=livecd.ubuntu-desktop-next.device.tar.gz --image-part=livecd.ubuntu-desktop-next.rootfs.tar.gz -o wily.img" which gave me an image, but kvm says it's not a bootable disk ... any idea how to debug?
<mvo_> elopio: I wanted to add some integration tests for snappy build, check if systemd/random-seed is writable and similar things, do you think its ok to still do this via the old sh or should I do it in go nowdays?
<ogra_> mvo_, you should loop over 7etc7system-image/writable for that
<mvo_> seb128: you could boot with -kernel -initramfs -append and point that to your local kernel
<ogra_> bah
<mvo_> ogra_: I'm confused?
<ogra_>  /etc/system-image/writable
<mvo_> ogra_: aha, yes
<ogra_> mvo_, it has all the info what should be writable :)
<seb128> mvo_, that sends me to initramfs with error like /etc/fstab no existing, I feel like the generated img is unvalid
<mvo_> uh
<mvo_> ok
<seb128> no idea if the files from our image builder are even valid
 * seb128 is just poking around
<jdstrand> tyhicks: for some value of 'urgency'
<jdstrand> I don't think it is incredibly high personally, but someone might think it is
<tyhicks> ok
<jdstrand> ie, let' snot be distracted by it. just know there is no (safe) workaround policy at this time
<tyhicks> jdstrand: I'm not sure if I ever mentioned it but upstream iputils merged the unprivileged ping socket patches for ping and ping6
<jdstrand> you did. that's great :)
<tyhicks> cool
<seb128> mvo_, are you going to do a livecd-rootfs upload today? or is it ok if I upload the change you commited earlier?
<elopio> mvo_: first, I would like if you merged https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592
<mvo_> seb128: yeah, just upload with my changes, thats fine
<elopio> mvo_: the only blocker in there is that it tries to sign the packages
<seb128> mvo_, thanks
<mvo_> elopio: aha, ok
<elopio> mvo_: then, maybe it's better for you to write the test in shell, while we figure out how to do it in go with adt-run.
<elopio> from the discussion between fgimenez and pitti, I get that there are still some things to figure out.
<mvo_> elopio: ok, thats fine, I can convert it to go later once that is settled
<mvo_> elopio: let me fix the signing part now
<elopio> mvo_: thanks.
<mvo_> elopio: r468 should have that now
<elopio> dholbach: davidcalle: are you guys going to take care of the developer docs?
<mvo_> elopio: if that looks good, you can top-approve the MP and it will be auto-merged
<fgimenez> elopio, mvo_ i hope to push something shortly with a simple implementation of pitti's suggestion of creating an image with the debs installed
<fgimenez> elopio, mvo_ i'll ping you when it'll be ready
<elopio> mvo_: I'll give it a new try.
<elopio> fgimenez: thanks!
<mvo_> thanks!
<dholbach> elopio, in which sense?
<elopio> dholbach: like, who should write about this? https://bugs.launchpad.net/developer-ubuntu-com/+bug/1457935
<davidcalle> elopio, please define take care, publish or write, if write, about what ? :)
<ubottu> Ubuntu bug 1457935 in Ubuntu Developer Portal "The snappy getting started guide doesn't mention the serial console" [Undecided,New]
<dholbach> I don't know - maybe rsalveti can comment?
<dholbach> ^ elopio
 * davidcalle really needs a board
<elopio> davidcalle: like a trello board or like a beagle board? :)
<davidcalle> elopio, beagle (nobody sane would "need" another trello board ;-) )
<elopio> davidcalle: they are giving away the raspberries with the orange case, you just have to reply to gustavo's email.
<davidcalle> elopio, good point
<elopio> or maybe rsalveti can get you one from the order he's making for the team. If you are going to write docs about snappy, that makes sense.
<elopio> but well, then we are back to the question: who writes the docs?
<davidcalle> elopio, common effort, but I will very certainly write some more myself
<elopio> I suppose, whoever knows about it. So I'll jfdi for the serial.
<dholbach> <3
<pitti> fgimenez, mvo_: note, I did suggest to *not* install debs on snappy, but build a custom image out of it; installing debs on snappy for testing is wrong :)
<elopio> pitti: still a good step to get started, right?
<pitti> elopio: well, not "good"; it's an okay workaround for running a test locally
<elopio> we have a big list of things to fix on the tests, to make them closer to how a real system would work.
<pitti> mounting / r/w and installing debs is exactly how real systems don't work :)
<fgimenez> pitti: yep, that's what i'll try, using --install option of u-d-f, sounds good?
<pitti> and with the writable bind mounts you are going to have a hard time installing debs
<ogra_> the --install option is for snaps
<pitti> fgimenez: I suppose that's going to do the same, though? i. e. mount r/w and install debs?
<pitti> ah
<ogra_> (unless i'm totally wrong)
<ogra_> i.e. --install webdm
<elopio> I'm okay with an okay step to get started :)
<pitti> but please don't ever put that into production
<elopio> while fgimenez gets the correct thing working.
<fgimenez> ogra_: thx! i got confused with the "packages" part of the description
<ogra_> np :)
<fgimenez> then, how can be built a custom image using local debs?
<pitti> how do we build the official images?
<ogra_> pitti, livecd-rootfs/live-build
<ogra_> on cdimage
<ogra_> (or "via"
<ogra_> )
<ogra_> the rootfs then gets imported by system-image.u.c, diffed for the deltas and merged with the device bits
 * longsleep cheers at bug 1462954 fix commited
<ubottu> bug 1462954 in Snappy trunk " systemd-random-seed fails to start because /var/lib/systemd/random-seed is read only" [High,Fix committed] https://launchpad.net/bugs/1462954
<ogra_> mvo_, hmm, i see /var/lib/systemd/snappy and /var/lib/systemd/click in /etc/system-image/writable-paths but neither of them mounted ... are they leftovers from older implementations or bugs ?
<elopio> pitti: with "please don't ever put that into production" do you mean trunk? I would like to get mvo's branch merged because it prevents some errors, and will make it easier for us to transition into tests written in go.
<elopio> if we skip the building the deb part, it also serves to check the released images.
<pitti> elopio: I mean relying on installing debs on snappy
<pitti> it's going to fail for some packages, and it's the wrong approach
<longsleep> For some reason my FAT partition got borked again automatically .. (second time)
<elopio> pitti: ok, totally agree to that.
<elopio> lets figure out something better.
<ogra_> longsleep, weird, we explicitly run an fsck on it from the initrd
<elopio> is snappy always going to be a deb? or will it become a snap at some point?
<ogra_> so even if you just pull the power plug it should recover fine
<pitti> elopio: IMHO it would be a very worthwhile exercise to try and reproduce the image build locally, then simplify/scriptify that, so that we can do it for tests, in the cloud, etc.
<ogra_> elopio, i doubt we will stop rolling images from debs
<pitti> i. e. ideally a live-build config
<pitti> snappy being a snap sounds like a bootstrap issue
<pitti> AFAIUI we'll build our system images from debs
<ogra_> well, as lon as we build our rootfs from debs it should be a deb
<pitti> *nod*
<ogra_> and i dont see us stop doing that for the next few years
<ogra_> since the old ubuntu wont go away
<elopio> now about the selftests, instead of packaging them as debs, we can just package them as snaps.
<elopio> in case it was not meta enough before :)
<pitti> elopio: why do you need to package them at all?
<longsleep> ogra_: it does not even come to boot, the boot.ini is invalid and thus the u-boot does refuse to boot it
<longsleep> the text files have some binary garbage in them (in all of them)
<longsleep> it seems to happen after it automatically rebooted because of new rootfs
<longsleep> ok its not garbage
<longsleep> it always added \x94 in regular order
<longsleep> s/added/replaced/g
<longsleep> and all the files in a and b are uppercased and using short name
<longsleep> maybe something wrote to parts of the fat partition upgrade
<elopio> pitti: I'm copying the test binaries atm, so no *need* to package them.
<elopio> but it would be extra cool that if you want to verify that your board is correct beyond the checking if it boots, you could
<elopio> sudo snappy install snappy-selftests && snappy-selftests
<longsleep> it must have happend when snappy-system.txt was written
<pitti> elopio: oh, tests are now in go instead of a scripting language?
<elopio> pitti: that's the experiment I'm trying to do.
<longsleep> ogra_: Fschk results manually run on that partition confirm that it is broken :/
 * longsleep has to leave for linux user group now 
<pitti> elopio: that sounds hard; a deb can't be installed in principle, and a snap doesn't have the necessary privs; a framework should do, not sure whether that can have "unlimited" system privs
<pitti> elopio: in particular, not sure if a framework should be able to install snaps and such
 * pitti waves good night
<sergiusens> elopio: pitti it is doable, but beats the purpose of a snap as it can wreck the system (I would not allow install/remove in a test suite designed to run on a live system)
<elopio> so... maybe we just make the tests a deb and bundle them into the image that we will somehow build from trunk. Or I don't know. First, to get this branch merged, then the future.
 * elopio tests.
<mterry> Is it possible to flash the BBB over USB?  (I don't have an SD slot on my laptop)
<Chipaca> wooohoo! branches landing! woo.
<elopio> mterry: I don't think so. I have this: http://www.amazon.com/Transcend-Information-Card-Reader-TS-RDF5K/dp/B009D79VH4/ref=sr_1_1?ie=UTF8&qid=1433868800&sr=8-1&keywords=sdcard+reader
<elopio> mterry: https://lists.ubuntu.com/archives/snappy-devel/2015-June/000732.html
<sergiusens> elopio: that's not related to sdcard requirements though
<sergiusens> what mterry wants is network boot
<mterry> elopio, interesting amazon link.  cheap enough
<elopio> sergiusens: I was wondering if the memory could be flashed from usb, not from sd card as that script is doing.
<elopio> network boot sounds cool too. I want that.
<mterry> Do you folks also use some sort of casing for the BBB, or a mat or something?  It feels weird to have a bare circuit board
 * elopio puts it into ogra's TODO :)
<sergiusens> mterry: you eventually get used to it ;-) but there are cases
<mterry> sergiusens, I would also be happy with a USB flash, not necessarily network boot
<sergiusens> mterry: there is no recovery mode in these devices though, so usb flash seems a tad complicated
<rsalveti> elopio: so, ideally the way to change the image is basically as pitti said, which is creating another clean image with livecd-rootfs
<rsalveti> elopio: the proposed-migration work that the ci team is doing basically that, but using launchpad to build the new image
<rsalveti> we should just have a script or something that can easily do that locally (something like rootstock, ogra_ ^^)
<rsalveti> elopio: we definitely don't want to change the image by installing debs in runtime, as that's not the same path used when we produce the final images
<rsalveti> about the selftests, I wonder if we can install them by default, as long it's not big
<rsalveti> that would allow us to run the tests as part of the produced image
<rsalveti> sergiusens: what do you think?
<rsalveti> elopio: one curious thing, while go helps, why are we moving away from shell scripts?
<ogra_> i can look into making rootstock work for core
<rsalveti> I know shell is not necessarily ideal, but it generally easier to script tests, right?
<sergiusens> rsalveti: I think it's a bad idea
<sergiusens> rsalveti: installing the selftests on production images
<rsalveti> sergiusens: why?
<sergiusens> rsalveti: because they can alter the system
<rsalveti> right
<sergiusens> it's not idempotent to run the tests
<rsalveti> then how can we easily install/deploy the self tests that are compatible with a specific image?
<ogra_> well, we could add a rule that test packages cant have maintainer scripts
<sergiusens> rsalveti: a sideloaded snap is fine
<sergiusens> rsalveti: but not on the store
<ogra_> then they cant alter it
<rsalveti> sergiusens: right, but then we'd need to find a way to store that and make that easily available
<sergiusens> rsalveti: but
<rsalveti> and in a way that we can match the tests with the image
<sergiusens> rsalveti: this is the reason I suggested to make it a go binary, so it can just be copied over and ran
<rsalveti> shell script also allows that, right?
<sergiusens> rsalveti: if it's a snappy package you can match releases at all
<rsalveti> don't think we're going to remove bash :-)
<sergiusens> rsalveti: we are going to remove bash actually
<ogra_> and even then you could ship your own and use "#"./sh"
<sergiusens> you can use dash
<rsalveti> bash is fine
<rsalveti> yeah, sh and dash should still be around
<sergiusens> rsalveti: it's going to be removed and provided by the comfy framework
<rsalveti> sergiusens: what is the comfy framework?
<ogra_> yeah, but you most likely also want to test without that installed
<rsalveti> guess lool was going to write something for it today
<sergiusens> rsalveti: a set of tools to make the system easy to admin
<ogra_> comfy has all the minimal convenience packages for admins
<rsalveti> right
<ogra_> proper vim, htop etc etc
<rsalveti> got it
<rsalveti> we still need to find a way to easily provide the selftests that match the image
<rsalveti> once we merge selftests in lp:snappy, we can at least match the versions in there
<ogra_> yeah, then we should just branch into /home/ubuntu
<ogra_> and run them from there
<sergiusens> ogra_: just like we did for click ;-)
<rsalveti> right, that might be easier indeed
<ogra_> no packages or anything at all
<kyrofa> sergiusens, currently the webdm web interface and the snappy scope talk to webdm via its API. For some reason I've been assuming that webdm will be going away and its API will be moving into snappy itself, and the web interface and scope will be talking directly to snappy. However, it sounds like that's not the case. Can you explain what will become of webdm as you develop the snappy service?
<sergiusens> kyrofa: what do you mean not the case?
<rsalveti> I just still don't fully understand the reason to migrate from shell to go for everything (I understand that's a good thing for some tests)
<ogra_> yeah
<rsalveti> since having a go test that will be basically calling many other commands is like an overkill thing
<rsalveti> shell is perfect for that
<sergiusens> kyrofa: the diagram on the rest doc shows that afaik
<ogra_> i dont think we should add additional compiling if not needed
<rsalveti> right
<kyrofa> sergiusens, it shows webdm is still there, but talking to snappy. Can you explain what exactly it's doing other than hosting an API for the web interface?
<sergiusens> rsalveti: ogra_ you can't bzr branch on the target so what's the problem?
<ogra_> you can scp
<ogra_> and branch on the host
<sergiusens> kyrofa: showing a browseable view/interface
<sergiusens> ogra_: and compile
<rsalveti> you can install comfy
<rsalveti> and then checkout
<rsalveti> or just scp
<sergiusens> rsalveti: comfy doesn't have bzr
<ogra_> well, then you cant test without comfy :)
<sergiusens> nor git
<kyrofa> sergiusens, okay so it just becomes the web interface. No API
<sergiusens> and what ogra said
<rsalveti> can't we add it? :-)
<ogra_> sure
<rsalveti> at least git
<sergiusens> kyrofa: well it will have an api that the browser would consume
<ogra_> but still, you want to be able to thest the plain image too
<rsalveti> sure
<rsalveti> but doing an scp in one script or one binary is the same thing
<sergiusens> kyrofa: but ted said he wants store + local view consolidated into a single view provided by snappy
<sergiusens> so things are in flux again
<rsalveti> how making it go will make it any easier?
<ogra_> sergiusens, i would actually stuff binaries into the tree instead of compiling on the host
<ogra_> *if* i need any binaries at all
<kyrofa> sergiusens, yeah flux here too
<sergiusens> rsalveti: ogra_ anyways, the move to go was to get some test framework in place more than anything else
<rsalveti> right, that's is a good thing
<rsalveti> I just don't want us to simply rewrite everything just because of reasons
<ogra_> +1
<kyrofa> sergiusens, okay. I know we just talked about this, but with my newfound understanding, just to clarify: webdm does NOT need screenshots, reviews, ratings, etc.?
<rsalveti> elopio: mvo_: I also created a QA column in our backlog to make sure we don't forget about stuff we want to automate: https://trello.com/b/4PQViyUQ/snappy-core-stakeholders-backlog
<kyrofa> sergiusens, or was that only snappy itself that didn't need that stuff?
<rsalveti> mvo_: we could use that and include a card for the systemd random-seed regression testing you wanted to add
<rsalveti> elopio: so since the ubuntu-snappy package includes the bzr rev as part of the package version, we could use that when using the self tests against an specific image
<rsalveti> once everything is merged
<rsalveti> so we know we're testing the same revision
<sergiusens> kyrofa: webdm does need reviews, screenshots and ratings, where and how it gets them is in flux ;)
<kyrofa> sergiusens, ah, good. Okay, ted didn't like the "extract the snappy store stuff into a lib" idea-- he wants the primary package path to go through snappy. So now I'm thinking I'll write a go lib to get that "leaf data" from the store, and maybe webdm can use that?
<kyrofa> rsalveti, ^^
<rsalveti> kyrofa: if a go lib maybe snappy can use that later
<rsalveti> but yeah, from what I understood from tedg he wants everything to go via snappy, using the rest api
<rsalveti> and then everything to consume from the rest api
<rsalveti> tedg can explain better when he gets back online :-)
<kyrofa> rsalveti, same understanding here. Does that mean he also wants that extra data (screenshots etc.) coming from snappy?
<rsalveti> I'd guess so, but not sure
<rsalveti> let's wait on tedg
<kyrofa> rsalveti, alright, good deal
<sergiusens> kyrofa: well not webdm but snappy
<sergiusens> kyrofa: and yeah, even screenshots
<sergiusens> kyrofa: I think we want to improve the API we have exposed on webdm today
<tedg> rsalveti, kyrofa, I'd say the leaf data like screenshots isn't critical, but it would be better if it went through snappy.
<tedg> But it seems to me that once you have 90% of the data going through snappy, you should just do that too.
<tedg> I like the idea of "one route to get data" even if snappy is just signing the URLs underneath the scope and passing them along.
<sergiusens> tedg: there are a couple of cases where this needs decoupling though; remote devices (ala google play's webui)
<tedg> sergiusens, Do you mean "install on my device" like via a website?
<sergiusens> tedg: yes
<tedg> sergiusens, Wouldn't in that case it be a push notification to the device?
<sergiusens> tedg: ah, right
<tedg> I think we need push messages for two things: new version available and install this app.
<ogra_> install this app ??
<tedg> ogra_, For like when you're browsing the Google Play store on your computer and you select something to install, it'll then install on your Android device.
<ogra_> ah
<tedg> I think we should definitely do at least one "are you sure?" check there :-)
<ogra_> heh, yeah
<kyrofa> tedg, alright. sergiusens, rsalveti: so the store code should probably stay in snappy, since the scope will continue talking to snappy. For now, I'll write a small go package to get the leaf data, and hopefully that's something that can be repurposed by snappy when it's ready. Does that sound reasonable?
<tedg> +1
<tedg> kyrofa, Or just patch snappy? Work things out in code review?
<sergiusens> kyrofa: as tedg says, maybe create launchpad.net/snappy/store
<sergiusens> or remote
<sergiusens> whatever you want to call it
<ogra_> a fork !
<tedg> Open Source is about freedom
<kyrofa> sergiusens, would we need to make a new API call for that stuff? Or will it fit into something we already have?
<sergiusens> kyrofa: our store api inside snappy is quite limited to cli needs
<sergiusens> kyrofa: I'd rip it out and decouple and start using store.API
<kyrofa> sergiusens, ah, right-- you're still waiting for the new API to be approved, right?
<sergiusens> kyrofa: oh yeah, new api, I wasn't following you; yes, that exposed api needs approval and apparently a retwist to bring back remotes
<sergiusens> kyrofa: for sure doing PUT /v1/packages/[name] is wrong with this model
<kyrofa> sergiusens, alright let me talk to alecu about where he wants my priorities. I think this is the solution long-term, but I may do a quick workaround to get the scope off the ground before I come back to this
<alecu> kyrofa: sergiusens: hola!
 * alecu reads backlog
<beuno> jdstrand, review scripts updated to r476
<jdstrand> \o/
<jdstrand> thanks :)
<beuno> jdstrand, sorry it took so long, clouds, storms, etc
<jdstrand> it's all good :)
<rsalveti> sergiusens: for our tools we want to have everything available for trusty, utopic and vivid, right?
<rsalveti> and wily as well, but guess part of the archive
<sergiusens> rsalveti: yeah, but wait
<sergiusens> rsalveti: what version are you releasing?
<rsalveti> sergiusens: not releasing anything yet, just checking our tools ppas
<rsalveti> want to remove the need for the beta one, align the versions for the other ppas
<rsalveti> and adjust the build scripts
<sergiusens> rsalveti: ok; what version is being aligned to?
<rsalveti> checking now, every ppa got a different version
<rsalveti> sergiusens: is there anything you want to releasE?
<sergiusens> rsalveti: maybe 0.23
<sergiusens> rsalveti: of u-d-f
<sergiusens> rsalveti: btw http://bazaar.launchpad.net/~snappy-dev/snappy/snappy-tools-update/view/head:/snappy-tools-update
<rsalveti> oh, great
<rsalveti> sergiusens: yeah, would be nice to release udf
<sergiusens> Chipaca: can you later take a look at my MPs, pretty small
<elopio> catching up with the backlog.
<elopio> rsalveti: the tests in go are just a proposal for further discussion, once we have something to show. I think they are more readable and easier to write.
<elopio> on bash we can do regexp matching, but we can't do proper set up and tear down, nor nice test reporting or failure messages.
<rsalveti> elopio: right, that's fine, I just want to make sure we don't get into this mode of rewriting everything unless really needed
<elopio> what we discussed is that as we are already compiling the source code, it wouldn't be a lot more pain to also compile the test. And we get a lot more options.
<rsalveti> or part of a further test development goal
<elopio> rsalveti: we don't want to just rewrite the current tests. We want to make them self contained and independent.
<elopio> as long as we finish testing we can finish the prototype.
<elopio> s/long/soon.
<rsalveti> sure, that's fine
<sergiusens> nice, the powerpc seems to not be broken anymore
<sergiusens> rsalveti: want to build the images with https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.23-0ubuntu1 ? If that's it, it's the one that needs propagation across the ppas
<sergiusens> rsalveti: I would like to get the install.yaml in place, but that requires a bit more time
<rsalveti> sergiusens: yeah, will propagate that
<rsalveti> sergiusens: jdstrand: asac: do you guys know why we have the click-ubuntu-policy package?
 * rsalveti is doing the tools ppa cleanup
<rsalveti> was created by asac a while ago
<rsalveti> and only published for trusty
<rsalveti> actually it's also in the archive, but same version
<rsalveti> so guess just let it there
<jdstrand> rsalveti: all I can say is that it doesn't do what it sounds like it does
<rsalveti> yeah :-)
<jdstrand> I'm not sure what it is or why it is there
<jdstrand> ah "initial version with the Ubuntu click store public key"
<rsalveti> yeah, just includes the public key
<rsalveti> jdstrand: so besides our packages, there are 2 main packages that you are maintaining in there
<rsalveti> click-reviewers-tools and ubuntu-core-security
<rsalveti> jdstrand: it seems both are maintained in bzr
<rsalveti> so was wondering if we could have a recipe to build trunk and automatically publish that into tools-proposed
<rsalveti> that then migrates to tools once a week
<rsalveti> jdstrand: or if you would prefer to for us to only track the released versions
<rsalveti> which then means someone needs to manually track and upload the package to the ppa
<jdstrand> rsalveti: ubuntu-core-security I'd rather see updates in the archive. we can discuss the review tools, but can we do that tomorrow (heading out)
<rsalveti> sure, will ping you tomorrow then
<rsalveti> but guess it's fine to track releases as well
<rsalveti> usually we just want to update the tools ppa before every stable release, or when required
<rsalveti> would be even better if we could do binary copies, but we can discuss tomorrow
<asac> rsalveti: there was a problem during release rush that migth or might not got resolved by this upload to ppa... unfortunately, i cant remember anymore. maybe it was a dependency? if you can purge it from host & target (not sure where its on) on trusty and still can build the webcam demo guide then its not needed :).
<asac> it was while jdstrand was sleeping :P
 * asac  off
<rsalveti> yeah, not doing it for this release :-)
<elopio> utlemming: my vm is still provisioning in azure. Is it normal that it takes so much time?
#snappy 2015-06-10
<rsalveti> sergiusens: did you delete the build recipe for goget-ubuntu-touch?
<sergiusens> rsalveti: yes, as we now have proper releases for wily
<sergiusens> rsalveti: it was a stop gap
<rsalveti> sergiusens: got it
<rsalveti> sergiusens: the released images are all including webdm, right?
<sergiusens> rsalveti: wrt to click-ubuntu-policy asac was going with desperate measures and that's why I'm on trusty today ;-)
<rsalveti> haha, got it
<rsalveti> sergiusens: that's cool, you can validate the tools ppa tomorrow then
<rsalveti> sending one email now with the remaining tasks we need for the release, and one is testing that https://launchpad.net/~snappy-dev/+archive/ubuntu/tools is useful on trusty
<rsalveti> will deprecate beta
<sergiusens> rsalveti: yay!
<sergiusens> rsalveti: not tonight though :-)
<rsalveti> sergiusens: nops, tomorrow
<rsalveti> sergiusens: ubuntu-device-flash is actually failing for me =\
<rsalveti> $ sudo ubuntu-device-flash core 15.04 --channel edge --enable-ssh --device generic_amd64 --output ubuntu-15.04-snappy-amd64-generic.img
<rsalveti> Determining oem configuration
<rsalveti> generic-amd64 failed to install: Unexpected status code 502
<rsalveti> not sure if a problem with the store
<miken> Yeah, there is a problem with the store (downloads) which ops are working on right now.
<miken> rsalveti: ^
<rsalveti> miken: oh, alright then :-)
<rsalveti> guess that's the time to go to sleep
<sergiusens> rsalveti: I think the store is down
<rsalveti> sergiusens: yeah, perfect timing
<sergiusens> rsalveti: I see those errors in click-sync too
<rsalveti> sergiusens: before you get off, what is the right way to sideload webm?
<rsalveti> there is the --install option but it says it's deprecated
<rsalveti> and it also failed here
<sergiusens> rsalveti: --install
<sergiusens> rsalveti: or eventually the oem package would list webdm
<rsalveti> right
<sergiusens> rsalveti: but they would all fail the same way if the store is down
<rsalveti> sergiusens: right
<rsalveti> sergiusens: can I run that from my host even when creating the bbb image?
<rsalveti> since it's a different arch
<sergiusens> rsalveti: if you leave this for tomorrow morning I'll create oem package that include webdm
<rsalveti> don't know the internals
<rsalveti> sure
<sergiusens> rsalveti: yes you can; we pick the architecture to install from from the architecture entry in the oem package
<sergiusens> rsalveti: given fat packages, it's ofter irrelevant
<rsalveti> great, was more worried if we had to execute something at the target arch
<rsalveti> indeed
<sergiusens> rsalveti: nah, it's all the same, it's an unpack, symlinks and the apparmor stuff is on first boot
<rsalveti> awesome :-)
<sergiusens> ok, going to bed now :-)
<sergiusens> good night!
<rsalveti> sergiusens: have a good night!
<rsalveti> sergiusens: for you, for tomorrow: http://paste.ubuntu.com/11685208/
<miken> rsalveti, sergiusens: downloads from the store should be working consistently now (thanks blahdeblah )
<rsalveti> awesome
<rsalveti> miken: thanks!
<pitti> rsalveti: right, live-build or vmdebootstrap are convenient starting points for building images
<fgimenez_> good morning
<seb128> hey there
<seb128> slangasek, hey, still up? any suggestion on how to get the personnal image on the system-image channels?
 * seb128 replied to emails before going to bed in case that would help to have things going during the european night but doesn't see a follow up in the morning :-/
<Chipaca> mo'in
<davmor2> Moe's Inn, mo'in the lawn, doing impressions of cows.....oh Morning Chipaca
 * Chipaca ignores the inane remarks, and considers seppuku, or more coffee
<davmor2> Chipaca: I'm only part way through my first coffee is my excuse and I'm sticking to it
 * Chipaca growls back
<davmor2> Chipaca: I know that feeling my back growls too, it's old age my friend ;)
<JamesTait> Good morning all; happy Ball Point Pen Day! ð
<mvo> Chipaca: sorry, no seppuku for you, you are way too important! coffee it is
<john-mcaleely> I have a noob question. reading: https://developer.ubuntu.com/en/snappy/guides/porting/
<john-mcaleely> I think it states that the kernel needs to support:  multiv7_defconfig
<john-mcaleely> niave browsing of the kernel tree suggests to me that's exisited (for arm) in versions 3.7 and higher of the kernel
<ogra_> well, it needs to use the same options
<john-mcaleely> does that mean I can say 'I need 3.7 or higher for easy porting with snappy'?
<john-mcaleely> ogra_, that makes sense
<john-mcaleely> ok, so am I right in thinking snappy uses the ubuntu vivid kernels today?
<Chipaca> john-mcaleely: very
<john-mcaleely> which looks like it might be 3.19 ?
<plorenz> hi - i've got a problem with updating snaps that are installed manually. i've installed my app's snap version 0.1 (containing a custom apparmor profile) and then used "snappy install <my package in version 0.2>" to update to a new version. the files and directories seem to be correct, but the daemon process won't start anymore with this error: "aa_change_onexec failed with -1. errmsg: No such file or directory"
<Chipaca> plorenz: that sounds like a bug
<Chipaca> plorenz: in us
<Chipaca> plorenz: are you on rollin'?
<plorenz> Chipaca: i'm on ogra_'s RPi2 image
<Chipaca> ogra_: was that cut from rolling?
<ogra_> Chipaca, 15.04 edge
<Chipaca> hmm, that shouldn't have my "don't build apparmor" bug
<ogra_> well, i know that apparmor doesnt regenerate the profile if youo dont bump the version ... but that doesnt seem to be the case here
<ogra_> but i guess the two packages use different namespaces
<ogra_> (.sidleoad vs .$developer)
<plorenz> interestingly, i can see a file "/sys/kernel/security/apparmor/policy/profiles/rda-watchdog.sideload_rda-watchdog_0.1.5" - but i guess this should rather be 0.2 ?
<plorenz> ogra_: they are both .sideload
<Chipaca> plorenz: what does 'snappy list' say?
<plorenz> Chipaca: "rda-watchdog 2015-06-10 0.2     sideload"
<Chipaca> plorenz: find /var/lib/apparmor -ls
<plorenz> Chipaca: http://pastebin.com/J29TzWwr
<Chipaca> plorenz: could you pastebin the systemd unit?
<plorenz> Chipaca: you mean the file /etc/systemd/system/rda-watchdog_rda-watchdog_0.2.service ?
<Chipaca> plorenz: yes
<plorenz> sure- http://pastebin.com/AHusnvfm
<Chipaca> /usr/bin/ubuntu-core-launcher rda-watchdog.sideload rda-watchdog.sideload_rda-watchdog_0.2 /apps/rda-watchdog.sideload/0.2/bin/rda-watchdog
<Chipaca> that seems correct to me
<Chipaca> the args are: qualified appname, apparmor profile, binary
<Chipaca> plorenz: can you run that by hand and report back?
<plorenz> Chipaca: maybe the wrong profile was loaded? in dmesg i see this after installing the updated snap: "operation="profile_replace" profile="unconfined" name="rda-watchdog.sideload_rda-watchdog_0.1""
<Chipaca> ahhh
<plorenz> (so version 0.1)
<Chipaca> hm
<Chipaca> yes
<plorenz> running it by hand gives the same error as above
<Chipaca> and i should have seen it the first time you said it, about the 0.1.5
<plorenz> (aa_change_onexec failed with -1. errmsg: No such file or directory)
<plorenz> :)
<Chipaca> plorenz: try: sudo aa-clichook -f
<Chipaca> aa-clickhook
<Chipaca> not clichook
<Chipaca> sorry :)
<plorenz> Chipaca: no problem, i figured that one out ;) but i still get the same error
<Chipaca> darn, and it's stupid-o'clock for most apparmor-savvy folks
<plorenz> hehe :)
<Chipaca> plorenz: pastebin "sudo apparmor_status" please
<Chipaca> i'm working from the manpages here :)
<plorenz> http://pastebin.com/nZFwZqwq
<plorenz> Chipaca: no problem :) as long as i can help
<Chipaca> plorenz: sudo apparmor_profile -a /apps/rda-watchdog.sideload/0.2/meta/rda-watchdog.apparmor
<plorenz> Chipaca: that gives me a command not found error :/
<Chipaca> because it's apparmor_parser
<Chipaca> not apparmor_profile
<Chipaca> sorry :)
<plorenz> Chipaca: hehe - okay, it says "Unable to add "rda-watchdog.sideload_rda-watchdog_0.1".  Profile already exists"
<plorenz> Chipaca: wait a second... i have my own apparmor profile included - maybe there's 0.1 somewhere
<Chipaca> ooooh
<Chipaca> looks like the profile is wrong
<plorenz> Chipaca: aaargh - yes, it is :( sorry!
<Chipaca> yeah
<Chipaca> heh! no worries. TIL.
<plorenz> thank you for your help :)
<plorenz> it's working with version 0.3 now
<fgimenez> hello everyone, quick question, can u-d-f be used to create images for bbb from the edge channel, 15.04 release?
<fgimenez> i'm using this sudo ubuntu-device-flash --verbose core 15.04 -o my-snappy.img --size 4 --channel edge --oem beagleblack --enable-ssh --device-part=./device.tar.xz
<fgimenez> but it doesn't boot (and no serial cable yet...)
<Chipaca> fgimenez: aiui that should work
<Chipaca> well, except the device part thing
<Chipaca> never used that
<Chipaca> fgimenez: want me to try with mine?
<fgimenez> Chipaca, i've been following https://developer.ubuntu.com/en/snappy/guides/porting/, the image generated for the stable channel works fine
<fgimenez> Chipaca, if you can give it a try it would be very helpful :) is there a log of the failed boots? i feel blind without this serial cable...
<rickspencer3> is there any documentation on how to use snappy configure or how to set up my snaps so it works?
<Chipaca> rickspencer3: did you read config.md?
<rickspencer3> um
<rickspencer3> Chipaca, can you tell me more?
<Chipaca> 1 sec
<Chipaca> rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/config.md
<Chipaca> it's probably also on developer.u.c but dunno where. dholbach?
<fgimenez> Chipaca, after trying again it's booting just fine with edge, perhaps i missed before a sync command, thanks!
<Chipaca> fgimenez: ah, good! because my sd card seems to have dieded
<Chipaca> fgimenez: or maybe my sd reader. or maybe i need to reboot.
<rickspencer3> Chipaca, so I write a program that takes standard input and outputs a yaml file?
<Chipaca> rickspencer3: yep
<rickspencer3> then snappy restarts the service, which presumably reads the new yaml and goes?
<rickspencer3> Chipaca, seems like we could make a simple Go app for the handler, at least as a sample to get folks started
<rickspencer3> or is there something available already to get me started?
<rickspencer3> (maybe an example shell script?)
<ogra_> i think sergiusens had one
<ogra_> but it is essentially that ... create a yaml file snappy reads then
<ogra_> (pretty awful if you ask me)
 * ogra_ would like to see "snappy config <package> <key>=<value>" instead
<rickspencer3> ogra_, oh, that is not how the command works?
<ogra_> no, you need to pipe the yaml into it iirc
<ogra_> or point it to the file
 * ogra_ tries to find the example
<rickspencer3> interesting
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/config-example/bin/hello
<dholbach> Chipaca, https://developer.ubuntu.com/en/snappy/guides/config-command/
<rickspencer3> hmmmm
<rickspencer3> dholbach, I saw that
<rickspencer3> but there is no example of the user using the command
<rickspencer3> nor any source code to show how to implement the hook
<ogra_> snappy config <package> /path/to/yaml
<rickspencer3> ogra_, right, and it looks like you can supply the yaml by just typing it on standard in
<rickspencer3> I need clearer explanations and samples to do the correct implementation myself
<rickspencer3> ogra_, so it looks like my hook needs to be a program that configures the snap
<rickspencer3> in my case, my snap is configured with a yaml file
<rickspencer3> so I need a hook that parses the yaml file, then updates it with the new content that the user specified with the snapppy config command
<rickspencer3> I know how to do this in Go, but what would you suggest for writing this?
<rickspencer3> Go worries me because then I would have to compile the hook, and then deal with multi-arch
 * ogra_ hasnt rolled packages with config hooks yet ... but i would use shell and parse the yaml 
<Chipaca> ogra_: you'd parse yaml with sh?
<ogra_> i'd parse everything non-binary with shell :)
<rickspencer3> ok
<rickspencer3> I'm not too great with sh :/
<rickspencer3> far from my forte
<ogra_> well, then use whatever else you like ... but ship the interpreter if its an interpreter lang
<rickspencer3> ogra_, no, I can try sh
<rickspencer3> I want to do the best example implementation that I can
<rickspencer3> it seems like reading a yaml file and updating it and then rewriting it should be doable
<Chipaca> rickspencer3: note you'll be given your current config as stdin
<Chipaca> rickspencer3: so if it's a simple transformation, maybe you can express it with sed
<rickspencer3> uh
<mvo> rickspencer3: is the rest of your app written in go as well?
<rickspencer3> mvo, yes
<rickspencer3> but, I would rather have a re-usable component
<ogra_> well, then you need to handle the multiarch bit anyway
<ogra_> as well as the compiling
<ogra_> so shell wouldnt really be an advantage
<rickspencer3> ogra_, well, I won't necessarily write all my apps with Go
<sergiusens> rickspencer3: the reusable component part is complicated
<sergiusens> rickspencer3: the external interface is yaml, but internally it can be anything
<ogra_> rickspencer3, sure, but for a go app i would also use go for the config
<rickspencer3> sergiusens, right, I get that
<mvo> rickspencer3: TBH the yaml config and the lack of sh based tools bother me as well, I wrote a python based xpath like yaml thing in one of the config examples, but its really not great
<rickspencer3> my app reads a yaml file on startup
<ogra_> the only advantage of shell is that you dont need to compile anything and it is always available
<rickspencer3> so, I assumed the hook would write out that file
<sergiusens> rickspencer3: e.g.; https://github.com/sergiusens/camlistore.snap/blob/master/meta/hooks/config
<sergiusens> but that might not work in the future :-)
<mvo> rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/config-example-bash/meta/hooks/ but you probably saw this already
<rickspencer3> mvo, I did not, but ... I thought using Python without including your own Python?
<dholbach> mvo, https://bugs.launchpad.net/snappy/+bug/1463804 is the bug you asked me to file
<ubottu> Ubuntu bug 1463804 in Snappy "Convert click manifest to package.yaml automatically" [Undecided,New]
<sergiusens> rickspencer3: python is 15.04 material, guaranteed to stick
<rsalveti> morning
 * ogra_ would still not recommend using the system one ... 
<ogra_> to keep your apps future proof
<rsalveti> sergiusens: not sure it is guaranteed to stick
<rickspencer3> yeah
<rsalveti> who knows what is ahead of us :-)
<sergiusens> rsalveti: on 15.04 yes
<sergiusens> on rolling no
<Chipaca> sergiusens: mvo: rsalveti: what if we added support to the core launcher so that, if told to exec a directory, we exec directory/$arch ?
<sergiusens> rsalveti: we said once something was released, everything on there would stick
<rsalveti> sergiusens: right, I get that, but last time I asked about python nobody was completely sure
<rsalveti> but I get your point
<rsalveti> would still recommend not using the system one though, to avoid it being only compatible with 15.04
<sergiusens> rsalveti: oh, but that's a developer choice
<sergiusens> rsalveti: and that means we need to remove half of our example packages ;-)
<rickspencer3> yeah, but I don't want to repackage everything for 16.04 if things change, so I'll probably go with sh
<rsalveti> sergiusens: that might be a good idea, yeah
<sergiusens> python3 in the apparmor allowance, so it's fine for 15.04
<rsalveti> once ogra_ is done with the next python tutorial that includes the interpreter
<ogra_> yeah, need to talk to ricmm today about that :)
 * Chipaca should make an example using micropython
<mvo> rickspencer3: yeah, I'm cheap and I know it will continue to work on 15.04. but 16.04+ its all up in the air
<rickspencer3> hehe
<rickspencer3> mvo, I just want to make sure that when I write stuff, it is the "right" stuff
<rsalveti> fgimenez: you don't need to use --device-part=./device.tar.xz when creating the beagle image
<rsalveti> unless you want to force your local device tarball
<mvo> Chipaca: I'm in favour for auto-magic for multi-arch, i.e. find the right binary, setup LD_LIBRARY_PATH - there is even a branch for that
<Chipaca> oooh
<rsalveti> --oem beagleblack should already take care of all the dependencies
<Chipaca> mvo: what blocks it?
<mvo> rickspencer3: yeah, that is indeed the better approach :) I wonder if we should provide a go based helper for sh ?
<ogra_> heh
<mvo> Chipaca: I blame sergiusens https://code.launchpad.net/~mvo/snappy/snappy-binary-ld-library-path-wrapper/+merge/252560
<Chipaca> mvo: *always* blame sergiusens
<fgimenez> rsalveti, ok, much better, i'll update the notes in the pad
<Chipaca> mvo: you'll have better-than-random chance of being right
<ogra_> rsalveti, fgimenez waas trying ou the porting guide ...
<ogra_> *out
<mvo> rickspencer3: I mean, something that helps you extract your config a bit like this python-yaml-helper but as part of the system. wdyt?
<sergiusens> mvo: Chipaca wat did i do?
<ogra_> (device tarball makes sens then i guess)
<ogra_> +e
<mvo> Chipaca: heh :)
<rickspencer3> mvo, I think that I should be able to use a standard place/name for the snap configuration yaml
<Chipaca> sergiusens: mvo: i think we should put together a branch that did this, and put it up for discussion
<rickspencer3> and then snappy automatically does config for me
<rickspencer3> tbh
<sergiusens> mvo: Chipaca oh; well it is unanswered ;-)
<sergiusens> and WiP
<rickspencer3> I don't see why I have to write a hook if I am not doing something custom
<Chipaca> sergiusens: still blaming you
<sergiusens> Chipaca: heh, this at least needs to be accompanied by proper documentation ;-)
<Chipaca> rickspencer3: me, i think we should have "snappy set $package config=key:value" work
<fgimenez> ogra_, i was taking it as a reference for creating bbb images with u-d-f, it's the only place in the guides where i find this mentioned
<rsalveti> ogra_: right, if trying from the porting guide it's fine :-)
<rsalveti> indeed, we don't have anywhere showing how to use ubuntu-device-flash
<ogra_> fgimenez, for "just creating" you dont need the device bit
<ogra_> it will simply pull it from the system-image server
<fgimenez> ogra_, ok thx
<mvo> rickspencer3: that is a good point
<mvo> rickspencer3: looks like when we designed this we optimized for the uncomon case :/ for the sake of flexibility. let me try to draft something
<rickspencer3> mvo, I think I can simulate it in the meantime by writing sh script that "just works" in the meantime
<rickspencer3> where "just works" == if you name your yaml file in a certain way, the script will handle reading and writing to it
<sergiusens> rickspencer3: well, you can't guarantee shell scripting would be accesible in the future either
<rickspencer3> (and interacting with the snappy config command, o course)
 * sergiusens is trying to make a point
<rickspencer3> sergiusens, really?
<rickspencer3> sh may stop working?
<sergiusens> rickspencer3: that is the mantra of rolling, anything, anything can stop working
<rickspencer3> wow, I have trouble envisioning such a system and how it would work
<sergiusens> rickspencer3: what I'm saying is that it's hard to plan for something that hasn't been released
<rickspencer3> sergiusens, I think there are some things that we can predict better than others
<rickspencer3> I think "you might have to package your own Python" is more likely than "you have to package your own sh"
<rickspencer3> but, that said, noted
<sergiusens> rickspencer3: right, but you might get something lesser than dash
 * rickspencer3 nods
<sergiusens> not compatible with whatever you script
<rickspencer3> right,  I get it
<ogra_> sergiusens, i think you can be sure that all shells we ever ship will be POSIX compliant at least
<ogra_> ash, dash or busybox will all work with proper POSIX script
<Chipaca> ogra_: depends how you configure busybox
<Chipaca> :)
<Chipaca> the smallest busybox shell was not very posix
<ogra_> oh
<ogra_> yeah, that might be
 * Chipaca wins at pedantic
<ogra_> indeed i assume the busybox binaries you can currently find in ubuntu
<Chipaca> you could shave *kilobytes* by having it not support background processes, if i remember correctly
<ogra_> gigantic !
<ogra_> :)
<sergiusens> mvo: btw, thanks for the reviews!!!!
<sergiusens> :-D
<mvo> sergiusens: your welcome
<mvo> rickspencer3: how does http://snappy.asac.ws:9001/p/snappy-config-simplify look? as a straw-man - feel free to remove my germanism in there (and/or improve the entire approach :)
<rickspencer3> mvo, I'll look right after this call
<mvo> sure
 * sergiusens wonders who the green dude is
<Chipaca> that's rickspencer3 i think
<Chipaca> the "restart your snap" makes me think so :)
<rickspencer3> mvo, I did myt best to express myself
<rickspencer3> sergiusens, Chipaca, yeah, that was me
<rickspencer3> how did you know I was a dude?
<Chipaca> rickspencer3: you have very masculine handwriting
<rickspencer3> anyway, this is how I think the developer should be
<rickspencer3> I think that we have the custom case implemented, but not documented holistically yet
<rickspencer3> I *think* that I can write a walk through that teaches how to do it, though
<sergiusens> I thought dude was gender neutral these days :-)
<ogra_> what would be the female variant of dude ? dudette ?
<rickspencer3> anywhoooo ...
<Chipaca> sergiusens: ogra_: depends where you are; some places it's neuter; other places, yes, dudette
 * rickspencer3 moves on before a sjw shows up
 * ogra_ sighs about his laptop doing another emergency shutdown due to overheating :( 
<rickspencer3> I wonder if we need to design an end to end tutorial that includes all of the conventional ways of building an app for snappy?
<rickspencer3> https://msdn.microsoft.com/en-us/library/aa716527(v=vs.60).aspx
<ogra_> crappy vivid :(((
<rickspencer3> ^ dates me, but I always liked that they had that
 * sergiusens installs vb6
<rickspencer3> haha
<ogra_> rickspencer3, what are the "conventional ways" ?
<sergiusens> heh, maybe I should get back to work instead :-P
<ogra_> you have so many possibilitied
<ogra_> *possibilities
<rickspencer3> ogra_, indeed, but ...
<rickspencer3> there are conventions also
<sergiusens> the conventional way is the no brainer snapcraft way ;-)
<rickspencer3> I should be able to ask "what is the best way to do x"
<rickspencer3> and  there should be an answer
<ogra_> yeah, snapcraft for everyone !
<rickspencer3> for a greenfield
<rickspencer3> I think that we need to support two forks of developers
<rickspencer3> and we are smartly focused on fork 1 now ... people who have apps that need to be converted to snaps
<rickspencer3> but, even there, there are probably conventions
<rickspencer3> and snapcraft will be the tool for those conventions :)
<ogra_> we are literally just inventing these conventions
<rickspencer3> but, I am in fork 2, I want to write new apps for IoT
<rickspencer3> ogra_, I know
<rickspencer3> :)
<ogra_> once we have them we will indeed document them
<rickspencer3> but, there is a lot of implicit knowledge in the development team now
<rickspencer3> most of my questions do have answers, it's just really really hard to get them written down, especially when 60% of it could easily change in a week ;)
<mvo> rickspencer3: +1 on better end-to-end tutorial
<mvo> rickspencer3: ehh, s/better/an/ - 'cause there is none yet :)
<rickspencer3> mvo, I have written a file uploader program that uses a yaml file for configuration
<rickspencer3> I'll change it to use snappy config
<rickspencer3> https://code.launchpad.net/~rick-rickspencer3/+junk/go-uploader
<rickspencer3> then I can write a tutorial :)
<mvo> rickspencer3: as for the config - does it sound acceptable if I change (2) so that your app reads from a SNAP_CONFIG_FILE environment? the reason I ask is that ideally /apps/$pkg/$ver/ is a bit of a read-only space and we want to verify that its unaltered on disk. so separating the config into a different dir would be nice. also its useful to keep the original config around for a 3-way merge (but that could be done in different ways of course)
<mvo> rickspencer3: nice project
<rickspencer3> mvo, sure
<rickspencer3> all I want is that I can not worry about implementing snappy config
<rickspencer3> if I follow the rules, I want snappy config to do the work for me
 * mvo nods
<mvo> rickspencer3: I created a trello card for your suggestion so that it won't get lost https://trello.com/c/XHloYivT - I think its a really good idea to make this simpler
<rickspencer3> thanks mvo
<rickspencer3> meanwhile, I work on a walkthrough for the "custom" solution
 * mvo nods
<rickspencer3> since we should at least explain that since it really works
<mvo> yeah
<rickspencer3> I need to do this for my home IoT Gateway, anyway
<sergiusens> mvo: can you check https://code.launchpad.net/~sergiusens/snappy/upload/+merge/261563 again please?
<mvo> sergiusens: sure
<mvo> sergiusens: very impressive!
<rickspencer3> mvo, so I am not actually sure where to put my file-upload.yaml
<rickspencer3> do I put it next to the executable?
<rickspencer3> i.e. in /bin/whateverarch/file-upload.yaml
<rickspencer3> ?
<mvo> rickspencer3: you mean right now with the current mechanism? the recommended place is in $SNAP_APP_DATA_PATH
<rickspencer3> mvo, can you show me what that would like in the shell, i.e. appname/?
<sergiusens> mvo: thanks
<mvo> rickspencer3: something like "printf "key: value" > ${SNAP_APP_DATA_PATH}/myconfig.yaml" you mean?
<mvo> rickspencer3: hope I did not misunderstand the question
<rickspencer3> mvo, sorry, my question is even more basic
<rickspencer3> my snap package has bin and meta, right?
<mvo> yes
<rickspencer3> so, is there a place in there that is normal for yaml to go?
<rickspencer3> my bin is laid out with bin/amd64, bin/Arm
<mvo> aha, just create a dir for that, config/ or etc/ or cfg/ or data/
<mvo> and put your base config in there
<sergiusens> kyrofa: how about a quick hangout?
<rickspencer3> mvo, at the top level, so it is bin/ meta/ cfg/ ?
<mvo> yeah
<mvo> I think thats a sensible layout
<rickspencer3> k
<rickspencer3> thanks
<rsalveti> mvo: thanks for starting the release notes :-)
<rsalveti> mvo: elopio: fgimenez: sergiusens: ogra_: so it seems we're good to go, right?
<rsalveti> ogra_: care to promote 82 into stable?
<rsalveti> mvo: sergiusens: do you guys also know what needs to be done for promotion?
<sergiusens> rsalveti: I tested with u-d-f but only last night, nothing today
<kyrofa> sergiusens, I've got standup in a few minutes. Can I ping you after?
<ogra_> rsalveti, after i rebuilt it with the changes we just discussed and tested it
<ogra_> rsalveti, oh, you talk about the official image ?
<sergiusens> rsalveti: prebuilts or promotion?
<mvo> rsalveti: I don't know, I think there is a mail from steve somewhere how that works, but documenting it would be good I think
<sergiusens> for prebuilts, after promotion
<sergiusens> kyrofa sure
<sergiusens> mvo: promotion is as on the phone, I bet ogra_ knows the flow
<rsalveti> sergiusens: ogra_: not prebuitls, promotion itself
<rsalveti> like we do for the phones
<rsalveti> we basically need to promote 82 into stable
<ogra_> right, thats just a call to copy-image but i need the exact channel names
<rsalveti> and then I can create the pre-built images
<rsalveti> yeah, would be nice to document that
<rsalveti> I created the card https://trello.com/c/PUpWXouz/89-stable-release-checkpoints to be a placeholder for release related things
<fgimenez> rsalveti, tested the full suite in kvm, "long" upgrade path (stable -> edge -1 -> edge), rollback and failed boot in bbb, no new issues
<ogra_> rsalveti, mvo, do we promote whatever cruft is in 15.04/edge/generic_arm64 ?
 * jdstrand wonders how plorenz had a version in "his own apparmor profile". Maybe he is using "security-policy" and didn't write the profile with the correct variables to be expanded via aa-profile-hook...
 * jdstrand shrugs
<ogra_> and do we promote azure images too ?
<mvo> fgimenez: what does no *new* issues mean, do we have existing ones (sorry if this is a silly question)
<mvo> ogra_: arm64? I doubt this even works :/ no idea why its there in the first place
<ogra_> well, something gets regularly imported into edge :)
<ogra_> whatever that is
<sergiusens> ogra_: rsalveti mvo what do you think of http://snappy.asac.ws:9001/p/promotion
<fgimenez> mvo, i mean that nothing new has arisen, sorry if it wasn't clear enough :)
<ogra_> sergiusens, what is alpha ?
<sergiusens> ogra_: a channel
<ogra_> sergiusens, any why do we need it ?
<mvo> fgimenez: cool, nothing new and nothing old so no known issues, thats  great, thanks a lot for the testing
<ogra_> we test from edge
<sergiusens> ogra_: to make sure the upgrade from what is in stable to what goes to edge is going to work
<ogra_> well, creating channels is a slangasek thing i guess ...
<ogra_> (i could poke around in the config but i have never added a new channel and would feel more comfortable if someone does that who has experience)
<rsalveti> ogra_: sergiusens: right, we don't have an alpha at the moment
<rsalveti> we can promote from edge to stable now and then work on creating the alpha
<ogra_> ok
<sergiusens> rsalveti: I know we don't, but it's an easy way to test the upgrade path as a final step
<rsalveti> for now having alpha won't change anything, right?
<rsalveti> sergiusens: how different that would be from stable -> edge?
<sergiusens> rsalveti: doing a channel change triggers a full image update
<rsalveti> sergiusens: right
<ogra_> you have one test channel where you can try out automated upgrades fir4st
<ogra_> makes sense
<rsalveti> then we'd need to create it :-)
<ogra_> right
<elopio> buenos dÃ­as
<fgimenez> elopio, hey! good to see those "i" with accent around :)
<elopio> fgimenez: :) how are you today?
<elopio> davidcalle: I want to make some small changes on the guides that are not in the snappy branch. How can I edit those docs?
<sergiusens> jdstrand: not sure it's my image, but is ReleaseName allowed? [ 3993.417227] audit: type=1107 audit(1433945875.311:61): pid=604 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="ReleaseName" mask="send" name="org.freedesktop.DBus" pid=1439 label="hello-dbus-fwk_srv_1.0.0" peer_label="unconfined"
<davidcalle> elopio, you can have editor access on the website with the lp team: https://launchpad.net/~ubuntudeveloperportal-editors
<elopio> dpm: can you please approve my membership there? ^
<elopio> davidcalle: what's the review process? I would like you or somebody else to check what I change before it goes live.
<fgimenez> elopio, fine, getting to know this bbb thing :)
<jdstrand> mvo: hi! with the mtime patch from jjohansen, do we still need to have the meeting today?
<davidcalle> elopio, when you edit a page, you are in "draft" mode, other editors have access to it, just ping me when you are done :)
<rickspencer3> hmmm
<dpm> elopio, done
<elopio> davidcalle: dpm: thanks.
<mvo> jdstrand: I thought I replied by mail, as far as I'm concerned we are fine and I don't need the meeting
<rickspencer3> can anyone advise me on the best way to refer to a file path in Go code in a snap?
<mvo> jdstrand: his patch is the outcome I had hoped for from the meeting
<rickspencer3> is just using "../../data/" considered ok, or is there a better, more reliable way?
<davidcalle> elopio, I have to run for ~1h , dpm or dholbach, do you mind sending the editors guide link to elopio?
<dpm> davidcalle, already done :)
<davidcalle> dpm :)
<jdstrand> mvo: oh you did-- I'm still going through my inbox and I filtered on 'cache', but the subject said 'caching'
<jdstrand> mvo: ok-- we may want to revisit this in the future, but I'll cancel the meeting for now
<mvo> rickspencer3: its probably better to use "dir := os.Getenv("SNAP_APP_DATA_PATH")" (or any of the other ones)
<mvo> jdstrand: revisit for a different approach like using hashes? as long as the functionatlity remians  I don't mind how its implemented :)
<rickspencer3> thanks mvo
<ogra_> sergiusens, rsalveti, alpha channel has been created (will show up with the next importer run)
<jdstrand> mvo: no, I more meant make sure we are satisfying all of snappy's needs
<ogra_> and there it is
<jdstrand> rsalveti: I think you scheduled the apparmor caching meeting-- can you remove it?
<mvo> jdstrand: ok
<rsalveti> ogra_: and are we importing the current stable images in there?
<rsalveti> jdstrand: sure
<jdstrand> thanks
<ogra_> rsalveti, it is a completely dead channel, only for manual copying
<ogra_> rsalveti, but yes, i'm doing exactly that right now
<rsalveti> ogra_: awesome
<davidcalle> elopio, good luck! Feel free to ping me when I'm back if you have issues with the edition, some aspects of the cms can seem tricky the first time
<elopio> davidcalle: will do.
<ogra_> oh
<ogra_> and i see, stable only has armhf and amd64
<mvo> yes, thats ok
<mvo> we never released a stable i386 yet
<ogra_> ok, "alpha" now has the stable image 2 in it
<ogra_> now everyone needs to install that ... and i can copy the latest from edge
<rsalveti> http://www.ronpaul.com/wp-content/uploads/2015/03/its-happening.jpg \o/
<ogra_> heh
<mvo> haha
<ogra_> hmm
<ogra_> using --enable-ssh instead of --developer-mode refuses to use my oem snap
<gatisp> Hi. I was wondering if there is a snappy command for selecting older core image version? I have freshly flashed device with a latest version, so there is nothing to rollback to, but maybe there are another ways to get older version? This part does not seem to be documented anywhere. Thanks.
<ogra_> gatisp, ubuntu-device-flash has a --revision option that you could use to create an older image
<gatisp> ah ok, will check. Did not know about that tool, I just downloaded the *.img file and dd-ed to Rpi2
<ogra_> sergiusens, hulp ... how do i create an image without having my personal ssh key inside when i use a local oem snap ?
<ogra_> Determining oem configuration
<ogra_> 2015-06-10 14:45:29 ERROR snappy logger.go:199 pi2_0.13_all.snap failed to install: Signature verification failed with exit status 10
<ogra_> pi2_0.13_all.snap failed to install: Signature verification failed with exit status 10
<ogra_> (for details)
<sergiusens> ogra_: ah, you can't
<ogra_> damn
<sergiusens> ogra_: sort of to avoid random non signed pkgs distributed
<ogra_> sure, i get the reason
<sergiusens> ogra_: well, build it from a user with no keys I guess
<sergiusens> ogra_: that's a workaround :-P
<sergiusens> ogra_: also, why not put your rpi snap into the store?
<ogra_> will it then just give me a normal usr/password login ?
<ogra_> yes, i was planning that
<sergiusens> ah, you need to override anyways due to the device part
<ogra_> i just have never done an oem snap :)
<mvo> ogra_: fwiw, I created amd64/armhf image from the alpha channel now, so let me know once they can/should be upgraded
<ogra_> sure, but it makes sense to eventually update the store one
<sergiusens> ogra_: it should just work (random user no keys and --developer-mode)
<ogra_> mvo, i wanted to make a call in the standup and once everyone who participates is ready i'll just copy edge on top and upgrades should magically happen
<mvo> cool
<ogra_> sergiusens, ok, i'll try that
 * ogra_ guesses just moving ~/.ssh out of the way should be enough
<sergiusens> beuno: if I have snappy pakage N available for release X and X+1, upload N+1 and only tag it for X+1, what happens to N that was on X
<sergiusens> ?
<sergiusens> beuno: I'm asking because the channels document mentions this is working already, but I don't think it is
<beuno> sergiusens, not what it should
<beuno> there's oversight there
<beuno> where we need 2 versions of the app available at the same time for different releases
<sergiusens> beuno: shouldn't it work though?
<beuno> sergiusens, the newest version is the only one that will be available
<beuno> so that's something we need to fi
<sergiusens> more so since we are diverging 15.04 and rolling as days pass
<beuno> indeed
<beuno> sergiusens, can you file a bug pretty please?
<sergiusens> beuno: ack
 * sergiusens just uploaded the last * release compatible webdm
<ogra_> Enabling developer mode...
<ogra_> failed to obtain a public key for developer mode: open /home/ogra/.ssh: no such file or directory: no pub ssh key found, run ssh-keygen first
<ogra_> aha
<ogra_> that looks good then
<ogra_> (but now i'm not sure which webdm i got :P)
<sergiusens> beuno: bug 1463872
<ubottu> bug 1463872 in Software Center Agent "Support a version to live published per release" [Undecided,New] https://launchpad.net/bugs/1463872
<sergiusens> ogra_: you might want 0.9
<ogra_> sergiusens, i know what i want
<sergiusens> lol
<ogra_> i just dont know what i got :)
<ogra_> u-d-f doesnt tell me the version
 * ogra_ will re-create after the meeting ... by then 0.9 should surely have promoted i guess
<beuno> nessita, FYI bug 1463872
<ubottu> bug 1463872 in Software Center Agent "Support a version to live published per release" [Undecided,New] https://launchpad.net/bugs/1463872
<nessita> beuno, checking
<sergiusens> beuno: also, your input on this is welcomed https://myapps.developer.ubuntu.com/dev/click-apps/2822/feedback/
<kyrofa> sergiusens, alright, I'm out of meetings now. You available?
<sergiusens> kyrofa: that was a long standup!
<sergiusens> kyrofa: I now have mine :P
<beuno> sergiusens, done
<sergiusens> ty
<kyrofa> sergiusens, we have it every day, and for some reason today my uncaffeinated mind thought it was a half hour earlier :P
<kyrofa> sergiusens, I sat around wondering why people were so late for a while
<kyrofa> sergiusens, anyway, the rest of my day is free. Just ping me when you've got some free time :)
<sergiusens> kyrofa: ok, I'll ping after lunch if that's fine; what your timezone btw?
<kyrofa> EST-- I'm in Virginia
<nessita> sergiusens, beuno we don't support different version per releases, I think that will be possible with channels. Without channels, a package can have only one "live and valid" upload at a time
<nessita> this is the same behavior as with frameworkds
<nessita> beuno, the goal was to avoid developers neglecting older version in older frameworks
<beuno> nessita, yes
<beuno> I think releases are different
<beuno> because they are built to co-exist
<beuno> so we'll need to think about that
<sergiusens> there is overlap with releases
<sergiusens> right
<sergiusens> as in support timeframe
<nessita> beuno, right, currently releases are the same a frameworks with other name
<nessita> beuno, so this new requirement combined with channels will be super extra interesting to design and implement
<beuno> nessita, don't need to combine them
<beuno> just FYI
<nessita> "fun" fabian says
<beuno> we'll figure out priorities
<nessita> beuno, combined at code level, I mean :-)
<beuno> nessita, this is why people become managers
<nessita> beuno, to think about when priotitizing: are we allowing targetting different releases in each upload in each channel?
<nessita> I mean, the index will soon start returning results for a specific channel only
<beuno> nessita, we will need to allow uploading different binaries to different releases to different channels
<Chipaca> mvo: https://github.com/google/gxui/blob/master/samples/progress_bar/main.go :-p
<longsleep> sergiusens: If possible we can discuss OEM snap submissiong name scheme here as well (regarding ODROID snap sumission feedback on app 2822).
<nessita> beuno, exactly, so, "boom in heads and in source code", but of course, always doable
<nessita> beuno, let me add this to the backlog
<beuno> nessita, thanks, sorry
<mvo> Chipaca: oh? is that a new/different progress bar? I was too lazy to be honest to look for a different one than the "gb" i was using
<elopio> utlemming: do you have some time today to talk about the testing your team does for the snappy cloud images?
<mvo> sergiusens: re cache> one option might be to do what python-httplib2 is doing and cache transparently by storing the http headers (i.e. valid-until etc) plus the content and simply use that to check if the net needs to hit at all etc. that was used in s-c-agent
<sergiusens> mvo: right, that was my last idea; transparent caching proxy, would solve all scopes in general
<mvo> sergiusens: yeah, I used it quite successfuly in the past
<Chipaca> we can construct a unique version number, thus: 2^(kernel #) + 3^(device #) + 5^(os #) + ... + prime_n^(# of part_n)
<mvo> Chipaca: heh, indeed
<ogra_> *********** I give everyone another 30mins to install an alpha image and in 30min i will copy over the edge image into the channel **************
<Chipaca> mvo: wrt progress bars, i was kidding about gxui (it's too green yet). That program, when run, looks something like http://i.imgur.com/ta4AE1Q.gif
<sergiusens> ogra_: so heavy
<ogra_> (speak up if thats to short)
 * Chipaca goes to get some tea
<ogra_> sergiusens, i'm a drama queen ;)
 * Chipaca didn't know we supported alphas, goes to dig his out of the attic
<mvo> Chipaca: I don't even know what gxui is
<ogra_> sergiusens, is webdm 0.9 published ?
<sergiusens> ogra_: it should be, let me check
<sergiusens> ogra_: search.apps.ubuntu.com/api/v1/package/webdm
<sergiusens> it is
<Chipaca> mvo: google's experimental green-as-a-Nezara-viridula cross-platform ui library
<ogra_> sergiusens, awesome, thanks !
 * ogra_ re-rolls the pi image
<sergiusens> elopio: is the selftest stuff documented?
<ogra_> no webdm ... and cloud-init spills errors on my new pi image :(
<ogra_> ï¿½[  235.955313] cloud-init[832]: 2015-06-10 15:49:14,086 - url_helper.py[WARNING]: Calling 'http://192.168.2.2/latest/meta-data/instance-id' failed [50/120s]: request error [HTTPConnectionPool(host='192.168.2.2', port=80): Max retries exceeded with url: /latest/meta-data/instance-id (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x75e0b530>, 'Connection to 192.168.2.2 timed out. (connect timeout=50.0)'))]
<ogra_> not sure why it wants to do a web request to my firewall
<ogra_> seems it also never reaches the login prompt :/
<ogra_> it prints that error for 10min now
<Chipaca> ogra_: we're talking âubuntu-device-flash core 15.04 --channel alpha -o 15.04-alpha.img --developer-modeâ, yes?
<ogra_> Chipaca, for the test ? yeah
<ogra_> aha, now webdm started
<ogra_> this delay is awful :/
<ogra_> ogra@anubis:~/datengrab/rpi$ ssh ubuntu@webdm.local
<ogra_> ssh: connect to host webdm.local port 22: Connection refused
<ogra_> sigh
<ogra_> sergiusens, so there seems to be no sshd running now
<ogra_> hmpf
<ogra_> and i cant log in on serial console either
<sergiusens> ogra_: that's worrisome
<ogra_> localhost login: ubuntu
<ogra_> Password:
<ogra_> Login incorrect
<ogra_> thats what i get on serial
<sergiusens> ogra_: it's broken here too...
<sergiusens> preinstalled webdm that is
<ogra_> well, webdm started eventually
<ogra_> just took pretty long
<ogra_> no login is more worrysome i think
<sergiusens> aa_change_onexec failed
<sergiusens> Chipaca: ^
<sergiusens> do you know?
<sergiusens> Chipaca: created with sudo ubuntu-device-flash core 15.04 --channel alpha --install webdm --output amd64-webdm.img
<Chipaca> sergiusens: unless something is built against snappy trunk from last week, no
 * Chipaca tries installing hello-world
<Chipaca> things installed with snappy directly work
<Chipaca> now to try webdm
 * ogra_ notices that the icons for an installed snap vanish from the webdm UI 
<ogra_> (showing the generic icon only)
<ogra_> hmm, no
<ogra_> snake is fine, only chatroom changes the icon after install
<ogra_> so how do i get my login back now :(
<ogra_> seems i need some random ssh key ?
<ogra_> (since without any ssh key it doesnt seem to work at all)
<Chipaca> sergiusens: confirmed, things installed with webdm are missing apparmor
<Chipaca> sergiusens: meaning you've built it against snappy trunk
<Chipaca> sergiusens: before the mangle branch landed
<Chipaca> sergiusens: tut, tut
<Chipaca> sergiusens: also, sorry :-/
<sergiusens> Chipaca: well, it's u-d-f, not webdm
<ogra_> 0.10 is a nicer version number anyway
<Chipaca> sergiusens: what is?
<sergiusens> Chipaca: I'm not suing snappy trunk for webdm
<Chipaca> sergiusens: ah, you get that from the installed webdm?
<sergiusens> Chipaca: yes
<Chipaca> sergiusens: because i get that from packets installed from webdm
<sergiusens> Chipaca: webdm is locked to launchpad.net/snappy    bzr     snappy_tarmac-20150507103214-pgd90adryua6v6wi   444
<sergiusens> Chipaca: but this error is from webdm itself
<Chipaca> and indeed i see the apparmor files
<Chipaca> then why am i getting this error?
<Chipaca> wat
<Chipaca> ah, it's because i can't read
<sergiusens> Chipaca: hmm, no symlinks in /var/lib/apparmor
<Chipaca> rsalveti: a reminder that i'm away friday and monday
<Chipaca> rsalveti: clearly you won't lose much :-/
<sergiusens> rsalveti: we need a new snappy release and a u-d-f rebuild ^
<Chipaca> sergiusens: why a snappy release?
<sergiusens> Chipaca: u-d-f builds from snappy packages
<sergiusens> Chipaca: if the apparmor stuff is broken in lp:snappy, we need a new snappy release to rebuild u-d-f
<Chipaca> the error i see is about /tmp being wrong
<sergiusens> Chipaca: so core launcher?
<Chipaca> sergiusens: the apparmor stuff *was* broken in lp:snappy, but is now fixed
<Chipaca> sergiusens: but this is in pre-update alpha channel
<sergiusens> Chipaca: don't confuse me
<Chipaca> sergiusens: so it's the known one
<sergiusens> Chipaca: oh, right!
<sergiusens> so confusing :-P
<sergiusens> Chipaca: sorry
<sergiusens> rollback rsalveti
 * sergiusens goes for lunch
 * Chipaca can't remember what the old rsalveti looked like
<ogra_> more beardy
<ogra_> sergiusens, so all is fine ?
<ogra_> hmpf
<ogra_> so even with a randomly generated key i cant get an ssh login now
<ogra_> aha, IP works ... webdm.local doesnt
<ogra_> funny, since it works in the browser
<ogra_> ************** copying edge over to alpha *NOW* .... ****************
<ogra_> you should see a version 3 now
<Chipaca> yes
<ogra_> happy upgrading then :)'
<ogra_> ogra@anubis:~/datengrab/rpi$ ping webdm.local
<ogra_> PING webdm.local (254.193.204.33) 56(84) bytes of data.
<ogra_> WOAH !
<ogra_> seems it is hopping between 254.193.204.33 and 192.168.2.25 ... how can .local ever resolve to a real address ?!?
<conyoo> am i doing something wrong?
<conyoo> sudo snappy rollback webdm
<conyoo> panic: runtime error: invalid memory address or nil pointer dereference
<conyoo> [signal 0xb code=0x1 addr=0x20 pc=0x5ca3b1]
<ogra_> Jun 10 16:26:52 localhost kernel: [  859.165000] audit: type=1400 audit(1433953612.650:14): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chatroom.ogra_chatroom_0.1-8" pid=2159 comm="apparmor_parser"
<conyoo> snappy list -v
<ogra_> ERR
<conyoo> webdm          2015-06-07 0.8
<conyoo> webdm          2015-06-10 0.9        *
<ogra_> why is that unconfined ?
<Chipaca> conyoo: noice
<Chipaca> conyoo: how did you get to that?
<Chipaca> conyoo: in answer to your question though, maybe, but the panic is ours to fix
<ogra_> well, would be interesting to know what HW that happens on
<conyoo> Chipaca, i don't really know what i'm doing :)) i am just playing with snappy but i get this error when trying the rollback command. i was wandering if i'm using it wrong or it's just a bug :))
<Chipaca> conyoo: it's a bug. steps to reproduce would be very helpful.
<Chipaca> including, as ogra_ says, what hw this is
 * rsalveti checking backlog
<rsalveti> Chipaca: of course we're going to miss you :-)
<rsalveti> Chipaca: but sure, please just add that in your calendar
<Chipaca> rsalveti: i mean, because it seems i'm not tracking things properly at this point :-/
<rsalveti> sergiusens: hm, still didn't check everything, but why do we need a release?
<rsalveti> which bug did we find?
<ogra_> rsalveti, an old one ... it was the wrong image
<ogra_> (as i understand)
<ogra_> (i.e. old stable)
<Chipaca> separate issues
<Chipaca> as i understood it at least (but see: tracking)
<Chipaca> rsalveti: u-d-f is built against a snappy that has a bug
<rsalveti> right
<Chipaca> rsalveti: fails to do the apparmor hooks
<Chipaca> rsalveti: that's u-d-f trunk (tools ppa?)
<Chipaca> confirm with sergiusens tho
<rsalveti> Chipaca: yeah, tools ppa and wily archive
<conyoo> Chipaca, i just installed snappy with KVM using this tutorial https://developer.ubuntu.com/en/snappy/start/ and then sudo snappy install webdm sudo snappy update sudo snappy rollback webdm (i have the image installed since last week maybe, so i had webdm 0.7? 0.8 and now 0.9)
<Chipaca> ahhhh
<Chipaca> conyoo: could you confirm that after 'sudo snappy update' you have two webdms in the output of 'snappy list'?
<Chipaca> one with .sideload, one without
<ogra_> Chipaca, see above
<ogra_> <conyoo> webdm          2015-06-07 0.8
<ogra_> <conyoo> webdm          2015-06-10 0.9        *
<conyoo> Chipaca, yep snappy list -v
<conyoo> Name           Date       Version    Developer
<conyoo> ubuntu-core    2015-04-23 2          ubuntu*
<conyoo> config-example 2015-05-16 1.0.6      canonical*
<conyoo> mc             2015-06-09 3-4.8.13-3 sideload*
<conyoo> snake          2015-05-29 0.0.5      mectors*
<conyoo> webdm          2015-06-07 0.8
<conyoo> webdm          2015-06-10 0.9        *
<conyoo> generic-amd64  2015-04-23 1.1
<conyoo> generic-amd64  2015-05-10 1.1.1      *
<Chipaca> conyoo: no, without -v
<conyoo> Chipaca, snappy list
<conyoo> Name           Date       Version    Developer
<conyoo> ubuntu-core    2015-04-23 2          ubuntu
<conyoo> config-example 2015-05-16 1.0.6      canonical
<conyoo> mc             2015-06-09 3-4.8.13-3 sideload
<conyoo> snake          2015-05-29 0.0.5      mectors
<conyoo> webdm          2015-06-10 0.9
<conyoo> generic-amd64  2015-05-10 1.1.1
<Chipaca> hmm
<elopio> sergiusens: what do you mean with selftest stuff? mvo wrote some things on the README.
<elopio> are you after something more than that?
<elopio> dpm: should I ask davidcalle for reviews on the docs, or anybody from the community team?
<elopio> or maybe just wait for somebody to go through the docs in draft.
<slangasek> seb128: we just need to agree a name for the channel
<rsalveti> ogra_: sergiusens: Chipaca: I'm still confused if we need to rebuild udf or not (and if that will affect the image)
<rsalveti> (sorry, also in a call)
<rsalveti> ogra_: did you find out why you had the ssh/login/cloud-init issues?
<ogra_> rsalveti, well, it seems unhappy with no key at all
<ogra_> rsalveti, i generated a fake key and it works now
<rsalveti> hm, alright
<ogra_> i also added the promotion info to http://snappy.asac.ws:9001/p/promotion for the moment
<ogra_> (i guess we need some proper place for that later)
<rsalveti> ogra_: awesome
<rsalveti> yeah, I can move things around
<elopio> zyga_: could we use checkbox to record all the inputs and outputs to the terminal?
<dpm> elopio, primarily davidcalle, but feel free to ask myself of dholbach too
 * ogra_ goes downstairs, dont try to catch me on the other server :)
<conyoo> Chipaca, and after that error, webdm stops working even if i restart. the only way to recover is to remove webdm and reinstall
<zyga_> elopio: outputs, yes, inputs no (but it's easy if you'd really want to)
<zyga_> elopio: we don't give you a pty though
<zyga_> elopio: but it's all doable
<zyga_> elopio: and as a bonus, we record timings
<zyga_> elopio: so you can replay a session as it happened
<zyga_> elopio: with realistic timings between events
<elopio> zyga_: I'm not sure if I really want to. Just thinking here.
<zyga_> elopio: what are you trying to build/achieve?
<elopio> zyga_: it might be nice a snap that records an exploratory testing session.
<zyga_> elopio: for that, I'd use off-the-shelf asci/terminal recorders
<zyga_> elopio: though if you want to automate that :)
<zyga_> elopio: or to let devs see replays of each test
<zyga_> elopio: plainbox can help you with that
<plars> anyone have issues trying to use snappy-remote on a device rather than over qemu? with an rpi I'm getting 'ssh: could not resolve hostname : Name or service not known", but there's not a lot of context for the error... I've even tried setting up my key in authorized_keys on the device.
<ogra_> plars, what rpi image is that ?
<elopio> zyga_: I might also want the thing to suggest areas to test. Not quite sure about this either.
<plars> ogra_: it's the one from you :)
<elopio> zyga_: just ideas. Do you know a good recorder I can try?
<plars> ogra_: from http://people.canonical.com/~ogra/snappy/raspberrypi2/
<zyga_> plars: does ssh over the raw ip work?
<plars> zyga_: yes
<ogra_> plars, well, that was initially generated using my ssh key ... send me the snap and i can install it for you :P
<zyga_> elopio: I used a few in the past
<zyga_> elopio: though I don't know if they're foss
 * zyga_ looks
<plars> ogra_: it's not enough to just add my key?
<zyga_> elopio: https://asciinema.org/
<ogra_> plars, the next image is generated with a fake key ... (but that will likely not fix this issue)
<zyga_> elopio: (random google)
<ogra_> plars, yeah, you should be able to put your key in place and use the --pub-key option for snappy-remote i guess
<plars> ogra_: I still get that error even with --pub-key
<plars> ogra_: I also tried giving it a hostname, because the default seems to be "localhost"
<plars> still no luck
<elopio> https://github.com/cortezcristian/terminal-recorder
<elopio> this looks shiny :)
<zyga_> 	snappy-remote --url=ssh://$(deploy_target) install ./$(snap_pkg)
<zyga_> plars: ^^ that's how I deploy my snap
<plars> zyga_: that's exactly what I'm doing
<zyga_> plars: I can also ssh to bb1.lan directly
<zyga_> plars: (ssh config is setup)
 * zyga_ wonders if he has two irssi sessions :P
<zyga_> hmm
<zyga_> no?
<ogra_> plars, http://paste.ubuntu.com/11691282/
<zyga_> odd
<ogra_> plars, use ubuntu@ ..
<ogra_> hmpf
<plars> ogra_: yes, tried that too... I wish I knew where it was trying to look up a hostname and which hostname it was trying to look up
<ogra_> ogra@styx:~$ ping webdm.local
<ogra_> PING webdm.local (254.193.204.33) 56(84) bytes of data.
<ogra_> hmpf
<ogra_> i really dont get how it can return such an IP
<ogra_> plars, well, it definitely works for me using the IP and ubuntu@
<plars> ogra_: ok, I'll keep messing with it. I really wish snappy-remote had a --please-give-me-a-useful-error-message flag though
<ogra_> lol, yeah
<ogra_> sergiusens, hmm, while i have the open/manage button in webdm now, the description is still the wrong one
<sergiusens> ogra_: well the description is the one from the package, not the store; they are supposed to be unique
<sergiusens> once installed that is
<ogra_> from where in the package ? it doesnt come from readme.md it seems
<sergiusens> ogra_: is tis ogra's chatroom one?
<ogra_> yeah
<ogra_> the icon is also broken :/
<ogra_> there are related errors in syslog for the icon though
<ogra_> (that might be my fault)
<sergiusens> ogra_: did you push the edge to alpha already?
<ogra_> sergiusens, yep
<sergiusens> ogra_: neat, revno 3, right?
<ogra_> yeah
<sergiusens> ogra_: autopilot worked at least :-)
<ogra_> btw, i think promoting from alpha to stable might not be clever ... it might result in a different delta ... i'll do the final promotion from edge
<sergiusens> ogra_: I guess that's fine, not sure why the delta would be different though
<ogra_> yeah,. me neither ... just a gut feeling
<rsalveti> ogra_: sergiusens: so how is alpha looking? it seems to work fine here at my kvm image
<rsalveti> what else do we need to do before promoting it to stable?
<ogra_> nothing i guess
<ogra_> i'd like to hear feedback for a BBB from someone though
<ogra_> elopio, ^^ ?
<rsalveti> yeah, elopio, can you give us a hand with that?
<rsalveti> I'm still waiting for mine
 * ogra_ wonders if we have any avahi specialist in the company ... 
<ogra_> i'm really confused that webdm.local for me resolves to some public address
<ogra_> that shouoldnt be possible
<elopio> ogra_: let me flash it.
<ogra_> elopio, flash #2 ... we want to test the upgrade (which is why i held back #3 for 1h)
<ogra_> (in the alpha channel)
<elopio> sudo ubuntu-device-flash --revision=2 --verbose core --output=snappy.img --developer-mode --channel=alpha 15.04 --oem=beagleblack
<elopio> ogra_: looks good? ^
<ogra_> pitti, hey, you know stuff about avahi, right ?
<ogra_> elopio, yeahm that looks fine
<ogra_> autopilot should offer you an upgrade relatively quick
<sergiusens> ogra_: what's wrong with avahi?
<ogra_> ogra@styx:~$ ping webdm.local
<ogra_> PING webdm.local (254.193.204.33) 56(84) bytes of data.
<ogra_> sergiusens, ^^
<sergiusens> ogra_: is that your IP?
<ogra_> (the device has 192.168.2.25 ... )
<ogra_> sergiusens, the external one ? hmm
<sergiusens> ogra_: are there more interfaces?
<ogra_> my external one is 79.223.149.242
<sergiusens> ogra_: I'm trying to nail down a possible bug report ;-)
<ogra_> no, there shouldnt be any other interfaces
<ogra_> sometimes i actually get the right IP
<sergiusens> ogra_: anything in sudo journalctl --no-pager -u webdm_snappyd_0.9.service |pastebinit.mvo
<rsalveti> that's super weird
<ogra_> and webdm.local works well in the browser
<rsalveti> try tracing the routing tables
<sergiusens> ogra_: more than one device?
<ogra_> well, i suspect rather my network than the webdm install
<ogra_> sergiusens, not that i know of
<rsalveti> maybe your isp router is also called webdm :P
<ogra_> only the Pi should run
<rsalveti> is the store that slow for you guys as well?
<rsalveti> hard for me to get more than 40kb/s
<rsalveti> unless kvm is doing something
<ogra_> sergiusens, http://paste.ubuntu.com/11691505/
<ogra_> installing pastebinit was pretty fast for me just now
<ogra_> Installing pastebinit.mvo
<ogra_> Starting download of pastebinit.mvo
<ogra_> 52.57 KB / 52.57 KB [=========================================================================================] 100.00 % 235.30 KB/s
<ogra_> Done
<sergiusens> rsalveti: I switched to slower network this weekend and it is a bit slower, but not too slow
<rsalveti> might be my network
<rsalveti> sergiusens: no fiber anymore?
<sergiusens> rsalveti: ah, store is slow 45.58 KB/s
<sergiusens> rsalveti: vdsl
<rsalveti> right, that's what I'm getting
<ogra_> must be your continent :)
<rsalveti> probably
<sergiusens> rsalveti: I have fibertel (fiber) which is unplugged now; hired to services to deal with outages
<rsalveti> where is the server located?
<rsalveti> would guess europe as well
<ogra_> london ?
<rsalveti> sergiusens: got it
<rsalveti> ogra_: there is a pi2 snap from lool, do you know what that is?
<ogra_> rsalveti, his first try i guess
<ogra_> i'll have to find out how to replace that
<sergiusens> ogra_: I don't see anything strange in the paste; except maybe ::1 is not a good idea
<ogra_> (since it is namespaced)
<rsalveti> ogra_: right, yeah, it's just showing as an app snap it seems
<ogra_> sergiusens, well, only if you use v6
<ogra_> a simple ping on cmdline should only use v4
<rsalveti>  ERROR: pi2.lool failed to install: package name with namespace not supported
<rsalveti> :-)
<ogra_> yeah
<rsalveti> lool: ^^
<sergiusens> ogra_: that is localhost, so if anyone gets it they get the wrong thing :P
<sergiusens> rsalveti: lool's package should be wiped
<ogra_> sergiusens, sure, but that shouldnt cause such weird behavior
<sergiusens> ogra_: no, not the one you see
<rsalveti> sergiusens: who can do that besides lool ?
<ogra_> the store-master :)
<ogra_> zuul :)
<sergiusens> rsalveti: you see that in the store?
<rsalveti> guess beuno then
<sergiusens> beuno: it is
<rsalveti> sergiusens: webdm
<ogra_> it is in the store, yes
<sergiusens> either that or create an alias
<sergiusens> but the alias of pi2 is not easily taken ;-)
<beuno> wut wut?
<ogra_> all your fault !
 * beuno throws gasoline everyone
<beuno> you won't be able to prove it
<ogra_> :)
<ogra_> beuno, we want to get rid of the pi2 package from the store
<beuno> I can do that
<beuno> do you just want the alias, or to kill the app all together?
<ogra_> i guess kill it for now ... not sure it should be in the store at all (you need a device tarball anyway atm)
<ogra_> rsalveti, ^^^?
<sergiusens> unpublish or untick 15.04-core and rolling-core ;-)
<rsalveti> ogra_: beuno: yeah, just kill it
<beuno> sergiusens, ogra_, rsalveti, unpublished
<ogra_> yay
<mvo> last minute issues?
<rsalveti> beuno: thanks
<rsalveti> now I guess you can publish the rpi2 oem
<rsalveti> mvo: nops, just waiting elopio to validate the bbb image
<beuno> tips not included
<rsalveti> with the alpha channel
<mvo> aha, cool
<sergiusens> Chipaca: mvo rsalveti I grabbed latest image, built with "sudo ubuntu-device-flash core 15.04 --channel alpha --install webdm --output amd64-webdm.img"
<sergiusens> and I see webdm not being able to launch due to aa_change_onexec -> no such file or directory
<ogra_> weird, works for me on the RPi
<rsalveti> works fine after installing webdm, guess the problem is with the sideload part then?
<sergiusens> ogra_: I'm on trusty
<rsalveti> let me try reproducing that
<ogra_> sergiusens, me too
<rsalveti> ogra_: are you using the tools ppa?
<rsalveti> and did you update to the latest udf?
 * sergiusens is on the tools ppa
<ogra_> 0.21-1+173~ubuntu15.04.1build1 ...
<rsalveti> ogra_: yeah, not the one from the tools ppa
<rsalveti> which is why it might be working for you
<sergiusens> I think we need to release the latest ubuntu-snappy into wily and rebuild u-d-f with that...
<ogra_> yeah, outdated .. apt-cache policy says 0.23-0ubuntu1 is the candidate
<rsalveti> sergiusens: is fix already in trunk?
<rsalveti> if so I can release and upload
<sergiusens> rsalveti: if you can reproduce
<rsalveti> yeah, trying
<sergiusens> rsalveti: well Chipaca implied that earlier, but I was confused with the alpha thing
<rsalveti> alright, was able to at least create the image with --instlal now
<rsalveti> sergiusens: Jun 10 18:30:42 localhost systemd[1]: webdm_snappyd_0.9.service: main process exited, code=exited, status=1/FAILURE
<rsalveti> where can I get the logs for webdm?
 * sergiusens runs /lastlog journal
<sergiusens> rsalveti:  sudo journalctl --no-pager -u webdm_snappyd_0.9.service
<rsalveti> Jun 10 18:30:42 localhost.localdomain ubuntu-core-launcher[834]: aa_change_onexec failed with -1
<rsalveti> Jun 10 18:30:42 localhost.localdomain ubuntu-core-launcher[834]: . errmsg: No such file or directory
<sergiusens> yeah, same
<sergiusens> rsalveti: let me locally build u-d-f here with the latest snappy
<rsalveti> sergiusens: great
<rsalveti> if that works we can just upload and do the release dance
<ogra_> hmm, i guess i need to re-gen the Pi image then
<elopio> how can I reduce the timer for the autopilot? I don't want to wait 25 minutes.
<sergiusens> elopio: edit the systemd job and refresh
<elopio> sergiusens: but then I would have to make the partition writable. Shouldn't it be possible to configure it?
<davidcalle> elopio, hey, it was longer than expected :) Any issues with the edit?
<sergiusens> elopio: making it configurable wasn't a requirement
<elopio> davidcalle: no. I just updated the version number in https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam
<elopio> could you please review it?
<davidcalle> elopio, sure
<elopio> sergiusens: it's a requirement for automation. But we can discuss about it if/when we write end-to-end tests for autopilot.
<davidcalle> elopio, at first glance, I only see 1.0.1 -> 1.0.2 changes, that's right?
<sergiusens> rsalveti: please release the latest ubuntu-snappy :-D
<rsalveti> sergiusens: alright, all good then?
<davidcalle> elopio, in any case, I don't see any issues, feel free to push the publish button :)
<elopio> davidcalle: that's right. I thought I couldn't push the publish button myself...
<davidcalle> elopio :)
<davidcalle> elopio, you have my permission :p
<elopio> davidcalle: I hate it that you can't search on the editor.
<elopio> oh, you can. Scratch that.
<elopio> I just had to move to the source view.
<sergiusens> rsalveti: yeah
<davidcalle> elopio, the wysiwyg editor itself is... ok-ish, I tend not to use it
<slangasek> seb128: the channel name that sergiusens proposed on the list was ubuntu-personal/rolling/edge.  This looks reasonable to me from the server side; but who should ack the name product-wise? willcooke?
 * mvo added a is dd target already mounted sanity check to godd and calls it a day
<lool> rsalveti: yeah, that's one of the things that needs to be changed while rebuilding: dropping the namespace; actually snappy should support them in 15.10 eventually, but in 15.04 it didn't
<lool> sergiusens: shall I unpublish my package or something?
<rsalveti> lool: already removed by the store master
<lool> eh
<rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.1.1-0ubuntu1
<rsalveti> will do another upload for udf once it gets published in proposed
<rsalveti> and powerpc is indeed fine again it seems
<sergiusens> yup
<elopio> ogra_: I'm in alpha #3. Do you want me to check something special in here?
<ogra_> elopio, if the upgrade worked we're all fine
<rsalveti> elopio: if nothing exploded it is already a good sign
<elopio> rsalveti: I only explode things on tuesdays.
<rsalveti> sergiusens: it seems you forgot to push the release tag/commit for goget-ubuntu-touch
<rsalveti> guess just needs to change from UNRELEASED to wily and then call debcommit -r
<rsalveti> sergiusens: I can do that now
<sergiusens> rsalveti: hmm, sure, thanks
<tedg> mterry, Okay, I've got one. What about devpacks that include the same dependencies?
<tedg> mterry, Like for instance a Ubuntu SDK devpack would include Qt, but potentially there could be a Qt Devpack. What if the build.yaml specified both.
<tedg> ?
<mterry> tedg, ok...
<tedg> And, worse case, what if they have different versions of Qt in them.
<mterry> tedg, so devpacks need some smarts, right?  to detect if they've already installed a dependency before
<mterry> tedg, if they are keeping Qt in the same place, they may notice that they don't have to do anything
<mterry> tedg, if they aren't, we have two copies of Qt
<mterry> Although one could compile it differently from the other, even if they install in same place
<tedg> mterry, I guess this might be enough of an edge case that we let the developer handle it.
<tedg> Yeah, for instance they might be the same version, but with a small patch.
<mterry> tedg, I'm leery of crafting an enormous dependency resolution system
<tedg> Me too
<tedg> Perhaps it just generates an error.
<tedg> "Can't install libraries: file conflicts"
<mterry> tedg, and we'd detect that?
<tedg> mterry, No the devpack itself would
<mterry> tedg, but how would it know it was another devpack that installed it, vs just a previous install of Qt that it did
<tedg> mterry, It wouldn't, and we wouldn't, we'd just have to generate an error that we can't copy the file(s).
<mterry> tedg, but we want to allow using dirty build envs (where the devpack has previously installed qt).  Otherwise every time you build, you have to freshly install qt
<tedg> mterry, I don't think we can track which files in the buildenv go to which devpack.
<mterry> tedg, so the devpack has to be tolerant if Qt is already there, it wouldn't know it was from another devpack necessarily
<tedg> I guess it could *assume* as it's unlikely to be anything other than another devpack putting it there :-)
<tedg> But it certainly wouldn't know which one.
<mterry> tedg, or have best practices for devpacks to install Qt under a namespace
<mterry> tedg, but then if two want to install it, it gets done twice
<mterry> tedg, but in either case, we couldn't say something like "Can't install libraries: file conflicts"
<tedg> Yeah, okay. Crazy idea: what if we generated a hashes.yaml after every devpack operation. Then we *could* track who the owner of the file was, and could make the error better.
<tedg> We'd have to hash the entire buildenv each time to see if the files changed.
<tedg> On the scale of: eating Nutella to volcano surfing, how crazy is that?
<mterry> tedg, or have devpacks be able to resolve dependencies via other devpacks (or at least the core devpack?)  -- i.e the Ubuntu SDK would say "tell the core devpack to install Qt" and a Python module that needs Qt would do same thing?
<mterry> tedg, wouldn't solve all problems...  but most?
<mterry> tedg, I guess I don't know if the core devpack would be able to receive a "install Qt" command
<mterry> that seems complicated
<tedg> Yeah, it seems like we start building a dependency system. It would be nice if devpacks had the same ethos as the rest of snappy.
<tedg> So they're basically bundling everything they need.
<mterry> tedg, right, monolithic
<mterry> tedg, which makes me think that each devpack would install its own namespaced version of Qt
<mterry> (if there were two Qt devpacks)
<tedg> Yeah, I think that makes sense. You could in theory want that, perhaps not for Qt, but something like OpenSSL.
<tedg> Then it becomes critical for devpacks to be able to modify the runtime environment to do things like ensuring their version ends up in the LD_LIBRARY_PATH
<tedg> I don't think we want each devpack adding its own shell wrapper :-)
<rsalveti> the problem with dependencies is that the makes everything harder when reproducing the builds
<rsalveti> and handling such conflicts
<rsalveti> because it becomes a combination of things
<rsalveti> maybe we could have a qt devpack, but the ubuntu one whould ship its own qt as part of it
<rsalveti> guess we can just try some smarter thing to identify possible conflicts
<tedg> Yeah, curious if we couldn't deduplicate there. Like notice that I'm hardlinking all the same file.
<rsalveti> build env size is cheap right?
<rsalveti> guess the major issue is understanding what the linker/compiler will use
<tedg> Yeah, and if it tries to link two versions of the *almost* same lib bad things may happen.
<tedg> Not sure it's a problem we can solve for folks though.
<tedg> (without building a full dependency system)
<ogra_> rsalveti, i'll go afk now, leave me a note about the promotion and i'll do it tomorrow morning (if nobody does it at night)
<rsalveti> ogra_: I'll try to do in a few
<rsalveti> ogra_: your notes should be good I guess
<rsalveti> let me quickly check
<ogra_> i didnt add the actual promotion like ... you should copy from edge to stable in the last step
<rsalveti> cdimage@nusakan:~$ /srv/system-image.ubuntu.com/bin/copy-image ubuntu-core/15.04/edge ubuntu-core/15.04/edge generic_amd64 82
<rsalveti> cdimage@nusakan:~$ /srv/system-image.ubuntu.com/bin/copy-image ubuntu-core/15.04/edge ubuntu-core/15.04/edge generic_armhf 82
<rsalveti> ogra_: right?
<rsalveti> ops
<ogra_> heh
<ogra_> close :)
<rsalveti> cdimage@nusakan:~$ /srv/system-image.ubuntu.com/bin/copy-image ubuntu-core/15.04/edge ubuntu-core/15.04/stable generic_amd64 82
<rsalveti> cdimage@nusakan:~$ /srv/system-image.ubuntu.com/bin/copy-image ubuntu-core/15.04/edge ubuntu-core/15.04/stable generic_armhf 82
<ogra_> yeah
<rsalveti> ogra_: what is the -k?
<ogra_> i thought you'd build a new one
<ogra_> -k means "keep the version number"
<rsalveti> yeah, then this should be good
<rsalveti> ogra_: we're just waiting udf to publish
<ogra_> i wanted the initial version for the upgrade test to be identical to whats in stable
<rsalveti> the image should still be good
<rsalveti> got it, cool
<ogra_> so i kept the 2
<rsalveti> then yeah, should have everything under control
<rsalveti> ogra_: thanks so much
<ogra_> cool
<rsalveti> enjoy :-)
<ogra_> pfft, i didnt do anything
<ogra_> (and just saw an awful football game :P )
<ogra_> (GER - USA ... 1:2 )
<rsalveti> oh, usa got a strong team this year as well
<rsalveti> we won yesterday
<rsalveti> sergiusens: elopio: ogra_: I think we're good to go, new tools available at https://launchpad.net/~snappy-dev/+archive/ubuntu/tools
<rsalveti> created an image with --install=webdm and worked fine
<rsalveti> will brb, but I guess we can finally release it
<bladernr_> Hey, where should I file bugs about the snappy docs at developer.ubuntu.com?
<bladernr_> https://developer.ubuntu.com/en/snappy/tutorials/using-snappy/ specifically, snappy list results in an error as the snappy command doesn't support list
<bladernr_> http://pastebin.ubuntu.com/11692654/
<bladernr_> when someone gets around: https://bugs.launchpad.net/snappy/+bug/1464021
<ubottu> Ubuntu bug 1464021 in Snappy "certificates problem causes snappy to traceback when accessing store" [Undecided,New]
<elopio> bladernr_: hum, snappy list works for me.
<elopio> what version are you using?
<elopio> I suppose it's an old one, because when I do snappy versions it tells me it's deprecated and I should use list.
#snappy 2015-06-11
<rsalveti> time to publish the new image :-)
<rsalveti> and finalize the release
<elopio> rsalveti: I'll be here for another hour. Let me know when it's done, to try an update from stable -1.
<rsalveti> elopio: great
<sergiusens> \o/
<rsalveti> generic_amd64 should have image 3 already
<rsalveti> sergiusens: elopio: image 3 should be available for both archs now
<rsalveti> man, I hate this issue when using --install webdm
<rsalveti> need to open a bug for that
<elopio> rsalveti: this one also references beta: https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
<elopio> I'll update it, but it would be nice to somehow reference the ppa only from one page.
<rsalveti> elopio: I already updated it
<rsalveti> hit f5
<elopio> rsalveti: great.
<sergiusens> rsalveti: weird, it should happen always (since oem snaps are also installed).
<rsalveti> can only reproduce when using --install
<sergiusens> rsalveti: right, --install just appends to the slice (as does --oem)
<sergiusens> rsalveti: in any case, I think I may know what it is, and can solve it by serializing a bit instead of so much parallelism
<rsalveti> right
<elopio> rsalveti: kvm happily updated, rolled back and updated again.
<elopio> beagle in progress...
<rsalveti> awesome, mine is still downloading
 * rsalveti kicks launchpad
<rsalveti> giving a lot of errors when copying packages around
<rsalveti> sigh
<sergiusens> rsalveti: use the python lp libs
<rsalveti> sergiusens: that works, but then the interface says it failed
<rsalveti> like https://launchpad.net/~snappy-dev/+archive/ubuntu/beta/+packages
<rsalveti> Launchpad encountered an internal error while copying this package. It was logged with id OOPS-c5d363b745138ca15db2f2fff68342c9. Sorry for the inconvenience.
<rsalveti> failed for 2 packages
<rsalveti> goget-ubuntu-touch and ubuntu-snappy, both for vivid
<sergiusens> bummer
<rsalveti> for other series it all worked fine
<rsalveti> well, at least we're killing this PPA
<rsalveti> so that's fine
 * rsalveti now kicks ubuntu-device-flash
<rsalveti> tried 5 times, failed every single time
<rsalveti> with --install
<rsalveti> hahah
<rsalveti> and now store gave up on me
<rsalveti> 10k/s
<sergiusens> rsalveti: did you copy package already?
<rsalveti> sergiusens: yup
<rsalveti> sergiusens: tools and tools-proposed are all in sync with latest
<rsalveti> and beta as well
<rsalveti> sergiusens: are we missing anything?
<rsalveti> crap, I can't using --install!
<sergiusens> rsalveti: nope, but I'm going to update and build some images
<rsalveti> *use
<sergiusens> rsalveti: what if you --install hello-world instead of webdm?
<rsalveti> sergiusens: any quick hack or workaround I can use?
<rsalveti> let me try
<rsalveti> trying: sudo ubuntu-device-flash core 15.04 --channel stable --oem beagleblack --install=hello-world --enable-ssh --output ubuntu-15.04-snappy-armhf-bbb.img
<rsalveti> sergiusens: same issue
<rsalveti> http://paste.ubuntu.com/11693333/
<rsalveti> let me open a bug
<sergiusens> rsalveti: only with --install?
<rsalveti> sergiusens: yup
<sergiusens> rsalveti: if you don't it all works?
<rsalveti> sergiusens: yup
<rsalveti> no issue
<sergiusens> rsalveti: the problem with that statement is that even if there isn't an --install, there is always at least one install called (and this is serialized)
<rsalveti> sergiusens: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1464054
<ubottu> Ubuntu bug 1464054 in goget-ubuntu-touch (Ubuntu) "Fails to create a snappy image when using --install" [Undecided,New]
<rsalveti> let me try to create the image on another computer I have around
<rsalveti> elopio: sergiusens: https://launchpad.net/snappy/+milestone/15.04.1
<rsalveti> trying to update the pre-built images now, then upload and release to snappy-devel
<sergiusens> rsalveti: oh wow, you can upload files directly to lp!
<rsalveti> yup, when making releases
<sergiusens> rsalveti: I run in a loop and I get this over and over http://paste.ubuntu.com/11693360/
<sergiusens> rsalveti: it might be a race and easy for you to trigger as your machine is faster... not sure
<rsalveti> interesting
<rsalveti> maybe, also using vivid
<elopio> rsalveti: nice.
<sergiusens> rsalveti: in my xp, when talking go it usually doesn't matter; what is elopio using?
<rsalveti> sergiusens: right, but I don't think go is the issue here
<elopio> sergiusens: as in what distro? vivid.
<rsalveti> maybe the external environment is helping causing the race
<rsalveti> oh, and he got the same machine
<sergiusens> elopio: rsalveti and you guys have the same computer
<sergiusens> rsalveti: yeah ;-)
<rsalveti> elopio: mind trying to reproduce 1464054 ?
<rsalveti> bug 1464054
<ubottu> bug 1464054 in goget-ubuntu-touch (Ubuntu) "Fails to create a snappy image when using --install" [Undecided,Incomplete] https://launchpad.net/bugs/1464054
<elopio> on it...
<sergiusens> rsalveti: can you remove the channel part from First stable release for the 15.04 channel. ?
<sergiusens> Making it "First stable release for 15.04"? since channels in the future represent something else
<rsalveti> sure
<sergiusens> oh, I think I can change that too :-P
<rsalveti> sergiusens: yup
<rsalveti> already did
<sergiusens> rsalveti: I can reproduce slowing down the download ;-)
<rsalveti> sergiusens: hahaha
<elopio> sergiusens: rsalveti: http://paste.ubuntu.com/11693402/
<rsalveti> https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1464054/comments/3
<ubottu> Ubuntu bug 1464054 in goget-ubuntu-touch (Ubuntu) "Fails to create a snappy image when using --install" [Undecided,Incomplete]
<rsalveti> for what you asked
<elopio> this is from my desktop.
<sergiusens> well not exactly reproduce, but something similar
<rsalveti> yeah, same issue
<rsalveti> at least it's consistent
<elopio> hum, my beagle could update and rollback. But after the second update, I am now in emergency mode.
<sergiusens> rsalveti: oh, it is the same issue
<elopio> this happened to me last week too. Not sure how.
<sergiusens> elopio: not good
<rsalveti> yeah
<rsalveti> we could really use some automated tests for beagle
<rsalveti> to stress it
<sergiusens> rsalveti: I slow down the download by installing a bigger package, there some semaphore missing somewhere
<rsalveti> cool
<sergiusens> rsalveti: did you also forget to push the tag for lp:goget-ubuntu-touch?
<rsalveti> sergiusens: did I?
 * rsalveti looks
<rsalveti> sergiusens: maybe it's launchpad, hit f5 and it should show the correct rev :P
<sergiusens> rsalveti: I'm bzr pulling
<rsalveti> damn
<elopio> journalctl -xb is not particularly easy to read, but can you make sense of any of these errors? http://paste.ubuntu.com/11693431/
<sergiusens> elopio: fat partition is busted
<sergiusens> elopio: how sane is your sdcard?
<elopio> sergiusens: I got it in austin, that's like a month ago. I have flashed it less than 20 times.
<elopio> I can switch to a different one to see if it happens again during the week.
<sergiusens> elopio: hmm, then that's not it; something is writing incorrectly or unmounting uncleanly and just being bad
<elopio> https://bugs.launchpad.net/snappy/+bug/1464057
<ubottu> Ubuntu bug 1464057 in Snappy "snappy rebooted into emergency mode after update" [Undecided,New]
<elopio> I attached the journal in there.
<sergiusens> elopio: I think we already have a bug with this...
<sergiusens> but we can search for it tomorrow
<rsalveti> slangasek: one interesting question, how to update something at releases.ubuntu.com?
<rsalveti> I thought it was also at nukasan
<rsalveti> *nusakan
<elopio> sergiusens: I found two similar, but the error messages they have don't appear in my journal.
<rsalveti> sergiusens: yeah, also reproduced on trusty (my older machine)
<rsalveti> problem is indeed the connection speed I guess
<elopio> I'm going to the gym. bbl.
<slangasek> rsalveti: releases.u.c is the /srv/cdimage.u.c/www/simple tree, as opposed to www/full
<rsalveti> slangasek: oh, got it
<sergiusens> rsalveti: so I'm seeing "install fails", returns an error, triggers the unmount path and for some reason the same process is still "using" it and blocking the unmount
<sergiusens> I see it with docker only
<sergiusens> docker failed to install: unable to create /var/lib/snappy/apparmor/policygroups/docker_client: open /var/lib/snappy/apparmor/policygroups/docker_client: file exists
<rsalveti> hm, here I don't get a failure when installing it
<rsalveti> sergiusens: was able to create the images with the uk vpn
<sergiusens> rsalveti: there is no chance to print it out
<rsalveti> store is a bit faster with the vpn
<sergiusens> yeah, true
<sergiusens> rsalveti: can you give this a quick try? https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/BeLazy/+merge/261679
<rsalveti> sergiusens: sure
<sergiusens> rsalveti: no need to approve or anything, I've been playing a bit to get rid of my self induced panic call in the code
<sergiusens> rsalveti: so far, now docker fails to install here and errors out correctly
<rsalveti> great, let me check
<sergiusens> going to sleep now to be able to get some prep work for webdm topics tomorrow
<rsalveti> sergiusens: great
<rsalveti> will put the feedback in the MR
<rsalveti> just waiting releases.ubuntu.com and cdimage to show my pre-built image and will send the announcement
<rsalveti> sergiusens: ops, just found a bug =\
<rsalveti> (amd64)ubuntu@localhost:~$ snappy info
<rsalveti> release: ubuntu-core/15.04/stable
<rsalveti> architecture: amd64
<rsalveti> frameworks: webdm
<rsalveti> apps:
<rsalveti> webdm as a framework
<elopio> rsalveti: I see the same. Not a regression though, same output on #2.
<rsalveti> wonder if this is a tool issue
<elopio> we were testing only snappy list -v. One more reason to get the selftests extended.
<rsalveti> even when using snappy install it is still showing as framework
<rsalveti> did we change it to be a framework?
<rsalveti> failing to login now, weird
<rsalveti> after installing webdm and rebooting
<elopio> http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/pkg/meta/package.yaml#L5
<rsalveti> yeah, then the doc is wrong
<elopio> it is a framework. Now  I'm really confused about what are frameworks.
<rsalveti> maybe because it's exporting apis now
<rsalveti> might be replaced for an app once we implement the rest api
<elopio> shouldn't we allow apt-cache policy ?
<elopio> how do I know the version of the snappy installed?
<rsalveti> elopio: use /usr/bin/apt-cache
<elopio> good trick. But it says: Installed: (none)
<rsalveti> /usr/bin/apt-cache policy ubuntu-snappy
<elopio> :D
<elopio> that's right.
<rsalveti> slangasek: how long does it usually take for something under /srv/cdimage.ubuntu.com/www/full to show up at http://cdimage.ubuntu.com ?
<rsalveti> elopio: can you update https://developer.ubuntu.com/en/snappy/tutorials/using-snappy tomorrow with the proper output we get from image 3?
<elopio> rsalveti: I can do it now.
<rsalveti> elopio: great, thanks!
<elopio> np
<rsalveti> elopio: http://cdimage.ubuntu.com/ubuntu-snappy/15.04/stable/20150609/
<rsalveti> elopio: http://releases.ubuntu.com/15.04/ was also updated
<elopio> yep. Downloading because my sdcard got busted.
<elopio> I should start keeping all the images, instead of overwriting them.
<rsalveti> elopio: https://lists.ubuntu.com/archives/snappy-devel/2015-June/000789.html
<rsalveti> \o\ |o| /o/
<elopio> rsalveti: nice job.
<rsalveti> as usual it took way more work than expected :-)
<rsalveti> guess we learned a lot as well
<elopio> I'm sure I did.
<rsalveti> yeah
<elopio> I will send a testing report now.
<rsalveti> great
<rsalveti> utlemming: now just need your side to update the cloud images ^
<pitti> ogra_: avahi> I roughly know what it is for and what it's supposed to do, yes :)
<sarnold> what's the deal with the +generic and +bbb filenames here? http://releases.ubuntu.com/vivid/
<sarnold> ahh just keep reading the list sars, just keep reading the list :)
<miken> heh, I was about to point you to https://lists.ubuntu.com/archives/snappy-devel/2015-June/000787.html , but sounds like you found it :)
<sarnold> indeed :) thanks
<seb128> slangasek, "ubuntu-personal/rolling/edge" looks fine to me as well, but yeah willcooke should validate it I guess
<slangasek> seb128: ok - can you check it with him today, perhaps?  I'm heading off to bed now; but if we have the channel name I can set it up in the morning
<seb128> slangasek, sure, waiting for him to get online
<seb128> slangasek, have a good night!
<slangasek> thanks, have a good day :)
<seb128> slangasek, I guess I should wait on that rather than try to hack an image build locally ;-)
<seb128> thanks
<ogra_> pitti, so do you have any clue how a avahi reply could return a real external IP ?
<ogra_> <ogra_> ogra@anubis:~/datengrab/rpi$ ping webdm.local
<ogra_> <ogra_> PING webdm.local (254.193.204.33) 56(84) bytes of data.
<ogra_> i thought that was impossible
<pitti> ogra_: why? isn't that the point?
<pitti> you have a machine --> over there which offers a service, like ssh, or cups or whatnot
<ogra_> pitti, you mean returning internet IPs in a lan ?
<pitti> or in this case, .local host names
<pitti> isn't that a local LAN address?
<ogra_> indeed not :)
<ogra_> and at times i actually get 192.168.2.25 ... which is the right IP
<pitti> 169.254.* would also be plausible (ipv4ll), but I suppose we don't use that
<ogra_> right
<ogra_> it should either return a non-routable local IP or something in the reserved 169.254 range
<fgimenez> good morning
<ogra_> s/non-routable/not externally routable/
<ogra_> i'm very confused how it can return the above
<seb128> hey willcooke
<willcooke> hey seb128
<seb128> willcooke, sergiusens proposed to use "ubuntu-personal/rolling/edge" as the channel name for the personal image, slangasek asked for somebody to "ack the name product-wise" before setting that up ... can you do that? (or suggest something better if you have some other idea about that)
<willcooke> seb128, sergiusens - name sounds fine to me.  I'll confirm with kgunn and report back asap
<seb128> willcooke, thanks, slangasek went to bed and said he could set up the channel during his tomorrow, so I guess it let you the day to check with Kevin ;-)
<willcooke> :)
<ogra_> mvo, sergiusens http://paste.ubuntu.com/11694984/ i cant create images on trusty anymore with the recent u-d-f
 * ogra_ wanted to build a final image for the rpi from the stable channel
<Chipaca> ogra_: how does it fail?
<ogra_> see the paste :)
<Chipaca> you know what
<Chipaca> if i didn't see the url in your question
<ogra_> it seems to try to mount an already mounted disk image
<Chipaca> maybe i should finish my coffee first
<ogra_> err ... or rather ... it tries to unmount one that is in use
<Chipaca> ogra_: isn't that the partx race ?
 * ogra_ cant read today it seems
<mvo> ogra_: for some people it seems to help to remove the sd card when creating the image
<ogra_> is there a workaround ?
<ogra_> mvo, which sd card ?
<mvo> ogra_: oh, no sd card or anything else removable in your system :/ ?
<ogra_> (my SD sits in the rpi ... i would only use it after i have an image :) )
<mvo> ogra_: meh, sorry, thats the best I have, maybe reboot :(
<ogra_> sigh ... thats my work desktop ... takes me 30min to start all work scripts after a reboot ...
 * ogra_ would prefer to not have to :P
<ogra_> i guess i'll do my monthly dist upgrade then :P
<ogra_> mvo, u-d-f worked fine until the upgrade fwiw
<Chipaca> ogra_: silly quesiton
<mvo> ogra_: meh, best to talk to sergiusens then
<Chipaca> ogra_: does it happen every time?
<ogra_> Chipaca, 3 out of three tries, yes
<Chipaca> dang
<ogra_> and there is no loopback device left once it stopped
<ogra_> err
<ogra_> no, i'm lying
<ogra_> /dev/mapper/loop0p2 on /tmp/diskimage643565256/system type ext4 (rw)
<ogra_> /dev/mapper/loop0p3 on /tmp/diskimage643565256/system-b type ext4 (rw)
<ogra_> /dev/mapper/loop0p4 on /tmp/diskimage643565256/writable type ext4 (rw)
<Chipaca> a lying liar of lies!
<ogra_> ogra@anubis:~/datengrab/rpi$ mount|grep loop
<ogra_> ogra@anubis:~/datengrab/rpi$ sudo losetup -a
<ogra_> /dev/loop0: [0811]:66982244 (pi2.img)
<ogra_> ogra@anubis:~/datengrab/rpi$ sudo losetup -d /dev/loop0
<ogra_> ogra@anubis:~/datengrab/rpi$ sudo losetup -a
<ogra_> /dev/loop0: [0811]:66982244 (pi2.img)
<ogra_> hmm ...
<Chipaca> mvo: i've got more weirdness for you
<Chipaca> mvo: in case you're bored
<Chipaca> mvo: ubuntu-core-launcher failing to run because it can't find librt.so.1 on image 69
<Chipaca> no
<Chipaca> i mean ubuntu-core 69
<Chipaca> this is on my wily image, which is rolling edge
<Chipaca> and it's because of an apparmor denied?
<Chipaca> [Thu Jun 11 08:47:20 2015] audit: type=1400 audit(1434012441.158:15): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/lib/x86_64-linux-gnu/librt-2.21.so" pid=779 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<Chipaca> and indeed, that's not in the profile
<Chipaca> ... and it isn't using librt when i build it locally
<Chipaca> maybe this is wily -specific?
<JamesTait> Good morning all; happy Ferris Bueller Day! ð
<ogra_> Bueller ... !!!!
 * ogra_ thinks he has 80s day today ... someone on G+ injected a huey lewis song in my brain that i cant get rid of and now *that* !
<mvo> Chipaca: oh, interessting. let me try to reproduce
<Chipaca> mvo: if you ldd /usr/bin/ubuntu-core-launcher on wily, it uses librt
<Chipaca> mvo: but not on vivid
<Chipaca> adding librt to the profile fixes it
<Chipaca> but, i don't see why we now need librt
<mvo> Chipaca: sounds a bit like a question for doko, but let me poke, I bet its gcc5
<ogra_> so the reboot was useless
<ogra_> same error after fresh boot and dist-upgrade
 * ogra_ sighs
<mvo> Chipaca: ha! I blame libudev
<mvo> Chipaca: if I update that I get the new librt dependency
 * ogra_ downgrades to u-d-f 0.23-0ubuntu1
<ogra_> sigh ... same issue
<Chipaca> mvo: needing a commit message on https://code.launchpad.net/~mvo/snappy/snappy-remove-bin-path-compat/+merge/261596
<mvo> Chipaca: thanks a bunch
<mvo> Chipaca: I have some huge branches soon, but I think I get lunch first :)
<Chipaca> sounds good
<Chipaca> i'm figuring out what "other snappy" is running during boot, which is blocking regen from running
 * ogra_ looks at the u-d-f diff and finds ...
<ogra_>  	// create /boot/uboot
<ogra_> -	if err := os.MkdirAll(filepath.Join(img.System(), "boot", "uboot"), 755); err != nil {
<ogra_> +	if err := os.MkdirAll(filepath.Join(img.System(), "boot", "uboot"), 0755); err != nil {
<ogra_> that seems to be the only change in core_uboot.go
 * ogra_ would just patch it and try it out, but obviously i cant fulfill even the build-deps on trusty :(
<Chipaca> well... 755 is obviously wrong, so
<Chipaca> :)
<conyoo> so guys, there is a noticeable lag 4-5s in webdm 0.9 (15.04 ubuntu core 3)
<ogra_> conyoo, that is why the spinner was added to the page i guess
<conyoo> :D
<conyoo> rollback worked ubuntu-core 3 -> ubuntu-core 2 \o/
<conyoo> now how do i get back to 3? snappy update?
<ogra_> yes
<conyoo> thanks ogra_ :D
<Chipaca> grah, "booted" and "internal-run-hooks" run at the same time
<zyga> hey
<zyga> morning
<zyga> I just updated bb to -3
<zyga> and rebooted
<zyga> and  http://pastebin.ubuntu.com/11695375/
<zyga> (it doesn't boot, stops on nandboot not defined
<Chipaca> pitti: can a service unit file have an ExecStartPre and no ExecStart?
<pitti> Chipaca: I believe a Type=oneshot can; a Type={simple,forking,notify}, i. e. a real "service" needs to have an ExecStart
<Chipaca> yeah, this is a oneshot
<Chipaca> and i have other things depending on it
<Chipaca> but they'll start before the oneshot is done
<ogra_> zyga, hold the user button down, thats not a snappy boot at all, looks like the board boots from eMMC
<pitti> Chipaca: yeah, then this only matters if you want to override parts of it with drop-ins
<zyga> ogra_: oh
<dpm> seb128, quick question: will the snappy personal image be writable?
<zyga> ogra_: thanks, I'll wipe emmc
<Chipaca> dpm: no
<pitti> Chipaca: err, a Type=oneshot isn't "done" until after ExecStart* all have finished
<ogra_> at least that kernel version doesnt look like any ubuntu kernel to me
<Chipaca> pitti: well then something's awry
<Chipaca> pitti: do you have five to look at it?
<pitti> Chipaca: does that other unit have a proper After= (directly or indirectly) on the oneshot?
<pitti> Chipaca: yes, sure
 * pitti just quickly finishes his open-iscsi fix
<Chipaca> pitti: oh
<Chipaca> pitti: it's got an After on the wrong one :)
<pitti> Chipaca: that might be related :)
<Chipaca> pitti: thanks :)
<dpm> Chipaca, so it's going to be the same in terms of writability as the phone, then?
<pitti> Chipaca: After=YKWIM.service !
<pitti> JFDI=true
<Chipaca> pitti: i prefer After=YFDWIM.already
<pitti> Chipaca: computers are sooo picky
<Chipaca> pitti: inorite
<ogra_> WOW ... http://paste.ubuntu.com/11695398/
<Chipaca> dpm: maybe. Do you consider the "writable" phone to be supported?
<dpm> no
<ogra_> since when does tar call mknod when extracting a tarball
<Chipaca> dpm: then yes :)
 * ogra_ has never seen such an error
<Chipaca> ogra_: whenever the tarball has special files in it?
<ogra_> Chipaca, it doesnt just extract them ?
<ogra_> i have never had something like this happen to me and i tend use chroot tarballs a lot ...
<zyga> ogra_: filesystem mounted with nodev?
<ogra_> zyga, not on purpose at least :)
 * ogra_ checks 
<ogra_> but still, why would tar call mkdnod instead of just blindly unpacking whats there
<Chipaca> um
<zyga> ogra_: and besides, mknod is priviledged, no?
<zyga> ogra_: sudo
<Chipaca> ogra_: how would it unpack a special file?
<ogra_> zyga, i know how to work around it
<ogra_> i want to know why it suddenly happens
<Chipaca> ogra_: it creates files with open, directories with mkdir, ... etc
<ogra_> Chipaca, and how did it do that before ?
<Chipaca> ogra_: same way?
<Chipaca> ogra_: i mean, there's no other way
<ogra_> well, i usually only start using sudo when i enter my chroots
<zyga> ogra_: maybe fakeroot wrapper made mknod a fake mknod
<zyga> ogra_: and you just didn't notice (wild guess)
<ogra_> hmm
<ogra_> nops :P
<ogra_> /dev/sdb1 on /home/ogra/datengrab type ext4 (rw,nodev,noatime,nodiratime,acl,user_xattr)
<ogra_> WTF ...
<zyga> ogra_: systemd? :)
<ogra_> trusty
<zyga> hmm!
<zyga> indeed
<ogra_> ogra@anubis:~/datengrab/rpi/udf/chroot$ grep /home/ogra/datengrab /etc/fstab
<ogra_> UUID=a3818c99-93e5-4596-bc93-f058a2daa60d /home/ogra/datengrab	ext4	user,acl,user_xattr,noatime,nodiratime,exec,suid 1	2
<ogra_> and no "nodev" in fstab
<Chipaca> ogra_: blame sergiusens
<Chipaca> ogra_: works for me :-p
<zyga> offtopic, I haven't tried yet so feel free to bash me, can I use docker to get a normal debian chroot with snappy
<Chipaca> zyga: aiui, yes
 * zyga erased emmc, boot still tries to go from it
<zyga> hmm
<zyga> just boot from the sd card
<zyga> http://pastebin.ubuntu.com/11695445/
<zyga> hmm
<ogra_> zyga, hmm, corrupt fat ?
<Norbell> Hello. :) I like to configure Ubuntu Snappy as a Router with some docker features. But I can't find any information which is the best way to install something like ufw or firewalld on snappy?
<zyga> but http://pastebin.ubuntu.com/11695460/
<zyga> ogra_: I'll check on my host, I just love sd cards
<Chipaca> Norbell: i don't know of a snap that does that yet, but it's doable
<Norbell> @Chipaca Okay, thanks. Do you think it's possible to use something like deb2snap to convert firewalld into a snappy app?
<nothal> Norbell: No such command!
 * ogra_ sighs ... no lick for me today ... 
<ogra_> so running u-d-f in a wily chroot doesnt work either
 * ogra_ only wants this rpi image done ... dmaned
<ogra_> *damned even
<ogra_> s/lick/luck/
<ogra_> what a wasted day :(
<Chipaca> Norbell: I don't know, sorry
 * ogra_ decides to rather wait for sergiusens or rsalveti to make u-d-f work again
<Norbell> Since a firewall is something you un only once on a linux installation. What is the appropriate snappy component for a firewall? There a frameworks and apps. But both app-types allow multiple instances of one app. In one news Canonical mentioned that some companies plan to install snappy on their routers.
<Chipaca> Norbell: i'd expect it to be a regular snap
<Chipaca> Norbell: ie an app, not a framework
<Chipaca> Norbell: frameworks are for mediating access to hardware
<Norbell> @Chipaca And what about applications that configure Wi-Fi?
<nothal> Norbell: No such command!
<Chipaca> Norbell: same
<Norbell> Chipaca: thank you. Now I have at least an idea of what I have to do :)
<ppisati> ogra_: is modprobe still available on the snappy image?
<Chipaca> ppisati: yes
<ogra_> GRRR !
<ogra_> exactly the same issue on my vivid laptop
<ogra_> so u-d-f is officially completely broken for me :(
<Chipaca> ogra_: here, de-grrr with http://i.imgur.com/vXO0HyH.jpg
<Chipaca> it's my background image today (by random rotation), and has been making me smile all morning
<Chipaca> ogra_: that's âderelict at-at among the sierra nevadaâ by oliver wetter, fwiw
<ogra_> lovely !
<Chipaca> pitti: FYI, running systemctl start from within the exec of a (oneshot) service hangs
<Chipaca> so i guess generators are the only way forward for this
<rickspencer3> rsalveti, ridiculously smooth update on my Beagle Bone
<rickspencer3> nice work everyone
<zyga> ogra_: with some extra checks I'm sure the fat is working
<zyga> ogra_: any advice on what I can use to debug why it doesn't boot after upgrade?
<sergiusens> ogra_: yeah,  that no change rebuild caused a bunch of issues I'm trying to track down since last night
<seb128> dpm, hey, base OS is a readonly image, then apps are snaps, a bit similar to the phone yes, ro fs and clicks in their own space
<dpm> thanks seb128, that's what I was after
<seb128> dpm, yw!
<dpm> seb128, another question: I've seen some talk on the channel about how the final image will be delivered, but I haven't followed it up. Have you guys figured it out?
<dpm> as an ISO, or as an image channel...
<seb128> dpm, as a snappy image
<dpm> seb128, as an image I can e.g. dd into a USB stick, such as the ones for BBB and RPi2?
<Chipaca> mvo: mostly +1 on https://code.launchpad.net/~mvo/snappy/snappy-improved-developer-mode2/+merge/261692 ; just a stray comment to fix
<Chipaca> mvo: a couple of non-blocking questions also :)
<seb128> dpm, what's the difference?
<seb128> dpm, the rpi can't be dd-ed?
<seb128> oh, you meant those are dd-able
<dpm> seb128, I'm not trying to point any differences, just trying to make sure I understand
<seb128> dpm, not sure if there are several type of snappy images?
<seb128> dpm, dunno, for me there was only one type of snappy images
<seb128> and they can be dd-ed
<seb128> but I didn't investigate much so maybe I'm wrong
<seb128> others here can probably reply better to that
<dpm> seb128, I'm not implying there are different types, I just wanted to figure out and understand how the initial installation would work
<seb128> dpm, not figured yet
<seb128> dpm, the snappy team has that in their backlog
<dpm> ack
<Chipaca> snappy images are divided in: (a) signed by canonical, (b) deprecated, (c) working, (d) for quadcopters, (e) firewalls, (f) fabulous, (g) odds and ends, (h) included in this classification, (i) that break all the time, (j) innumerable, (k) maintained by ogra_, (1) etcetera, (m) that break the hardware when booted, (n) that look ok when squinting.
<sergiusens> sounds about right
<sergiusens> images are like appliances
<sergiusens> up to each product to define how to best install it
<seb128> dpm, my understanding is that next steps for personnal are for willcooke to confirm the channel name
<seb128> then sergiusens/slangasek to set up that image/channel
<seb128> then we should be able to use u-d-f to build a personal image
<sergiusens> seb128: the channel name I suggested is on par with 'core' and makes the transition to pure snaps easier
<dpm> seb128, ok, I think that answers all of my questions, thanks
<sergiusens> Chipaca: you really prefer syscall.Mount?
<seb128> dpm, yw!
<seb128> sergiusens, great, waiting on willcooke to confirm with kgunn that the name is ok I think
<sergiusens> Chipaca: wasn't syscall in deprecation mode?
<Chipaca> sergiusens: moved elsewhere, but not deprecated per se
<Chipaca> sergiusens: I don't know if I prefer it or not. If it were C, would we still be exec'ing /bin/mount ?
<Chipaca> sergiusens: I don't know :)
<Chipaca> /bin/mount does a bunch of things around mount(2), which might make it worth just exec'ing
<mvo> Chipaca: thanks a lot
<sergiusens> Chipaca: there is no syscall.Umount or it's too early for me
<Chipaca> sergiusens: https://golang.org/pkg/syscall/#Unmount
<Chipaca> sergiusens: they added a random n in there
<Chipaca> :-p
<sergiusens> Chipaca: ah
<ppisati> nice, the raspi2 modfies the dtb on the fly before passing it to the kernel to make the i2c devices visible
<ppisati> very nice
<ppisati> except that since we use uboot to boot the syste,
<ppisati> and thus we pass the dtb file from the filesystem
<ppisati> we don't give a sh*t about the modified dtb that start.elf is prepping for us
<ppisati> becuause uboot != kernel
 * Chipaca ~> lunch
<pitti> Chipaca: yes, never use systemctl start without --no-block in a systemd unit
<pitti> Chipaca: it's best to avoid calling systemctl altogether, it's usually a hack (you rather shold use Wants=, Requires=, etc.)
<pitti> Chipaca: calling systemctl start in an unit causes a deadlock
<ogra_> sergiusens, let me know once you have something to test, i really want to get that final rpi2 imae out
<ogra_> *imae
<ogra_> bah
 * ogra_ needs new kbd
<rsalveti> morning folks
<rsalveti> how are we doing? did something explode because of the update? :-)
<sergiusens> ogra_: you can try the branch I told rsalveti to try
<sergiusens> rsalveti: no, just the u-d-f rebuild
<sergiusens> :-/
<ogra_> sergiusens, how do i build it ? i cant even get the build-deps installed here
<sergiusens> ogra_: bzr bd --builder='sbuild -c wily ...'
<ogra_> without deps ?
<sergiusens> sbuild or pbuilder or what suits you
<ogra_> a plain chroot ... or even better just my main system :)
<sergiusens> ogra_: on wily, mk-builddeps -i
<ogra_> i dont run wily on any of my prod machines
<ogra_> trusty and vivid are what i can offer
<rsalveti> sergiusens: hm, that I tried but didn't help me at least
<rsalveti> unless you updated it again, let me check
<rsalveti> sergiusens: will try it again in a few minutes
<sergiusens> rsalveti: you got a different error due to something else
<rsalveti> sergiusens: yup, still mount related, but will give it another shot soon
<zyga> ogra_: I frlashed the image from instructions on the website just now, clean card, clean emmc, it doesn't boot
<zyga> ogra_: something is wrong there
<ogra_> zyga, well, QA tested it ...
<zyga> ogra_: well, is the thing they tested uploaded?
 * ogra_ hasnt tried the BBB, i'm focused on the rpi
<zyga> ogra_: I can sha the image (uncompressed) that I have
<ogra_> well, compare the MD5 with the one on the server then
<ogra_> uh, weird
<ogra_> rsalveti, that cdimage fs structure is super confusing ... (for the actual img's)
<ogra_> why is 15.04 snappy under preview and not under releases ...
<ogra_> and there is also an ancient "alpha 3" in the scratch dir
<zyga> ogra_: is there anything on emmc that can influence the boot if I hold the user key?
<ogra_> not if you hold the key, no
<ogra_> then it should always boot from SD
<zyga> ogra_: I'm re-downloading from this URL http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz
<zyga> ogra_: what I see now is:
<zyga> http://pastebin.ubuntu.com/11696123/
<zyga> shouldnt it try mmc1?
<zyga> mmc1 is sd, mmc0 is emmc
<zyga> right?
<ogra_> no idea
 * zyga wonders if qa images worked just because someone had good bits of bootloader on their board
<zyga> and actual images don't work
<zyga> ogra_: I have a second bone with normal ubuntu and that's how it works there
<zyga> sd is on mmc1
<ogra_> well, then the above is right
<ogra_> wait for elopio, he can surely tell you how he tested
<zyga> thanks
 * ogra_ grins about the latest mail to ubuntu-phone
<zyga> ogra_: from Linn Error? ;-)
<ogra_> yeah :)
<ogra_> \o/
<ogra_> sergiusens, thanks so much, the MP helped
<sergiusens> ogra_: great
<sergiusens> ogra_: I don't like the MP though :-P
<ogra_> yeah, its just hiding the prob
 * jdstrand didn't get to respond to Norbell on how he is going to have trouble with a firewall snap since the security policy doesn't allow it and the kernel isn't autoloading iptable_filter and ip6table_filter and probably other things
<jdstrand> I'm trying to get ufw going in my spare time and collecting data that I will present to the architects group. I sorta think we need something like hw-assign but for net-admin
<sergiusens> ogra_: what I think is happening is that snappy.Install is returning but some thread is still running and so when I try to unmount I get a device under use unmount error and boom
<jdstrand> but we'll see
<ogra_> sergiusens, well, then a sleep would do the same
<sergiusens> I had some test code with fuser and the only process using the mount was u-d-f
<ogra_> but with clean unmount
<sergiusens> ogra_: both ugly, but I can do some sort of sync and wait
<ogra_> sergiusens, both ugly, but the sleep would prove that whatever holds the lock actually returns after a while
<ogra_> the lazy unmount wont
<sergiusens> ogra_: yeah, will give it a go in a bit
<rsalveti> ogra_: which path is the one containing alpha 3 and so on?
<rsalveti> but yeah, there is some duplication in there
<ogra_> rsalveti, http://cdimage.ubuntu.com/ubuntu-core/scratch/
<rsalveti> too a while to find out the right place to dump new images
<ogra_> and there is http://cdimage.ubuntu.com/ubuntu-core/preview/
<rsalveti> ogra_: right, but we're using http://cdimage.ubuntu.com/ubuntu-snappy/
<rsalveti> :-)
<rsalveti> just to help causing more confusion
<ogra_> lol
<sergiusens> rsalveti: we should just upload to launchpad ;-)
<rsalveti> sergiusens: yeah
<ogra_> well, we should wipe the ubuntu-cpre ones
<ogra_> old and useless anyway
<sergiusens> rsalveti: zx'ing gives a 156MB image
<ogra_> [    0.001750] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
<ogra_> heh
<ogra_> i never noticed rpi had such a low BogoMIPS value
<rsalveti> maybe early boot only?
<ogra_> yeah
<ogra_> it surely doesnt act like 38.40 :)
<ogra_> hmm
<ogra_> even though ... cpuinfo has the same
<ogra_> funny
<ogra_> great, image seems to work
 * ogra_ installs a few snaps
<zyga> ogra_: tried again, yep, it's broken
<zyga> ogra_: md5sums match
<zyga> ogra_: user key pressed
<rsalveti> ogra_: my problem with udf is only when using it with --install
<zyga> ogra_: shall I file a bug on lp:snappy?
<ogra_> rsalveti, your prob with udf is with using grub ;)
<ogra_> for me it fell over when enabling developer mode
<rsalveti> weird
<ogra_> the MP from sergiusens fixes that bit here
<rsalveti> ogra_: did you try sergiusens's mr?
<ogra_> yes
<ogra_> just commented on it
<ogra_> this was my error this morning http://paste.ubuntu.com/11694984/
<ogra_> k, now the ultimate test ...
 * ogra_ installs docker and owncloud ... (via webdm this time :) )
<ogra_> once that passes i'll push the stable RPi image up
<zyga> elopio: ping
<ogra_> sergiusens, bladernr_, do we have any plans to refresh the store page when the user installed a framework package ?
<sergiusens> ogra_: installing docker fails for me
<sergiusens> just fyi
<ogra_> sergiusens, works fine here
<sergiusens> ogra_: :(
<ogra_> i'm just installing owncloud now
<sergiusens> ogra_: oh, on a prebuilt I mean
<ogra_> well, at least webdm didnt spill any error
<ogra_> oh, you mean via --install ... got it
<sergiusens> ogra_: yup
<sergiusens> Chipaca: fyi docker failed to install: unable to create /var/lib/snappy/apparmor/policygroups/docker_client: open /var/lib/snappy/apparmor/policygroups/docker_client: file exists
<sergiusens> Chipaca: that's the exit 1 we used to see ;-)
<zyga> ogra_, sergiusens: are you mostly working on hardware or qemu?
<sergiusens> zyga: both
<mvo> Chipaca: thanks a lot for your review marathon! if you have further suggestion for improvements, I'm all ears, I will probably continue tomorrow or so, I'm a bit tired now :)
<ogra_> zyga, only HW currently
<ogra_> (myself that is)
 * zyga goes to try qemu image
<mvo> pitti: is it intentional that libudev now requires librt.so? just curious
<Chipaca> sergiusens: do you have the whole error output?
<mvo> Chipaca: I will add a apparmor ok rule for ubuntu-core-launcher if you don't have that already
<sergiusens> Chipaca: it's just that, it's the err returned from snappy.Install
<Chipaca> mvo: i don't
<Chipaca> sergiusens: lies! you've got a line number somewhere, surely?
<Chipaca> sergiusens: in syslog?
<rsalveti> sergiusens: do we actually want webdm to be a framework?
<pitti> mvo: kind of -- new libudev is now internally using the sd-device library, and some bits in the internal systemd libs use mq_getattr and friends
<mvo> ok
<mvo> sergiusens: sorry for nagging, you mentioned you already did a static grub.cfg (similar to uboot) is that available somewhere? I would love to look at it at some point
<rsalveti> mvo: Chipaca: is there any major issue to be fixed still for wily?
 * rsalveti is checking the create wily/rolling images
<Chipaca> rsalveti: well, ubuntu-core-launcher doesn't
<Chipaca> rsalveti: so that's fairly major :)
<mvo> https://code.launchpad.net/~mvo/ubuntu-core-launcher/apparmor-plus-librt/+merge/261726
<mvo> rsalveti: -^
<rsalveti> :D
<mvo> maybe more, this blocks the testing right now, I need to check if the apparmor fix is in wily already
<rsalveti> right, awesome
<mvo> the proper one  from john
<rsalveti> mvo: one of the pending questions we have is how we're going to maintain the ubuntu-snappy package
<jdstrand> mvo: I just now approved it
<rsalveti> mvo: since we now have the desktop guys also creating the ubuntu-personal images
<mvo> jdstrand: \o/ should I cherry pick it into our ppa or will there be a upload soon(ish)?
<rsalveti> so in general I believe it would be good to land everything in the archive and avoid using the ppa
<mvo> rsalveti: meh, I really really the auto-build of that package :/
<rsalveti> but since we can't auto land in there, maybe we can do a weekly release in the archive or such
<jdstrand> mvo: I wasn't planning on fixing it, but I can if you want. I was just rying to expedite the proces for you :)
<rsalveti> mvo: yeah
<jdstrand> ie, just gave my blessing to upload
<mvo> jdstrand: its fine, I can do it, I just did not want to duplicate work
<rsalveti> mvo: maybe syncing once a week is fine, what do you think?
<rsalveti> sync ppa -> archive
 * jdstrand nods
<mvo> rsalveti: yeah, I guess.  Iwould love to automate this as much as possible (which is tricky, I understand that)
<mvo> rsalveti: I mean, if we have super strong auto-testing (and we are on a good way) I don't see why releasing would be manual, if all tests are good it should go in automatically
<mvo> jdstrand: where is that branch you just approved :) ?
<jdstrand> https://code.launchpad.net/~mvo/ubuntu-core-launcher/apparmor-plus-librt/+merge/261726
<mvo> jdstrand: aha, thanks
<rsalveti> mvo: yeah, the only tricky thing is uploading to the archive
<mvo> jdstrand: hm, maybe there is a misunderstanding, I was wondering if there was a plan for a new apparmor release with the fixes from john for https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1460152
<ubottu> Ubuntu bug 1460152 in Snappy "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Critical,In progress]
<mvo> rsalveti: indeed
<rsalveti> mvo: maybe we can convince the personal guys to also use our ppa?
<rsalveti> until we find a better way
<jdstrand> mvo: oh that was a misunderstanding
<mvo> jdstrand: don't get me wrong, I don't want to give you work, just double check that I don't do stuff that is already in progress
<jdstrand> mvo: let me check
<mvo> happy to cherry pick it myself and push to the PPA for now
<jdstrand> mvo: what is that bug number?
<mvo> rsalveti: +1 from me and we put it on the list of things to do
<mvo> jdstrand: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1460152
<ubottu> Ubuntu bug 1460152 in Snappy "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Critical,In progress]
<mvo> (this one?)
<jdstrand> mvo: is the workaround in wily already?
<rsalveti> mvo: sure
<mvo> jdstrand: I don't think so, iirc I did not upload it because I hoped for a better fix (and I was lucky :)
<mvo> did not upload it to wily
<jdstrand> mvo: ok, so, we are planning a new apparmor upstream release and a corresponding apparmor upload to wily. that won't happen for 2-3 weeks. do you need it in wily before then?
<mvo> jdstrand: so I could apply the two patches from john against the wily apparmor and upload to the PPA and your team can upload the real wily at your convinience?
<mvo> sounds ok?
<rsalveti> seb128: hey, regarding personal images, we're currently auto deploying ubuntu-snappy in our ppa and using that when creating the core images since we can't easily automate the upload to the archive
<jdstrand> mvo: that does sound ok. it would also be ok for vivid. that said, before you upload can you double check with jjohansen that this is the final patch?
<mvo> seb128: and our auto-deploy is awesome :P
<rsalveti> seb128: so there could be an out-of-sync issue with the version you guys end up using if you're also not using our ppa
<seb128> rsalveti, hey, unsure how to parse that bit of info
<seb128> ah ok
<jdstrand> mvo: and if you do vivid, you would remove the workaround systemd unit?
<rsalveti> seb128: would you mind also adding our ppa to your builds at least for now?
<mvo> jdstrand: sure, will do. vivid is not super critical right now I'm ok with the worakaround there for now. but yeah, if vivid then the workaround will go
<rsalveti> until we find a better way to automate the publishing in the archive
<seb128> rsalveti, mvo: I'm unsure to understand why you can't regularly land updates to wily?
<rsalveti> seb128: we can, but we're landing stuff more than daily in our ppa
<jdstrand> ok. I'm not super excited about the workaround (you may have gathered that from the bug comment), but so long as it gets there eventually, that's ok
<mvo> jjohansen: hi, jdstrand suggested to double check with you that the two patches for https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1460152 are the final ones or if there is more in your git repo that I should cherry pick?
<ubottu> Ubuntu bug 1460152 in Snappy "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Critical,In progress]
<rsalveti> and we want to automate that to be something for every commit
<seb128> rsalveti, you could land more than daily in the archive
<jdstrand> mvo: thanks!
<rsalveti> we want to always release our trunk
<mvo> seb128: because its a manual bzr-buildpackage; dput that a bzr build recipe can also do
<ogra_> seb128, not during freezes
<seb128> ogra_, why not?
<rsalveti> yeah, but requires a manual step, and also not during freezes
<rsalveti> yeah
<seb128> I though we didn't freeze proposed
<mvo> if I can have my way each commit to trunk will be a upload :P automatically
<seb128> even if we freezed migrations
<rsalveti> but we don't build from proposed
<ogra_> seb128, we dont build images from proposed
<seb128> do you need to use packages?
<seb128> can't you just lp:ubuntu-snappy then?
<rsalveti> atm, yes
<ogra_> live-build uses packages
<ogra_> (and we need binaries indeed)
<seb128> ogra_, you could make it branch & bzr bd & dpkg
<ogra_> seb128, yeah, or just use a PPA :)
<rsalveti> SUBPROJECT=system-image EXTRA_PPAS=snappy-dev/image for-project ubuntu-core cron.daily-preinstalled --live
<rsalveti> how we're building our images
<ogra_> right
<rsalveti> so I'd suggest you guys to use the same ppa for now when building the snappy personal one
<ogra_> just needs the "EXTRA_PPAS" var set
<rsalveti> until we find a better way
<rsalveti> we're working on it
<seb128> I'm sure Laney isn't going to like that :p
<seb128> divergence...
<seb128> we should converge, not diverge
<ogra_> nah, convergence
<seb128> by not using our standard archive & infra
<ogra_> you move closer to snappy :)
<seb128> lol
<seb128> I think that if nobody push back to reduce the divergence it never happens
<seb128> let's keep personnal off that, it's going to create the motivation to resolve the issue
<rsalveti> the problem is the archive and having uploads for every commit
<rsalveti> if the solution is moving away from the archive
<rsalveti> then we're not going to converge *in* the archive
<seb128> that's not a solution
<seb128> our archive/infra should be fit for our needs
<seb128> if it's not we need to fix/change it
<rsalveti> well, following your suggestion to build the package in livebuild
<seb128> yeah, that was a stupid workaround suggestion
<ogra_> sergiusens, mvo, is the content in http://people.canonical.com/~platform/snappy/ used by anything or could i wipe it and create a RPi2 subdir
<rsalveti> sure, we need to fix it, all I'm saying is that while it's not fixed, it's better to just using the ppa
<seb128> what sort of issues do we have using the archive versions?
<seb128> those should be usable now?
<jdstrand> mvo: re Chipaca's comment on the apparmor rule. try: /lib/@{multiarch}/librt{,-[0-9]*}.so* mr,
<seb128> even if they lag a bit behind
<ogra_> you are behind on fixes
<rsalveti> seb128: it's usable, just lagging behind
<seb128> that's fine
<ogra_> it can be really bad
<seb128> at least we experience what our users experience
<rsalveti> if that's fine, then fine :-)
<ogra_> (see the recent u-d-f issues)
<mvo> jdstrand: ok, do you prefer that over librt-*.so* (same as libc?)
<seb128> well, if the archive version is that bad, let's not have that package in the archive
<seb128> so nobody uses it
<seb128> let's keep it in a ppa where it's rolling
<rsalveti> the udf issue is a different one
<rsalveti> we don't expect the archive one to be broken
<rsalveti> since we don't even want our package in the ppa to be broken
<ogra_> sure, i'm just trying to point out that there can indeed be fatal bugs
<seb128> in the ppa as well
<rsalveti> sure, but that can happen for any package that gets uploaded
<ogra_> right
<seb128> you would expect a every commit snapshot to have more issues than one that is manually tested and uploaded to the archive
<ogra_> but due to the extra iteration throuh the PPA it will take longer til it reaches the archive
<ogra_> thats what i meant
<rsalveti> right
<rsalveti> it's fine, we're going to improve our automated testing to verify it better as we go
<rsalveti> the only issue is that you guys might end up using an older version
<mvo> in my ideal world there is no need for manual testing everything that would be done manual is run automatic
<jdstrand> mvo: either is ok. I see I did use -* before. if I were to do it again, I would use what I suggested for all
<rsalveti> yeah, the only missing piece in that ideal world is having a permission to upload to the archive
<seb128> rsalveti, thanks for the heads up
<seb128> we need to discuss it
<rsalveti> but, we're still uploading packages in a ftp server
<rsalveti> in 2015
<mvo> jdstrand: ok, so I will uses the suggestion from john and update libc too for consitency(?)
<seb128> but I would prefer to keep personnal on the archive
<rsalveti> seb128: sure
<seb128> would it only because it helps to keep the motivation to fix our infra for our need
<seb128> rather that paperover in a specific way
<jdstrand> mvo: I don't understand that statement. I mean, I do, but I'm confused by it. if you are choosing to update all of them, please do:
<jdstrand> /lib/@{multiarch}/librt{,-[0-9]*}.so* mr,
<jdstrand> /lib/@{multiarch}/libc{,-[0-9]*}.so* mr,
<jdstrand> /lib/@{multiarch}/libpthread{,-[0-9]*}.so* mr,
<jdstrand> that is more precise while still allowing for good maintenance
<elopio> hola
<zyga> elopio: hey
<zyga> elopio: so you've tested the last beagle image?
<zyga> elopio: I tried to install it today, it doesn't boot for me
<elopio> zyga: hello. stable #3, yes.
<zyga> elopio: maybe I did something terribly wrong
<elopio> zyga: maybe. Can you connect to the serial console and see what it says?
<zyga> elopio: do you think you can tell me what I might have done wrong
<zyga> elopio: I did that
<zyga> elopio: its says...
<zyga> http://pastebin.ubuntu.com/11696123/
<mvo> jdstrand: yeah, sorry, I'm not expressing myself well today. branch updated
<zyga> elopio: it also failed on upgrade
<zyga> elopio: I was running previous version
<jdstrand> mvo: hehe, np. I probably made this harder than required
<zyga> elopio: up until this morning when I updated
<mvo> jdstrand: :) all good
<zyga> elopio: then tried a clean flash from ...
<jdstrand> but it's all good now :)
<jdstrand> hehe
<zyga> elopio: stuff listed here http://developer.ubuntu.com/en/snappy/start/
<zyga> elopio: (md5sums match what I've downloaded)
<zyga> elopio: one question, when you test a new image
<zyga> elopio: do you have anything on emmc?
<elopio> zyga: I'm about to start a meeting.
<elopio> on the emmc I have debian.
<zyga> elopio: is there any chance that is helping you to boot
<zyga> elopio: otherwise, I'm not sure what happens to me
<zyga> elopio: my emmc is wiped clean
<elopio> zyga: I doubt it. But maybe...
<sabdfl> hiya
<sabdfl> hangout?
<zyga> elopio: by default the boot order is nand > sd
<sabdfl> ah, ww
<zyga> elopio: so perhaps that would explain why it works for you
<ogra_> sabdfl, wrong channel ?
<sabdfl> indeed :)
<zyga> :-D
<elopio> zyga: how did you wiped the emmc?
<zyga> elopio: from uboot
<sabdfl> ironically, an invitation to talk snappy though!
<zyga> elopio: mmc erase ...
<ogra_> haha
<zyga> elopio: mmc dev 0 # or something like that to pick the right mmc
<zyga> elopio: mmc erase something something # 0 size or the reverse,
<zyga> elopio: without the sd card with the image (that fails to boot into the kernel) I just see 'C' on the serial line
<sergiusens> mvo: the grub.cfg I use is just from the image, using a u-d-f branch I have with some modifications, I'll get it up as soon as all these criticals go away
<sergiusens> Chipaca: feel free to try yourself ;-)
<sergiusens> rsalveti: webdm a framework was a requirement not imposed by me
<mvo> sergiusens: push now, or I will die from curiosity ;)
<zyga> elopio: ao anyway, any help is appreciated
<zyga> elopio, ogra_: https://bugs.launchpad.net/snappy/+bug/1464275 FYI
<ubottu> Ubuntu bug 1464275 in Snappy "Unable to boot beagle bone black from prebuilt image #3" [Undecided,New]
<sergiusens> mvo: okie dokie
<mvo> sergiusens: lets talk after the meeting if you have a minute
<sergiusens> sure
<ogra_> sergiusens, mvo, is the content in http://people.canonical.com/~platform/snappy/ used by anything or could i wipe it and create a RPi2 subdir
 * ogra_ just re-cycles the last question :)
<mvo> ogra_: I have no idea
<ogra_> sergiusens, ? ^^^
<willcooke> sergiusens, seb128 - kgunn is +1 on the name - let's roll!
<seb128> willcooke, thanks
<seb128> slangasek, ^
<slangasek> seb128, willcooke: nice, thanks
<sergiusens> ogra_: mvo that's dead
<kgunn> seb128: i tried to read thru scrollback, is the summary, we need to use core ppa to build on ? not archive, in order to stay in sync with core guys?
<ogra_> sergiusens, awesome, deleting ... there are other snappy dirs that look dead as well one levelk up
<davmor2> willcooke: WOT you got away with sheworeanitsybitsyteenyweenyyellowpokerdotbikini?
<sergiusens> ogra_: .NEW and .ORIG, yeah good to go as well
<ogra_> sergiusens, http://people.canonical.com/~platform/snappy.NEW/ and http://people.canonical.com/~platform/snappy.ORIG/
<ogra_> cool
<ogra_> ogra@anubis:~/datengrab/rpi$ ssh people.canonical.com
<ogra_> Agent admitted failure to sign using the key.
<ogra_> Permission denied (publickey).
<ogra_> ssh_exchange_identification: Connection closed by remote host
<ogra_> oh come on !
<ogra_> so mv'ing my ~/.ssh dir away and back in place gets me this ? ...
<ogra_> funnily i can ssh localhos and then it works
<seb128> kgunn, define "stay in sync", things keep changing, so depending on where you start your build and how often you build things are going to be slightly "out of sync" anyway
<seb128> kgunn, if wily is *that outdated* then we have an issue
 * ogra_ wonders what caches the ssh key ... i cant find any process with ssh or agent in the name :/
<seb128> ogra_, on what system?
<kgunn> seb128: thanks...so the "how out of date is wily" is still an unknown
<kgunn> ?
<seb128> kgunn, well, I don't know about that, rsalveti & mvo claim we should use ppa because wily is outdated
<slangasek> seb128, sergiusens: what are the device types that we expect on personal? generic_$arch ?
<ogra_> seb128, on my trusty desktop ... to create the rpi image i needs to create a fake ssh key ... for which is moved my .ssh dir out of the way ... moving it back gets me key errors (it works after i ssh localhost so i guess something in the UI session cached the wrong key somehow)
<seb128> kgunn, but it wily is outdated/has versions our users should not use I say we have an issue, because our users are on wily and are going to get things from there
<kgunn> slangasek: the intent is any/all devices that use the full shell
<seb128> ogra_, likely gnome-keyring-agent
<ogra_> -deamon ... but yeah
<seb128> right, sorry
 * ogra_ hugs seb128 
 * seb128 hugs ogra_ back
<ogra_> works, thanks :)
<slangasek> kgunn: right, this is more a technical question of how the devices are named so that they can be consumed properly by whatever's being done on the udf side
<seb128> slangasek, define "device types"? any i386/amd64/armhf config we can boot on?
<slangasek> I would /assume/ that 'generic_armhf', 'generic_i386', [...] gives the right result, but I'd rather have it confirmed
<slangasek> seb128: system-image has a channel, and within the channel are devices, and each device has a set of tarballs to deliver (rootfs, tarball, etc).  u-d-f does some wrapping of this to map it into the snappy design, I want to make sure the device names I work are going to be compatible with whatever udf and/or your gadget snap expect
<slangasek> I work?  I use
<slangasek> seb128: btw I see that only armhf and i386 are built so far, is amd64 ftbfs or not yet added?
<seb128> slangasek, ftbfs, a do armhf
<seb128> or, armhf built today
<seb128> slangasek, amd64 fails with
<seb128> "+ cp -ar boot/vmlinuz-3.19.0-20-generic boot/vmlinuz-3.19.0-20-generic.efi.signed /tmp/tmp.zew1ZPxIai/assets/vmlinuz
<seb128> cp: target '/tmp/tmp.zew1ZPxIai/assets/vmlinuz' is not a directory
<seb128> E: config/hooks/500-move-kernel-to-device-tar.binary failed (exit non-zero). You should check for errors."
<slangasek> fun fun
<slangasek> ok
<ogra_> rsalveti, so i moved the stable Pi image to http://people.canonical.com/~platform/snappy/raspberrypi2/ ... will announce it and update developer.ubuntu.com docs to point to that
<seb128> slangasek, the code does " cp -ar boot/vmlinu?-* $TMPDIR/assets/vmlinuz"
<seb128> slangasek, that regexp doesn't play nicely with the .signed
<slangasek> yep
<seb128> unsure how to change that though
<seb128> do you have any suggestion? ;-)
<slangasek> check for the presence of a .efi.signed first, if presence, use it; otherwise fall back to the current command
<slangasek> present
<slangasek> words, today
<seb128> I'm even unsure why we have a .signed here and why ubuntu-core doesn't
<sergiusens> slangasek: I need to create the personal subcommand, but in the meantime using a full channel path with 'core' should work
<ogra_> asac, just confirming twice before i write an announcement, http://people.canonical.com/~platform/snappy/raspberrypi2/ is ok as url for the Pi image ?
<slangasek> seb128: I don't know why ubuntu-core doesn't currently have the .signed; but it should, so that's a separate bug
<slangasek> sergiusens: ok, that doesn't tell me what device names I should use though
<kyrofa> Chipaca, ping
<sergiusens> slangasek: generic_amd64 and so on or are we thinking phone targets here too?
<sergiusens> I guess you are not the target for that question
<sergiusens> and I can't decide on that either, what are the requirements? :-)
<slangasek> sergiusens: just the generics for now
<kgunn> slangasek: i see what you mean, and yeah, generics i think makes sense atm
<Chipaca> kyrofa: pong
<kyrofa> Chipaca, so I've been trying to use go-dbus, and I ran into a problem with it: anything dealing with messages is impossible to test because the serial numbers aren't exported
<Chipaca> kyrofa: yes, go-dbus sucks at testability
<elopio> fgimenez: I didn't touch your branch yesterday, I'm sorry. That's the only thing I will do today.
<kyrofa> Chipaca, so I found github.com/godbus/dbus which is a lot more testable, but before I jumped to it I wanted to make sure I learned any lessons you learned-- is there a reason you didn't use that one?
<elopio> fgimenez: can you please make the merge proposal, with status in progress, to nicely see the changes?
<elopio> zyga: sorry, one more meeting. Thanks for reporting the bug.
<fgimenez> elopio, np, it's already working now, ok i'll make the mp
<elopio> zyga: I'm now afraid to reproduce it and break my beagle. But I guess I can always reflash debian in there.
<zyga> elopio: :D
<zyga> elopio: yeah
<zyga> elopio: I have two
<zyga> elopio: one runs ubuntu, the other snappy ubuntu core
<zyga> elopio: it's a very useful arrangement
<zyga> elopio: btw, when you do testing, do you boot with the user key pressed?
<zyga> oh, and btw, elopio, we need to talk :D
<zyga> (I didn't realize it was you)
<zyga> elopio: about what you do for testing, so that we don't duplicate work in the cert process
<zyga> elopio: and which tools you use
<elopio> zyga: yes!
<zyga> elopio: quick idea: get a different SD card
<zyga> elopio: flash that
<elopio> do you want to emet in 30 minutes?
<zyga> elopio: and hold the user key while booting
<zyga> elopio: sure
<zyga> elopio: just ping me, I'll be around
<elopio> zyga: I don't press the button, my board doesn't require that. I can try.
<kyrofa> Chipaca, the only significant limitation (as far as I can tell) is its inability to use lower-case dbus method names
<zyga> elopio: then the test process is wrong
<zyga> elopio: as this means the test depends on what you have on emmc
<zyga> elopio: and you really boot the emmc boot loader
<zyga> elopio: not the one on the card
<elopio> I see.
<zyga> elopio: let's talk about that and everything else in a hangout
<zyga> elopio: when you can
<sergiusens> kyrofa: that looks nice (godbus)
<kyrofa> sergiusens, I've been really happy with my limited testing, but I wanted to see if there was a reason most Canonical projects were using go-dbus on launchpad (the similar naming is unfortunate, but I'm not sure what else I'd choose)
<sergiusens> kyrofa: maintained by someone in Canonical was one of the reasons
<kyrofa> sergiusens, that makes sense
<sergiusens> kyrofa: the other one I saw was the one coreos guys wrote, but I don't think we have any strong criteria
<kyrofa> sergiusens, I just... must write tests. I feel so dirty when I have a huge chunk of completely untested code
<kyrofa> sergiusens, Chipaca: If you were starting another go project that used dbus, would you use go-dbus again?
<sergiusens> kyrofa: for that dbus code base?
<sergiusens> kyrofa: I would try not to use dbus at all :-P
<kyrofa> sergiusens, ah, yes, that :P
<zyga> sergiusens: heh
<zyga> sergiusens: I know that from somewhere
<zyga> sergiusens: dbus is good, but ramps complexity a lot
<longsleep> I just received my first set of bug reports for the ODRIDDC image builder - one is '"sudo: unable to resolve host odroid"' - is that a problem i can solve with some yaml options?
<Chipaca> ogra_: whine, whine, whine :-p
<sergiusens> longsleep: that's a snappy bug afaik as /etc/host is not updated
<seb128> slangasek, in the vmlinuz .signed case, should that be "vmlinuz" or does the .signed matters in the naming?
<elopio> zyga: fgimenez: the meeting is running late. Lets better do it tomorrow, I'll schedule it for 14:00 utc.
<elopio> zyga: is it a good time for you?
<fgimenez> elopio, fine with me
<longsleep> sergiusens: All right thanks - i will add it to launchpad if not already there
<zyga> elopio: let's see
<zyga> elopio: yes
<zyga> elopio: well
<zyga> elopio: maybe not, I have a snappy meeting on 15:00 my time which is probably 14:00 utc
<zyga> elopio: let's do it next week
<zyga> elopio: I'll know more
<mvo> jdstrand: here is another approach I was remembering https://lists.debian.org/debian-dpkg/2014/08/msg00006.html about signatures
<zyga> elopio: can you tell me where you have a list of tests to perform on new images?
<Chipaca> kyrofa: i'm not sure that dbus binding was there when we went looking for one
<zyga> elopio: and I'll send a quick agenda for next week
<Chipaca> kyrofa: give it a try and let us know :)
<elopio> zyga: this is what we are using as a starting poing.
<kyrofa> Chipaca, alright, good to know :)
<elopio> *point
<jdstrand> mvo: yes, ima is captured as well. that is an interesting idea for snaps
<elopio> zyga: we can do the meeting on tuesday at 13:00, I'll just get up a little earlier. Otherwise your standup and our standup are in the way.
 * jdstrand updates doc
<elopio> zyga: also, confirmed that when I boot with the button pressed, I get into debian.
<elopio> without the button, snappy.
<zyga> elopio: I can skip my standup
<zyga> elopio: that's really weird, that should be entirely reverse
<Chipaca> kyrofa: places where dbus bindings struggle is in complicated variants (like some of the ones we use for menues and such), and services with dynamic paths
<zyga> 17:40 < elopio> zyga: this is what we are using as a starting poing.
<zyga> elopio: ^^ what?
<Chipaca> kyrofa: so keep a look out for those
<elopio> zyga: https://docs.google.com/document/d/1R_Tw0N0QbEpjFeYf9XnVV8Gp8ldT2Ig0PO6MfR-kuSM/edit#heading=h.2sakiuiw8x0b
<zyga> elopio: thanks
<Chipaca> kyrofa: also, async is hard; look for races
<zyga> elopio: I think we will cooperate on those a lot
<Chipaca> kyrofa: (on amd64, go build -race is your friend)
<mvo> jdstrand: cool, thanks. I only glanced over your doc so far (sorry) so I missed that its already covered
<elopio> zyga: the idea is to get all of that and more automated here: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/integration-tests/run-in-image/tests/
<zyga> elopio: do you know about plainbox/checkbox?
<elopio> zyga: moar hands! :)
<kyrofa> Chipaca, yeah I've been wanting to play with that race detector!
<elopio> zyga: yes, you told me the basics about it some months ago.
<seb128> slangasek, http://paste.ubuntu.com/11696900/ looks fine to you?
<zyga> elopio: ok,
<Chipaca> kyrofa: keep in mind the race detector is racy :)
<kyrofa> Chipaca, thanks for the list of trouble-spots-- exactly what I was looking for :)
<elopio> zyga: atm, we don't really have any tests that need manual intervention. This month we'll attempt at automating them and run them with adt-run.
<zyga> elopio: ok, lots of things to check and think, let's talk next week, we'll definitely need to automate those tests too but in a way that runs with plainbox, let's think about how we can share those
<jdstrand> mvo: no, that thread wasn't covered (I just added it now), but IMA in general was
<zyga> elopio: adt-run over ssh against a deployed machine?
<jdstrand> mvo: thanks for the link
<elopio> zyga: yes.
<zyga> elopio: ok
<elopio> zyga: and +1. Lets share our ideas next week, and see how to join the effort.
<zyga> elopio: ok
<mvo> jdstrand: cool, thank you
<jdstrand> sergiusens: hey, you said you wanted some information for my bbb situation?
 * jdstrand reboots it
<jdstrand> somehow it keeps getting stuck
<elopio> zyga: this is our playground: https://code.launchpad.net/~fgimenez/snappy/go-functional-tests. A wrapper that provisions a machine, then adt-run deploys the go end-to-end tests, runs them and collects the results.
<sergiusens> jdstrand: snappy-system.txt in /boot/uboot and OS versions so if nothing works channel.ini from each partition
<elopio> zyga: still a prototype, so any suggestions are welcome.
<zyga> elopio: I sent out an invite
<zyga> elopio: correct the time, I'm not sure what time suits you
<zyga> elopio: should I look at the merge request or at the whole tree
<elopio> zyga: it suits me but fgimenez EODs in the middle of the meeting.
<zyga> fgimenez: what time would work for you? earlier than stand up?
<fgimenez> elopio, zyga here's the mp, maybe better to see the changes https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748
<zyga> elopio: I'm not faimilar with snappy codebase, I don't know where to look basically
<slangasek> seb128: the .signed doesn't matter in the naming, it's just to disambiguate on the source filesystem when both are installed; and the tooling expects the filename of 'vmlinuz' so 'vmlinuz' it shall be
<slangasek> seb128: yes that diff looks ok to me
<seb128> slangasek, k, so that diff ... thanks
<fgimenez> zyga, elopio yep, 14:00 utc would be fine
<jdstrand> sergiusens: http://paste.ubuntu.com/11696954/ (I think that is what you need wrt /writable/cache/system)
 * zyga wonders how to show utc in google calendar
<jdstrand> sergiusens: do not, this is not the 'some weird image issue' we discussed a week or two ago-- I reflashed after asking you if udf was new enough (and you said yes)
<jdstrand> s/do not/do note/
<elopio> zyga: settings -> additional time zone.
<jdstrand> sergiusens: so, snappy_ab=b but:
<jdstrand> /dev/mmcblk0p2                 999320 553640    376868  60% /writable/cache/system
<jdstrand> /dev/mmcblk0p1                  64511  39328     25183  61% /boot/uboot
<jdstrand> it seems that 'a' booted? (guessing that p1 is 'a' and p2 is 'b')
<sergiusens> p2 is a
<sergiusens> p1 is boot ;-)
<jdstrand> oh
<ogra_> that doesnt look like mounted on "a"
<zyga> elopio: thanks!
<jdstrand> well, /writable/cache/system/etc/system-image/channel.ini  has 'build_number: 82'
<jdstrand> but snappy list says I am on 79
<zyga> elopio, fgimenez: ok, I think it's moved to 14:00 utc now
<jdstrand> sergiusens: ^
 * jdstrand doesn't really know anything about this part of snappy
<jdstrand> so, please advise
<sergiusens> jdstrand: snappy list --verbose
<jdstrand> /dev/disk/by-label/system-b    999320 462180    468328  50% /
<jdstrand> sergiusens: http://paste.ubuntu.com/11697005/
<elopio> zyga: what happens to you if you boot without holding the button?
<zyga> elopio: the console just streams 'C' 'C' 'C'
<zyga> elopio: probably boot-over-serial handshake
<zyga> elopio: er, wait
<zyga> elopio: without the card
<zyga> elopio: holding the button has no effect for me
<ogra_> thats the ROM then
<zyga> elopio: as emmc is empty
<zyga> ogra_: right
<sergiusens> jdstrand: if you manually run snappy update, before rebooting can you give me snappy-system.txt and reboot
<ogra_> telling you it cant find a boot sector
<zyga> yep
<zyga> ogra_: with the card in I get uboot and the pastebin earlier (snappy_boot not defined)
 * jdstrand runs sudo shutdown -c
<jdstrand> sergiusens: fyi, here is an updated paste that has df at the bottom: http://paste.ubuntu.com/11697009/
<jdstrand> sergiusens: so the bottom of: http://paste.ubuntu.com/11697014/
<jdstrand> see*
<fgimenez> elopio, the branch is under my user, maybe we can put it elsewhere so that the team can collaborate?
<elopio> fgimenez: I
<elopio> fgimenez: as you prefer. We can do the same proposing branches to merge against yours.
<zyga> elopio, fgimenez: use git!
<zyga> :)
<jdstrand> sergiusens: I have not rebooted
<elopio> fgimenez: the qa policy of the shared branch was nice, but not sure this team needs it.
<fgimenez> zyga, yep :) elopio ok, merging of other branches sounds good
<elopio> fgimenez: and from now until the game ends, we are enemies.
<elopio> I might talk to you again when Navas is the goalkeeper of Real Madrid.
<ogra_> oh, who plays ?
<elopio> ogra_: Costa Rica - Spain.
<ogra_> something erious or just a freinds game ?
<ogra_> *serious
<fgimenez> elopio, casillas is free to be hired too i think :)
 * ogra_ guesses everthing will be better than ger - usa was :P
<sergiusens> jdstrand: it seems consistent, so you updated, a is selected which has 82
<elopio> it's friendly.
<ogra_> ah, a relaxed one then :)
<sergiusens> jdstrand: it would interesting to view what happens during the reboot (u-boot failing to find the files, corrupted, kernel crashing, systemd causing a reboot) and if that is the reason you get sent back to 'b' and 79
<fgimenez> leaving, nice evening everyone, elopio don't be too worry about the result, maybe next time.. :D
<jdstrand> sergiusens: how would I see that? I don't have a serial console
<sergiusens> jdstrand: oh, yeah that makes it hard... /proc/last_kmsg for the kernel but not sure how to see anything else
<sergiusens> jdstrand: oh, hdmi out from the bbb
<sergiusens> but you need one of those mini plugs
<jdstrand> yeah, I don't have one
<jdstrand> well, I'll reboot and see what happens
<jdstrand> sergiusens: is there a way that the logging can be improved for debugging this sort of thing?
<jdstrand> sergiusens: it can up in 79
<sergiusens> jdstrand: well you won't be able to see what happens at the bootloader level though
<sergiusens> jdstrand: 'find /boot/uboot -ls' (and checksum maybe)
<jdstrand> I don't have /proc/last_kmsg
<jdstrand> seems I'm stuck
<sergiusens> jdstrand: in theory /boot/uboot/a/* should be the same as /boot/uboot/b/*
<ogra_> ppisati, ^^^^ could we enable the ram console for our arm builds ?
 * ogra_ wanted to ask that before ... now jdstrand reminded me :)
<jdstrand> $ diff -Naur /boot/uboot/a/ /boot/uboot/b/ && echo yes
<jdstrand> yes
<ogra_> /proc/last_kmsg is one of the most helpful things
<jdstrand> $ cat /proc/last_kmsg
<jdstrand> cat: /proc/last_kmsg: No such file or directory
<ogra_> yeah
<jdstrand> is that the 'ram console' ?
<ogra_> not enabled in the kernel
<jdstrand> hmm
<ogra_> i think it is called that in the kernel config
<sergiusens> jdstrand: snappy-system.txt is back to snappy_ab=b and snappy_mode=regular, right?
<jdstrand> so, I'm not sure autopilot has ever worked right on my device. every time I try to log into it it is either telling me it is going to reboot or is wedged somehow and I can't ssh in
<jdstrand> snappy_ab=b
<jdstrand> snappy_mode=regular
<jdstrand> yes
<jdstrand> sergiusens: as it happens, I have the image from Jun 1 that I used to flash the device
<jdstrand> it was r72
<jdstrand> I know I did a snappy update/reboot manually at least once
<sergiusens> jdstrand: mind creating a new image with --revision=-1?
<jdstrand> I'm not sure if autopilots worked or that did
<sergiusens> jdstrand: autopilot is just something that runs snappy update
<jdstrand> sergiusens: sure. I'm using this: sudo ubuntu-device-flash core --channel=edge --oem=beagleblack --enable-ssh --output=15.04-edge.bbb 15.04
<jdstrand> sergiusens: with udf 0.23-0ubuntu2
<jdstrand> sergiusens: it will take me a while to flash the card
<jdstrand> sergiusens: actually, I forget --revision=-1. so I'll use that. isn't that going to give me the lastest version?
<sergiusens> jdstrand: latest minus 1
<jdstrand> ah, cool
<jdstrand> sergiusens: ok, I'll ping you
<sergiusens> jdstrand: so  sudo ubuntu-device-flash --revision=-1 core --channel=edge --oem=beagleblack --enable-ssh --output=15.04-edge.bbb 15.04
<sergiusens> jdstrand: and i'm going for lunch now :-)
<jdstrand> that is the command I run ftr
<jdstrand> ran*
<zyga> elopio: if you want, I can pastebin the contents of my files on the boot partition
<zyga> elopio: still not sure what's going on
<elopio> zyga: please do that, but attach them in the bug.
<zyga> elopio: k
<elopio> I'm learning here, so I won't be able to make a lot of sense of the files.
<elopio> somebody else from the team will look at your bug and triage it.
<zyga> elopio: updated, thanks for your help
<elopio> np.
<jdstrand> sergiusens: ok, the system is running r81
<jdstrand> http://paste.ubuntu.com/11697548/
<jdstrand> sergiusens: fyi, "snappy autopilot triggered a reboot to boot into an up to date system"
<jdstrand> sergiusens: so waiting for that to happen automatically
<jdstrand> sergiusens: also, just noticed a typo: "snappy autopilot triggered a reboot to boot into an up to date system-- temprorarily"
<jdstrand> sergiusens: s/temprorarily/temporarily/
<elopio> hum, now there's something wrong with the selftests from trunk.
<elopio> it asks for password, and never connects to the ssh.
<elopio> now it works. weird.
<jdstrand> sergiusens: ok, ir upgraded and rebooted into 82 fine. for somereason I have a feeling it is the 2nd update. eg 80 -> 81 -> 82, but I have no evidence to support that
<sergiusens> jdstrand: if it's the second update b would have 81 and you'd be on a with 82
<jdstrand> sergiusens: well, I'll keep an eye out for what happens with 83
<jdstrand> sergiusens: did you see the typo comment above?
 * zyga bought a new card to try
<jdstrand> sergiusens: thanks for helping me with that. I wish we had a better resolution, but like I said, I'll keep an eye on it
<sergiusens> jdstrand: yup, saw the typo :-)
<sergiusens> jdstrand: and yes, we need to track the upgrades better, elopio raised a bug on something similar to what you saw (but different).
<jdstrand> yeah, that prompted me to bring it up. wasn't sure if it was the same or not
<jdstrand> Norbell: hey, fyi I in my spare time looked at packaging ufw as a snap
<jdstrand> Norbell: there are several issues that prevent it from working correctly. I am jotting those down and will be filing bugs/bringing the issues up to the snappy architects
<Norbell> @jdstrand Awesome. Thats realy realy cool. :)
<nothal> Norbell: No such command!
<jdstrand> Norbell: the two most major ones were that iptable_filter and ip6table_filter didn't autoload (so it can't work on reboot) and that extending privileges are needed to run it (eg, capability net-admin)
<jdstrand> Norbell: since obviously routers, firewalls, etc are interesting to snappy, I'll be presenting the problems and propose a solution to the architects
<jdstrand> this won't be fixed really soon, but we'll get it to the point where it can be done
<Norbell> jdstrand: Interesting. I thought Canonical had  Routers and Firewall in mind during the process of creating snappy. I mean, they advertise this feature
<jdstrand> Norbell: however, these can be worked around now-- if you adjust /etc/modules to load iptable_filter and ip6table_filter you should then be able to use 'security-policy' in your app yaml for handcrafted policy and have something that works on your system
<jdstrand> Norbell: well, yes, which is why I want to bring this up :)
<jdstrand> I don't think it is a ton of work. the kernel module autoloading is just a bug and the other just needs a bit of design and small implementation
<Norbell> jdstrand: Thank you. ;) Tomorrow i will try to get it running on my pi 2. This would be a great feature for my  bachelor thesis ;)
<jdstrand> Norbell: actually, you could probably get away with adjusting /etc/modules and then use 'security-teamplte: unconfined' in you app yaml
<jdstrand> Norbell: it won't be confined, but it should run until we get this bit worked out
<jdstrand> Norbell: you can also look at the webdm packaging for how to use 'security-policy' if you wanted it to run confined with custom policy
<jdstrand> note: neither of those will be allowed in the snappy store, but it should unblock you
<jdstrand> sergiusens: btw, did you ever update your seccomp policy in webdm?
<Norbell> jdstrand: Okay. Thank you for the great advises. I will try it. for the first time its enough to get it running on my pi. Hopefully it will get available in the main release  ;)
<sergiusens> jdstrand: no, not yet
<sergiusens> sorry no easy link to link to :-)
<jdstrand> sergiusens: is it in bzr?
<jdstrand> sergiusens: I can give an MP
<jdstrand> sergiusens: at least, the start of one :)
<sergiusens> jdstrand: lp:webdm
<jdstrand> sergiusens: is it known that removing an app via webdm fails with: ERROR: hook command /usr/bin/aa-clickhook failed with exit status 2
<sergiusens> jdstrand: no
<sergiusens> jdstrand: and I wasn't seeing that with my testing yesterday
<jdstrand> hmm
<sergiusens> jdstrand: the only one that fails is the one I asked about yesterday (dbus fw and ReleaseName being allowed or not)
<jdstrand> no seccomp denial, but ERROR snappy logger.go:199 hook command /usr/bin/aa-clickhook failed with exit status 2
<sergiusens> jdstrand: any specific app?
<jdstrand> hello-dbus-app
<jdstrand> but running webdm under seccomp
<sergiusens> jdstrand: hmm, that's the one I asked about yesterday
<sergiusens> jdstrand: I guess my question got lost
 * sergiusens searches
<jdstrand> did you ask me about it?
<jdstrand> cause if yes, then yes, it got lost
<sergiusens> irclogs/Freenode/#snappy.log:11:19 < sergiusens> jdstrand: not sure it's my image, but is ReleaseName allowed? [ 3993.417227] audit: type=1107 audit(1433945875.311:61): pid=604 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="ReleaseName" mask="send" name="org.freedesktop.DBus" pid=1439 label="hello-dbus-fwk_srv_1.0.0" peer_lab
<sergiusens> there
<jdstrand> interesting
<sergiusens> jdstrand: that happens when uninstalling and causes an error on remove (it ends up removing anyways in the end)
<jdstrand> I wonder what changed that prompted that
<jdstrand> sergiusens: which were you uninstalling?
<sergiusens> jdstrand: hello dbus fwk
<jdstrand> ok, let me look into this
<jdstrand> alright, so running under seccomp there was an issue, but no logging
<jdstrand> I keep feeling like logging isn't fantastic on the bbb
<jdstrand> as in, messages getting dropped
<jdstrand> sergiusens: is hello-dbus-fwk removal via webdm?
<sergiusens> jdstrand: yeah
<sergiusens> jdstrand: let me setup; just finished tracking down an unreleased file descriptor that blocked unmounting and will get more details
<jdstrand> sergiusens: I can confirm that
<jdstrand> no need
<jdstrand> sergiusens: I got it from here
<jdstrand> I just need to decide how to fix it
<sergiusens> Chipaca: rsalveti: ogra_ I found the root cause of the unmounting issues https://code.launchpad.net/~sergiusens/snappy/releaseDaReadme/+merge/261778
<ogra_> ha !
<Chipaca> sergiusens: how big is the dent in your forehead (after hitting the desk with it)?
<sergiusens> Chipaca: lol; bigger when figuring out lsof gives more information than fuser :-)
<sergiusens> Chipaca: this can explain why long running webdm instances can all of the sudden block too, so I'll need to rebuild webdm after this is out
<sergiusens> Chipaca: also http://paste.ubuntu.com/11698150/
<sergiusens> Chipaca: it's not logged, reason for no line number
<rsalveti> sergiusens: nice
<rsalveti> wow, that's an interesting root cause
<sergiusens> rsalveti: well it blocks an unmount; I'm making u-d-f not try to unmap if mounting fails and not obfuscate the real error now
<sergiusens> *unmounting
<rsalveti> right
<rsalveti> sergiusens: then guess we need another round of releases
<sergiusens> rsalveti: well snappy in core doesn't use this
<rsalveti> I mean, tools releases
<sergiusens> rsalveti: so it's not important; tools, yes
<rsalveti> push ubuntu-snappy and then rebuild udf
<sergiusens> rsalveti: yup
<rsalveti> great
<sergiusens> rsalveti: and webdm, webdm does open (indirectly) that readme file
<rsalveti> alright
<sergiusens> so I'll push that to the store today too
<rsalveti> awesome
<sergiusens> another reason to kill that useless readme.md :-P
<jdstrand> sergiusens: fyi, I'll have a fix for hello-dbus-fwk in a few minutes
<sergiusens> jdstrand: oh, it's in hello-dbus-fwk itself?
<jdstrand> yes
<jdstrand> it is a framework so it ships its own policy
<sergiusens> right
<jdstrand> it RequestName()s to bind t the well-known connection name, but isn't allowed to ReleaseName() it
<sergiusens> jdstrand: writing policies takes some iterating I've discovered :-)
<jdstrand> it can, yes
<rsalveti> sergiusens: going back to my previous question, what happend, or who asked for webdm to be a framework?
<rsalveti> and the following up question, would it just be an app once we provide the rest api?
<sergiusens> rsalveti: mark; and I asked the same question you did
<rsalveti> right, guess we'll go over this again eventually
<sergiusens> rsalveti: yeah, you can bring it up end of June or start of July ;-)
<rsalveti> right :-)
<kgunn> jdstrand: hey, so i had a chance to toy with mir snap, i just changed the security-template to nondefault
<kgunn> which i thot i could do to basically get networking groups....thot that might be enough to hit the next hurdle
<kgunn> but i'm failing to install
<kgunn> that was the only thing i changed
<kgunn> any ideas ? or...how to debug? (i bascially know nothing :)
<jdstrand> sergiusens: ok, hello-dbus-fwk 1.0.1 uploaded. there is no apparmor denial now (so I tink my part is done), but if I remove it via webdm 'Removing...' never goes away
<jdstrand> sergiusens: now that is on a system where I was removing/adding/sideloading before removing and install again from the store
<jdstrand> sergiusens: so not sure if there is another issue or if it is a local issue
<elopio> gooooool!
<jdstrand> kgunn: is there a bzr branch somewhere?
<kgunn> jdstrand: lemme push....
<kgunn> jdstrand: lp:~mir-team/mir/snappy-packaging
<kgunn> just cd into snappy-packaging and run make
<jdstrand> sergiusens: it says 'Sorry something went wrong', but it is removed from the list if I reload
<jdstrand> kgunn: there are 2 package.yamls. one in overlay/meta and one in snappy-packaging/overlay/meta
<jdstrand> kgunn: I guess I should be looking at the one in snappy-packaging/overlay/meta ?
<kgunn> jdstrand: should only be the one
<kgunn> http://bazaar.launchpad.net/~mir-team/mir/snappy-packaging/files/head:/overlay/meta/
<jdstrand> heh, well, I promise there are two :)
<kgunn> what the heck
<jdstrand> and they have different contents
<jdstrand> one has your security-template change, and the other uses security-policy
<jdstrand> so I don't really know what to comment on
<jdstrand> except to say that the security-template change won't work. 'nondefault' isn't a valid template
<jdstrand> on a device or in a kvm you can do 'snappy-security list' and see the available templates
<sergiusens> jdstrand: let me check the logs
<jdstrand> sergiusens: is that your logs or my logs?
<kgunn> jdstrand: so  i just pulled a clean lp branch and i only see one yaml ?
<jdstrand> kgunn: since you said you aren't familiar with this, you might want to read these:
<jdstrand> https://developer.ubuntu.com/en/snappy/guides/security-policy/
<kgunn> also...wrt nondefault...
<jdstrand> https://developer.ubuntu.com/en/snappy/guides/frameworks/
<sergiusens> jdstrand: I'll setup
<kgunn> jdstrand: so i did specifcally on
<kgunn> https://developer.ubuntu.com/en/snappy/guides/security-policy/
<kgunn> there's an example there...
<kgunn> which uses nondefault
<kgunn> and indicated in the text it would get network-client
<kgunn> am i just interpreting the example in the wiki incorrectly?
<jdstrand> kgunn: yes, that is just trying to say 'anything else that is on the device that isn't 'default''
<jdstrand> you are
<kgunn> k
<jdstrand> kgunn: in the example yaml, 'qux' does get 'network-client' since 'caps' isn't specified for 'qux'
<kgunn> jdstrand: so i see from the core i'm running it has network-client, network-services, networking
<kgunn> so i can pick from those...
<jdstrand> kgunn: but 'nondefault' isn't a usable template in real-life
<kgunn> but what do you do if you want some capability not in those 3 ?
<jdstrand> there is a trello card for the community team to get a tutorial going so people don't have to read thick guides
<jdstrand> kgunn: to answer that question, you write your own policy (security-policy) or provide an override (security-override, which is akin to the click security manifest). but let's back up. what are you trying to accomplish here?
<jdstrand> kgunn: note, framework snaps, which mir is, will almost use 'security-policy' since they are extending the system or need privileged access
<jdstrand> s/almost/almost always/
<jdstrand> https://developer.ubuntu.com/en/snappy/guides/frameworks/
<jdstrand> "Frameworks are tightly coupled with separately maintained security policies that extend the security policy available to apps consuming a framework"
<jdstrand> "Frameworks are developed and iterated by parties that have a contractual relationship with Canonical"
<jdstrand> "Unlike apps, frameworks have special permissions which allow them elevated access to the system. For the official Ubuntu store, a contract will include terms to ensure framework safety and maintenance"
<jdstrand> kgunn: so an *app* developer focuses on simple templates and caps whereas a *framework* developer uses security-policy and provides framework-policy
<jdstrand> (typically)
<jdstrand> kgunn: ok, I think I see what happened to my bzr branch. I already had one and I accidentally moved the one I pulled today into the other one
<jdstrand> heheh, funny
<jdstrand> kgunn: so at some point in the past I guess someone was using security policy
<jdstrand> security-policy
<jdstrand> but it was removed
<jdstrand> kgunn: this also is what I reviewed
<jdstrand> err
<jdstrand> kgunn: this also isn't what I reviewd in the store
<bladernr_> can someone point me to some document that explains how to add things like python libraries to a snap?  The tutorials and such all seem based on stand alone apps and already included libararies, and I've not found an example yet that shows adding thigns like custom or externally created libraries to a snap
<jdstrand> kgunn: so, what are you trying to achieve when you changed 'unconfined' to 'nondefault'
<jdstrand> kgunn: fyi, I was wrong about it not being what I reviewed. I see now that what is in the store used the 'unconfined' template
<jdstrand> jjohansen: hey, can you think of a reason what a process running under seccomp can't unload an apparmor profile?
<jdstrand> jjohansen: I'm not getting a log message
<tedg> bladernr_, We don't have something like that yet, we're working on a tool to help with it. But there's a lot of good information on mostly using the Python that is there today here: http://www.wefearchange.org/2015/04/creating-python-snaps.html
<jdstrand> jjohansen: does it have something to do with MAC_ADMIN?
<jjohansen> jdstrand: not that I know of
<jdstrand> ok, I'll keep investigating
<kgunn> jdstrand: sorry, distracted, thanks for all that....so with a framework, i figure you need priviledges to access system stuff...and then capabilities to express what an app might want to use (in your fmwk)
<kgunn> so the security-policy is the means for the fmwk to access system stuff ?
<kgunn> just making sure i got it right
<jdstrand> kgunn: a framework is there to provide a service to apps. a framework most often needs privileged access to something on the system. that privileged access is *not* expressed with security-templates and caps because *apps* don't need that access
<jdstrand> kgunn: therefore, "security-policy" exists for framework authors to write their own apparmor policy for their service
<jdstrand> kgunn: framework-policy is what your framework app ships. that *will* ship one or more caps and zero or more templates that *apps* can use
<jdstrand> kgunn: the framework-policy caps ans template give apps access to your framework service(s)
<kgunn> got that...that part makes sense now, e.g. when we build a gui snap on top, it'll use that cap from that fmwk policy
<jdstrand> exactly
<jdstrand> so the bit you were fiddling with is the framework service
<jdstrand> it was using the 'unconfined' template
<kgunn> right...so i can "use what i want" :) on the system..."i" being the fmwk
<jdstrand> that is 'ok' for a demo, but it really should instead use "security-policy"
<kgunn> got it
<jdstrand> yes
<jdstrand> secuiryt-policy is where you say "here is my handcrafted apparmor policy, and here is my handcrafted seccomp policy"
<kgunn> for my fmwk...in order to access xyz on the system ?
<jdstrand> yes
<kgunn> got it now
<jdstrand> so, you might go from this:
<jdstrand> security-template: unconfined
<jdstrand> to this:
<jdstrand> security-policy:
<jdstrand>   apparmor: meta/mir.apparmor
<jdstrand>   seccomp: meta/mir.seccomp
<kgunn> and those will contain a bunch of paths to bins and stuff ?
<jdstrand> then you write your apparmor rules in meta/mir.apparmor and put the syscalls you need in meta/mir.seccomp
<jdstrand> right
<kgunn> and examples in wikis of seccomp file ?
<kgunn> i think i kinda get the apparmor stuff
<jdstrand> kgunn: kgunn you might want to see: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Debugging
 * longsleep has fixed the system-boot fat corruption for ODROIDC by cherry-picking a bunch of U-Boot fixes
<kgunn> jdstrand: thanks...i'll go tinker
<jdstrand> kgunn: the seccomp policy is just a text file that is a list of syscalls
<jdstrand> kgunn: you might start by installing the hello-world.canonical snap, then looking at /var/lib/snappy/seccomp/profiles/hello-world.canonical_env_1.0.17
<jdstrand> kgunn: that just uses what is in the default template
<kgunn> k
<jdstrand> kgunn: a fun quality of seccomp is that it will kill your the process if it violates policy
<kgunn> i saw that
<kgunn> sigkill how great
<jdstrand> kgunn: so watch your logs and see that Debugging page
<jdstrand> it would be nice to do something different, but there isn't a safe way to do that
<jdstrand> (eg, deny and log)
<kgunn> i think it's kinda awesome
<jdstrand> annyhoo
<kgunn> violent
<jdstrand> it is fun
<kgunn> :)
<jdstrand> and apparmor could do it too, but we choose not to :)
<jdstrand> kgunn: so, couple of things--
<jdstrand> kgunn: 1. do note that regular app developers aren't supposed to have to worry about apparmor rules and syscalls
<jdstrand> kgunn: they just use templates and caps
<kgunn> right
<kgunn> i'm special that way
<jdstrand> kgunn: 2. frameworks are quite special since they mediate access to a shared resource. mir falls into this category-- it is supposed to mediate access to the graphics card
<jdstrand> kgunn: (that said I know that things aren't perfect there, but that is ok-- I know tvoss said that is a longer term goal)
<jdstrand> kgunn: 3. framework authors should engage with Canonical on framework policy. so please ask questions, have us review the policy
<jdstrand> kgunn: (but depending on how many frameworks come in, this might have to move to another team)
<jdstrand> kgunn: 4. the framework should be designed in a way that the access the it gives out to apps via its framework-policy is safe for all apps to use, potentially simultaneously. ie, the framework should provide the same isolation and protect the system from attack
<jdstrand> kgunn: (which is why framework authors engage with us)
<jdstrand> we've been through all those talks wrt mir already for touch
<jdstrand> but just trying to give context
<jdstrand> that's it from my unless you have questions :)
<jdstrand> oh, addendum to '4' - if the policy isn't safe for everyone, then the policy should include '# Usage: restricted' at the top of its framework-policy file
<jdstrand> kgunn: hopefully this was useful to you :)
<kgunn> very jdstrand, thanks, sorry i'm very elementary atm
<jdstrand> no worries. snappy is pretty new :)
<kgunn> jdstrand: one last one, i wondered....what would constitute a "policy isn't safe for everyone" situtation ?
<jdstrand> kgunn: that is kinda discretionary, but giving out access to files in /dev, write access to areas outside of the app's area, granting capabilities, etc
<jdstrand> which now you may understand why I mentioned hw-assign/oem in the review
<jdstrand> jjohansen: fyi, if I run aa-clickhook under its own seccomp profile, it is fine, so I don't think it is an interaction between seccomp and apparmor at this time
<jdstrand> sergiusens: I think what is happening is that snappy is running under the same seccomp policy that I am trying to give to webdm which is making it very grumpy. seccomp doesn't have the concept of an exec transition with a new profile
#snappy 2015-06-12
<sergiusens> jdstrand: ah, fwiw the only reason we exec snappy is to snappy unpack
<rsalveti> sergiusens: will release snappy and goget-ubuntu-touch
<sergiusens> rsalveti: ok, I'm preparing a nice u-d-f branch that makes things nicer
<rsalveti> sergiusens: oh, great then
<rsalveti> sergiusens: the other branch is already merged, and pushed ubuntu-snappy already
<rsalveti> should hit proposed in a few, then an upload for goget-ubuntu-touch should do it
<rsalveti> then just need to copy it over tools-proposed, and test it again
<sergiusens> rsalveti: did you create the next milestone already? :-P
<sergiusens> rsalveti: hmm, the u-d-f change wasn't needed :P
<sergiusens> rsalveti: this branch would allow to preprovision images with frameworks that provide policies https://code.launchpad.net/~sergiusens/snappy/policyRoot/+merge/261802
<sergiusens> utlemming: btw ^
<sergiusens> such as docker
<seb128> hey snappy world
<seb128> slangasek, hey, just as a fyi, desktop-next built on amd64 now ;-)
<mvo> seb128: yay, does it also boots ;)
<seb128> mvo, dunno, I still didn't manage to transform those tarballs in an image locally
<seb128> the reply I got is "get the build on a s-i channel and use u-d-f"
<mvo> and its not yet imported info s-i?
<seb128> it was not yesterday
<seb128> unsure if that happened during the night
<seb128> somebody needs to set that up
<seb128> unsure who the somebody is, slangasek?
<mvo> seb128: does it have a config already?
<mvo> looks like it
<mvo> [channel_ubuntu-personal/rolling/edge]
<mvo> seb128: looks like you have a image
<ToyKeeper> Well, hmm.  The latest snappy rpi image comes pre-loaded with ogra_ 's ssh key in .ssh/authorized_keys.
<seb128> mvo, oh, nice ;-)
<seb128> mvo, going to try that in a bit
<mvo> seb128: I guess the next step is that you get u-d-f support for personal, it derrives the url from the product name (core) so right now its not working
<seb128> oh?
<mvo> seb128: or do you have a commandline that works?
<seb128> I see
<seb128> I don't
 * mvo i smaybe missing something
<seb128> I didn't try u-d-f yet
<seb128> I didn't even know the channel was configured
<mvo> seb128: slangasek added it yesterday (according to the bzr logs). so say a big thank you to him :)
<seb128> slangasek, thanks ;-)
 * seb128 is going to pay some beers at the next conference
<seb128> mvo, thanks as well ;-)
<seb128> mvo, who do I pay beers to for the u-d-f changes now? ;-)
<mvo> seb128: sergiusens is the man! let me see if I can add something for you to unblock you
<seb128> mvo, thanks
<mvo> seb128: you can try http://paste.ubuntu.com/11700595/ first line is the command, second the diff to use for u-d-f
<seb128> mvo, danke
<mvo> seb128: heh, u-d-f needs to create bigger partitions for you now
<seb128> mvo, those are not dynamic to accomodate the tarball?
<fgimenez> good morning
<mvo> seb128: no, hardcoded afaik
<mvo> fgimenez: hey, good morning
<seb128> mvo, do you know where? did you try to generate a personnal image? did it fail because of that?
<fgimenez> hi mvo!
<davidcalle> Good morning o/
<davidcalle> ogra_, hello, still want to wait for the raspi2 to become officially supported to updated the dev site? The "I expect this URL to persist for a while" from your ml email makes me think we should do it now.
 * davidcalle grabs coffee, brb
<ToyKeeper> I have a lot of learning to do to figure out how rpi2+snappy works.
<davidcalle> to update*
<mvo> seb128: so system-{a,b} are just 1gb big, how much do you need? 4?
<ToyKeeper> With snappy and systemd and no apt-get and all the other new stuff, it feels like a whole different operating system.
<mvo> ToyKeeper: yeah, it is
<seb128> mvo, I'm unsure, is it compressed or uncompressed? it should be pretty similar to our standard iso which is a bit over 1G, I'm unsure how much is the installed system nowadys but 4G should be enough
<ToyKeeper> Speaking of partitions, one of the things on my todo list is change partition sizes to use the whole card instead of just 4GB.
<ToyKeeper> But not tonight.  Tonight, bed.
<mvo> seb128: ok, you get a updated debdiff in a sec
<seb128> mvo, thanks ;-)
<seb128> ToyKeeper, night
<mvo> ToyKeeper: if you use u-d-f you set the size at image creation time
<mvo> seb128: but only for the writable partitions, the system-a/b are hardcoded
<seb128> mvo, ?
<seb128> mvo, was that second line for ToyKeeper as well?
<mvo> seb128: for you because you need partition size changes :) http://paste.ubuntu.com/11700710/ should do it
<mvo> seb128: sorry, too little context I guess
<seb128> mvo, ?
<seb128> mvo, trying that change, thanks
<seb128> mvo, "<mvo> seb128: but only for the writable partitions, the system-a/b are hardcoded"
<seb128> not sure what that meant
<seb128> anyway, I understand your code change, so trying that ;-)
<mvo> seb128: sorry, too little context. I was refering to that ubuntu-device-flash has a --size option. but that it won't help you  because of the hardcoding of the sizes of a/b
<seb128> oh, right
<seb128> mvo, I though it was a reply to ToyKeeper "one of the things on my todo list is change partition sizes to use the whole card instead of just 4GB."
 * mvo nods
<seb128> the snaps are installed in the writable one right?
<mvo> seb128: yes
<seb128> mvo, u-d-f ongoing, it's a bit weird, it downloads a 78M file and a 456M one, those doesn't match the generated tarballs from launchpad
<seb128> but let's see
<seb128> maybe it's normal and I'm having wrong assumptions there
<mvo> seb128: might be different compression (xz vs gz)? the 78mb is the kernel
<seb128> mvo, kernel = device tarball?
<seb128> mvo, it's 148M on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29455
<seb128> hum
<seb128> mvo, did you try that command?
<seb128> "issue while mapping partitions: more partitions then expected while creating loop mapping
<seb128> "
<seb128> it bails out on that here
<mvo> seb128: meh, I got that now too
<mvo> seb128: not sure what to do, maybe we need sergiusens for the rescue this is not really a area I worked in much
<mvo> seb128: but could also be something else, I just set it back to 1024 and get the same error, maybe it got confused because of the earlier error?
<seb128> mvo, ok, no worry, that can wait a few hours
<seb128> mvo, or maybe something in the channel is wrongly set
<seb128> ?
<seb128> ubuntu-core doesn't have a device tarball
<seb128> ubuntu-desktop-next has
<mvo> could be
<seb128> so maybe they have different configs and need another u-d-f handling
<seb128> mvo, let's wait for sergiusens
<mvo> 150mb vs 78 is indeed a huge diffrence
<seb128> thanks for trying to help ;-)
<mvo> yw, sorry that it did not work out
<seb128> no worry
<ogra_> davidcalle, that was my plan ... i have some meetings til noon though
<mvo> ogra_: did you see what ToyKeeper wrote earlier?
<ogra_> mvo, its a fake key ... i explicitly generated it and moved my real one away ... u-d-f --developer-mode requires it
<ogra_> (it refuses to roll the image if there is no key)
<davidcalle> ogra_, np, to update the page, I just need to know if the first udf snippet (the one not using the OEM .snap) is still relevant and what should replace it. (https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2). I think I can figure out the rest with your README and the current text.
<mvo> ogra_: heh, nice. is it a actual key or a string like "garrrrr, kthxbye")?
<ogra_> mvo, i wasnt sure if it checks for validity so it is actually a key :)
<ogra_> else i would just have touched the file ... will try that for the next build :)
<ogra_> (it is quite an annoying process btw ... once you moved a new key in place half the desktop gets confused because gnome-keyring-daemon caches the wrong one)
<mvo> ogra_: woah
<mvo> ogra_: I guess some people will be unhappy if it looks like a valid key because they have no way of knowing that there exists on maching key on your side :/
<ogra_> mvo, well, ppisati has a new kernel binary, there is the issue witjh the serial number on cmdline to get a fixed MAC ... i'll have to re-roll anyway soon i guess
<ogra_> i'll try the touched file then
<mvo> nice
<mvo> thanks!
<vsuojanen> Hello, I haven't tried yet but can you say is it possible in amd64/i386 stable images possible to configure and custom grub menus without loosing the settings after ubuntu core updates?
<ogra_> lol, why do people always ask the easy questions :)
<ogra_> mvo, i think the above is a very interesting question ... will snappy personal support dual booting (which means we need a grub menu) ?
<vsuojanen> there is only etc/grub.d/09_snappy. what did you mean by snappy personal ? is it some other than https://developer.ubuntu.com/en/snappy/ ?
<ogra_> yes, the desktop version
<ogra_> or the converged version ...
<mvo> vsuojanen: its not straightforward right now, what use-case do you see here?
<ogra_> ... however you want to call it :)
<mvo> ogra_: *uff* we want to get rid of update-grub soon
<ogra_> mvo, well, for a desktop install i would expect people to still have dual boot here and there
<ogra_> or rather "to want to have" ... :)
<mvo> ogra_: right, I see the need, I just have no idea right now what to do
<mvo> ogra_: well, there are various ways :) need to think about this, but I really really want our grub to be dramatically simpler
<ogra_> why are we getting rid of update-grub instead of making it get out of our way ?
<vsuojanen> coreos support pxe and ipxe so that you can netboot and load your rootfs with root= separately.
<ogra_> vsuojanen, but without using the snappy initrd you wont get the snappy filesystem setup at all
<ogra_> (you need to make sure thats supplied by your PXE setup ... and even then it will look for partition labels which you would need to hack up inside the initrd)
<mvo> ogra_: it adds (lots) of complexity we don't need. we know exactly what kernels are on the system and where to find them. we can remove ~500 lines of shell to detect labels/parittions/kernels we also can make the mounting much simpler, right now we chroot into the "other" parition and bind-mount back the original one because the system needs to see them both
<mvo> lots of complexity here that will come and bite us with bugs
<ogra_> yeah
<mvo> ogra_: but other OSes is something we need to think hard about
<vsuojanen> so snappy is both kernel (with initrd) and rootfs ?
<mvo> yes
<ogra_> well, a readonly rootfs
<vsuojanen> apps are there in the persistent partition
<ogra_> and a writable partition where the files live you need writable on a system
<ogra_> and in fact it is two readonly rootfs'es if you want the rollback support
<vsuojanen> thanks ogra_ mvo
<zyga> hi
 * zyga goes to figure out what's wrong with https://bugs.launchpad.net/snappy/+bug/1464275
<ubottu> Ubuntu bug 1464275 in Snappy "Unable to boot beagle bone black from prebuilt image #3" [Undecided,New]
<ogra_> it is funny that only you seem to hit it
<zyga> ogra_: next sd card, verified everything
<zyga> ogra_: and previous image ran
<zyga> ogra_: magic
<JamesTait> Good morning all; happy Friday, and happy Peanut Butter Cookie Day! ð
<zyga> ogra_: is this correct based on your knowledge https://bugs.launchpad.net/snappy/+bug/1464275/comments/6
<ubottu> Ubuntu bug 1464275 in Snappy "Unable to boot beagle bone black from prebuilt image #3" [Undecided,New]
<zyga> ogra_: the external sd card is mmc 0, the boot partition (fat) is 1
<zyga> ogra_: where do bootpart and loadaddr come from, are they hardwired into uboot?
<ogra_> usually from uEnv.txt
<zyga> ogra_: well, the uEnv.txt I have is just two lines
<zyga> # where to load initrd
<zyga> initrd_addr=0x88080000
<zyga> # load Snappy environment and call into Snappy boot after processing this file
<zyga> uenvcmd=load mmc ${bootpart} ${loadaddr} snappy-system.txt; env import -t $loadaddr $filesize; run snappy_boot
<ogra_> not sure if the BBB image ships a uboot.env file
<zyga> (+ comments)
<zyga> nope
<zyga> just uEnv.txt and snappy-system.txt
<zyga> at least in the image I've got
 * zyga really really wants someone to try to reproduce that
<ogra_> hmm, does anyone else have issues reaching people.canonical.com ?
<ogra_> zyga, then it just uses the defaults from u-boot
<ogra_> hrm, seems my VPN is screwed up
<zyga> ogra_: oh
<tvoss> ogra_, I cannot reach canonical's irc
<ogra_> yep, same here
<ogra_> and the VPN is dead too
<ogra_> yay, friday :P
<zyga> ogra_: I figured it out
<zyga> ogra_: I need to check if it works just because everyone that ties still has debian on emmc
<zyga> ogra_: but the config is borked
<zyga> ogra_: the defaults point to emmc
<zyga> ogra_: and there's nothing there
<zyga> fgimenez: hey, do you have a beagle bone black?
<ogra_> there should be an SPL
<zyga> ogra_: can it insert variables into uboot?
<ogra_> no, it doesnt, it will just switch to SD
<ogra_> but you need something there to actually boot
<zyga> ogra_: the problem seems to be that on the image we ship, bootpart is 1:2
<zyga> that's eMMC, partition 2
<zyga> and nothing in uEnv.txt changes that
 * ogra_ wonders if you have a different model 
<zyga> ogra_: different model of what? uboot from the sd card?
<ogra_> BBB
<fgimenez> zyga, yes, but no serial cable, yesterday version 3 worked for me, do you want me to try?
<ogra_> the BBB is open HW, anyone can make and sell them ... we usually all have element14 devices
<ogra_> there might be minor differences when manufactured by another manufacturer
<zyga> (sorry, system crash)
<zyga> ogra_: I have A5A written on the side,
<zyga> ogra_: trying to look at elinux.org but it seems down
<zyga> (looking for changelog)
<zyga> ogra_: both of my beagles are from element 14
<ogra_> well, then we should all be on the same HW
<zyga> ogra_: I think it's a minor issue to fix, it _did_ work until I upgraded to -3
<ogra_> elinux is fine here
<zyga> ogra_: and it seems the issue can be fixed with one line in the uEnv.txt
<zyga> ogra_: which version do you have?
<ogra_> dunno
<zyga> ogra_: (and if you know) how to determine the version correctly
<zyga> fgimenez: which version do you have
<fgimenez> zyga the box says it's bbb rev C, don't know if i can query the hw somehow, was the 4gb flash storage size in rev B?
<zyga> fgimenez: I think it was 2GB in B
<zyga> fgimenez: ok, you have some C version
<zyga> fgimenez: can you erase your emmc to see if this is unique to a5?
<zyga> mvo: which lab runs tests on snappy/beagle? (looking at one ofthe TODO:QA cards on trello)
<mvo> zyga: I don't know but I was able to run all of them here with my local BBB
<zyga> mvo: I'm trying to understand who runs those tests and how that's set up
<mvo> zyga: fgimenez or leo can help here I think
<fgimenez> zyga mvo there's still no lab for that, we hope to set up an environment for running the selftest on this monthly iteration
<zyga> fgimenez: do you have a location?
<fgimenez> zyga nope, we'll contact CI for that, and in the meantime (and always to have consistent results from the tests) we'll run the automated suite locally
<zyga> fgimenez: thanks
<zyga> mvo: how do you run tests with adt?
<sergiusens> morning
<zyga> sergiusens: hi
<sergiusens> seb128: I'll take care of personal; you need more snappy[a|b] storage space, right?
<sergiusens> zyga: where does booting stop for you?
 * sergiusens tries to avoid reading the full backlog in detail
<zyga> sergiusens: it doesn't get out of uboot
<zyga> sergiusens: tries to load everything from the wrong partition
<sergiusens> zyga: oh, weird; on a bbb revC?
<zyga> sergiusens: I can figure out the workaround, just being frustrated at the replacement laptop just being slow and crappy
<zyga> sergiusens: A5A
<zyga> sergiusens: I doubt it's rev relevant
<zyga> sergiusens: more like what you have on emcc
<zyga> mmc
<zyga> sergiusens: unless uboot has wrong defaults for rev A
<zyga> sergiusens: (which is possible)
<sergiusens> zyga: yes, maybe, plars had a similar issue with that board
<sergiusens> zyga: and the quick solution was to first install the latest debian to the emmc
<zyga> sergiusens: have a look at https://bugs.launchpad.net/snappy/+bug/1464275
<zyga> sergiusens: well
<ubottu> Ubuntu bug 1464275 in Snappy "Unable to boot beagle bone black from prebuilt image #3 (hardware A5A, empty emmc)" [Undecided,New]
<zyga> sergiusens: the image is just broken :)
<zyga> sergiusens: it's just plain wrong and easy to see why :)
<zyga> sergiusens: if you can confirm that your bbb has the same defaults on revc (interrupt uboot)
<zyga> sergiusens: then it's not specific to board revision
<zyga> sergiusens: where can I send patches to uboot config (uEnv.txt)
<sergiusens> zyga: lp:snappy-hub/snappy-systems
<zyga> sergiusens: thanks, I'll branch that
<zyga> https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems ?
<sergiusens> zyga: yeah, beagleblack/uEnv.txt iirc
<zyga> yeah, got it
<zyga> sergiusens: yes
<zyga> sergiusens: that fixes it
<zyga> sergiusens: I'll sent a merge request out
<zyga> ogra_: I fixed it :)
<sergiusens> ack
<zyga> https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833
 * zyga looks at how to rebuild a clean image for testing
<mvo> zyga: sorry for the delay, there is a readme for that, once sec
<mvo> zyga: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/integration-tests/run-in-image/README
<zyga> mvo: thanks!
<zyga> sergiusens: are there any instructions for rebuilding the fully snappy image?
<sergiusens> zyga: from which point?
<zyga> sergiusens: I want to rebuild the bootloader snap
<zyga> sergiusens: and rebuild the SD card image with that and core-3
 * zyga needs to get some terminology right
<zyga> (please teach me)
<sergiusens> zyga: if it's to integrate your new bbb snap, snappy build it and then; sudo ubuntu-device-flash core 15.04 --oem ./local_beagleblack.snap --developer-mode --output bbb.img
<zyga> sergiusens: fantastic, thanks
<zyga> sergiusens: do I need any ppas apart from the snappy one>
<sergiusens> zyga: it's just that the personal folk are dealing with the same one level deeper
<sergiusens> zyga: no, it's all in ppa:snappy-dev/tools
<zyga> sergiusens: is sudo needed for that?
<zyga> sergiusens: or is it just a habit
<ogra_> u-d-f needs to mount images
<ogra_> so it need sudo
<ogra_> *needs
<zyga> ah, I see
<ogra_> the patch looks sane, but i'd like to hear from lool, perhaps he sees drawbacks
<zyga> ogra_: thanks
<ogra_> (and you probably want some verification that it doesnt regress for working boards indeed
<ogra_> )
 * zyga sees hardware packs and linaro-media-create everywhere he looks ;-)
<zyga> ogra_: yep, I'll test a clean image now
<zyga> ogra_: and I want to see how it works on other beagles
<ogra_> yeah, its kind of an evolution of that :)
<tvoss> ogra_, do you still have issues accessing irc.canonical.com, too?
<ogra_> nope
<ogra_> vpn works, irc works
<zyga> ogra_: boots okay on empty emmc
<rsalveti> o/
<rsalveti> sergiusens: https://launchpad.net/snappy/+milestone/15.04.2 :-)
<ogra_> tvoss, did you restart your VPN connection after the outage ?
<tvoss> ogra_, not running on a vpn connection here
<ogra_> ah
<rsalveti> did we have another outage?
<seb128> sergiusens, hey, yes, mvo tried to bump it to 4G with http://paste.ubuntu.com/11700710/ but the image build fails atm with a  "issue while mapping partitions: more partitions then expected while creating loop mapping"
<ogra_> rsalveti, vpn and irc were gone ... not sure if for everyone
<seb128> sergiusens, but maybe something is wrong with the channel content, it tries to download a 78M device tarball where the one generated by the launchpad builder is 140M
<rsalveti> ogra_: right, was fine for me at least
<rsalveti> weird :-)
<plars> zyga: ah, right, the way uboot is set up on the BBB image is really weird. I've mostly got it sorted though
<plars> zyga: I'm just waking up though, give me a bit and I'll send you the info on it
<zyga> plars: hey
<zyga> plars: I fixed the bug
<zyga> plars: details are here https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833
<zyga> plars: with that patch merged you can always boot
<sergiusens> seb128: I'll sort it out
<tvoss> asac, ping
<sergiusens> mvo: hey, can you later look at https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/beBetter/+merge/261804 ?
<mvo> sergiusens: sure
<seb128> sergiusens, thanks, let me know if you figure out anything or if you have any patch/hack to try
<seb128> sergiusens, I would have liked to get an image I can boot today, just to a nice way to wrap the week feeling like we get things in shape ;-)
<mvo> sergiusens: you will hate me, have tons of questions. sorry for that, probably because its so hot here. nothing to worry about though (and I'm only at ~20% of the MP sso far) :/
<sergiusens> mvo: no worries, I mostly switched to composing and implementing the diff in that MP
<plars> zyga: yeah, we should discuss later. Basically the control over boot location with the s2 button doesn't necessarily do what you'd expect wrt where it pulls uboot from, and even which image it boots (it should worry you that you don't have to press s2 to boot snappy from the sd card)
<plars> and in fact, you are booting the uboot from emmc when you do that, not the one that came on the snappy image
<zyga> plars: I'll explain after the meeting
<elopio> hello
<tedg> elopio, Howdy!
<zyga> plars: s2 doesn't change anything here, the problem is that even if you hold s2 and boot from sd
<zyga> plars: uboot will load environment from emmc
<zyga> plars: and that environment shipped on production boards from element 14
<zyga> plars: actually allows our current images to boot
<plars> zyga: right, that's why I had to rebuild uboot
<zyga> plars: if you wipe emmc then you still boot from sd but now don't have the missing uEnv.txt
<zyga> plars: the patch I provided changes that so emmc is irrelevant
<plars> zyga: noooo, we want emmc
<plars> zyga: without it, what happens if you flash a bad snappy image?
<plars> zyga: you have no sensible way of replacing it
<zyga> plars: it tries to load snappy from emmc, look at this:
<zyga> https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833
<zyga> plars: replacing what?
<plars> zyga: I think we're talking about two slightly different, but related problems
<zyga> plars: we want emmc but the defaults in our image are wrong
<zyga> plars: with this patch you can still use emmmc for anything
<zyga> plars: it just won't be on the critical path for booting
<roadmr> heya snappers. I did snappy update ubuntu-core (on rpi2), snappy list -v showed 81* and 83!, but when I rebooted it didn't switch to 83, shows 81* 83. Where do I start looking at what happened?
<plars> zyga: scenario: automated snappy testing on bbb, you flash a bad snappy image to the sd, boot, and find out it's broken. How do you get back your stable testing platform?
<plars> zyga: that's what I was going for
<plars> you're just hitting the bad bootpart setting in uboot
<zyga> plars: well, I don't know, that's out of the scope
<plars> zyga: I certainly hope not!
<zyga> plars: my point is that snappy images that we ship should work _regardless_ of what you have on emmc
<zyga> plars: (well, we can use lava LMP)
<plars> zyga: indeed, and I agree
<zyga> plars: or "master image" on emmc
<rsalveti> elopio: spain won in the end, right?
<zyga> plars: so I think it is out of scope
<plars> zyga: haha, well, they don't even use that. Apparently it doesn't work
<zyga> plars: as long as the image we use boots regardless if placed on sd card
<plars> zyga: talk to dave sometime
<zyga> plars: oh? :D
<zyga> plars: I would love to talk to them
<elopio> rsalveti: yeah... We were close to a tie though.
<plars> zyga: yeah, I had the same hope, but they told me it was doa
<rsalveti> saw a few minutes, and was a bit intense, the goalkeeper was doing an amazing job
<rsalveti> elopio: yeah, cool
<plars> zyga: at least that's what he said a few weeks ago, and didn't sound optimistic at the time
<elopio> fgimenez: I forgive you. I'm setting up the hangout.
<elopio> fgimenez: https://plus.google.com/hangouts/_/gwxohxu2okyw57dw2o5w2657jqa
<elopio> everybody: fgimenez and I will start doing a daily hangout before the standup. Join us if you ever feel alone and need somebody to talk to... about tests.
<fgimenez> elopio, omw 2-1...
<ogra_> davidcalle, so how can i log in to the developer.ubuntu.com site in a way that i can edit (i think you or daniel once gave me edit rights)
<ogra_> the "log in" button only expands a "my apps" option when i click it
<ogra_> lool, can you remove your pi2.lool snap from the store (i guess we either want an updated one or none at all)
<zyga> elopio: can you send me an invite please
<elopio> zyga: I think it's open, just use the link: https://plus.google.com/hangouts/_/gwxohxu2okyw57dw2o5w2657jqa
<zyga> lool: hi, could you have a look at https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833
<elopio> let me know if it doesn't work.
<zyga> elopio: looking
<zyga> elopio: cool
<davidcalle> ogra_, https://developer.ubuntu.com/openid/login/ (make sure you check the "editor" checkbox)
<seb128> sergiusens, did you look at the snappy personnal image build yet? just curious to know if you see an issue or a workaround we could use to try to get an image build today ;-)
<sergiusens> seb128: I just got back from errands, so will be looking now
<seb128> sergiusens, thanks
<jdstrand> sergiusens: so overnight my bbb is now not responding to ssh. it will respond to pings
<jdstrand> sergiusens: is there an r83 image now?
<sergiusens> mwenning-wfh: all your comments are awesome btw
<sergiusens> err, mvo I mean ^ :-)
<mwenning-wfh> aw man I was trying to sleep
<mwenning-wfh> :-)
<mvo> sergiusens: thanks
<ogra_> davidcalle, geez, are we serious about that CMS ? it manages to get my 8 core i7 with 16G ram to its knees !
<davidcalle> ogra_, how?
<ogra_> seems to have ginormous amounts of javascript that eat my CPU and ram
<davidcalle> ogra_, there are a some pretty bad things with it (and a lot of cool ones), but this one is new to me :/
<ogra_> well, hangout in one tab, the CMS in another and my browser turns to a slideshow
<davidcalle> ogra_, hmm, for now, do you want to send me your edits (or draft or notes), working fine for me
<ogra_> no, i'm fine its just dog slow
<fgimenez> elopio, so, the problem with the wrapper is related to the build of the debs, the dependencies are updated and doesn't work on vivid, right?
<elopio> fgimenez: I have a brain overload. The build of the deb worked on the desktop, but ssh failed. ssh works on the laptop, but the build fails.
<elopio> http://paste.ubuntu.com/11702627/
<elopio> http://paste.ubuntu.com/11702636/
<fgimenez> elopio, the first one seems to be related to the different release versions, if you try to execute bzr-buildpkage it should fail too
<sergiusens> mvo: here's another one (just a rebase) https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865
<elopio> bzr bd works.
<fgimenez> elopio, yep it seems to be more permissive with changes in the source tree
<zyga> have a great weekend everyone
<fgimenez> bye zyga
<fgimenez> elopio, do you think that we should compile the tests in the deb build process as part of the wrapper card?
<fgimenez> elopio, we can also leave this for the card about deploying selftests
<elopio> fgimenez: I'm not yet sure if we should compile the tests as part of the deb build. Maybe we better make a different card for that.
<elopio> fgimenez: yes, that sounds better. We can put a task in there about figuring out the best way to compile them.
<kgunn> jdstrand: hey, just want to test my thinking, so i'm working on the sec policy like you walked me thru...
<fgimenez> have a nice weekend o/
<kgunn> i was planning on running mir-demo-server with strace
<kgunn> and just collecting the syscalls there...does that seem like a sensible approach
<kgunn> for the seccomp file
<kgunn> brb
<noise][> Anyone else encounter an error w/the latest rpi2 image: $ snappy list -v
<noise][> 1970/01/01 00:20:36 Can not parse 'name: webdm
<noise][> source: lp:webdm
<noise][> that's right after a freshly installed image from http://people.canonical.com/~platform/snappy/raspberrypi2/
<beuno> I bet Chipaca broke it
<noise][> since he's probably off for the day, it's definitely his fault
<beuno> why else would he take the day off?
<noise][> and i was soooo excited to have my orange matchbox up and running
<noise][> _was_.
<beuno> noise][, so
<beuno> the first issue is the wrong date
<beuno> ssl doesn't *love* being told it's the 1970's
<noise][> y, but not sure why that would affect parsing the rest
<beuno> yeah, definetly
 * noise][ recalls something about that date issue, checks list archive
<beuno> sergiusens can also be blamed
<jdstrand> rsalveti: hey, what is a simple way I can determine if a snappy is a snappy system as opposed to touch, desktop or server?
<jdstrand> s/if a snappy/if a system/
<jdstrand> I really hate the last minute workaround in click-apparmor that just looks for /usr/bin/snappy
<rsalveti> noise][: hm, I think ogra_ updated the image earlier today
<rsalveti> it was fine yesterday
<noise][> rsalveti: bummer
 * sergiusens can sometimes be blamed, but not by beuno :-P
<rsalveti> jdstrand: hm, wonder if sergiusens can help you with that
<sergiusens> rsalveti: the only other alternative was to parse /etc/system-image/channel.ini and check for ubuntu-core in there
<rsalveti> until we change to the store, yeah
<jdstrand> yeah, that was what I was thinking. ok, thanks
<jdstrand> sergiusens: I'm uploading https://code.launchpad.net/~sergiusens/click-apparmor/snappyFameworksDir/+merge/261032 to wily. do you want a corresponding upload to the system image build ppa?
<sergiusens> jdstrand: just wily for now
<sergiusens> thanks
<jdstrand> sergiusens: ok. fyi, the change would be harmless on 15.04, but that's fine
<ogra_> rsalveti, i didnt update anything
<ogra_> http://paste.ubuntu.com/11704275/
<ogra_> all fine on my install
<ogra_> noise][1, i cant really repro that here :/
 * ogra_ will take a deeper look tomorrow ... 
<noise][1> ogra_ hmm.. i'm off now but maybe I'll reflash and try again later/tomorrow
<kgunn> jdstrand: hey, i'm back at it, first denial i see is a seccomp denial for lchow (which i think is due to the script changing the socket so apps can use it)
<kgunn> so do i litterally just place lchow in my newly created seccomp.mir ?
<sergiusens> ogra_: he install webdm 0.1, that predates the release of all releases :-P
<ToyKeeper> gah...  there's no rsync on the orange box and no apt-get.
<ToyKeeper> I can work around most of the missing stuff, but the workarounds require rsync.  :(
<slangasek> ToyKeeper: what workarounds do you need that work with rsync but not scp?
<ToyKeeper> slangasek: The idea was to do everything on my desktop and 'rsync -av --delete' that directory to /home/ubuntu on the pi2.  scp is nowhere near as good at syncing that way.
<slangasek> hmm, well. it requires a bit more scripting for the --delete part
<ToyKeeper> When a project is ready, I'd then make a snap for it and install it that way.
<ToyKeeper> Ideally, I'd prefer a 2-way sync like unison, but that's far less standard.
<ToyKeeper> slangasek: BTW, do you have any idea how to get X11 running on the orange box?  Most of my project ideas involved a television.
<slangasek> ToyKeeper: X is incompatible with snappy; you can have Mir instead...
<ToyKeeper> Hmm.  That makes most of my ideas impossible until/unless we get XMir.
<ToyKeeper> Cutting out all legacy debian/ubuntu packages and all legacy graphical apps really limits the options here...
#snappy 2015-06-13
<longsleep> Is docker supposted to work? I am getting BUG: scheduling while atomic: docker.armhf/5023/0x00000002 when trying to start a container - see http://paste.ubuntu.com/11709495/ for full log.
<ToyKeeper> Dammit, scp doesn't have an option to copy symlinks as symlinks instead of following them.
 * ToyKeeper adds another request for rsync in the default image
<ToyKeeper> Would be nice to have strace too.
 * ToyKeeper tries to figure out how to get /dev/i2c entries in order to use all the lovely I/O this thing has.
<ToyKeeper> BTW, it'd be nice to have lspci too.
<ToyKeeper> And lsusb.
<ToyKeeper> 'modprobe -v i2c-bcm2708 i2c-dev' didn't seem to help.  :(
<ToyKeeper> So far it looks like no HDMI and no i2c, which reduces my project ideas to zero.
<ToyKeeper> I could use it as a SSO token generator, but I've already got a container doing that on my lxc server.
<ToyKeeper> With udev and systemd and such, I'm guessing I can't just mknod the device entries.
<ToyKeeper> I wonder if audio works, and if I can get NFS tools installed plus some codecs.
<ToyKeeper> It could function as a music player pulling songs from a NAS...
<ToyKeeper> I'm looking for use cases which I can't just spin up another LXC client for.
#snappy 2016-06-13
<stevebiscuit> sergiusens: in case you missed it on Telegram, WebDM is now SnapWeb and lives on GitHub: https://github.com/snapcore/snapweb
<lundmar> Hi. Is it possible for a snap (eg. app) to depend on another snap (eg. lib) or should all dependencies be included as parts?
<ogra_> there will be library snaps at some point that will aloow content sharing between two snaps ... but that does not exist yet and will very likely be limited to one user (i.e. you wont be able to use my lib snaps, but if you package a whole desktop you can have a shared lib snap for all your desktop snaps)
<lundmar> ok, so for now I simple bundle everything in one. Got it. Thanks.
<lundmar> simply*
<ogra_> yeah
<zyga> o/
<joc_> zyga: hey, whats the next step for the serial-port PR?
<zyga> joc_: I have to review it again; I'm sorry I was pretty busy lately
<joc_> zyga: np, thanks
<jennym> Hi, I am trying to build a java application using snapcraft which depends on a package from an external jar file. I am thinking I need to use the copy plugin to move the external jar file to where it can be seen by the ant plugin. Any ideas?
<zyga> slangasek: hey, did you commit all the packaging improvements from debian into snap-confine?
<trijntje> Hi, I'd like to learn to make snappy packages. Is it also possible to use snappy for things like python libraries? I need a later version of pyvcf then is in the repo so I thought that might be a good test case
<zyga> trijntje: no, because libraries are not executable directly, libraries can be represented as snapcraft "parts" and later included in othre snaps
<trijntje> zyga: ok, so if I want a library that I can import in my own programs, I need to install them system wide using .deb. But when I make an app that depends on that library I can include it as a snapcraft part
<popey> jdstrand: (sorry for double ping) http://paste.ubuntu.com/17287781/ what do I do about these kinds of things?
<popey> (I have [x11, network, network-bind, unity7, opengl, home])
<dpm> davidcalle, dholbach, hey. Quick question - how often is the gadgets page on d.u.c updated? E.g. if someone uploads a new gadget, it should appear automatically on the page after how long?
<davidcalle> dpm: since we got various requirements that did not fit the current app (eg. indicating official support or not, etc.) the list is back to manual updating since the sprint.
<zyga> trijntje: if you want to use it in your programs that are packaged as a snap you don't need the deb
<trijntje> zyga: I work as a bioinformatician, so I'm usually writing small scripts to do a specific trick, so for me its important I can just put 'import libraryX' and have it work. I usually don't package each and every script I create
<zyga> trijntje: you can just use pip for that
<zyga> trijntje: pip install --user ...
<zyga> trijntje: if you want to package your scripts into a snap you can also use pip packages
<dpm> davidcalle, thanks. Can you give me more context on these requirements that caused the updates to be manual?
<trijntje> zyga: I'm in a bit of a weird spot, since I write a lot of tools, and I have do distribute those to like 5 different users. So I want to do as little manual stuf as possible, but packaging everything 'by the book'  also seems overkill
<trijntje> Right now I try to use as much stuf from the repo as possible, and put my scripts in a simple .deb, which is easiest for the users, but a pain when I need a later version then is in the repo
<zyga> trijntje: do a snap then :)
<davidcalle> dpm: I've forwarded you some threads for context. In a nutshell: need to fetch a new type of snaps ("gadget", we are only looking for "oem" right now which is not used in 16 series anymore), identify gadget snaps maintained by Canonical, sort by release, add links in some cases, that don't exist in the store description.
<dpm> great, thanks davidcalle
<dpm> davidcalle, when you've got a minute, could you also publish the snapcraft 2.10 blog post? We might want to change the title to reflect the actual announcement was last week
<trijntje> zyga: I'd like to, but not if first I have to snap all python libraries that I want to use. Thats a lot of extra work right?
<davidcalle> dpm: have you seen my comment on it?
<davidcalle> dpm: about gadget snaps, the new type fecthing + sorting by release is merged in trunk, other requirements are blocking.
<zyga> trijntje: no, you don't have to snap then
<zyga> trijntje: if your libraries are on pypi you can use them directly
<zyga> trijntje: add a part that installs your libraries into the snap
<zyga> trijntje: (see snapcraft docs for that, I don't remember which plugin it was)
<zyga> trijntje: then add another part that puts your scripts into the snap
<zyga> trijntje: and expose each script as an app
<trijntje> zyga: ok, that sounds pretty good. So I just do pip install for myself for development, and use pip for the snappy package as well
<zyga> trijntje: there's a way to pass a requirements.txt to your part
<zyga> trijntje: I just don't recall the syntax
<dholbach> dpm, there's also no way to distinguish between supported and unsupported snaps in the store
<dholbach> dpm, I'll raise this with the store team again
<trijntje> cool, I'll give that a go. I'd have to spend a bunch of time to build a new .deb for the lib I want anyway, so if I can use pip thats already a big win. And it will work for every python lib ofc ;)
<dpm> davidcalle, I've now seen the comment and replied to it. I've made some tweaks to the text and I think it should be good to go. Do you think you could look at publishing it in the next few hours? Thanks!
<dpm> davidcalle, as usual, feel free to modify, especially if you have a better suggestion for the title
<davidcalle> dpm: yes, seen it. wfm! Will publish right after lunch.
 * dpm hugs davidcalle
<d_ed> has there been any thought on how to handle libexec? Most libs (KDE frameworks anyway) hardcodes it into apps based on the install prefix. Naturally that doesn't work in snappy
<zyga> d_ed: some peopple use --prefix=/snap/$SNAP_NAME/current/usr
<zyga> d_ed: though sadly it would be best if this was handled upstream, if upsteams integrated with $SNAP
<d_ed> I've submitted patches in review to load from an env var
<d_ed> so we can then do KF5_LIBEXEC_DIR=$SNAP/whatever/libexec  in the snap launcher
<d_ed> --prefix=/snap/current is technically broken
<seb128> zyga, that prefix doesn't work though, it makes things being mounted in /snap/name/current/snap/name/current...
<ogra_> iirc there was recently env var support added to snapcraft.yaml ... not sure that got released yet though
<d_ed> as if you ran an old version you'd hardcode into a different file
<ogra_> so you dont need to patch, you just define KF5_LIBEXEC_DIR= in your snapcraft.yaml
<d_ed> well, I need the patch in frameworks to actually look at KF5_LIBEXEC_DIR as it didn't exist yet
<ogra_> right, but you shouldnt need to patch the snap launcher for it
<d_ed> yep
<d_ed> thanks
<zyga> seb128: ah, right
<zyga> hmmmmm
 * zyga has no idea
<ogra_> wouldnt a relative prefix work ?
<ogra_> --prefix=./usr
<d_ed> and depend on the CWD from where you launch snap?
<dpm> ah zyga, I wanted to follow up - last week Jamie mentioned you'd had found some issues with the clock app, but I couldn't trace some of the things you mentioned in the wrapper. Could you remind me of the issues you found and confirm if that's the code you were looking at? -> http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/calculator.wrapper
<dpm> sorry, I mean *calculator snap, not clock
<davidcalle> dpm: about to publish, but see doc for an alternative title suggestion
<slangasek> zyga: I have no commit access to snap-confine, so no
<zyga> slangasek: can you propose a pull request
<zyga> slangasek: I've made a lot of improvements now and lintian is much happier
<slangasek> zyga: well, I don't have any packaging changes yet for snap-confine because I still only have ubuntu-core-launcher in Debian; so those would need to be rebased
<zyga> slangasek: ok
<zyga> slangasek: you should now be able to use 1.0.29 as a base for debian
<zyga> slangasek: just change packaging to not call --enable-rootfs-is-core-snap
<zyga> slangasek: and call --disable-confinement
<zyga> slangasek: that will make it work
<slangasek> ok
<zyga> slangasek: we should be able to do non-native packages
<zyga> slangasek: I don't know if you want to make that happen
<slangasek> zyga: so that's just 1.0.29+1 -> 1.0.29+2 for Debian, with the above changes?
<zyga> mhm
<zyga> yep
<zyga> and run some snaps to make sure it all works
<zyga> but I think w'ere good
<slangasek> non-native package would make sense to me, but I wasn't going to insist just yet
<zyga> ok
<slangasek> zyga: so looking at 1.0.29, I don't see --enable-rootfs-is-core-snap set anywhere
<slangasek> or supported in the code
<jdstrand> popey: so, snappy-debug mentioned what you need: add one of 'firewall-control, network, network-bind, network-manager, unity7, x11' to 'plugs'
<jdstrand> popey: I suggest using plugs: [ network ]
<dpm> davidcalle, replied, thanks!
<jdstrand> popey: especially if the application is trying to use the network (which is a safe bet, but only the snap author would know)
<popey> jdstrand: ahh, network-manager and firewall-control were new ones on me
<popey> gotcha
<davidcalle> https://developer.ubuntu.com/en/blog/2016/06/13/Snapcraft-210-zip-files-devmode-and-macaroons/
<slangasek> zyga: so yeah, I don't see how to do what you're describing on 1.0.29
<popey> jdstrand: added all those plugs and it fails in the same way
<zyga> slangasek: one sec
<dholbach> mvo, zyga: do you guys know why snapd is still stuck in -proposed?
<mvo> dholbach: its a bit unclear if all the verification is finished, we are discussed this right now with the sru guys
<dholbach> go go go! :)
<dholbach> let me know how things go
<slangasek> mvo: somewhat related, I see snapd 2.0.8+16.10 is still stuck in yakkety-proposed due to new autopkgtest failures
<slangasek> (these autopkgtest failures also show up on http://people.canonical.com/~ubuntu-archive/pending-sru.html, but I guess we'll ignore them...)
<seb128> dholbach, mvo, on http://people.canonical.com/~ubuntu-archive/pending-sru.html snapd has unverified bugs (not all green)
<dholbach> zyga, ^ too
<slangasek> yes, including the only bug that is /supposed/ to matter, which is bug #1588052 ;)  but they've been tagged v-done now
<ubottu> bug 1588052 in snapd (Ubuntu Xenial) "[SRU] New stable micro release" [Medium,Fix committed] https://launchpad.net/bugs/1588052
<slangasek> oh, but https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580463 still hasn't been
<ubottu> Launchpad bug 1580463 in apparmor (Ubuntu Yakkety) "Snap blocks access to system input methods (ibus, fctix, ...)" [Medium,In progress]
<seb128> right
<jdstrand> popey: you should've only needed the one plug 'network'. does it fail in exactly the same way? if so, can you uninstall then install again?
<seb128> slangasek, mvo, btw the i386 test issue looks like it's bug #1576066
<ubottu> bug 1576066 in libseccomp (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,Confirmed] https://launchpad.net/bugs/1576066
<jdstrand> slangasek, seb128 let me verify that
<jdstrand> (1580463)
<mvo> (in a meeting right now)
<popey> jdstrand: yes, it fails in the same way, i completely removed, rebuilt and reinstalled.
<seb128> well allowing socketcall should make it work, that's the workaround I was using locally
<popey> jdstrand: not using --devmode btw, should I?
<jdstrand> popey: are you sure it failed in the same way? look at the timestamp-- is it the same as the one in the paste?
<slangasek> seb128: right; strange, I somehow thought that one was already fixed in 2.0.8
<popey> jdstrand: http://paste.ubuntu.com/17289635/ looks same to me
<popey> -rw-r--r-- 1 alan alan 90206208 Jun 13 13:51 wine_1.6-git_amd64.snap
<jdstrand> popey: it might be failing cause of something other than the sandbox but showinng you the olddenial
<popey> snap built and installed just before that error
<seb128> slangasek, well, the snappy update "fixes" it by allowing socketcall, the real bug to fix is that libseccomp one though
<seb128> slangasek, the "fix" is only a workaround
<popey> jdstrand: paste shows time delta between the two reports
<seb128> slangasek, I was just pointing in case you didn't see the libseccomp one
<slangasek> seb128: but 2.0.8 is still failing, so not worked around after all
<seb128> oh ok
<seb128> I didn't try that
<jdstrand> popey: ok-- can you paste your yaml?
<seb128> slangasek, mvo marked the bug verification-done though?
<mvo> seb128: the syscall one is fixed in git
<mvo> slangasek: falling with a bad syscall?
<popey> jdstrand: sure
<ysionneau> hi, why not allowing "cross compilation" for the "copy" plugin in snapcraft?
<seb128> mvo, fixed? like you fixed libseccomp/bug #1576066
<ubottu> bug 1576066 in libseccomp (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,Confirmed] https://launchpad.net/bugs/1576066
<ysionneau> should just be a matter of adding def enable_cross_compilation: pass, no?
<seb128> mvo, or "fixed" like you allowed socketcall?
<mvo> seb128: yes, we allow this now
<popey> jdstrand: http://termbin.com/nlou my yaml
<jdstrand> allowed socketcall until it can be properly fixed
<seb128> k
<jdstrand> seb128: ^
<seb128> so workarounded
<seb128> wfm
<seb128> jdstrand, mvo, thanks
<mvo> oh, sorry, yeah, not "fixed" but "worked-around"
<slangasek> mvo: the current i386 autopkgtest for 2.0.8 is failing, no messages about syscalls in the log
<jdstrand> popey: you should change that to: plugs [ network, unity7, opengl ]
<popey> ok
<jdstrand> popey: not that it will fix the issue, just fyi
<jdstrand> popey: can you paste /var/lib/snapd/profiles/snap.wine.wine?
<jdstrand> popey: whoops
<jdstrand> /var/lib/snapd/seccomp/profiles/snap.wine.wine
<popey> jdstrand: ok
<ogra_> ysionneau, well, to do it properly you would have to enable multiarch on the host machine so it can find the foreign arch packages in the archive
<ogra_> there is a bit more to it
<ysionneau> ogra_: maybe there's something I don't get, I thought "copy" was just "dummy copy files"
<ysionneau> which does not imply compiling anything
<ogra_> it allows stage-packages
<mhall119> ogra_: where is the source for the freecad snap?
<ogra_> mhall119, no idea ... you have to ask the developer :)
<mhall119> well you mentioned it specifically when talking about translations support in snaps, so I assumed you knew something more about it :-P
<ogra_> mhall119, i pointed vejmarie to my nethack snapcraft.yaml and he adapted it for his freecad build ...
<popey> jdstrand: http://termbin.com/d8i8 - sorry for the delay - wanted to rebuild with your changed plugs first
<ysionneau> ogra_: anyway, it would be good to allow using copy to just copy files, when you cross compile
<jdstrand> seb128, slangasek: fyi, 1580463 is now verification-done
<seb128> jdstrand, thanks
<jdstrand> popey: hmm, so , the policy has recvfrom. Can you run scanlog now, then try to launch the app again and let me know if you get a new entry from scanlog?
<ogra_> mhall119, https://linuxfr.org/users/vejmarie/journaux/mon-premier-snap-sur-xenial has the snapcraft.yaml
<popey> jdstrand: same, recvfrom
<seb128> jdstrand, that's not enough to get ibus to work though, should I open a new bug about that?
<jdstrand> that is strange
<popey> jdstrand: http://paste.ubuntu.com/17289866/
<jdstrand> seb128: what else is needed?
<mhall119> thanks ogra_
<jdstrand> seb128: but to answer your question-- yes, that bug was about policy violations, what you need will not be a bug in the policy
<seb128> jdstrand, I need to re-test to make sure, but iirc ibus tries to get the ibus-daemon bus id from ~/.config/ibus
<popey> jdstrand: this might be a factor... /snap/wine/100001/bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=8d1c78fd3bb1c66399c240ccb4c0b1e6e64d961e, not stripped
<popey> 32-bit binary
<popey> (I'm on amd64)
<seb128> jdstrand, which is not available in the snap (or not under that path in any case)
<jdstrand> seb128: we allow that in the policy, but the snap is going to have to find it somehow. I think the problem is that HOME is set to ~/snap/$SNAP
<seb128> right
<seb128> which is still an issue to solve
<seb128> I guess ibus needs to be patched
<jdstrand> seb128: perhaps before you exec your app, have it do: "cd $HOME/../../"
<mhall119> ogra_: am I missing something, or are both examples hard-coding en_US as the locale?
<jdstrand> seb128: there are different ways to handle it. what I suggested would be a workaround, but might break the app in a different way (since maybe it need HOME to be ~/snap/$SNAP
<seb128> jdstrand, in fact ibus should use the xdg dirs so the env should make it work, let me re-test to make sure it really doesn't
 * jdstrand nods
<jdstrand> popey: that was my next question actually
<popey> heh
<jdstrand> popey: let me run the command in an x86 chroot
<mvo> slangasek: I believe the current i386 failure is a different one, I'm trying to reproduce this as we speak (I think its a new one :(
<jdstrand> popey: on i386 it is 'brk' which is in the policy
<jdstrand> popey: are you on yakkety or xenial?
<jdstrand> popey: are you using an ubuntu kernel?
<jdstrand> popey: can you give me the snap?
<jdstrand> basically, it should not have that denial based on the policy
<jdstrand> popey: are you using snap-confine/snap-run and not ubuntu-corelauncher?
<jdstrand> ubuntu-core-launcher*
<jdstrand> popey: actually, nm. I know the issue. it *is* that it is 32 bit and running on amd64. what is happening is that because it is amd64, it is getting the amd64 seccomp translation, but it needs the i386 filter translation. please install in --devmode
<jdstrand> popey: or better-- install 64bit version in the snap
<slangasek> zyga: sorry, any further guidance on snap-confine?
<mvo> slangasek: anything else pending on the snapd 2.0.8 release? anything we can or or need to do?
<sergiusens> ysionneau the copy plugin needs a simple fix if you want to use it with `--target-arch` (look at the tar plugin if you want to create a PR, will gladly accept), a unit test would be nice as well
<slangasek> mvo: not from my side; I gathered you were talking to infinity about it, was he going to hit the publish button?
<mvo> slangasek: I was only talking via ogra_as my proxy :) so no idea what the status is
<slangasek> ok
<slangasek> mvo: released
<ogra_> \o/
<slangasek> mvo: I would love to have a version newer than 2.0.2 releasable to yakkety (autopkgtests); among other things it would clean up component-mismatches
<mvo> slangasek: I tried to figure out why yakkety fails last week without much success so far, the errors are a bit strange and its exactly the same snapd code as in xenial that is tested, but I give it another go today and tomorrow (sorry that I don't have a better answer currently)
<slangasek> mvo: no worries, just want to make sure it's still on the list
<mvo> thank you!
<popey> jdstrand: I am on xenial, 4.4.0-23-generic
<popey> jdstrand: it's a 32-bit app. the 64-bit version of the snap contains a 32 bit build of the app
<ysionneau> sergiusens < I did the fix locally, but I stopped submitting PR to snapcraft since some test never passes and the PR never gets accepted
<oparoz> How close/far are you from a stable Snappy base image?
<ogra_> oparoz, every time we have to answer that question the image gets delayed by 1 day :)
<oparoz> lol
<oparoz> Sorry, I thought you were really close :)
<ogra_> "stable" is still far out ... a "first shot" might be a matter of 1-3 weeks
<oparoz> Thanks ogra_, that's useful info :)
<ogra_> (first shot meaning you will not have to re-flash)
<ogra_> dont take these numbers as official though ... i'm broadly guessing here
<oparoz> Yeah, that'll be good. Something which can be built by anyone and doesn't require a reflash
<oparoz> Still useful, I haven't followed the latest development and was just wondering :)
<zyga> slangasek: hey
<zyga> slangasek: yes, let's talk about it
<zyga> slangasek: when you said that this option didn't exist, where did you look?
<zyga> slangasek: I suspect you looked at the launchpad tree
<ogra_> zyga, he just went with his laptop in the backpack
<zyga> slangasek: did you see https://github.com/ubuntu-core/snap-confine/releases/tag/1.0.29
<zyga> ogra_: :)
<zyga> ogra_: thanks
<jdstrand> popey: https://bugs.launchpad.net/snappy/+bug/1592022
<ubottu> Launchpad bug 1592022 in Snappy "32 bit applications on 64 bit system fail due to seccomp" [Undecided,New]
<popey> jdstrand: do you still need the snap?
<jdstrand> popey: no. I can reproduce with /bin/ls
<popey> ok, thanks
<jdstrand> popey: not, my gut says that is not going to be fixed any time soon
<jdstrand> but investigation needs to be had
<popey> ok, will back-burner that one then
<popey> thank you
<jdstrand> popey: if you could find a 64 bit wine, it would work fine
<popey> yeah, I expect so, but it would not be useful :)
<jdstrand> no?
<popey> i believe not, but will test
<jdstrand> why not?
<jdstrand> fyi, Debian has 1.8.2
<popey> ok, will play more :)
<mhall119> sergiusens: so how does the translations in nethack work, do you include all the language files in the snap?
<sergiusens> mhall119 I don't know what nehack uses, can't really answer that
<sergiusens> but I would imagine that is a start
<zyga> ogra_: have you guys finished working for today?
<mhall119> sergiusens: ok, I'm just lost reading these launcher scripts trying to figure out what is actually being done :(
<mhall119> ogra_: ^^ I guess you'd be the one to help with nethack, not sergiusens
<mvo> slangasek: autopkgtest on i386 works for me https://github.com/snapcore/snapd/pull/1316
<mvo> slangasek: with that branch, so hopefully (and I know I promised this last time) with the 2.0.9 we have xenial/i386 green
<dpm> Has anyone seen a similar error message, or am I doing something wrong?
<dpm> - Download snap "ubuntu-clock-app" from channel "stable" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/vjQhIxU28Zszo6iEjbbrmosRqSpBq4GD_5.snap)
<dpm> that was after doing `sudo snap install ubuntu-clock-app`
<dpm> actually, it seems I can't install any snaps now :/
<Sweet5hark> so, I just published a snap on beta/edge channels. How do I get/install those?
<Sweet5hark> (has to be beta, as it is devmode)
<pedronis> Sweet5hark:  snap install --channel=beta ...
<willcooke> https://bugs.launchpad.net/snappy/+bug/1591664
<ubottu> Launchpad bug 1591664 in Snappy "'snap install' should support --beta, --candidate and --edge options" [Medium,In progress]
<willcooke> pedronis, should that work for snap find too?
<Sweet5hark> pedronis: thx
<noise][> willcooke: snap find only searches stable
<willcooke> thx noise][
<shuduo> hello, i tried to install a snap app on Ubuntu Desktop 1604 then I interruppted installation with Ctrl+C as slow networking. Now I get 'snap: "ubuntu-core" has change in progress' when I tried to install again. How I can resume installation or reset to initial state?
<qengho> shuduo: I have gotten this at least three times. It needs a really good bug report. Do you think you can write it?
<shuduo> qengho: OK. let me do it.
<sergiusens> elopio coming back to the environment fixture, is there a way to clear the complete environment?
<sergiusens> elopio that is what I want
<elopio> sergiusens: EnvironmentVariable('PATH', None)
<shuduo> qengho: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592074
<ubottu> Launchpad bug 1592074 in snapd (Ubuntu) "ubuntu-core is change in progress after interrupt "snap install"" [Undecided,New]
<sergiusens> elopio whatabout every other environment variable exported in my running environment?
<sergiusens> elopio do I need to do a for k in os.environ.keys()?
<sergiusens> elopio look at the test and you will understand :-)
<elopio> sergiusens: ah, so you want to have no env var. Yes, I would write a new fixture that does os.environ = empty, and resets it in the cleanup.
<elopio> sergiusens: https://github.com/testing-cabal/fixtures/blob/master/fixtures/_fixtures/environ.py
<sergiusens> elopio btw, have you taken a look at `pytest`?
<elopio> sergiusens: never tried it seriously. Do you want that instead of testtools?
<qengho> shuduo: I filed a sister bug report for something similar: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592088
<ubottu> Launchpad bug 1592088 in snapd (Ubuntu) "snap command doesn't finish when snapd already gave up" [Undecided,New]
<qengho> I'm dumb for asking this before justtryitalready, but I use avahi/zeroconf to advertize that my services exist and where. There can be only one zeroconf daemon listening on port Whatever, so services use dbus or something to ask the zeroconf daemon to advertize on their behalf. How could that work in a snappy world?
<qengho> I see someone's packaging Squid, for instance. My cache-needy client could discover that over zeroconf requests. But, I don't know how the squid snap would advertize itself.
<qengho> Assume I ship my own zeroconf in case there is no system one. Or something.
<sergiusens> elopio can you look at the gulp PR again?
<sergiusens> elopio I am not saying I want to, just asking what your opinion was
<elopio> sergiusens: running through the document now. Give me a few minutes.
<roadmr> Hey folks! I'd like one of the commands in my snap to call another, but if I just say "foo", it uses the actual binary in $SNAP/bin, and I'd like for it to use the wrapper in /snap/bin/foo. Is it OK to use an absolute path here?
<beuno> roadmr, so, snaps are meant to be confined, so generally not easily able to call each other
<roadmr> beuno: this is the same snap
<beuno> oh, so snapname.binary should work
<beuno> I think absolute paths are fragile
<roadmr> beuno: oh, I may be able to hack that...
<roadmr> beuno: yes, agreed, that's why I'm looking for advice :)
<roadmr> beuno: the snap is called bar, so it has two binaries in /snap/bin: bar and bar.foo; the thing is that bar.foo should call bar but if I just say bar, it goes to $SNAP/bin. But maybe I can put bar in bar-baz or something so I get the namespacing. OK, hacking!
<beuno> roadmr, wouldn't bar.bar work?
<roadmr> (basically if the command's name is the same as the snap's, it collapses them so it's not bar.bar haha)
<roadmr> beuno: hm, let me try that
<roadmr> beuno: no, doesn't work :/ no biggie, let me shuffle my wrappers
<trijntje> is there a way to get an offline or pdf version of the snappy documentation? I want to learn snap but I'd like to read most of the docs offline
<sergiusens> roadmr beuno instead of calling the exposed binary name call the internal one, that is the guidance I got from jdstrand
<roadmr> sergiusens: thanks for looking into this! much appreciated, I'll try that
<roadmr> (I had it working with the external one but let's try with the internal command)
<sergiusens> elopio added an integration test for gulp
<sergiusens> roadmr might work in devmode, but once confined doing the seccomp or apparmor pivot might be hard
<roadmr> sergiusens: exactly the problem I'm having - only works in devmode :(
<sergiusens> roadmr so calling the internal binary should solve that
<roadmr> "Parts 'gnuchess' and 'glue' have the following file paths in common" - is there a way to force overwriting the file in common? I want to replace the one that part A creates with one from a "glue" part which is better-customized
<roadmr> A == gnuchess btw
<alejo_> Hi everyone. O have a question.  I developed an app for my job and I want to snap it. My problem is that when I start my app it does not show the window. I have this problem with some snaps. Can someone point me in the right direction?
<tsimonq2> elopio: you around?
<slangasek> zyga: ok, so your 1.0.29 tag doesn't match the 1.0.29 that was already uploaded to the archive; you might want to do a bit of revision surgery there
<roadmr> ok, so in --devmode, one of the binaries in my snap does "exec" and calls the other successfully. Without devmode, I don't even see the "exec" call (denied or otherwise) in syslog. Is there some magic needed to allow exec?
<roadmr> (a plug maybe? none of the ones I see in "snap interfaces" sounds topical)
<zyga> slangasek: I moved the tag one commit further to ship tests in the tarball
<zyga> slangasek: sorry, you just saw the wrong window there ;)
<roadmr> zyga: \o/ which plug do I need for a command in my snap to be able to use the setpriority syscall?
<sergiusens> roadmr use the snap, stage and organize keywords
<roadmr> sergiusens: I'll read up on those :) whee
 * roadmr probably just needs to dive into the docs
<slangasek> zyga: no... ubuntu-core-launcher 1.0.29 was uploaded to Ubuntu on 10 May, your 1.0.29 doesn't match the "real" 1.0.29 that already exists
<sergiusens> roadmr `snapcraft help plugins`
<roadmr> sergiusens: oh great! thanks! heh
<croepha> anyone use chef or puppet  or similar with core ?
<sergiusens> elopio http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1056/console about this
<sergiusens> elopio would be good if we `set +e` after the tests run (or right before) to not be affected by that error ^
<Sweet5hark> so, I have a libreoffice.canonical package uploaded and published to beta and edge channels of the store, but "sudo snap install --devmode --beta libreoffice.canonical" or "sudo snap install --devmode --beta libreoffice" both return that the snap could not be found. any help?
#snappy 2016-06-14
<elopio> 
<tsimonq2> hello :)
<elopio> sergiusens: that one fails because on the all-snaps image something left an apt running, so the others couldn't install things.
<elopio> weird. But I just need a  little time to make that error better. Hopefully tomorrow.
<tsimonq2> elopio: hey, would you happen to have time to look at https://github.com/ubuntu-core/snapcraft/pull/567 ? I'm working on it right now and I would like some feedback on something.
<tsimonq2> s/something/two things/
<elopio> tsimonq2: hey there. I can take a look in ~30 mins.
<tsimonq2> elopio: alright, I'll be around, thank you
<elopio> thanks to you
<sergiusens> elopio is it good to go then?
<elopio> sergiusens: no, it needs a retry. Many tests failed. http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1056/testReport/
<sergiusens> Boo
<sergiusens> Let me update branch
<tsimonq2> elopio: because I already knew it would get pointed out that Subversion was not with the other version control systems, I just rearranged it and committed :D
<jdstrand> beuno, roadmr: what sergiusens said-- we don't allow calling snap.app because that invokes the launcher and to be able to invoke the launcher you need to grant permissions to setup the sandbox and if you have the permissions to set the sandbox you can shange your own sandbox
<jdstrand> change*
<zyga> slangasek: ohhh
<zyga> slangasek: I see, this is the problem when we fork projects and move them around :/
<zyga> slangasek: I'll bump the version to 1.0.30 with an appropriate message
<zyga> slangasek: but we should really move away from lp:ubuntu-core-launcher towards snapcore/snap-confine
<zyga> mvo: ^^ FYI
<mvo> thanks zyga
<slangasek> zyga: agreed, re: moving; I've already uploaded 1.0.29+2 to Debian unstable including the Vcs-* move to github
<zyga> slangasek: the +2 version is the onfe from snapcore?
<zyga> slangasek: I'm sorry if I seem confused, I just woke up
<slangasek> zyga: yes; I took what was in the snapcore github, threw a 1.0.29+2 version on it, adjusted the packaging to avoid NEW, and uploaded
<zyga> slangasek: so snaps work on debian now?
<slangasek> zyga: yes
<slangasek> zyga: FTR I haven't successfully tested X-using snaps yet, something was wrong with my X forwarding from my VM; will double-check that today
<zyga> slangasek: was your VM headless?
<zyga> slangasek: thanks, let's make sure it works
<slangasek> zyga: I installed it as a base Debian system, no GUI in the VM
<slangasek> and I'm at a sprint where the bandwidth is not as advertised, so installing a desktop stack in the VM would be a fool's errand at the moment
<zyga> slangasek: ok, I see
<zyga> slangasek: I asked if elopio can test this and he's already on it
<dholbach> good morning! :-)
<ogra_> chiluk, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<dholbach> Can you snap* people join gitter too? https://gitter.im/ubuntu/snappy-playpen
<sgclark> Hi all, I hope to upload some KDE stuff to the beta storee today, I here there is some magic snapcraft command to achieve this?
<dholbach> zyga, can you review http://askubuntu.com/review/suggested-edits/578918? :-)
<sgclark> dholbach: I have a a meeting shortly, but if I do not have to show my ugly mug, perhaps after.
<dholbach> sgclark, https://developer.ubuntu.com/en/snappy/build-apps/upload-your-snap/
<sgclark> thanks
<zyga> dholbach: looking
<zyga> dholbach: this looks good, I don't know how I can review / approve it
<dholbach> zyga, oh ok... I thought you could do it... nevermind then. It looks approved now. Maybe somebody else was quicker. :-)
<willcooke> morning all
<zyga> ok
<willcooke> jamiebennett, Sweet5hark - hello!
<willcooke> Sweet5hark, can you explain your issue with installing from the beta store again?
<Sweet5hark> well, I uploaded a libreoffice snap to the store to beta/edge channels (as it is devmode) and published it (on the canonical account). Unfortunately, it doesnt show up in "snap find" and does not seem to be installable even with "snap install --channel=beta libreoffice".
<jamiebennett> Sweet5hark: what is the exact name of the libreoffice snap, is it "libreoffice"?
<Sweet5hark> yes
<jamiebennett> let me have a look
<ogra_> wohooo !!!
 * ogra_ dances
<Sweet5hark> jamiebennett: "libreoffice" or "libreoffice.canonical"
<mvo> Sweet5hark: might be a store issue, we had similar issues before, once sec
<jdstrand> zyga: hi! when were you thinking snap-confine would got to 6.04?
<jdstrand> err 16.04
<mvo> Sweet5hark: I'm asking the store people now, we had a similar issue some days ago where some reindex was needed
<ogra_> mvo, do you usually just copy-package livecd-rootfs to the PPA or do you do an actual upload ?
<davidcalle> Howdy, I'm trying to upload VLC to the store and it fails with "package contains external symlinks: lib64/ld-linux-x86-64.so.2 lint-snap-v2_external_symlinks", shouldn't snapcraft warn me in these cases?
<mvo> ogra_: I usually do an upload
<ogra_> ok
<mvo> ogra_: why do you ask? is there an advantage/disadvantage?
<ogra_> mvo, nah, just want to know, so we use the same process
<ogra_> (tonights build failed, need to upload the last livecd-rootfs)
<davidcalle> kyrofa: sergiusens, is that to be expected, that a snapcrafted snap builds/installs correctly but is rejected by the store? ^ (same rejection also happens with another one)
<ogra_> (pushed)
<mvo> Sweet5hark: store people are working on the issue
<jdstrand> sergiusens: fyi, I like how snapcraft is quieter in the 'snapcraft snap' step, but I think it may be too quiet. I'm snapping a large snap (1GB) and all I have is the spinner and not a progress meter, and so I don't really know what's going on
<mvo> ogra_: iirc you mentioned there is a qemu for pi2? is that packaged yet somewhere?
<mvo> ogra_: would love to use it for image build tests :)
<davidcalle> jdstrand: any advice on my external symlinks issue? ^
<davidcalle> What I'm wondering is: why is it blocking a package marked as requiring devmode, why is it the first time I stumble upon this, I would expect getting a warning from snapcraft
<zyga> jdstrand: I think that's up to mvo, I'd like to do that in 2.0.9 or .10 maybe
<jennym> Hi, anyone have any experience using ant plugin (for building java projects) and copy plugin?
<zyga> jennym: no, sorry
<jennym> zyga: Do you know where else I could get some assistance.
<zyga> jennym: yes, stick around a
<zyga> jennym: ask on snapcraft@lists.ubuntu.com
<zyga> jennym: ask sergiusens when he's around
<ogra_> mvo, i dont think that was me ... there is a qemu hack for BBB that i know of
<jdstrand> davidcalle: it indicates that your snap has symlinks pointing outside of the snap that liky don't exist and are dangling symlinks. it isn't a devmode thing. I'm not sure why snapcraft idn't alert you
<ogra_> mvo, did you turn on proposed for snappy builds ? i see it is suddenly enabled everywhere (and makes builds fail on amd64)
<sergiusens> jdstrand we will need to patch mksquashfs to get only progress and not the big dump
<ogra_> heh
<ogra_> it has a --noprogress option iirc ... so it just needs a --only-progress option now
<sergiusens> davidcalle you can manually run the reviewer tools, we are not doing that yet as we weren't on par up until a moment ago.
<mvo> ogra_: I did a one-off PROPOSED=1 build on ~saturday or sunday, nothing else
<ogra_> mvo, weird, that seems to have stuck somehow ... i cant manage to build without proposed at all anymore
<ogra_> and kernel meta packages being out of sync now make the images fail ...
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/65242 ... (Pocket: proposed) ...
<ogra_> all i'm currently running is:  ARCHES=amd64 DIST=xenial SUBPROJECT=system-image EXTRA_PPAS=snappy-dev/image for-project ubuntu-core cron.daily-preinstalled --live
<ogra_> and that shouldnt enable proposed at all
<ogra_> ... i'll try to hunt down infinity to take a look
<mvo> ogra_: when I greped for PROPOSED=1 in the script I am pretty sure it does not store that somewhere, strange indeed
<ogra_> yeah, very ... you didnt put it indo cdimages ~/.bashrc or ~/.profile either i guess *grin*
<ogra_> *into
<mvo> ogra_: I don't think so ;)
<zyga> sergiusens: please send your contributions upstream
<ogra_> env also doesnt show the var set
<ogra_> very strange ... adam is in a meeting though ... once he comes out i'll corner him :)
<ogra_> mvo, myth solved ... seemingly proposed is enabled globally for xenial now ... we actually need to build with PROPOSED=0 now
 * ogra_ adds that to the cron job for the default builds
<mvo> woah
<mvo> thats interessting (and scary ;)
<ogra_> yep
<dpm> seb128, hey
<dpm> seb128, does this GTK wrapper look similar to the latest work that you guys have been doing with GTK apps' wrappers, or do we need to include any recent changes you've done? https://github.com/dplanella/gtkconf/blob/master/gtk-launch
<seb128> dpm, howdy
<seb128> dpm, let me have a look
<dpm> great, thanks
<pmp> hi ogra, I'm getting back to you concerning dtoverlay usage with rpi and a custom kernel snap flashed with current u-d-f.
<seb128> dpm, how come some of us are doing the same work though :-/
<seb128> feels like waste/duplication
<sergiusens> zyga sorry, but what are you talking about? :-)
<pmp> ogra_: my kernel boots - which is nice
<sergiusens> zyga oh, mksquashfs I guess
<ogra_> pmp, right ... until the final version of the 16 images is there you will have to mangle the overlays manually
<dpm> seb128, well, the idea of that is to _remove_ duplication. That's a wiki part that most GTK apps should be able to use
<pmp> ogra_: your last hint was to copy the dtbo files manually to the boot-partition
<ogra_> specifically on the rpi where you need to create an overlays dir in the vfat
<pmp> like it is on raspian?
<seb128> dpm, right, asked differently why didn't we get concerned people Cced on a same email or talking before things got set up/started
<ogra_> i know niemeyer works on defininng some high level thing soo you caan do that from the gadget snap in the future
<ogra_> pmp, right, just like on raspbian
<seb128> dpm, oh well, in any case that seems mostly to be what we used, outdated revision missing some improvement and bugfixes though
<zyga> sergiusens: squashfs changes
<dpm> seb128, I'm not sure what you mean. We knew about the work you guys were doing with gtk apps and reused that, that's all
<seb128> dpm, is that going to be including in snapcraft itself?
<dpm> seb128, it's a part for now that snaps can point to in their snapcraft.yaml file, I'm not sure it would make sense to have a gtk plugin, but sergiusens might have better ideas
<seb128> dpm, forget about the comment, seems we each have diverging branches with different improvements/fixes but that's not the end of the world
<seb128> it's just that seeing work duped bothers me
<seb128> seems like we have several team working on the same things in not really coordinated ways
<dpm> seb128, I'd say on the contrary: you guys did the heavy lifting with the wrapper, and we're proposing a reusable part before everyone starts copying over that gtk wrapper in their snaps
<seb128> dpm, yeah, I guess I'm just grumpy because we didn't get involved in how/where that reusable parts have been set up
<seb128> like you clearly based on a version of our wrapper outdated with bugs
<seb128> I would have preferred that somebody included us upfront
<seb128> you also apparently did change to deal with gtk2 vs gtk3 that you didn't send us back/asked us for comment
<dpm> seb128, there wasn't much to coordinate, to be honest: I just did it this morning, and I thought I'd touch base with you now
<seb128> k
<dpm> and the gtk2 vs gtk3 bit is not yet working (but on the way to, I hope)
<seb128> dpm, anyway, you miss some fixes but it seems to be mostly good
<dpm> cool
<seb128> I also think it doesn't make sense to have a gtk plugin
<seb128> but most of those hacks should go away over time
<seb128> like snapcraft/snapd should export the proper env variable
<dpm> seb128, ack . Where are those latest fixes, so that I add them to the plugin?
<seb128> rather than requesting every snaps to set e.g the xdg dirs
<dpm> that's indeed a pain, yes
<sergiusens> kyrofa mind looking at https://github.com/ubuntu-core/snapcraft/pull/563 ?
<seb128> dpm, same, https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap
<seb128> dpm, diff them, I improved some things in commit 7 when I merged back the work from trevinho
<seb128> dpm, like your wrapper is probably displaying warnings on first start about invalid symlinks or so
<seb128> his code was not checking for empty dirs and suchs
<dpm> seb128, cool, thanks. Also, what's the best way to give you guys back changes/bug fixes?
<seb128> dpm, we don't have a proper project for that, diff via email or pastebined and shared on #ubuntu-desktop I guess
<seb128> dpm, none of you guys looked at getting translations to work by any chance?
<dpm> ack
<dpm> seb128, not yet. I looked at it for qt/sdk apps, but I failed
<seb128> k
<seb128> no worry
<kyrofa> sergiusens, sure thing!
<pmp> ogra_: the dtparam-parameter works, but dtoverlay-commands seem to be ignored, not sure how I should debug this
<ogra_> hmm, that should just work from config.txt ... we just use the upstream blobs from broadcom ... shouldnt be any different from raspbian
<pmp> ogra_: probably out of scope here, who is merging the device-tree with the overlays, the blobs from broadcom? When is it done? I assume it's done before u-boot boots .. how does the kernel then find the right merged device-tree?
<ogra_> right, it happens inside the broadcom blob ... there is hope the u-boot feature that just landed to merge dtbs is stable enough to actually use it instead for the final images
<ogra_> i will look into that next week (i'm at a sprint this week)
<roadmr> Heya folks! How can I get one of the binaries in my snap to be able to use the "setpriority" syscall? I think it's failing to call another binary in the same snap because of that.
<roadmr> (it works in devmode, btw)
<ogra_> likely thought an interface that doesnt exist yet ... zyga or jdstrand should be able to tell you
<pmp> ogra_ et roadmr , there should be a bug on launchpad for that
<pmp> we had the same problem
<roadmr> thanks ogra_ :)
<roadmr> meanwhile I'll try to hack the setpriority away from the binary to see if that's the only snag...
<pmp> roadmr: if you're running in devmode you should see apparmor warnings in syslog for all restriction you would see in real-life
<roadmr> pmp: indeed! that was the only suspicious one I saw
<pmp> ogra_: so, if I understand you correctly, uboot does not, currently, support dt-overlays merging on raspberry-pi. I found this discussion https://github.com/raspberrypi/linux/issues/942 saying exactly this
<pmp> ogra_: could I bypass u-boot and still boot to ubuntu? and will it be happy?
<ogra_> pmp, nope, all the boot logic in snappy lives in the uboot scripts
<ogra_> jospoortvliet, congrats on the nextcould release !
<ogra_> jospoortvliet, where is the snap ? :)
<tsimonq2> !info xfonts-100dpi yakkety
<ubottu> xfonts-100dpi (source: xfonts-100dpi): 100 dpi fonts for X. In component universe, is optional. Version 1:1.0.4+nmu1 (yakkety), package size 3733 kB, installed size 3971 kB
<tsimonq2> !info aspell-en yakkety
<ubottu> aspell-en (source: aspell-en): English dictionary for GNU Aspell. In component main, is optional. Version 7.1-0-1.1 (yakkety), package size 258 kB, installed size 330 kB
<jospoortvliet> ogra_: hahaa snap will be here soon I bet
<jospoortvliet> kyrofa: must be all over it :P
<jospoortvliet> kyrofa: now you know what we've been up to...
<jospoortvliet> whohoo :D
<ogra_> hopefully soon :)
<ogra_> great stuff :)
<jospoortvliet> for ppl not sure what the heck we're talking about: https://nextcloud.com/nextcloud-9-available-enterprise-functionality-to-be-open-source/
<jospoortvliet> yes, we go 100% open source (yay) and the first release already has some 'enterprise' features. Yay for liberating them :P
<ogra_> nice !
<jospoortvliet> awesome, right?
<kyrofa> jospoortvliet, awesome :) . Not diverged too much from ownCloud just yet though?
<ogra_> GRRR ... hotel wifi
<ogra_> (just kicked me out completely in the middle of commiting something)
<dpm> sergiusens, is there a cache of some sorts for wiki parts? I've done `snapcraft clean && snapcraft` for an app that pulls a wiki part that I just changed (gtkconf in https://wiki.ubuntu.com/Snappy/Parts), looking at the generated snap, it does not have those latest changes
<dpm> Either that, or `source-branch: devel` in the wiki page is being ignored
<sergiusens> dpm yes there is, but not in anything from snapcraft. The wiki's webfront just returns old results I believe
<dpm> sergiusens, oh, so how long in your experience until a change is made in the wiki and the server returns the updated data?
<sergiusens> dpm 10 minutes or so
<dpm> sergiusens, ok, good to know, thanks
<sergiusens> dpm also, might want to start playing with the future https://wiki.ubuntu.com/snapcraft/parts?action=raw
<dpm> sergiusens, I saw that, but you only wanted to give us a sneak peek, so I'm not sure what to do with it ;)
<tsimonq2> elopio: when you have a chance, can you look at my PR again? I think I'm done :)
<sergiusens> dpm this all might land next week ;-)
<sergiusens> elopio I fixed the integration test
<dpm> \o/
<pmp> ogra_: fyi, I succeeded with my device-tree-overlay on raspi
<pmp> ogra_: by integrating the device-tree stuff into the main device-tree
<pmp> ogra_: and then overwriting the /boot/bcm2709-rpi-2-b.dtb
<pmp> ogra_: overwriting the one in /boot/rpi2-kernel_0.snap/dtbs didn't work
<sergiusens> kyrofa just saw you reviewed as well, nice catches!
<kyrofa> sergiusens, no problem :)
<sergiusens> elopio btw, where do you get that `-` is not valid for ranges?
<sergiusens> kyrofa do you know about that? ^
<kyrofa> sergiusens, a comment he made in review?
<sergiusens> kyrofa yeah, but I want to know where the fact that it is not valid comes from
<sergiusens> kyrofa I would think that 2015-2017 implies: 2015, 2016, 2017
<kyrofa> sergiusens, ohhh
<kyrofa> sergiusens, same here. I use commas when it's two years and hyphens after that
<kyrofa> jospoortvliet, https://github.com/kyrofa/nextcloud-snap . Tested and working, publishing asap
<elopio> sergiusens: FSF guide. Take a look at http://git.savannah.gnu.org/cgit/emacs.git/tree/README#n99
<elopio> That statement is what makes the - valid. I don't know, layers are weird.
<jospoortvliet> kyrofa: whoah, amazingly quick...
<kyrofa> jospoortvliet, I told you, as soon as you had code!
<jospoortvliet> you're a man of your word
<jospoortvliet> respect
<jospoortvliet> real awesome
<sergiusens> elopio that actually implies that what I did is fine
<kyrofa> sergiusens, elopio agreed, it seems that hyphens are fine
 * sergiusens leaves to pick up his kid from daycare
<dpm> hi jospoortvliet, now that I see you here... this might be interesting for you too -> https://design.canonical.com/2016/06/the-app-design-clinics-are-back/
<jospoortvliet> ah nice
<jospoortvliet> guessing that might just need a nextcloud logo ;-)
<dpm> yeah, I guess the app was created pre-nextcloud :)
<kyrofa> Sweet5hark, https://askubuntu.com/questions/786974/libreoffice-5-2-snap-will-it-use-my-existing-profile
<mhall119> hi guys, I'm trying to setup another machine to build snaps for me, but I'm getting this on cleanbuild:
<mhall119> error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: permission denied
<mhall119> any ideas?
<mhall119> srw-rw---- 1 root lxd 0 Jun 14 12:52 /var/lib/lxd/unix.socket
<Sweet5hark> kyrofa: heh, that's an excellent and tricky question to answer ..
<sabdfl> jospoortvliet, welcome!
<kyrofa> mhall119, probably a sergiusens question
<mhall119> jospoortvliet: got that nextcloud snap in the store yet? :)
<kyrofa> mhall119, it's building now
<kyrofa> mhall119, i386 is the only one completed so far
<Sweet5hark> kyrofa: http://askubuntu.com/questions/786974/libreoffice-5-2-snap-will-it-use-my-existing-profile/786991#786991 <- answered, I hope that is ok.
<mhall119> kyrofa: excellent! Is jospoortvliet (or someone from nextCloud) all setup with an account in MyApps to publish them?
<kyrofa> mhall119, not yet, it's in the canonical account. But we can give them the name whenever they would it
<kyrofa> would like it*
<mhall119> jospoortvliet: ^^ you want that, so you guys can push updates directly (including use the beta-testing channel)
<niemeyer> jdstrand: ping for review on spread snap
<matteo> ciao
 * svij installed his first snap on archlinux. :)
<zyga> svij: woot! :)
<jamiebennett> \o/
<svij> can we have snapcraft as a snap?
<sergiusens> svij soon-ish
<svij> yay
<beuno> olli_, sabdfl, I'll fix freenode perms soon for a wider list of access
<olli> beuno, mind repeating for olli
<beuno> so many olli's
<olli> thx
<tsimonq2> (maybe just do his cloak?)
<olli> I was competing with myself  for the nick
* olli changed the topic of #snappy to: Package any app for any Linux desktop, server, cloud or device. Read how on http://www.snapcraft.io
<tsimonq2> http://snapcraft.io/create/ <-- this doesn't have instructions for any other flavor yet, it only lists `sudo apt install snapcraft`, and I heard something about Arch?
<svij> on Arch it's in the AUR, tsimonq2
<tsimonq2> so yeah, it should probably be added to that page, whoever has access
<olli> jamiebennett, ^
<jamiebennett> Hi tsimonq2. At the moment we are offering the snap runtime, snapd, on other distributions to enable snaps to be run. Supporting snapcraft so that you can create snaps on other distros is being worked on at the moment.
<tsimonq2> oh okay, thank you jamiebennett
<tsimonq2> jamiebennett: anything I can do to help, or is it not code related?
<jamiebennett> tsimonq2: sergiusens and kyrofa are working on that and can comment better on what is needed
<tsimonq2> jamiebennett: thank you for your time :)
<jamiebennett> tsimonq2: hey, no problem at all
 * svij made a one-line patch to snapcraft before it was cool.
<tsimonq2> sergiusens, kyrofa: is there anything I can do to help with what he mentioned?
<sergiusens> tsimonq2 sorry, I cannot follow the chain of thought in the thread, help with what exactly?
<jamiebennett> sergiusens: we were talking about snapcraft support on other distros
<jamiebennett> sergiusens: and what it would take to make it happen
<sergiusens> jamiebennett tsimonq2 we have a plan, but it is not going to be easy, end goal might be to make it a snap as svij hinted a while ago
<tsimonq2> sergiusens: I think that might be a good option, because on a snap-only system, as far as I know, you can't use snapcraft
<jamiebennett> tsimonq2: basically snap support in LXD can help us here and that is actively being worked on at the moment
<jamiebennett> tsimonq2: once that is available we will be able to progress further on the snapcraft cross-distro story
<zyga> tsimonq2: https://github.com/zyga/devtools/blob/master/classic.sh
<tsimonq2> jamiebennett: okay, thanks
<tsimonq2> zyga: do you accept pull requests? :)
<tsimonq2> ahh yes, says so in the readme
<zyga> tsimonq2: absolutely!
<tsimonq2> zyga: you have a pull request :)
<tsimonq2> jamiebennett: http://snapcraft.io/ needs a favicon.ico
<tsimonq2> s/needs/should have/
<jamiebennett> tsimonq2: Good catch, thank you
<jamiebennett> I've reported it to our webteam
<kyrofa> jospoortvliet, alright, nextcloud has been published
<niemeyer> jdstrand: ping
<niemeyer> tyhicks: ping
<mariogrip> this is awesome! http://news.softpedia.com/news/snap-packages-become-the-universal-binary-format-for-all-gnu-linux-distributions-505241.shtml
<tsimonq2> mariogrip: yeah! :D
<netphreak> Nice!!
<Shibe> What are snappy "realms"?
<aisrael> What's the procedure for installing extra kernel modules on snappy? In particular, trying to get a wireless dongle to work (a ralink 801.11n usb)
<marcoceppi> Okay, I'm ready to snap, but I have no idea for what to do
<caraka> It is totally worth stepping through the tutorials one by one and bulding each of the examples, marcoceppi
<marcoceppi> caraka: I've tried, the project I want to build has a deb and stuff
<marcoceppi> it's a golang project
<marcoceppi> none of the examples really enumerate that, was wondering if there was ane xample like that
<caraka> there are examples of both incorporating debs and working with go in the tutorials
<caraka> If I recall, they are separate tutorials, you'd have to combine the concepts
<caraka> I'm just working through them all myself
<caraka> snappy is a work in progress. I know that when I have come here with specific questions, I usually get an answer or a link to one.
<tsimonq2> caraka: what do you need?
<ali1234> so..... can i package software from raspberry pi 1 now?
<tsimonq2> zyga: the note you left on line 30, are you talking about replacing it with $classic, if not, I don't know what you mean, could you clarify?
<zyga> tsimonq2: hey
<zyga> tsimonq2: I like your change, I just want to make it a little bit more generic
<zyga> tsimonq2: everywhere where the script had hard-coded 'xenial' just use a variable ($classic)
<tsimonq2> zyga: yep, I'm working on the script now
<tsimonq2> zyga: I'm making it so you can do a lot more with it
<zyga> tsimonq2: fantastic, thanks :)
#snappy 2016-06-15
<TheMuso> I'm working on a snap that is command-line tools, but it has multiple command-line tools. When installing the snap, I notice the files in /snap/bin are renamed snapname.command... Any way to work around this in snapcraft.yaml, or is this by design?
<jdstrand> niemeyer1: done
<lpotter_> TheMuso: that's the design
<jdstrand> Chipaca: hey, when you have a moment can you help me debug a testsuite issue?
<TheMuso> lpotter_: Urm ok.
<Gunther_> Good morning! Is there a way in vivid, to influence ubuntu-device-flash so that I am able to set a custom static ip (instead of dhcp)? How can I change the "ubuntu" user or its password. I want to do this changes to the image at time of creation.
<trijntje> Hi all, I'm trying to get started using snaps by following the webcam tutorial on the site. I've got the snap to build, but when I install it with sudo snap install webcam_0.1_amd64.snap I dont know where it went
<tsimonq2> !info kde4-config yakkety
<ubottu> Package kde4-config does not exist in yakkety
<tsimonq2> !info kde-config yakkety
<ubottu> Package kde-config does not exist in yakkety
<tsimonq2> hmm
<tsimonq2> !info kdelibs-bin
<ubottu> kdelibs-bin (source: kde4libs): core executables for KDE Applications. In component universe, is optional. Version 4:4.14.16-0ubuntu3 (xenial), package size 181 kB, installed size 791 kB
<tsimonq2> \o/
<nhaines> I'm sort of curious as to how far out the pulseaudio socket is from landing in snapd.  :)
<tsimonq2> ^ yeah that would be nice
<nhaines> I have a cute little script whose only function is to throw sound at the speakers.  I'd love to snappify it.
<tsimonq2> nhaines: link? :D
<trijntje> Should snap packages work in a normal 16.04 system? I've tried to install the 'hello' package with 'sudo snap  install hello', but when I run it I get  failed to create user data directory. errmsg: Permission denied
<tsimonq2> trijntje: I am getting that exact same error on my machine, I think it's been reported already, but I could be wrong
<nhaines> tsimonq2: oh, I should probably put it on LP or at least a bzr directory...
<nhaines> http://www.apress.com/9781484206096 under "Source Code/Downloads".  It requires sox.
<trijntje> tsimonq2: ok thanks, I'm trying 'notes' now
<trijntje> hmm, same error
<dholbach> tsimonq2, trijntje: does 'snap changes' give anything?
<dholbach> is this with snapd 2.0.8?
<nhaines> dholbach: how do I find what's changed between various revisions of the moon-buggy snap?
<dholbach> nhaines, I think I would need to put it into changelog box when uploading the snap :)
<dholbach> the last upload was quite a while ago, so I'm not sure what I changed back then
<nhaines> dholbach: sure, but I don't think that shows up with 'snap' at all either, right?  :)
<mvo> tsimonq2, trijntje: anything in "ls -lR ~/snap" that is owned by a different user (or root) by any chance?
<tsimonq2> snap changes gives nothing
<tsimonq2> mvo: everything in ls -lR ~/snap shows that I'm the owner
<tsimonq2> dholbach: and yes, snapd 2.0.8
<trijntje> mvo: no, its all owned by me. I also found a bug report about appArmor getting upset at encrypted homes, so I'm going to test that next.
<dholbach> nhaines, I don't know
<dholbach> nhaines, if not, maybe there should be a bug for it?
<trijntje> but its lying anyway since it did create ~/snap/notes/1, so it has permission to write in my home dir
<tsimonq2> trijntje: I have an encrypted home directory :)
<tsimonq2> yeah
<nhaines> dholbach: hmm, maybe.  I suppose I'll have to look into it.
<dholbach> cool, thanks!
<nhaines> 'snap login' is really vague and confusing to me!  All I know is that if I use it, I don't have to run 'snap install' with sudo.  Why?  :D
<mvo> tsimonq2, trijntje thank you
 * mvo scratches head
<tsimonq2> mvo: and like stated eralier, I have an encrypted home directory with ecryptfs
<tsimonq2> *earlier
<mvo> tsimonq2: oh, that might indeed be why I don't see it here!
<zyga> tsimonq2: there's a bug about encrypted home directory
<zyga> tsimonq2: though last time I checked on xenial, it wasn't breaking anything, just printing messages when snap-confine / ubuntu-core-launcher were started
<zyga> ah
<zyga> mvo: one thing *has* changed
<tsimonq2> zyga: I'm on Yakkety :)
<zyga> mvo: the home directory is no longer created by snap-confine, now it's made by what? snap-run?
<tsimonq2> (FWIW)
<zyga> mvo: but that's not live yet, is it?
<mvo> zyga: thats not in xenial yet AFAIK
<ovalseven8_> Hello, what's the exact difference between the distribution of a statically linked software (one executable) and the Snap packages?
<zyga> ovalseven8_: snaps can use shared libraries (e.g. you can ship two executables and a common shared library inside a snap)
<zyga> ovalseven8_: statically linked software is just that, a static executable
<trijntje> zyga, mvo: both hello and notes work in a fresh 16.04 in virtualbox without encrypted home
<zyga> ovalseven8_: snaps provide data, shared libraries, executables and services in one bundle
<trijntje> should I report a new bug or comment on the existing one?
<zyga> trijntje: please comment on the existing one unless you think this is something very different than before, please include the version of snapd and ubuntu-core-launcher you have installed (apt-cache policy snapd)
<trijntje> zyga: can you link the bug report?
<ovalseven8_> zyga: Ok, but for the user of the software it doesn't really make a difference? Because if there's a bug in a dependency, he will have to update the snap/executable
<zyga> tsimonq2: I see https://bugs.launchpad.net/snappy/+bug/1574556 but reading it quickly I think a new bug is better now
<ubottu> Launchpad bug 1574556 in ubuntu-core-launcher (Ubuntu Xenial) "apparmor denials reported for encryped HOME" [Medium,Triaged]
<zyga> ovalseven8_: if there's a bug in the dependency the maker of the snap will see that as the snap won't run on their machine
<zyga> ovalseven8_: snaps don't depend on anything from the system
<trijntje> zyga: ill file a new bug report, but it looks like the last two comment (from bruno nova) are about the same problem I have
<ovalseven8_> zyga: Yeah, but the delivered dependencies inside the snap have to be updated, no?
<zyga> ovalseven8_: updated for what?
<ovalseven8_> zyga: If there's a bug
<nhaines> ovalseven8_: typically, the maker of a snap uses 'snapcraft', which automates getting everything from the Ubuntu repositories or from source repositories and then builds everything.  So the snap maker would have to run 'snapcraft' again, wait 5 minutes, and then upload the new version to the store.
<zyga> ovalseven8_: yes
<zyga> ovalseven8_: that's correct
<trijntje> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696
<ubottu> Launchpad bug 1592696 in snapd (Ubuntu) "snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied" [Undecided,New]
<tsimonq2> !info json-glib yakkety
<ubottu> Package json-glib does not exist in yakkety
<tsimonq2> !info libjson-glib-1.0-0 yakkety
<ubottu> libjson-glib-1.0-0 (source: json-glib): GLib JSON manipulation library. In component main, is optional. Version 1.2.0-1 (yakkety), package size 62 kB, installed size 313 kB
<tsimonq2> !info libjson-glib-dev yakkety
<ubottu> libjson-glib-dev (source: json-glib): GLib JSON manipulation library (development files). In component main, is optional. Version 1.2.0-1 (yakkety), package size 27 kB, installed size 441 kB
<tsimonq2> !info gnome-keyring
<ubottu> gnome-keyring (source: gnome-keyring): GNOME keyring services (daemon and tools). In component main, is optional. Version 3.18.3-0ubuntu2 (xenial), package size 577 kB, installed size 3908 kB
<morphis> zyga: ping
<tsimonq2> !info gnome-keyring-dev
<ubottu> Package gnome-keyring-dev does not exist in xenial
<petermaffay> hey there, i'm new to packaging snap and got a question: i develop a webapp which needs apache and php7, is there an option to import these two with the "plugin" tag in snapcraft
<tsimonq2> petermaffay: hello, you would put the appropriate packages in build-packages, the plugin is for compiling the snap
<dholbach> use "stage-packages" if you want to include the contents of packages in the snap.
<dholbach> "build-packages" are just packages you need to build the snap.
<petermaffay> thanks very much!!
<dholbach> anytime :)
<tsimonq2> petermaffay: if you want to check out some examples, take a look at snappy-playpen: https://github.com/ubuntu/snappy-playpen - if you have questions for how that would be implemented and such
<tsimonq2> !info cpp
<ubottu> cpp (source: gcc-defaults (1.150ubuntu1)): GNU C preprocessor (cpp). In component main, is optional. Version 4:5.3.1-1ubuntu1 (xenial), package size 27 kB, installed size 62 kB
<tsimonq2> !info c++
<ubottu> intercal (source: intercal): INTERCAL de-obfuscator. In component universe, is extra. Version 30:0.30-1 (xenial), package size 685 kB, installed size 1398 kB
<tsimonq2> !info g++
<ubottu> g++ (source: gcc-defaults (1.150ubuntu1)): GNU C++ compiler. In component main, is optional. Version 4:5.3.1-1ubuntu1 (xenial), package size 1 kB, installed size 16 kB
<tsimonq2> aha
<dpm> davidcalle, in addition to the snapcraft.io coverage, I was enjoying seeing the image you created for d.u.c on the media :) http://www.zdnet.com/article/ubuntu-snap-takes-charge-of-linux-desktop-and-iot-software-distribution/
<seb128> is there a way for snapcraft to run manual commands after the "make install" step from the autotools plugins?
<seb128> like to move files around or clean some
<seb128> before the squashfs is generated
<seb128> sergiusens, ^
<davidcalle> dpm: hehe same here, also on https://www.linux.com/news/ubuntu-snappy-based-package-format-aims-bridge-linux-divide . "Make it. Snap it. Push it. Update it" has been out there as well, this is pretty fun.
<tsimonq2> !info kde4-devel
<ubottu> Package kde4-devel does not exist in xenial
<tsimonq2> !info kdebase-dev-kde4
<ubottu> Package kdebase-dev-kde4 does not exist in xenial
<tsimonq2> !info kdelibs4-dev
<ubottu> Package kdelibs4-dev does not exist in xenial
<tsimonq2> !info kdelibs5-dev
<ubottu> kdelibs5-dev (source: kde4libs): development files for the KDE Development Platform libraries. In component universe, is optional. Version 4:4.14.16-0ubuntu3 (xenial), package size 1303 kB, installed size 9465 kB
<bollo> I installed vtop and then tried to remove it but it just stuck on remove. I then ran abort and now it's just stuck on that.
<bollo> Restarted snapd to see if that would solve anything but no.
<bollo> So now I can't try to remove it again since it's stuck on abort.
<bollo> I can't remove it since it can't be unmounted it seems
<jdstrand> zyga: hey, so snap-confine HEAD has a failing test. I feel like maybe I am not compiling it right with the lastest updates. basically, I'm snagging the Build-Depends, then doing 'debian/rules build'
<jdstrand> zyga: meh, nm
<jdstrand> common.sh was missing a syscall
<zyga> jdstrand: :-)
<zyga> jdstrand: I'll be enrolling snap-confine in spread this week
<zyga> jdstrand: to ensure it compiles and builds on ubuntu, fedora and arch (initially)
<zyga> jdstrand: and that tests pass
<zyga> jdstrand: we need to start thinking about making testing possible when snap-exec story is done
<zyga> jdstrand: and snap-confine unconditionally execs snap-exec
<petermaffay> hey, still trying to build apache snap, got this now: name: anchor  version: 0.1  summary: anchor file browser  description: no production use  confinement: devmode  parts:  webserver: stage-packages:      - apache2
<petermaffay> what should i use for plugin and source as they are required fields?
<petermaffay> at the moment just trying to package apache :P
<georgeowell> Hey all. I have an encrypted home directory and I'm running into this bug: https://bugs.launchpad.net/snappy/+bug/1574556
<ubottu> Launchpad bug 1574556 in ubuntu-core-launcher (Ubuntu Xenial) "apparmor denials reported for encryped HOME" [Medium,Triaged]
<georgeowell> Is there a work around? I don't really understand the stuff referenced in the launchpad comments.
<georgeowell> I get "failed to create user data directory. errmsg: Permission denied" when I try and run a snap
<trijntje> georgeowell: I think this is the bug you have: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696
<ubottu> Launchpad bug 1592696 in snapd (Ubuntu) "snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied" [Undecided,Confirmed]
<georgeowell> Do I just select "this affects me"?
<trijntje> yes, that way the developers see that a lof of people run into this bug
<trijntje> I expect this will be fixed pretty fast, since its a recent problem and a lot of people have encrypted homes (though I'm not a developer for snap)
<Gunther_> Hi there!
<Gunther_> Is there a working way to configure a static network interface in vivid using u-d-f? (Tried modifying meta-data with little success)
<ogra_> Gunther_, 15.04 is pretty dead, but you couold create your own gadget snap and apply config through that
<olli> t
<ogra_> u
<Gunther_> ogra_: I am currently editing the created image. Still /etc/network/interfaces.d/eth0 gets automatically created using a dhcp config. If I try to insert a static configuration file at the same place, its changed to dhcp at the first boot.
<Gunther_> I think the behaviour on 16.04 is the same
<ogra_> well, 16.04 isnt done yet ... the config interface and firstboot stuff is still in the works (all focus was at the desktop and cross distro stuff for the last weeks, images are looked at now )
<Gunther_> Just one answer please :): Who is generating /etc/network/interfaces.d/eth0 ?  systemd or cloud-init?
<ogra_> snapd
<ogra_> well
<ogra_> not sure if it did that in 15.04
<ogra_> nobody touched that in monts
<ogra_> (includign me)
<ogra_> (not even sure there was snapd ... could have been called snappy-firstboot or some such)
<Gunther_> ok looking for firstboot now. thanks
<Gunther_> ubuntu-snappy.firstboot.service :)
<ogra_> yeah
<ogra_> kyrofa, trying snapcraft for a wine package i get "multiple repeat at position 40" as answer when it fails ... any indicator what that might mean ?
<kyrofa> ogra_, huh... can you pastebin the result of snapcraft --debug ?
<ogra_> or sergiusens ^^
<ogra_> kyrofa, http://paste.ubuntu.com/17358094/
<ogra_> hmm
<ogra_> could it be because i dont use a subdir for the binaries i want to copy ?
<ogra_> (i have everything in the toplevel dir)
<kyrofa> ogra_, seems like a regex error
<ogra_> http://paste.ubuntu.com/17358140/ is the snapcraft.yaml
<kyrofa> ogra_, when it's trying to replace $SNAP in the output
<kyrofa> ogra_, please log a bug, I think there's a larger problem here
<ogra_> hmm .. i have a dash in the package name
<ogra_> ok
<ogra_> (though there are other packages with dash ... )
 * ogra_ files a bug 
<ogra_> kyrofa, sergiusens, bug 1592795
<ubottu> bug 1592795 in Snapcraft ""multiple repeat at position 40" when trying to create a snap" [Undecided,New] https://launchpad.net/bugs/1592795
<kyrofa> ogra_, no I don't think this is a YAML problem, it has something to do with the combination of the regex we're using and the file contents of the snap that needs some investigating
<ogra_> k
<ogra_> Son_Goku, zyga is zyga if he is on IRC :)
<Son_Goku> :/
<ogra_> (he isnt around atm obviously)
<Son_Goku> what time zone does he live in?
<Son_Goku> I'm in UTC-4
<ogra_> EU ... but i think he has to care for personal stuff this afternoon
<ogra_> perhaps we can help you ?
<ogra_>   yeah, he is UTC-2 or so
<Son_Goku> well, I wanted to talk to him about Fedora / Mageia packaging for snaps
<Son_Goku> but perhaps you can answer a more general question of mine
<Son_Goku> when will the server components to snaps be open sourced and allow for alternative repositories of snaps to exist?
<jamiebennett> Hi Son_Goku, the server-side components are not planned to be open sourced at this time
<Son_Goku> ...
<Son_Goku> wuh?!
<Son_Goku> why?!
<Son_Goku> is this going to be Launchpad all over again?
<jamiebennett> Son_Goku: we have been concentrating on the client side of snaps so it has not been on the roadmap so far
<jamiebennett> Son_Goku: we will of course continue to assess this going forward
<m15k> "error: cannot remove "jenkins": snap "jenkins" has changes in progress" any suggestions howto solve this?
<Narcotix> being completely new to the "snap" topic, i wonder: can anyone set up a "snap store"? i mean is the snap package system bound to the ubuntu store or ir cannonical just the only provider of snaps atm?
<Son_Goku> no one can currently set up snap stores
<Son_Goku> Canonical is the gatekeeper for all things snappy :(
<Narcotix> holy moly :O this is rly evil
<jamiebennett> Son_Goku: snaps can be side loaded easily
<Son_Goku> that's not an suitable answer
<Narcotix> i mean this is like with the windows universal apps
<jamiebennett> Son_Goku: sorry I can't give you a date at this time
<Son_Goku> sideloading means that there's no mechanism for updates
<ogra_> you can sideload the updates too :)
<Narcotix> so the snap packaging tool isn't open source ?
<jamiebennett> Narcotix: it
<jamiebennett> is
<jamiebennett> Narcotix: the server side stuff is not at this time
<Son_Goku> ogra_ yes, but that's not quite the same thing
<jamiebennett> Narcotix: for stores
<Son_Goku> essentially, if you want another store to exist, someone has to reverse engineer the protocol and then alter the client to user it
<Son_Goku> *use
<Narcotix> yeah but... it's like anyone can set up a store with win32 api programms, but only microsoft can set up a store for universal apps
<Son_Goku> to some extent, I'm not really surprised
<ogra_> no, but it is upgradeable that way
<Son_Goku> the system was designed for the mobile context, where everything is locked down because things
<Son_Goku> (the reasoning for locked down systems in mobile is too complicated for me to want to get into...)
<Son_Goku> but this new trend of bringing that locked down nature to traditionally open platforms is frightening
<Narcotix> wow, so if snap packages would become THE standard among all distros, this would mean that Linux would become more of a walled garden (if deb, yum and others get dropped somewhen in the future)
<ogra_> why woud deb and yum be dropped ?
<ogra_> there is no reason to drop them
<Narcotix> well, i guess you are right
<jamiebennett> Narcotix: and of course anyone can develop and push a snap to the store
<Narcotix> but developers could drop them
<ogra_> and none of the newer packaging systems focus on that ... they all focus on delivering apps
<jamiebennett> it is just a delivery mechanism
<Son_Goku> ogra_ that's not what Canonical is putting out
<Narcotix> so they still exist, but programs won't get published as debs
<Son_Goku> they've been talking about moving over to snap system in place of debs and rpms
<ogra_> Son_Goku, what are you referring to now ?
<Son_Goku> ubuntu snappy core and ubuntu snappy desktop
<ogra_> Son_Goku, do you have a refercene for that ?
<Son_Goku> lemme see if I can find it...
<ogra_> (an official statement)
 * ogra_ is sure there is none 
<ogra_> probably a third party speculation ...
<ogra_> oor a developers wishful thinking :)
 * Son_Goku sighs
<Son_Goku> it was somewhere on either launchpad or one of the ubuntu dev blogs
<ogra_> debs wont go away in ubuntu
<ogra_> neither will the classic installs
<ogra_> even *if* there will perhaps be full snappy based desktop installs ... the ubuntu deb archive would have to be used to create these snaps
<ogra_> so how could we ever drop it ? :)
<ogra_> Son_Goku, https://plus.google.com/+OliverGrawert/posts/YQ7idGAXzFd see the comments here
<m15k> Is there a documentation how the snapped packages are run? Currently I'm a little bit confused if the applications are isolated or how...
<justtesting> With regard to isolation, here's a page on security: https://developer.ubuntu.com/en/snappy/guides/security/ Not sure how they are really run though. Maybe another page details that.
<jdstrand> justtesting: see this https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
<jdstrand> m15k: ^
<ogra_> m15k, they are run inside the core snap  ... and via interfaces they can talk to the host
<m15k> Thanks, I'll have a look at the pages.
<ogra_> (and yeah, that page is probably the better answer :) )
<sabdfl> m15k, the apps run under a profile that is setup by the snap machinery, and covers seccomp, apparmor and a range of other confinement techniques
<sabdfl> m15k, the idea is that a snap can have a binary running as root which still doesn't see anything it is not allowed to
<morphis> ogra_, jdstrand: btw. how is the core snap involved on desktop? is LD_LIBRARY_PATH or so linked to it or is there no usage at all?
<ogra_> the launcer sets the library path
<morphis> ok as I thought
<morphis> matteo: ^^
<morphis> ogra_: so host binaries should used at all?
<ogra_> no, they shouldnt
<morphis> ok
<matteo> yes, I've tried but got a SIGSEGV
<seb128> does anyone know where is the snap/.desktop integration documented?
<seb128> there is no [.]desktop mentioned on http://snapcraft.io/create/
<seb128> nor on https://developer.ubuntu.com/en/desktop/get-started/
<seb128> why isn't it just using/exporting one based on the snap/u/s/a one with the exec mangled?
<seb128> mvo, ^ do you know?
<kyrofa> seb128, I suspect it's still not documented
<kyrofa> seb128, but you just drop them in snapcraft's setup/gui/ directory
<mvo> seb128: is https://github.com/snapcore/snapd/blob/master/docs/meta.md#gui-directory helpful?
<seb128> mvo, yes, thanks ... do you know why we just don't use the upstream one? would be less packaging work/easier
<seb128> and get translations&co
<mvo> seb128: its very close to the upstream one, translations and all will be unchanged, the upstream one will do something like /usr/bin/foo but it won't be /usr/bin/foo in the snap so that requires a tiny bit of tweaking. essentially Exec= and Icon= is what needs tweaking. I guess snapcraft could try to be smart about it
<seb128> mvo, right, my point is "why not using the upstream one and just mangling exec/icon automatically for the user"
<seb128> mvo, with the current scheme you need to dup info and keep up with upstream tweaking e.g their description or categories or keywords
<mvo> seb128: that would be cool, its a bit tricky to know how to map the meta/snap.yaml app to the exec line, we could try to do pattern matching I guess, we could of course be radical and allow only exec lines that match the snap name itself by default
<mvo> seb128: same for icons
<mvo> seb128: that would solve the common case at least, i.e. if you package "gnome-foo" your app in snap.yaml must be named "gnome-foo" and that is the exec line you get in your deskop file (and then we need to think about an override for this openoffice thing with 243324 desktop files inside ;)
<seb128> mvo, or you could have the manifest have a section that let you override the exec/icon by specifying those
<seb128> and having snapcraft doing the work for copying/sedding with those values
<mvo> seb128: manifest == snapcraft.yaml?
<seb128> yes
<seb128> sorry
<mvo> seb128: yeah, that is a sergiusens thing then :) works for me
<mvo> seb128: no worries, just wanted to be sure we talk about the same thing
<seb128> the current way is undocumented on our main websites
<seb128> so it's likely most desktop app snappers are going to overlook that
<mvo> davidcalle: -^ is that something you could help with?
<seb128> and we have less good integration in the desktop as a result
<mvo> davidcalle: basicly making https://github.com/snapcore/snapd/blob/master/docs/meta.md#gui-directory available somehow
<mvo> seb128: +1
<seb128> mvo, thanks for relaying the nag to the right people ;-)
<seb128> mvo, also since it's similar/related, do you know if there is an consideration using the upstream appstream info if available rather than requesting the snapcraft.yaml to duplicate e.g the description?
<davidcalle> mvo: sure, give me 3 min
<seb128> mvo, or we could have description: $appstream-desc
<seb128> ?
<davidcalle> mvo: oh I thought it was a new edit on the doc, but the last commit is actually mine... You mean giving it more visibility than in https://developer.ubuntu.com/en/snappy/guides/meta/?
<blackout24> What happend to the idea of frameworks? I can't find any info on framework snap anymore on the official websites.
<seb128> hum
<seb128> does anyone know how to I tell snapcraft that no the build step is not outdated?
<seb128> and that it should access to prime as I asked
<seb128> sergiusens, ^?
<seb128> shrug
<davidcalle> seb128: mvo: what about a new example (desktop integration-oriented) using the krita snap in https://developer.ubuntu.com/en/desktop/examples/
<seb128> davidcalle, shouldn't those things be covered on snapcraft.io?
<seb128> davidcalle, also I think the .desktop should be autogenerated from the upstream one rather than requesting you to have a new one
<sergiusens> seb128 you will need to marshall some yaml, how did you end up in this situation? kyrofa can help with state management
<seb128> sergiusens, I built a snap, then decided I need to do some changes before it's packed so I "snapcraft clean -s prime" and copied things around in stage/snap
<davidcalle> seb128: I fuly agree on both points, but if we want to have something sooner than later, let's use what we have (krita snap with custom desktop file), I think that desktop file generation is snapcraft's territory
<seb128> sergiusens, no that I modified the stage I wanted to rebuild the snap by using "snapcraft prime"
<seb128> now*
<seb128> sergiusens, should that work of did I do something fundamentally wrong?
<kyrofa> seb128, are you sure you didn't change the YAML at all?
<seb128> kyrofa, oh, I might for another later iteration
<kyrofa> seb128, because the build step saves the YAML on which it ran and compares to the current YAML to determine whether or not it's out of date
<seb128> where does it save it?
<seb128> there is no other *yaml in my dir
<kyrofa> seb128, in parts/<part>/state/<step>
<seb128> ok, indeed
<seb128> thanks kyrofa
<seb128> that didn't have the argument I added
<kyrofa> seb128, yep, that'll do it
<seb128> hum
<seb128> can I move things around in the stage?
<seb128> prime is complaining about a missing file
<seb128> which I moved around
<sergiusens> seb128 the files really get migrated from parts/<part-name>/install
<seb128> sergiusens, snapcraft.io states
<seb128> "stage/ is where all the content from parts/<part_name>/install is copied and consolidated in a single directory."
<seb128> so I though it was the step after
<seb128> like things get copied from parts
<seb128> and then the stage is moved to prime
<seb128> is that wrong?
<seb128> if I want to move things around should I do it in the install?
<sergiusens> seb128 mvo about desktop files and snapcraft. Doing things by convention was a mistake. I'll be allowing it to be declarative which would allow adapting such desktop file to whatever the "by convention" is in snapd
<seb128> sergiusens, would that avoid having to create one? could you say
<seb128> desktop:
<seb128>     file: ...
<seb128>    exec:
<seb128>      icon:
<seb128> and have it use the upstream "file" points at just sedding the exec/icon values?
<ogra_> sergiusens, i got the telegram update today, now i have a broken icon in the panel ... known issue ?
<sergiusens> ogra_ yeah, telegram does not respect the --no-auto-update switch it has :-/
<ogra_> well, i dont mind the update ... and i definitely didnt have a panel applet before
<ogra_> it is just the icon that is missing it seems
<kyrofa> seb128, regarding stage versus install: the files are pulled from stage, but the filesets are determined using install
<kyrofa> seb128, that's why you may notice that if you use the `stage` keyword to filter stuff, you almost always must include the same filter with the `snap` keyword
<didrocks> kyrofa: I guess seb128 is talking about the other stage
<didrocks> like:   stage        Stage the part's built artifacts into the common staging area.
 * ogra_ wishes he would be able to build any snaps at all :(
<ogra_> Fetched 0 B in 0s (0 B/s)
<ogra_> E:Unable to correct problems, you have held broken packages.
<seb128> kyrofa, sorry I don't understand, if I want to tweak the target layout between the "make install" and the prime what do I change?
<ogra_> thats all i see since hours :(((
<didrocks> (not the stage as stage-packages)
<kyrofa> didrocks, indeed, as am I
<dholbach> ogra_, did you try using --enable-geoip?
<didrocks> ah sorry, unsure to understand you either then :p
<dholbach> ogra_, or clearing your /var/lib/apt/lists cache?
<kyrofa> seb128, in my experience you kinda need to do that in prime
<kyrofa> seb128, because moving files around in stage will lead to issues when priming, as you noticed
<kyrofa> seb128, you can change contents in stage, but not layout
<ogra_> dholbach, well, ithe hosts apt works just fine ... it is only under snapcraft
<seb128> kyrofa, ok...
<kyrofa> seb128, not one of my favorite features, but I seem to remember there being a reason for it
<ogra_> it also worked once this morning ... but not anymore since
<kyrofa> ogra_, huh... does your system apt work okay?
<ogra_> yes
<ogra_> i have one private PPA enabled though ... i wonder if that causes havoc (though it didnt in the morning)
<dholbach> popey, http://paste.ubuntu.com/17365382/? :-)
<RaycatRakittra> Hello?
<RaycatRakittra> Anyone active?
<ogra_> yes
<ogra_> :P
<seb128> shrug
<seb128> I screwed snapcraft by moving a dir in the stage
<seb128> "snapcraft clean" fails now
<seb128> sergiusens, is there a "clean-without-check"?
 * seb128 just rm
<kyrofa> seb128, yeah, rm. Also rm the parts/<part>/state/stage
<seb128> kyrofa, thanks
<seb128> that was needed
<seb128> pocking around things you shouldn't is fun :p
<kyrofa> seb128, the state tracking is pretty whiny, but it means you can actually unstage a part without messing with other parts
<kyrofa> seb128, but yeah, it results in that if you poke at it
<seb128> I'm still unclear what I should do exactly if I want to move things after the make install
<seb128> move or remove
<seb128> like some of the make installed thing are useless and waste space
<kyrofa> seb128, at that point all best are off if you want snapcraft to continue working. You should be doing such things with the organize keyword, etc
<seb128> what's the official way to deal with that?
<matteo> I've disabled confinement in ubuntu-core-launcher with this patch: http://pastebin.ubuntu.com/17366167/ looks reasonable for you?
<kyrofa> seb128, or filter them out with the stage and snap keywords
<seb128> kyrofa, are those snapcraft.yaml keywords?
<kyrofa> seb128, indeed
<kyrofa> seb128, https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-syntax.md
<seb128> snapcraft.io doesn't cover those
<seb128> thanks
<seb128> kyrofa, so default is everything but if you use stage: you need to manually list all the things you want?
<seb128> is there a reverse "clean"?
<seb128> or "exclude"?
<kyrofa> seb128, or prefix with a minus
<kyrofa> seb128, to blacklist
<kyrofa> seb128, an example of all the mysql stuff I didn't want to ship in the nextcloud snap: https://github.com/kyrofa/nextcloud-snap/blob/master/snapcraft.yaml#L144
<seb128> kyrofa, thanks
<seb128> kyrofa, I don't really understand why there is a "snap"
<seb128> kyrofa, if you exclude things from the stage they are not going to be in the snap either at the end right?
<kyrofa> seb128, filter applying to stage versus filter applying to prime
<seb128> what difference does it make?
<kyrofa> seb128, no, that's what I was trying to say earlier
<kyrofa> seb128, for example, take the boost part: https://github.com/kyrofa/nextcloud-snap/blob/master/snapcraft.yaml#L115
<kyrofa> seb128, I need it in stage so I can build against it, but I don't want to ship it in the final snap
<seb128> oh, I see
<seb128> that makes sense now
<seb128> thanks
<kyrofa> Sure thing!
<didrocks> kyrofa: but if you exclude it from the stage, it will be excluded in the prime directory as a result, right?
<kyrofa> didrocks, no, that's what I was saying
<kyrofa> didrocks, it'll error instead :)
<kyrofa> didrocks, try it!
<didrocks> I was thinking stage -> impacts primes that way
<didrocks> hum, ok, will do
<kyrofa> didrocks, seb128 https://bugs.launchpad.net/snapcraft/+bug/1537850
<ubottu> Launchpad bug 1537850 in Snapcraft "Migratable filesets for stage should be considered in snap" [Undecided,Invalid]
<kyrofa> sergiusens may know more about the history/reasons for doing it that way
<didrocks> kyrofa: ok, so reading thisâ¦ shouldn't stage/ be skipped or kept empty if you don't have some after: keyword?
<kyrofa> didrocks, that's also where reorganization happens, I think
<didrocks> (and stage/ be populated only by parts which are declared after any after: keywords)
<didrocks> kyrofa: if the reorg happens in stage/ it's counter-intuitive then
<didrocks> as this will impact prime
<kyrofa> didrocks, indeed, I think you need to use the reorganized named in the filters: "filesets will refer to the exposed named applied after organization is applied."
<kyrofa> s/named/names/
<didrocks> kyrofa: something is still unclear in my head. I need to play with this and reorganizing at the same time. I bet if seb, you & I were puzzled at some point about this, something isn't right in the way snapcraft is handling it
<didrocks> but we may be all wrong (the 3 of us :p)
<kyrofa> didrocks, I completely agree
<didrocks> ok, I'll play with this tomorrow with reorg to see the behavior
<matteo> ping mvo
<kyrofa> didrocks, let me know
<didrocks> will do :)
<mhall119> sgclark: d_ed: hey, niemeyer1 would like to talk with you guys about how best to support the sharing of KDE Frameworks between KDE snaps
<d_ed> sure
<d_ed> I can tell you what we're currently doing for FlatPak at least.
<mhall119> niemeyer1: do you want to have a hangout for this?
<mhall119> sgclark: also, I have a pull request for your kate snap, I've got building in a clean lxc now
<sgclark> alrighty
<kyrofa> kgunn, here's the qmake plugin if you're able to take a look: https://github.com/ubuntu-core/snapcraft/pull/566/files#diff-dd46e36f2d591eb4108efc48a69fa41eR1
<mvo> matteo: pong
<matteo> hi mvo
<mvo> hi
<matteo> I've compiled ubuntu-core-launched with a patch to disable confinement
<matteo> but it's working bad, can you have a quick look?
<matteo> http://pastebin.ubuntu.com/17366167/
<mvo> matteo: oh, interessting! can you please check out https://github.com/snapcore/snap-confine ?
<mvo> matteo: it has a --isable-confinment configure switch
<matteo> yes I know
<mvo> matteo: and is otherwise compatible with ubuntu-core-launcher, so its a drop-in
<matteo> I took the relevant part from there
<matteo> mvo: I see that there is a wrapper around it
<matteo> which removes an argument
<matteo> right?
<mvo> matteo: yeah, it provides a wrapper, but that should be ok, did it not work for you?
<mvo> matteo: i.e. if it does not work, that would be a bug, its meant to be a drop-in replacement
<mvo> fully comaptible and all that
<matteo> I never tried that because I tought that snapd was not ready
<matteo> ok, I'll discard the core launcher then
<mvo> matteo: aha, sorry, please give it a try a shout if there are any problems :)
<matteo> thanks
<mvo> matteo: thank you! and keep us/me updated please
<matteo> will do :)
<mhall119> is it possible to build a snap for a different arch using snapcraft cleanbuild?
<mhall119> sgclark: I'm getting this when trying to build kdevelop: [Errno 2] No such file or directory:
<mhall119> '/root/parts/kdevelop/install/usr/bin/pp-trace'
<mhall119> any suggestion on what package that might be in?
<kyrofa> mhall119, regarding the cross-building, that's only supported for kernels right now
<kyrofa> mhall119, though if you ran snapcraft in a 32-bit lxc, that should work fine (cleanbuild won't do that for you)
<elopio> ping ogra_: I have a bash question. Are you here?
<willcooke> kyrofa, hey, re: qmake plugin.  I had an issue with qmake yesterday where I had to pass in the name of a specific .pro file.  I don't /think/ your plugin caters for that.  Do you want a patch?
<sgclark> mhall119: my repo has all the deps needed, builds in cleanbuild. however that is a qt4 build which I do not want.
<mhall119> sgclark: is there a cmake flag or something to tell it to build only for qt5?
<kyrofa> willcooke, ah, I was wondering about that
<kyrofa> willcooke, what does that command look like?
<sgclark> mhall119: nevermind, that particualre one is fine it will build qt5
<sgclark> we are doing some a bit differently
<willcooke> kyrofa, it's dead simple:  https://github.com/8none1/fritzing-snap/blob/master/parts/plugins/x-qmake.py#L54
<willcooke> kyrofa, it's probably a hack, but I'm not familiar with qmake, but it worked for me
<kyrofa> willcooke, looking at the manpage, it seems you can profile multiple .pro files, is that correct?
<kyrofa> s/profile/provide/
<kyrofa> willcooke, yeah, my familiarity with it is rather limited as well, obviously. I only ever use it from qtcreator :P
<willcooke> kyrofa, ah, yes it does look like it, haven't accommodated that but it should be easy enough
<kyrofa> willcooke, alright I'll add an optional config parameter that is an array of .pro files. Will that serve your purpose okay?
<willcooke> kyrofa, yeah, should do!  I can easily test with my use-case at least
<kyrofa> willcooke, also, can I safely assume that these are _paths_ to .pro files? i.e. they don't need to be in cwd?
<willcooke> kyrofa, hummm, don't know I'm afraid.  I just passed a .pro that *was* in cwd
<willcooke> i.e. "project-file:  wills-special-pro-file.pro"
<willcooke> in the yaml
<kyrofa> willcooke, alright
<willcooke> anyone in the channel a qmake expert? mhall119, know anyone?
<mhall119> willcooke: bzoltan maybe?
<willcooke> oh yeah! bzoltan do you know if the "files" passed in to qmake need to be in the cwd or can they be absolute paths as well?  I'd assuming the later.
<elopio> ogra_: hey, you would be proud. Look how I solved it: subunit2pyunit results.subunit 2>&1 >/dev/null | sed "s/\\\n/\n/g"
<bzoltan> willcooke:  hard to say, could you pastebin the pro file?
<elopio> the scary thing is that I'm understanding bash, and it's all your fault.
<kyrofa> elopio, aww, I could have helped you there, I'm sorry
<willcooke> bzoltan, the one I was using is here:
<willcooke> err, here: https://github.com/fritzing/fritzing-app/blob/master/phoenix.pro
<willcooke> but this is more a qmake thing,  can it accept absolute paths *and* relative ones passed to qmake?
<willcooke> Usage: /usr/lib/x86_64-linux-gnu/qt5/bin/qmake [mode] [options] [files]
<thibran> hi
<bzoltan> willcooke:  the file path there should be relative to the project file
<bzoltan> willcooke:  absolut path I am not sure about
<willcooke> bzoltan, oki, thanks!
<willcooke> kyrofa, so I guess we go with relative for now then ^
<thibran> would you be interested in a patch to change the output of 'snap find *' to 'snap find'?
<bzoltan> willcooke: good luck, ping me back if you ned help... i am not at the sharpest state right now... 9pm and started 5am :)
<willcooke> bzoltan, cheers!
<kyrofa> bzoltan, just to clarify, this is about the `files` parameter to the qmake cli
<kyrofa> bzoltan, it sounds like you're talking about the contents of the .pro file, no?
<kyrofa> bzoltan, but I think it must accept paths, since it seems out-of-source builds work fine
<bzoltan> kyrofa: yes, i am talking about the pro file
<bzoltan> zbenjamin: ^^^
<baggednismo> does anyone know the specifics og ubuntu core boot? hoping it loads an image in ram but cant find any docs on it anywhere
<zbenjamin> willcooke: kyrofa: since qmake supports shadow builds they can be somewhere else than cwd... there might be some restrictions. so for example the build directory can not be a subdirectory of the source dir
<zbenjamin> if i remember correctly
<kyrofa> zbenjamin, so if I'm in my build directory, `qmake /my/path/to/src` and `qmake /my/path/to/src/my_project.pro` both look like fine invocations?
<zbenjamin> kyrofa: yeah that should work
<ali1234> baggednismo: i don't think it does that. i think it has a read only root with tmpfs for logs etc
<kyrofa> zbenjamin, thank you!
<ralsina> Hi there, I seem to have managed to create a snap that breaks snapd :-)
<ralsina> https://pastebin.canonical.com/158808/
<ralsina> And the snapcraft.yaml is not very weird http://pastebin.ubuntu.com/17374772/
<baggednismo> @ali1234 im having trouble with my ubuntu IOT devices and they are getting powered off improperly. they are dropping like flies so I need a solution that loads the OS in ram so any read/write doesnt damage the OS if improperly shutdown
<nothal> baggednismo: No such command!
<ali1234> baggednismo: i have the same problem. i don't know the solution yet...
<ali1234> raspberry pi?
<baggednismo> :-)
<baggednismo> and liva
<baggednismo> they are powered by TV USB so when TV is turned off the pi is turned off
<baggednismo> liva is lasting longer because it never shuts off
<ali1234> yeah... it's a problem for sure
<ali1234> i had hope that snappy core would solve this problem but i haven't really been able to even get it to work yet
<baggednismo> i was hoping if the root is read only then it cannot possibly corrupt the OS
<ali1234> in theory it is supposed to be read only
<baggednismo> i was just reviewing snaps, mine would be time consuming but doable. need a LAMP stack on it
<ali1234> LAMP should be trivial
<ali1234> i need the videocore libraries for my app... i don't know how to include them in a snap
<baggednismo> right now im using wget to pull a page down to apache so if there is no connection to inet it will load the default. do you think thats doable? the apache directory will change regularly
<ali1234> also since i'm doing a battery powered device i used the A+... and ubuntu can't run on it
<ali1234> so i'm waiting for the 3A to be released
<baggednismo> :-(
<baggednismo> luckily i had a pi2 sitting around because even the last ubuntu core cant be ran on pi3
<ali1234> it should be working on 3 now i think... if you build the image youself
<ali1234> but i have all the different models... it's just that only the A+ fits inside my device
<ali1234> so i've tried running snaps on the 2B... but i didn't get very far
<ali1234> and that's even with loads of fantastic help from the people here
<ali1234> i'm sure LAMP would work fine though... it's very common
<baggednismo> im concerned about persistent storage though
<ali1234> not sure what happens if that gets corrupted
<elopio> kyrofa: what's the tag in askubuntu? ubuntu-core?
<saalen> how to resolve this snapcraft error on Arch (after reading the snapcraft.yaml): Could not find a required package in 'build-packages': "The cache has no package named 'make'" ?
<kyrofa> elopio, there are so many now... you might be able to just use my filter, hold on
<elopio> saalen: hey, snapcraft's build-packages are only for ubuntu. If you have lxc installed, you could do a cleanbuild.
<kgunn> kyrofa: so are snapcraft.ProjectOptions basically the usr/lib/$ARCH dirs?
<saalen> elopio: mmh, it is present in AUR and I read about it being ported to other distributions... so I gave it a try ;)
<kgunn> kyrofa: sorry...context is the qt plugin
<elopio> saalen: snapd is currently working in all the distributions. snapcraft not yet.
<saalen> elopio: thx
<kyrofa> kgunn, the ProjectOptions hold stuff like the target arch, number of parallel build jobs supported, etc
<baggednismo> ok so the question of the day before i start building my snap. where is the persistent storage on core if any?
<kgunn> kyrofa: ack..i was just trying to trace through that QT_SELECT would end up with env of /usr/lib/$ARCH/qt5/bin
<kgunn> which if your stuff works, then it must
<kyrofa> kgunn, basically they reflect command-line parameters that affect all plugins
<ali1234> baggednismo: it is on a separate partition which is created at first boot... at least on the raspi
<kyrofa> baggednismo, there are two environment variables: SNAP_DATA and SNAP_USER_DATA
<kyrofa> SNAP_DATA is in /var/snap/<snapname>/<snapversion>, SNAP_USER_DATA is in HOME/snap/<snapname>/<snapversion>/
<baggednismo> and what happend when the device gets rebooted repeatedly improperly? the data gets damaged and i will have to handle that in my snap?
<baggednismo> i just gotta make sure that OS will always boot. I can handle the data that gets damaged as long as its not the OS
<kyrofa> baggednismo, the OS and snap app themselves are read-only
<kyrofa> baggednismo, so unless there's real damage,  you should be okay
<kyrofa> kgunn, the QT_SELECT stuff is using qt as a build-package though
<kgunn> kyrofa: oh, not runtime env
<kyrofa> kgunn, indeed
<kgunn> which is fine
<baggednismo> define real damage? i have found a lot of my devices out there have random problems like all permissions got changed, services wont start, os just fails to boot all simply from powering the device off improperly. what would constitute "real damage"?
<baggednismo> or are you jumt implying physical damage?
<Shibe> why are ubutnu snaps so big?
<Shibe> according to phoronix the libreoffice snap is 1.1GB
<Shibe> will this size issue get better?
<kyrofa> baggednismo, I was more talking about physical damage
<kyrofa> Shibe, because snaps bundle their dependencies
<baggednismo> ok, let me get into snap's then ;-) thanks for your help kyrofa
<baggednismo> ali1234, i think we have an answer. I will be testing this over the next few weeks and hopefully report success
<Shibe> kyrofa: yes but will anything be done to reduce the size in the future?
<Shibe> like sharing dependencies between programs that require the same version?
<ali1234> Shibe: we already have debs if you want a system that works that way
<caraka> ^^
<Shibe> ali1234: yes but there's the dependency hell thing
<ali1234> yeah well you have to pick one or the other
<Shibe> i mean like share libraries when both require the same version
<caraka> no dependency hell if they are bundled.
<caraka> The price is disk space
<ali1234> snaps already share the basic platform
<Shibe> caraka: but the snappy package is bigger than the combined size of the windows installer, a deb and an rpm of libreoffice
<ali1234> it is possible that the platform may be expanded in the future
<Shibe> caraka: and it's be problematic on mobile too since phones have much less storage than desktops usually
<ali1234> storage is the least of your worries on phones
<ali1234> if your phone is fast enough to run LO i bet it has 32GB as standard already
<caraka> all true Shibe, but storage and power are increasing rapidly on phones, and the truly monstrous apps aren't quite the kind for phone
<ali1234> like the nexus 6P... comes with 32GB, 64GB, or 128GB
<Shibe> caraka: and there's also the issues of low-end computers or people dualbooting Ubuntu
<ali1234> LO is an outlier anyway. most snaps are nowhere near that big
<Shibe> usually they won't give the Ubuntu partition as much storage as the windows one does
<caraka> All true Shibe, but then they can use the traditonal deb format and stay slim and light
<Shibe> caraka: but deb's are annoying and you usually stay behind versions depending on your distro
<Shibe> or your risk instabillity with arch and stuff
<caraka> there are tradeoffs for each of the systems - size is one of them
<ali1234> can you name a change made in the last release of LO?
<Shibe> ali1234: what is LO?
<caraka> no guarantee that outdated dependencies won;t get bundeled into snaps either
<ali1234> libreoffice
<Shibe> oh libreoffice
<caraka> LibreOffice
<Shibe> ali1234: uh libreoffice 5 took quite a while to appear on some distros
<Shibe> for example, mint got it in 17.3, many months after 5 came out
<ali1234> mint is a very silly place
<caraka> snaps won't solve all issues - only create different tradeoffs
<Shibe> ali1234: yeah but mainly because it's on Ubuntu 14.04 and dependencies are always tricky
<Shibe> who knows whether upgrading this library could break something
<caraka> same will happen with snaps
<Shibe> caraka: but don't snaps get to decide which version of a library they want?
<ali1234> Shibe: it's just a filesystem containing some files, ultimately
<kyrofa> Shibe, there's a content-sharing interface that is in the planning stages. The plan is to use that for e.g. the kde runtime, or gtk, etc
<Shibe> ali1234: yeah, but the developer knows that all users will be getting the same versions of libraries and hence it will work similarly across all distros
<caraka> yes they do. And the same developers will make the same kind of decisions when they package for snap as they do for other things - sometimes for the better and sometimes for the worse
<kyrofa> Rather, the plan is to be ABLE to use that. Devs don't have to
<Shibe> what about gtk apps btw?
<kyrofa> What about them?
<ali1234> what people don't seem to realise is that this is actually quite a hard problem
<Shibe> I used nix once, and each gtk app was a few hundred MB in size because they all downloaded the adwaita icon theme
<ali1234> there's a lot of talk in the peanut gallery along the lines of "old school unix developers, so naive... i could do better than that"
<ali1234> but when you actually try it, it's not as easy as it looks
<caraka> young developers are sometimes too abstracted from the bare metal and think it's all plug and play
<caraka> (says the old man)
<kyrofa> Shibe, I think the point is, as caraka mentions, there's no silver bullet. There are always going to be tradeoffs
<caraka> ^^
<caraka> snaps will have their ecosystem and their appropriate use. But they won;lt be the be-all end-all
<ali1234> platforms will be nice
<ali1234> i mean... optional ones as mentioned above
<Shibe> also how come the flatpak package is smaller than the snap?
<Shibe> flatpak is somehow only 156mb
<kyrofa> Shibe, because they have a runtime
<Shibe> ok
<ali1234> so... can i use PPAs when building a snap?
<kyrofa> josepht, elopio I'm not able to duplicate the ROS failures in the example tests... is something weird about that environment?
<kyrofa> ali1234, yes you can. snapcraft will use your sources
<caraka> ali1234: my PPAs offer to build snaps now. I haven't tried
<kyrofa> ali1234, oh, you mean build snaps in launchpad? Yes, you can do that as well
<ali1234> i found this ppa with videocore libs: https://launchpad.net/~ubuntu-raspi2/+archive/ubuntu/ppa
<ali1234> i want to put those libs into my snap
<kyrofa> Ah, yeah, add the PPA to your system and snapcraft should use it
<ali1234> kyrofa: i think you were right the first time
<kyrofa> caraka, the LP snap builders are pretty handy. https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
<caraka> I'm still trying to bundle by hand beffore I ask launchpad to do it
<kyrofa> Good idea
<caraka> yeah. get it right at home before sending it out into the world
<ali1234> i've got so many raspberry pis now that i'm having difficulty knowing which one is which
<ali1234> i need to reflash one again then i'll see if i can get videocore stuff working in a snap
<ali1234> that's where i got stuck last time
<willcooke> kyrofa, did you push that new qmake plugin in to your feature/1574774 branch?  The version I'm looking at there says it's 4 days old?
<allesz_> hi guys link http://www.snapcraft.io does not resolve for me
<ArmOrAttAk> no dns entry for that
<ArmOrAttAk> remove the www.
<allesz_> ArmOrAttAk: thanks that did the trick
<tsimonq2> jamiebennett: Hey, would you be able to contact someone about that? ^
<jamiebennett> tsimonq2: wow, not sure what is going on there
#snappy 2016-06-16
<lakcaj> Good day.  Snappy is getting a lot of buzz recently so I though I would check it out.  I'm a little confused how I'm supposed to assess the quality of snap packages.  From what I read, anything that makes it into the snappy repository is supposed to undergo some sort of quality assurance.  When I use snappy's to find packages I see this one:  "sudo  1        chipaca    -      not sudo".  What am I supposed to make of this?  Can I
<tsimonq2> elopio: I added the integration test and I believe that the code is ready. Can you confirm?
<sgclark> welp I have no idea what changed, but I can no longer launch any of my snaps
<nhaines_> Was there anything I can do about the "failed to create user data directory. errmsg: Permission denied
<nhaines_> " error in snapd 2.0. release on xenial?
<tsimonq2> nhaines_: do you have an encrypted home sirectory?
<tsimonq2> *directory
<mvo> nhaines_: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696
<ubottu> Launchpad bug 1592696 in ubuntu-core-launcher (Ubuntu) "snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied" [Undecided,In progress]
<mvo> nhaines_: some progress here fortunately :)
<mvo> tsimonq2: might be interessting for you as well
<tsimonq2> mvo: I moved off of an encrypted home directory today, and all snaps work fine now
<lpotter> anyone heard of anyone bringing snaps to sailfishOS?
<mvo> looks like jdstrand has it under control
<jdstrand> I just uploaded to yakkety
<jdstrand> I'm going to push the changes to snap-confine now
<mvo> lpotter: I have not heard anything, but its probably straightforward (given the amount of ports to other distros available)
<mvo> jdstrand: \o/
<jdstrand> mvo: when do we expect the snapconfine to 16.04? I ask cause I keep thinking its coming, but then more stuff was needed for cross-distro. anyway, trying to decide if need a separate sru for the ecryptfs changes or if snap-confine is uploaded soon, just waiting for that
<jdstrand> mvo: zyga said maybe for 2.0.9 or 2.0.10 at latest
<mvo> jdstrand: I think we can do it right away, its fully compatible, isn't it?
<jdstrand> mvo: snap-confine? I thought it depended on snap-run, etc, etc. not to mention, package name change, etc. I wasn't involved in the coding for any of that. aiui, it is supposed to work, but I got the impression you were driving the snap-run/snap-confine changes (and zyga the cross-distro bits). if I were to sru, I would just upload ubuntu-core-launcher with the apparmor change
<mvo> jdstrand: right, I'm driving snap run but its to a certain degree independent, we still provide ubuntu-core-launcher as a compat option in snap-confine and we could even keep the old package name lets sync up with zyga once he is around.
<mvo> jdstrand: you are in a european timezone currently?
<jdstrand> mvo: I am
<jdstrand> mvo: I just noticed that snap-confine didn't have the profile changes for ecryptfs: https://github.com/snapcore/snap-confine/pull/39. can you review/approve/merge?
<jdstrand> mvo: oddly, I don't have commit access to snapcore/snap-confine
<mvo> jdstrand: yeah, I can't merge either :/
<jdstrand> zyhalp ^ :)
<jdstrand> err
<jdstrand> zyga isn't here
<jdstrand> mvo: oh, it merged. that's good enough
<nhaines> mvo: thanks!
<mvo> thank you nhaines - and thanks to jdstrand of course!
 * mvo hugs jdstrand once more
 * jdstrand hugs mvo :)
<caleress> hey guys, how can you distribute snap packages in a private environment...not making them public i mean?
<jamiebennett> caleress: a snap is just like a zip file really, you can sideload them on to devices with snap install
<trijntje> caleress: you can install the snap locally, just the file. I'm not sure if hosting your own repository is supported
<bull> how to copy directory to stage area ?
<bull> olli,  i need help regarding snapcarft.yaml
<bull> anyone on ?
<dpm_> bull, you might want to post your snapcraft.yaml file somewhere so that someone can better help you
<bull> dpm_,  i will
<bull> wait
<bull> http://pastebin.com/Gnjg9scp
<bull> dpm_, http://pastebin.com/Gnjg9scp
<bull> Mut is qml module dir which i want in opt/deskie/bin/
<dpm_> bull, first of all, I think you need to remove the 'parts:' line on L19, as you've already specified it on L14
<bull> when i do that and place glue under parts:  it sys not allowed
<oSoMoN> hi all
<dpm_> hey oSoMoN o/
<bull> i got it its working now thanks
<dpm_> ah, cool
<oSoMoN> Iâm following the tour at http://snapcraft.io/create/, and when running the snap I created of hello, IÂ get the following error: "failed to create user data directory. errmsg: Permission denied"
<oSoMoN> corresponding apparmor denial:
<oSoMoN> Jun 16 13:03:16 bribon kernel: [12818.389036] audit: type=1400 audit(1466074996.565:59): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/osomon/.Private/" pid=5865 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<dpm_> bull, I'm not sure if you can copy entire directories with the 'copy' plugin. I think you might need to specify the files to copy one by one, as such: http://askubuntu.com/a/739692/9781
<dpm_> oSoMoN, seems like snaps are not working with an encrypted home dir?
<bull> dpm_,  it is copying
<dpm_> oSoMoN, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696
<ubottu> Launchpad bug 1592696 in ubuntu-core-launcher (Ubuntu) "snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied" [Undecided,Fix released]
<oSoMoN> dpm_, thatâs my wild guess without looking further, but it seems unlikely to me that no-one has ever run into this before meâ¦
<didrocks> bug  #359338
<ubottu> bug 359338 in apparmor (Ubuntu Karmic) "apparmor paths are broken when using ecryptfs" [High,Fix released] https://launchpad.net/bugs/359338
<oSoMoN> aha
<dpm_> there you go :)
<oSoMoN> known issue then
<bull> dpm_,  can i clean particular part build with snapcraft ?
<didrocks> make sure that you have all these rules in /etc/apparmor.d/usr.bin.ubuntu-core-launcher: http://paste.ubuntu.com/17392309/
<dpm_> oSoMoN, check out the workaround https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696/comments/8
<didrocks> then do: sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher
<didrocks> (from jamie)
<dpm_> bull, I don't think you can clean parts separately, no. It's all or nothing, if I'm not mistaken
<bull> dpm_, it is saying The 'build' step of 'glue' is out of date. Please clean that part's 'build' step in order to rebuild when i tried to change path in copy plugin
<bull> dpm_,  what this mean "Please clean that part's 'build' step in order to rebuild"
<dpm_> bull, I'd just do a 'snapcraft clean'
<oSoMoN> dpm_, thatâs quite an extreme workaround, removing confinement :)
<bull> dpm_,  man it will again download everything :(
<dpm_> bull, ah, wait, you can try something else
 * dpm_ checks syntax
<bull> how ?
<bull> https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/      did u mean these ???
<dpm_> bull, you can try 'snapcraft clean --step build'
<dpm_> which will just clean the build but not re-fetch the stage packages and the code
<bull> thanks i 'll try
<bull> thanks a lot bro
<dpm_> lol, no worries :)
<dpm_> but if that gives you an error, it might be because you've changed the snapcraft.yaml between builds without cleaning
<bull> no errors,
<dpm_> great :)
<bull> dpm,  one more  it build
<bull> but when i launch it it says :  /snap/deskie/x1/bin/qt5-launch: 74: exec: deskie: Permission denied
<dpm> bull, is your deskie file marked as executable?
<bull> dpm,  any idea ??
<bull> where ??
<dpm> what does the output of `ls -la /snap/deskie/x1/bin/deskie` say?
<bull> in prime directory ?  yes it is
<dpm> sorry, wrong dir
<dpm> `ls -la /snap/bin/deskie`
<bull> -rwxr-xr-x 1 root root 554 Jun 16 16:47 /snap/bin/deskie
<bull> is it okay ???
<dpm> looks good from the permissions
<bull> what may be reason then :(
<dpm> bull, I'm not sure what the issue could be, other than the launcher has trouble launching your executable. Perhaps you might want to upload your code somewhere (e.g. github) and others can help you better
<bull> here is the output of  ls -ls of qt5-launcher  -rwxr-xr-x 1 root root 2174 Jun 16 16:42 /snap/deskie/x1/bin/qt5-launch
<bull> is it okay ?
<dpm> the launcher is fine
<bull> man i think am done with snap :/
<bull> its pain
<bull> deskiw is close source app
<bull> deskie is not opensource
<bull> did you tried vlc's snap ?? it make the player useless
<dpm> I think there is some level of pain with being an early adopter tbh, but we're working on ironing out the issues
<bull> dpm, what's your real name or email i wana contact you ,
<oSoMoN> dpm, where do IÂ report issues with the documentation? on snapcraft.io/create, the following sentence doesnât sound right: Â« build/ where the build is append Â»
<bull> a asking this not just to seek help from you , i wana know everything about snapcarft cause i liked the concept , i am willing to make a  gui to do all this easily
<dpm> bull, https://launchpad.net/~dpm, but I think the best place to send an e-mail is the Snapcraft mailing list, where others can help you better -> you can find it at the bottom of http://snapcraft.io/
<dpm> oSoMoN, https://github.com/ubuntudesign/snapcraft.io/issues
<oSoMoN> cheers
<bull> thanks dpm
<dpm> np ;)
<bull> :)
<dpm> yw
<bull> damn , i know you
<bull> David Planella
<bull>  :D
<bull> haha
<dpm> so hi :)
<bull> lol
<bull> dpm :P
<bull> this is deskie https://www.youtube.com/watch?v=hfbC9dIAo4c
<bull> mhall119, you there ??
<oSoMoN> https://github.com/ubuntudesign/snapcraft.io/issues/19
<bull> nice
<bull> just reload page
<dpm> seb128, while you guys were working on the gtk launcher for snaps, did you ever come across this error? http://paste.ubuntu.com/17394424/
<dpm> seb128, I see it on a qt5 app that uses gtk for theming, so I had to add the gsettings schemas building part, but it now fails to launch with that error
<seb128> dpm, is that confined or in devmode?
<seb128> confined yes, it's expected, dconf doesn't work there
<dpm> seb128, it works in devmode, but not with confinement
<dpm> argh
<seb128> right, that's expected
<dpm> seb128, so I guess no known workarounds?
<seb128> I was going to try to look at that this afternoon
<seb128> you can try to set XDG_RUNTIME_DIR to a directory that exists in the snap
<seb128> e.g /tmp/dconf or something (with mkdir before)
<bull> seb128, can you help me with this : when i run a qt snapped app it says :--  /snap/deskie/x1/bin/qt5-launch: 74: exec: deskie: Permission denied
<seb128> bull, no idea about that
<seb128> is your wrapper +x?
<bull> idk
<seb128> though it seems like it's the dir which has an issue
<seb128> willcooke had somewhat similar issues earlier I think?
<bull> me ??
<bull> seb128,  u talking to me ?
<dpm> seb128, thanks, I'll give that a try this evening, and I'll check in with you later if you were planning to look at it
 * willcooke reads
<bull> willcooke, can you help me with this : when i run a qt snapped app it says :--  /snap/deskie/x1/bin/qt5-launch: 74: exec: deskie: Permission denied
<willcooke> bull, I have the same problem, not fixed it yet
<bull> willcooke, same here bro :(
<kyrofa> willcooke, oh... heh. It appears I didn't push it, which is super odd. Not sure what happened, but it's up there now
<sgclark> I also cannot run any of my qt5-launch apps
<sgclark> snaps rather
<bull> damn :D
<bull> is this way snap will work ?? launcher for apps and i thinks it sucks this way :?
<bull> whats difference b/t deb with launcher to load your own libs ??
<bull> and snap's launcher
<caleress> @jamiebennett ok thanks
<nothal> caleress: No such command!
<sgclark> well it has been working fine until this morning. The only thing that stands out to me is versioning scheme seems to have changed. /shrug to busy to muck about much today.
<caleress>  jamiebennett ok thanks
<dpm> hey sgclark, what's the issue, are you getting the "qt5-launch: 74: exec: deskie: Permission denied" error too?
<dpm> well s/deskie/yourapp/
<sgclark> aa_change_onexec failed with -1. errmsg: No such file or directory
<sgclark> and various other no such file errors
<sgclark> and looking in the filesystem they are still there..
<sgclark> qt5-launch and the wrapper seems to both be confused. dunno what possibly could have happened overnight.
<bull> dpm,  you maintaining qt5-launcher ?
<dpm> it seems after forking it I've inherited, yes :)
<joc_> kyrofa: hi, i've been trying out your new snapcraft qmake plugin, i wondered if you had any ideas how i could solve a problem i have with using the option attribute
<bull> :D bro after clean  --step build   snapcraft stage not working
<kyrofa> joc_, man you're on top of things! Yes please ask
<bull> i mean it runs fine but do not populate stage dir with what should be in stage dir
<joc_> kyrofa: ;) comes from looking at the PR page of snapcraft regularly
<kyrofa> Heh
<joc_> kyrofa: here is my work in progress yaml: https://github.com/jocave/telegram-app-snap/blob/master/snapcraft.yaml
<joc_> kyrofa: i copied your plugin to external but really i should just use your branch
<bull> dpm,  bro after clean  --step build   snapcraft stage not working , !  i mean it runs fine but do not populate stage dir with what should be in stage dir
<kyrofa> joc_, hmm... I added `options` to support arguments like -Wall etc.
<dpm> bull, I'm not sure I can help with that one, sorry :/
<bull> its okay , seems like its snap issue
<joc_> kyrofa: it actually works as it is except for the $QT_INSTALL_HEADERS variable
<kyrofa> joc_, what does that variable do?
<joc_> kyrofa: i haven't managed to work out how to expand that
<kyrofa> Yeah, snapcraft doesn't actually do variable expansion
<joc_> the SNAPCRAFT_STAGE gets put in correctly but then i need to work out where the QT5 include dir is below that
<kyrofa> joc_, indeed, SNAPCRAFT_STAGE is just something that snapcraft will replace for you
<kyrofa> joc_, ah, you need to use a staged qt
<kyrofa> Right?
<kyrofa> Except I don't see anything staging qt
<kyrofa> Or is that libqtelegram-ae?
<joc_> kyrofa: well not qt particulary, more the headers from the  libqtelegram-ae part
<kyrofa> Ah
<kyrofa> joc_, does it go into an architecture-dependent place?
<kyrofa> joc_, or is it something you can safely hard-code?
<joc_> kyrofa: yep, stage/usr/include/x86_64-linux-gnu/qt5/libqtelegram-ae/
<mhall119> bull: I am now, what's up?
<joc_> arch dependent
<kyrofa> joc_, blech, you might be stuck on https://bugs.launchpad.net/snapcraft/+bug/1576232 then
<ubottu> Launchpad bug 1576232 in Snapcraft "Doesn't allow dynamic file install targets ('usr/lib/$arch')" [Medium,Triaged]
<kyrofa> joc_, can you modify the libqtelegram part to install into an architecture-independent path?
<joc_> kyrofa: possibly, i'll have to look at the build configuration
<kyrofa> joc_, because if you can do that, of course you can just hard-code the path using SNAPCRAFT_STAGE, right?
<bull> mhall119,  am keshav , i was trying to snap deskie , i worked fine but when i launch app it says :  /snap/deskie/x1/bin/qt5-launch: 74: exec: deskie: Permission denied
<joc_> kyrofa: yeah that should work, i'll have a look at doing that, thanks
<kyrofa> joc_, thanks for taking the plugin for a test drive! willcooke has pointed out that I'm missing some build environment variables, have you run into anything else missing?
<joc_> kyrofa: yw, not that i've noticed so far, i'll let you know if i find anything
<didrocks> dholbach: dpm: fixed playpen CI for now, but I need to have a server to issue regular pings on docker hub
<dholbach> didrocks, what needs to be done there?
<dpm> thanks didrocks
<bull> dpm, where i have to place libs in snapcraft ?? which  i want put in snap for app runtime
<bull> under stage-packages or parts ??
<didrocks> dholbach: we need to have a server where I can cronify a curl command to dockerhub every day
<didrocks> people.canonical.com doesn't allow that
<dpm> bull, generally stage-packages if you use libraries from archive packages
<bull> thanks :)
<bull> dpm,  you wana try deskie ?
<bull> on 16.04 ?
<bull> i will give you deb
<dpm> bull, I generally use the default wallpaper, so I don't think I'm the best tester for a wallpaper changing app, but thanks in any case :)
<bull> you will love it ;p
<dholbach> didrocks, what does it do?
<dholbach> didrocks, I could run it from holba.ch if it's nothing too crazy
<matteo> zyga: I made a PR
<matteo> #38
<kyrofa> willcooke, where did you discover those qmake variables? I can't find any docs whatsoever on INCDIRS
<bull> dholbach, what is holba.ch ?
<dholbach> bull, my own server - nothing Ubuntu related
<willcooke> kyrofa, I copied them from popey ^^
<bull> oh
<kyrofa> popey, you have magical qmake knowledge-- share with me!
<willcooke> :D
<matteo> zyga: sorry, #40
<bull> willcooke, is it working now ??
<popey> wat wat wat
<popey> 13:46 < kyrofa> willcooke, where did you discover those qmake variables? I can't find any docs whatsoever on INCDIRS
<popey> hahahahaha
<popey> I feel your pain
<popey> i had like a thousand tabs open one day and distilled them down into a few lines in my qmake plugin and they worked
<popey> there was much rejoicing that day
<willcooke> bull, nope, not had time to look yet
<kyrofa> Hahahahaha
<mhall119> bull: make sure you chmod +x your deskie executable
<didrocks> dholbach: just issuing a curl command
<didrocks> to dockerhub
<dholbach> didrocks, can you PM it to me?
<zyga> matteo: hey, thank you :)
<zyga> matteo: I just got back from lunch, looking
<bull> it is already executable mhall119
<bull> mhall119,  willcooke having same issue , and one other was here also complaining about it
<mhall119> bull: check in /snap/deskie/current/ to make sure it's executable there
<bull> ok
<mhall119> if not, check in ./snap/ in your snapcraft build directory to see if it's executable there
<mhall119> if it's not, then I bet you ran chmod +x after the first run, and didn't clean the necessary steps/parts to get rid of the old file
 * mhall119 made that same mistake with hello-unity
<bull> mhall119, i did this from scratch with snapcraft clean
<bull> mhall119,  iwill provide output soon
<kyrofa> sgclark, hey you're getting apparmor issues?
<kyrofa> Does it look like this? https://github.com/kyrofa/nextcloud-snap/issues/1#issuecomment-226476228
<sgclark> kyrofa: not exactly
<kyrofa> sgclark, specifically the "aa_change_onexec failed with -1. errmsg: No such file or directory" stuff
<sgclark> and I cannot recreate to show you because I cannot not run any snaps at all as of this morning
<kyrofa> Yikes, what's going on?
<kyrofa> Did snapd just update??
<j-b> hello :)
<j-b> davidcalle: good morning. Are you around?
<davidcalle> j-b hi! I was thinking about finding a way to reach you this morning
<kyrofa> sgclark, happy to help debug if you have some time to poke around. I'm going to update and see if the same thing happens to me
<sgclark> afraid I am booked atm
<j-b> davidcalle: you are the one that made the vlc snappy, right?
<davidcalle> j-b: indeed
<j-b> davidcalle: you are currently my hero :)
<davidcalle> j-b: hah :)
<j-b> ;D
<j-b> davidcalle: now the bad questions:
<j-b> - will that run on 12.04?
<j-b> - can I get access to DVDs?
<j-b> - can I get access to the JVM?
<j-b> - can I get access to v4l?
<bull> davidcalle, i installed vlc last night , and its all broken
<davidcalle> j-b: maybe someone else in the channel will correct me, but I believe it will only run on 16.04
<davidcalle> bull: for now, try removing it and installing with the --devmode flag
<bull> not following system theming , not showing up in unity dash , no entry in nautilus menus , unable to run any file , ends up with permission denied issues
<bull> yeah you cant  make it run on 12.04  j-b
<kyrofa> davidcalle, indeed, 16.04 only
<bull> davidcalle, is the devmode working fine ??
<j-b> davidcalle: ok, what about the other?
<popey> kyrofa: anything you need from me, other than the stuff you have from my magic qmake plugin?
<kyrofa> popey, no sir, thanks for the help! I'm actually going to pull the qmake source, haha
<bull> hi popey
<bull> i need help regarding qt5-launcher if it is done by you
<ogra_> j-b, you would shil the jvm inside your snap ... Ã¶you would have to request an interface for DVD and v4l (i dont think we have either yet, but they can surely be added)
<davidcalle> j-b: DVDs andv4l are things that will require snap interfaces, right now it works well only unconfined (eg. installed with --devmode).
<bull> my app deskie is qt based and not opening with your launcher its ending up with : /snap/deskie/x1/bin/qt5-launch: 74: exec: deskie: Permission denied
<j-b> davidcalle: snap interface?
<j-b> I have no idea what you mean, tbh :)
<ogra_> s/can/will/
<ogra_> j-b, interfaces are how a snap can talk to the outside world
<bull> j-b they allow access your system
<bull> popey, you there ???
<ogra_> they give the user control about what a snap is allowed to do and to access
<j-b> ogra_: ok, so I need to code that interface?
<davidcalle> j-b. eg. right now the vlc snap has "interfaces" that gives it access to audio, access to X11, access to the home dir
<j-b> ok
<ogra_> j-b, either you or you file a bug and we do it
<j-b> I need /dev/s** RO  for DVD
<davidcalle> j-b: interfaces live in snapd iteslf, and snaps require them (you declare what you need basically)
<ogra_> DVD and v4l are surely on the list of planned interfaces
<j-b> and /dev/video* for webcams
<ogra_> until they exist you can simply install your snap with --devmode
<ogra_> that gives it full access
<j-b> yeah, but I can't tell that to my users.
<bull> ogra_,
<davidcalle> jdstrand: zyga: do you know how high on the todo list of interfaces these two are? ^
<bull> ogre is my fav takken character:D
<roadmr> ooo there's a todo list of interfaces?? is the "setpriority" syscall included in one of them? wooot!
<didrocks> j-b: we have a flag that you can set to your snapcraft.yaml file to say "this snap only works in devmode for now" and will refuse to install if not specified
<ogra_> roadmr, not sure if zyga has such a list yet
<didrocks> (it's going to be enforced by the end user tools soon), then the experience in --devmode is the same that traditional .deb/rpm packages (unconfined)
<roadmr> ogra_: heh, it's my passive-aggressive way of saying "I'd like an interface that allows setpriority for my snap to work nicely" :D
<j-b> didrocks: ok, but then it kind of defeats the idea :)
<bull> am getting this with my qt app launch can anyone help me ?? /snap/deskie/x1/bin/qt5-launch: 74: exec: deskie: Permission denied
<j-b> davidcalle: the interface are defined in the .yaml?
<kyrofa> sgclark, can I assume you're running kubuntu?
<didrocks> j-b: it's a transition plan ;) you still get a way to deliver latest and greatest to your users, cross-distro
<j-b> didrocks: well, sure, but then I have other solutions to do that.
<j-b> didrocks: but OK.
<bull> davidcalle, /snap/deskie/x1/bin/qt5-launch: 74: exec: deskie: Permission denied
<bull> davidcalle,  my qt app is giving me this as output when i run it
<bull> am using the same qt launcher like vlc
<davidcalle> j-b yes, see line 10 on https://github.com/ubuntu/snappy-playpen/blob/master/vlc/snapcraft.yaml it's the list of interfaces ('unity7' is a catch-all interface for desktop related authorisations)
<j-b> plugs?
<j-b> but where does it declare x11 and audio accesS?
<davidcalle> j-b, this file is missing the pulseaudio one and x11 is part of the unity7 one. See https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<j-b> and opengl
<j-b> davidcalle: so we need new plugs for dvd and v4l?
<sgclark> kyrofa: nope I am in Neon for the lastest packages
<kyrofa> sgclark, ah! So is the other person complaining about that. zyga ^^
<davidcalle> j-b: pretty much, yes, here is what the pulseaudio plug looks like: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/pulseaudio.go
<j-b> in go? o_O
<j-b> nice.
<sgclark> well we had a snap running in Arch, we best darned be able to use them in neon haha
<kyrofa> sgclark, no kidding :P
<kyrofa> Investigating now
<sgclark> ty1
<sgclark> !
<j-b> davidcalle: do we get access to DBus?
<davidcalle> j-b: I think we have some tailored dbus access allowed through the unity7 interface https://github.com/snapcore/snapd/blob/master/interfaces/builtin/unity7.go
<j-b> davidcalle: all DBus interfaces?
<ogra_> heh
<ogra_> surely not
<ogra_> that would kind of defeat the purpose
<ogra_> (then you can simply also use --devmode)
<j-b> So, how do we get DBus interfaces for us? Can we declare them in the yaml?
<ogra_> i would expect that you will eventually have different dbus interfaces for different purposes ... but surely not global access
<j-b> I'm thinking of org.mpris.*
<mhall119> j-b: you might get that with the unity7 interface already
<ogra_> mhall119, doesnt look like that has mpris ... lbut i think it should
<j-b> How do I get it?
<sergiusens> bull in case no one answered (and dpm) `snapcraft clean glue` would of worked
<ogra_> smells like an oversight in the unity8 interface ...
<j-b> File an issue somewhere?
<ogra_> j-b, file a bug
<dpm> ah, nice, thanks sergiusens
<j-b> on github? on snapd?
<ogra_> sigh ... who updated the channel topic and deleted the bug url
<davidcalle> j-b: https://bugs.launchpad.net/snappy
<bull> ty sergiusens :)
<seb128> mhall119, j-b, the mpris one doesn't seem in https://github.com/snapcore/snapd/blob/master/interfaces/builtin/unity7.go
<mhall119> ogra_: I agree that it should, mpris is an imporant part of unity7 integration
<ogra_> olli, can you fix the channel topic and add the links back ?
<j-b> seb128: yes, that's what I fear.
<mhall119> as it powers the sound indicator controls
<j-b> exactly
<seb128> j-b, should be easy to get added
<ogra_> yeah
<ogra_> just file a bug at https://bugs.launchpad.net/snappy
<mhall119> though a stand-alone mpris interface might be desired too
<ogra_> well, you need some desktop part for it
<jsupcik> Hello. I just compiled my first snap (cross compiled ubuntu/amd64 -> arm/rpi2)! I was able to upload the snap to "myapps", but it shows "0 byte". Is this OK? The snap itself is 1.8MB
<dpm> JamesTait, perhaps you can help jsupcik with the store question? ^
<mhall119> ogra_: you don't think it might be used in IoT stuff?
<jdstrand> davidcalle: video interface was on zyga's list and I believe he started it. I think it was deprioritized for the moment for cross distro
<bull> mhall119, i tried build app after clean , still facing same issue
<ogra_> mhall119, dunno, would that make sense ? ... afaik mpris always needs some UI part
<JamesTait> jsupcik, I did see a similar report a few days ago, but I'm not sure what came of it.  What's the package?
<mhall119> bull: is your binary marked as executable in /snap/deskie/current/?
<bull> yes
<mhall119> ogra_: UI yes, but not necessarily GUI
<ogra_> well, true
<ypwong> when I run 'snap find' it fails as in https://paste.ubuntu.com/17396451/ saying i/o timeout, anyone knows what's wrong? I can go to the reported url in browser/wget
<mhall119> I'm thinking in-car infotainment or "smart" speakers
<ogra_> mhall119, it should definitely be part of unity7 and 8 though, since indicator-sound provides the UI ...
<mhall119> yes, I agree with that
<ogra_> a standalone one could happen later
<ogra_> if thats actually needed
<mhall119> yup
<j-b> but, for VLC, I need to expose the DBus Mpris server.
<bull> mhall119,  my deskie binary is loacated in /snap/deskie/current/opt/deskie/bin/
<ogra_> though i guess it would always be part of the UI providing bit
<j-b> which is a bit different, no?
<bull> mhall119, and it is executable
<mhall119> bull: ok, but does it have it's executable bit set?
<jsupcik> JamesTait, the package is telecom-tower.supcik (click-apps/5219)
<ogra_> j-b, do yu actually need the server ?
<mhall119> bull: is your qt5-launcher calling "/opt/deskie/bin/deskie" or just "deskie"?
<ogra_> i thought you just attach to the dbus provider
<bull> it is running fine when i double click on it there
<j-b> ogra_: I have no idea, tbh.
<ogra_> heh
<ogra_> neither do i ... but i thought you just talk to mpris interfaces on the bus usually ...
<ogra_> probably my assumption is wrong though
<matteo> zyga: works for me
<j-b> well, yes, we implement the Mpris answers so Mpris clients talk to us. How it exactly works, I have no idea.
<JamesTait> jsupcik, it looks like it's fine.  The automatic review passed, and I've downloaded it and it's definitely a squashfs filesystem.
<matteo> I'm running it now
<JamesTait> jsupcik, I don't know why the binary_filesize is 0.
<bull> mhall119, my qt5-launcher  : http://paste.ubuntu.com/17396563/
<mhall119> bull: pastebin your snapcraft.yaml too please
<bull> mhall119, ok
<jsupcik> JamesTait, OK. Thank you.
<bull> mhall119, http://paste.ubuntu.com/17396622/
<didrocks> mhall119: you got it! :-)
<bull> mhall119, i think my qt5-launcher is assuming deskie directory  a executable binary and trying to execute it , just a thought :D
<mhall119> bull: on line 9, call "qt5-launch opt/deskie/bin/deskie"
<bull> mhall119, okay i will try
<bull> mhall119, what should i do now to build again ??
<halfline> does anyone have a good example of a third party vendor that ships .snap files right now?
<bull> mhall119, i dont wana clean cause it will take lot of time to build again :/
<mhall119> bull: "snapcraft snap" should be enough
<bull> mhall119, le me try
<mhall119> as it only needs to re-generate the launcher script used by snap-confine
<bull> okay :) ty
<popey> halfline: krita
<bull> mhall119, one more thing i noticed is my , indicator icon of application not showing up , and am having issue with dash icon too
<popey> halfline: nextcloud...
<bull> please review my snapcraft.yaml for icon entry
<halfline> thanks !
<halfline> popey: hmm, i only see app image here: https://krita.org/en/download/krita-desktop/
<bull> mhall119, it says while build , for icon : DEPRECATED: 'icon' defined in snapcraft.yaml. Look at https://github.com/ubuntu-core/snapcraft/blob/master/docs/metadata.md#snap-icon for more information
<popey> halfline: its in the store
<halfline> oh i wanted to try using .snap file directly instead of using the snap program
<halfline> to downoad it
<kyrofa> ogra_, to be fair, we're shipping the snap, they're shipping devices using it. Though I imagine they'll take over the snap at some point
<seb128> halfline, are you just looking for a .snap you can download?
<halfline> seb128: yea pretty much !
<halfline> seb128: hi btw
<ogra_> kyrofa, which snap now ?
<kyrofa> ogra_, nextcloud
<ogra_> ah
<seb128> halfline, http://people.canonical.com/~bjoern/snappy/libreoffice_5.2.0.0.beta2_amd64.snap
<halfline> thanks
<seb128> halfline, hey!
<seb128> yw
<kyrofa> ogra_, oh oops, that was meant for popey
<kyrofa> ogra_, so sorry
<ogra_> hah ... and i was wondering about $context :)
<mhall119> bull: yeah, that's not used anymore, but you can add your .desktop and icon into ./setup/gui/ in your  snapcraft directory
<kyrofa> ogra_, your nick just leaps off my fingers!
<ogra_> yay
<bull> mhall119, just dropping stuffs there will work ?? we dont need add them in snapcraft.yaml now ??
<bull> mhall119, that fixed the issue :) thanks my brother :*
<bull> app is still not running due to some dependencies issues i will add them in snapcarft.yaml
<mhall119> bull: just dropping them there will make snapd put the .desktop file where it can be found
<bull> wow nice :)
<bull> mhall119, see what am getting as output now , i know how to fix those qt qml issues but see the rest : http://paste.ubuntu.com/17396957/
<mhall119> bull: looks like you need qml-module-qtquick-controls in your stage-packages
<bull> yeH i said i will fix qt stuffs , what about the rest ??
<bull> mhall119, am gonna make this app's code public on github soon :P
<mhall119> \o/
<mhall119> bull: and publish it in the store when it's working :)
<bull> sure :)
<kyrofa> sgclark, found the issue. apparmor profiles aren't being generated for neon. Making a PR to fix now
<seb128> sergiusens, hey, I've a snapcraft.yaml with a version 3.10 and the generated snap is named name_3.1_arch.snap ... is that wanted or a (known?) bug?
<popey> seb128: put quotes round it
<popey> in the yaml
<seb128> popey, is that a workaround or the way it's supposed to be?
<kgunn> ev: mvo not sure where this bug lies...but i saw this a couple of weeks ago, it got fixed, but seems it's back?...i saw it last night
 * jdstrand tries to avoid asking about why the apparmor profiles weren't being generated for 'neon'
<popey> seb128: thats the way i work around it, assuming it's a workaround :)\
<kgunn> stitched a new image, and upon attempting to sideload, it went to the store instead
<seb128> popey, thanks
<popey> yw
<kgunn> anyone know where to log that as a bug ^?
<kgunn> even when i gave it relative path like ./mir-server_version#.snap, it still downloaded from store
<EdwardMorbius> hello, anyone knows why clock snap gives libgl errors on desktop? wont start, libreoffice snap does start, proprietary nvidia drivers.
<EdwardMorbius> libGL error: No matching fbConfigs or visuals found
<EdwardMorbius> libGL error: failed to load driver: swrast
<EdwardMorbius> Unrecognized OpenGL version
<EdwardMorbius> Unrecognized OpenGL version
<seb128> popey, seems like didrocks hit that one as and reported bug #1586988
<ubottu> bug 1586988 in snapcraft (Ubuntu) "Version 2.10 is converted to 2.1" [Undecided,New] https://launchpad.net/bugs/1586988
<didrocks> yep
<seb128> snapcraft.io uses quotes
<zyga> jdstrand: that's my doing
<didrocks> seb128: that's how I discovered the bug, and edited/added quotes :p
<seb128> didrocks, is the snapcraft team looking at ubuntu bugs? I usually also affect the project because I think they don't
<didrocks> seb128: for snapcraft, they do
<seb128> great
<didrocks> (I was told to always set against the package)
<seb128> so sergiusens is slacking and didn't triage it yet :p
<didrocks> ;)
<jdstrand> zyga: now, you see, you are trying to get me to ask for more info and I'm trying not to :P
<seb128> didrocks, I was unsure because package has 39 bugs and upstream project 139
<kgunn> EdwardMorbius: i'm interested, so you're on proprietary NV drivers? and you installed the clock-app from the snap store on your desktop and it failed?
<EdwardMorbius> kgunn yes with the above error
<zyga> jdstrand: but this is safe (tm)
<zyga> jdstrand: because at worst the app won't start and someone fixes snapd
<didrocks> seb128: I did try to open against upstream, but then, I don't remember if it was leo or sergio telling me to affect rather the package
<seb128> didrocks, bug #1586162 seems to be a duplicate
<ubottu> bug 1586162 in Snapcraft "snapcraft truncates trailing 0's from version" [Undecided,Triaged] https://launchpad.net/bugs/1586162
<didrocks> that was some months ago
<zyga> jdstrand: and it doesn't let unconfined snaps to run by accident
<didrocks> so maybe it changed
<seb128> didrocks, well with comment from jamie and sergio and gustavo
<didrocks> seb128: remember my unify scripts? ;)
<didrocks> ah
<seb128> :-)
<jdstrand> interesting
<jdstrand> unrelated
<kgunn> EdwardMorbius: i think it's just a bug...team's been trying to work through that aiui
<didrocks> seb128: yeah, I came to the same conclusion while looking at it
<kgunn> EdwardMorbius: i would be curious, have you ever tried the open drivers?
<jdstrand> zyga: what is the status of landing snap-confine in 16.04? trying to decide if I need to sru ubuntu-core-launcher for the ecryptfs fix
<kgunn> EdwardMorbius: it shouldn't matter...but curious
<zyga> jdstrand: that's a great question, I think mvo wants to get it in
<didrocks> seb128: the "issue" with the python yaml parser is that you can disable it completely and then, you have to say for each field what type is expected
<zyga> mvo: to fix the nvidia bits, correct?
<didrocks> (list, and so onâ¦)
<didrocks> but that's quite a lot of code
<didrocks> I think you can inherit parser, and maybe filter to say "version is always a string"
<didrocks> (feel free to duplicate btw)
<EdwardMorbius> kgunn on my old laptop with open source radeon drivers it worked. didnt try open source drivers on this one though, went for proprietary straight away (steam).
<seb128> didrocks, yeah, I'm not going to fix it, just good to know it's reported
<EdwardMorbius> but I am suspecting it would work with nouveau
<seb128> didrocks, unsure we should workaround in the documentation though, but that's another topic ;-)
<kgunn> EdwardMorbius: ok, that's interesting....i thot it wouldn't matter...but maybe it does?
<kgunn> EdwardMorbius: b/c this is all about the snap being able to peek out to the right dirs to find the drivers...unless nv put them some place special on install
<didrocks> seb128: well, I had the requirement to release on Tuesday AND to use GNU Hello which is at .10
<kgunn> esp in the case of the clock app i would think it wouldn't matter
<didrocks> seb128: so, I did the only thing I could do with those requirementsâ¦
<EdwardMorbius> kgunn I used 361 driver from Ubuntu Software, didnt work, upgraded to latest via Nvidia PPA, same thing, maybe some paths changed
<seb128> didrocks, yeah, I guess having a "btw the version there is buggy as you can see" isn't of the best taste
<didrocks> exactlyâ¦
<seb128> didrocks, popey, thanks
<didrocks> yw
 * seb128 does the quotes workaround as well
<didrocks> getting trendy :p
<EdwardMorbius> libreoffice as a snap opens normally however
<seb128> :-)
<seb128> #quoteyoursnapversions
<kyrofa> jdstrand, why they weren't being generated: https://github.com/snapcore/snapd/blob/master/release/release.go#L54
<sergiusens> didrocks seb128 we actually prefer project ones, I do triage ubuntu ones though. The 2.10 and 2.1 requires some discussion
<sergiusens> on the one hand we can do it and lose all the benefits of yaml by parsing everything as strings, but, then, this would not be proper yaml
<didrocks> sergiusens: ah, that did change then, ok, will know for the future
<didrocks> sergiusens: I wonder if we can't inherit parser
<didrocks> sergiusens: and create our own
<kyrofa> zyga, jdstrand I wonder if we should default to generating them if UBUNTU_CODENAME=xenial ?
<didrocks> then, special-casing "version:"
<sergiusens> didrocks we can, but do we want proper yaml?
<didrocks> sergiusens: as it's some declarative build tool, I think taking that liberty makes sense, (especially as 90% of them are going to be string)
<didrocks> as 3.4.2 is a string
<didrocks> but not 3.4
<EdwardMorbius> kgunn just saw this in description of Krita in the store "Notes: no translations are available yet, and due to a bug in Ubuntu, this snap doesn't work with proprietary video drivers, e.g. for NVidia." maybe this also affects clock
<mvo> zyga: yes
<mvo> zyga: in in in
<EdwardMorbius> yes same error with krita, libgl error.
<kgunn> EdwardMorbius: :) thanks for the info
<bull> mhall119, you there ??
<bull> after i added packages under stage-packages , why snapcraft not downloading them , it directly started building snap , i issued snapcraft snap
<bull> mhall119, after i added packages under stage-packages , why snapcraft not downloading them , it directly started building snap , i issued snapcraft snap
<bull> dpm, you there ??
<popey> bull: patience please.
<bull> :)
<bull> popey, can you help ??
<bull> alan :P
<popey> has snapcraft finished and built your snap?
<popey> can you look in stage/ and see if the pieces are there?
<didrocks> kyrofa: shouldn't the part being invalidated in that case and so "snapcraft snap" rebuild the part where stage-packages have been added? ^
<bull> am all set to snap my app , but i added some dependencies to yaml file and tried snapcraft snap , it started building snap without downloading new dependencies
<kyrofa> didrocks, yes it should, but it's not-- that should be logged
<kyrofa> (a bug I mean)
<popey> bull: did you let it finish?
<bull> popey, pieces are there but not the one which i added to stage packages
<bull> yes i let it
<seb128> bull, it's a bug, you need to clean the pull and redo it I think
<bull> i cleaned stag but still it is not downloading :D
<bull> yeah , :(
<bull> seb128, it looks like a bug
<seb128> unsure if you can manually add the deb in the dir
<seb128> bull, I think that's what didrocks was asking kyrofa
<didrocks> bull: please file the bug on launchpad, as kyrofa told :)
<bull> snapcraft need to check the file changes in yaml file
<didrocks> right, that's why we need to a bug to get that fixed
<bull> okay wait :P
<bull> oh ,
<kyrofa> bull, the stage-packages are pulled in the pull step, not stage
<kyrofa> bull, so you need to make sure you clean all the way back to pull to get them
<bull> so i need clean pull ??
<kyrofa> bull, indeed
<bull> but it will clean my downloaded stuffs :/ damn
<bull> oh
<bull> thats a bandwidth sucker thing they need fix this :D
 * popey runs apt-cacher-ng to reduce that problem
<seb128> bull, kyrofa, maybe copying the deb manually where it downloaded the other ones would work
<bull> how we getting these ?? from this guy    ------ >>>>>      *
<kyrofa> seb128, you'd need to unpack it as well
<bull> seb128,  le me try thiis trick
<seb128> bull, you need to unpack as well, might be easier to just clean and redownload if your internet isn't too limited
<bull> seb128, i will try it now and provide feedback now
<bull> i saved parts/application/ubuntu directory outside and issued snapcarft clean
<bull> now after clean i pasted ubuntu/ directory back to place let see what will happen
<bull> holy shi*  it says when i issued snapcraft stage :-   E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
<zyga> jdstrand, mvo: shall I make 1.0.30 release and let us all package that?
<mvo> zyga: yes, lets do it
<zyga> mvo: can you please comment on pull 40 snap-confine
<zyga> mvo: I'd like to include it but only if it won't make packaging more complex for dpkg
<bull> seb128,
<mvo> zyga: sure, looking now - fwiw, vcs-git in debian/control also needs an update
<zyga> mvo: oh, thanks, changing now
<ev> kgunn: snapd - https://bugs.launchpad.net/snappy
<ev> for reporting the bug
<zyga> mvo: merged, doing local package builds to see what works
<aatchison> Congrats on the multi-distro snaps!
<zyga> aatchison: :)
<bull> :)
<kyrofa> willcooke, I did some more research into the qmake variables (just cloned the stupid thing)
<kyrofa> willcooke, any chance you could give the plugin another shot?
<bull> willcooke, i resolved the issue mhall119 helped me in that
<kyrofa> willcooke, actually wait, I need to verify something
<kyrofa> sergiusens, you around?
<willcooke> kyrofa, sure - in a meeting right now
<willcooke> kyrofa, will try again in amo
<kyrofa> willcooke, good deal, I'll let you know when I push it up
<sergiusens> kyrofa of course
<kyrofa> sergiusens, scratch that, figured out a better way to do what I wanted. But while I have you, want to work on slides today at some point?
<sergiusens> kyrofa this is a total bummer :-P
<kyrofa> sergiusens, I know!
<sergiusens> let me try something
<sergiusens> kyrofa probably 2 days will be lost on this
<kyrofa> sergiusens, my thinking as well
<kyrofa> Bad timing
<kyrofa> willcooke, actually, I want to experiment. Can you share your project with me? Is it the one with the qmake plugin to which you've been referring?
<sergiusens> kyrofa and that is how you solve things :-)
 * kyrofa is impressed
<croepha> ubuntu core doesn't seem to have the /boot/config-* file? how can I know the kernel configuration?
<kyrofa> croepha, ogra_ is your man
<matteo> croepha: /proc/config?
<croepha> ls: cannot access /proc/config*: No such file or directory
<kyrofa> willcooke, must not be... that project doesn't build as it is
<kyrofa> willcooke, anyway, let me know
<willcooke> kyrofa, https://github.com/8none1/fritzing-snap
<willcooke> kyrofa, you also need to clone this in to ./fritzing-src
<willcooke> https://github.com/fritzing/fritzing-app
<kyrofa> willcooke, ahhh, that's what I was missing
 * willcooke <-- hacker
<willcooke> kyrofa, make sure that ./fritzing-src/snapcraft.pro survives the clone
<kyrofa> willcooke, indeed. Though the snapcraft.yaml refers to fritzing-snapcraft.pro
<kyrofa> willcooke, should that be snapcraft.pro?
<willcooke> err
<willcooke> ah, yes - I need to push
<bull> priming mean ??
<mhall119> hi all, if I have a part that builds a library, and another part that needs that library in order to build, how do I tell the second part where to find the first one?
<kyrofa> mhall119, so first of all, you should utilize the `after` keyword on the dependent part, in order to make sure its dependency is staged before its built
<kyrofa> mhall119, from there it may just work-- snapcraft tries to setup sensible CFLAGS, LDFLAGS, etc
<kyrofa> mhall119, if you need to actually give it some sort of "--this-is-where-the-dependency-is=" flag in the YAML, you can use $SNAPCRAFT_STAGE, which snapcraft will resolve to mean the stage directory, and give a relative path from there
<mhall119> kyrofa: it's in ./stage/usr/lib/granite/
<mhall119> and I have after: [granite]
<kyrofa> mhall119, and I assume it's not working? Is the error upon linking, or can it not find headers?
<mhall119> can't find headers it seems
<kyrofa> mhall119, can you pastebin the error?
<mhall119> kyrofa: http://paste.ubuntu.com/17401922/
<kyrofa> Ahh, cmake
<kyrofa> mhall119, how does mail try to find granite in the cmakelists.txt?
<kyrofa> mhall119, module, config, hard-coded?
<mhall119> kyrofa: http://paste.ubuntu.com/17402139/ search for granite
<mhall119> kyrofa: also, http://paste.ubuntu.com/17402022/ is the list of things in ./stage/
<kyrofa> mhall119, ah, pkg-config, okay
<kyrofa> mhall119, pastebin also the contents of stage/usr/lib/i386-linux-gnu/pkgconfig/granite.pc please
<mhall119> kyrofa: http://paste.ubuntu.com/17402248/
<kyrofa> sergiusens, I'm a little foggy on your ingenius pkg-config stuff, can you take a look at this?
<croepha> are build-packages for build time dependancies? do they get added to the .snap?
<kyrofa> croepha, build-packages get installed onto the host system to be used as build time dependencies. They do not go into the snap unless the snap links to libraries contained within them, in which case those libraries will get slurped in
<kyrofa> But not the whole deb
<croepha> nice
<croepha> does it use like ldd or something to guess the links?
<kyrofa> croepha, exactly
<kyrofa> mhall119, sergiusens will know a lot more, but that .pc file seems to be trying to pull granite from /usr
<kyrofa> mhall119, which may be the issue
<kyrofa> mhall119, out of curiousity, try modifying that file in stage/ to point to the right place and try to build mail again.
<mhall119> kyrofa: modify it how?
<kyrofa> mhall119, specifically, make prefix=/path/to/my/stage/dir/usr
<kyrofa> (absolute path)
<mhall119> prefix=/root/stage/usr
<mhall119> like that?
<kyrofa> mhall119, sure, yeah, if that's where stage is
<mhall119> kyrofa: http://paste.ubuntu.com/17402692/
<mhall119> same error
<bull> mhall119, after successful building deskie am getting these errors : http://paste.ubuntu.com/17402740/
<mhall119> bull: try installing again with the --devmode flag
<bull> wait let me try
<mhall119> bull: also, what plugs are you using?
<kyrofa> mhall119, meh, sorry, you need sergiusens
<mhall119> help me sergiusens, you're my only hope
<bull> i updated plugs , in yaml file opengl , x11 etc
<bull>  network   - network-bind      - unity7    - home    - x11  - network-manager      - opengl
<bull> mhall119, these are plugs
<mhall119> ok
<bull> any idea why it is throwing such errors ?
<mhall119> the icon ones, maybe a qrc lookup path problem?
<mhall119> I'm not sure
<bull> after devmode install  :   http://paste.ubuntu.com/17402945/
<bull> but it dont throw such errors with normal usage :/ image path are all good
<mhall119> hmm, still segfaulting, sorry bull that's the extent of my knowledge
<bull> :/
<bull> no problem mhall119
<bull> i will try fix it whole night :D
<bull> i already wasted my whole day :D but am with lots of knowledge thanks all for help :)
<bull> mhall119, one more thing , i leaned new is you dont really need to download packages from repo all the time
<bull> just copy that folder to some location outside before issuing snapcraft clean , and put it back to place when you are ready to stage and pull again
<bull> you getting me ??
<bull> haha
<mhall119> bull: here's another trick, you can clean individual steps with "snapcraft clean -s $step"
<mhall119> so you can "snapcraft clean -s build" and it will leave everything from the "pull" step
<mhall119> or "snapcraft clean -s stage" and it will leave everything from "pull" and "build" alone
<mhall119> so if you've built everything, and you just need to tweak how it's put together in the snap, you can do that and not re-build every time
<dpm> mariogrip, nice one with the octoprint snap!
<zyga> dpm: what is octoprint?
<dpm> zyga, http://octoprint.org/
<zyga> wow, nice
<dpm> zyga, also a nice example of a short and sweet setup: https://github.com/ubuntu/snappy-playpen/pull/69/files
<mariogrip> dpm: thanks :D
<willcooke> mhall119, where can I get your qt5-launch script from?
<willcooke> oh, playpen I bet
<dpm> willcooke, it's defined as a wiki part at https://wiki.ubuntu.com/Snappy/Parts - you simply need to specify 'qt5conf' in 'parts' and then as the command to launch your app 'qt5-launch <your-binary>'
<mhall119> willcooke: yeah, though sgclark's might be more recent
<willcooke> oh, sweet
<willcooke> how did I miss this?!?
<dpm> willcooke, the actual launcher code lives in the repo defined in the wiki
<dpm> mhall119, unless she's copied and pasted the launcher, it should be the same
<croepha> is there a guide somewhere on making kernel snaps?
<kyrofa> willcooke, okay, that PR should now work for you, but it required changes beyond just the plugin (so copying it into your tree won't work)
<willcooke> kyrofa, oki - should I clone the whole thing then and build it?
<kyrofa> willcooke, yeah you can test it out by cloning that branch, uninstalling snapcraft temporarily, and modifying your PATH to include snapcraft's bin folder
<kyrofa> willcooke, and remove your local qmake plugin, of course
<willcooke> kyrofa, sounds like a job for a fresh brain - can I try it in the morning?  I'd love to try and get qt5-launch integrated and tested tonight
<willcooke> and then I can fritz about with it in the morning
<kyrofa> willcooke, of course! The PR needs another pass by sergiusens and elopio now anyway. I won't merge without your go-ahead
<willcooke> thx kyrofa
<kyrofa> willcooke, thank YOU. I appreciate your good testing
<willcooke> *hugs*
 * kyrofa hugs willcooke back
<willcooke> this is *fun*, actually building software instead of doing slide decks ;)
<kyrofa> Hahaha
<kyrofa> Oh oops, sergiusens, elopio I missed our planning session, I'm sorry!
<willcooke> ha, ironic
<sgclark> mhall119: actually d_ed has a more recent one that he has not even provided to me! *hint*
<sgclark> kyrofa: ty, any eta on my ability to snap?
<d_ed> oops, will push
<jdstrand> zyga: I'm fine with that (1.0.30). the seccomp branch won't get the final review til next week I don't think
<kyrofa> sgclark, it's been merged into master, I'm checking on the anticipated release now. For your reference, this is bug #1593255. You can subscribe so you know when it actually gets released
<ubottu> bug 1593255 in snapd (Ubuntu) "apparmor profiles not generated on KDE Neon" [High,Fix committed] https://launchpad.net/bugs/1593255
<sgclark> ty
<ChrisWarrick> Login only works for local users in the sudo or admin groups.
<ChrisWarrick> â why is that? why not also support 'wheel' which is seen on many non-Ubuntu distros?
<kyrofa> sgclark, sounds like SRU days are on Wednesday, so I'm afraid this won't make it to you until next week
<sgclark> wow
<d_ed> kyrofa: are you a snap developer? One things that's caused a problem is not knowing where (at compile time) our snap will be. In particular libexec paths get hardcoded into the libs/apps. Fine under a normal system, but a problem here as $SNAP can't be known at compile time.
<kyrofa> sgclark, you might consider rolling back the latest snapd release, or I can walk you through running it from source if you like
<bull> mhall119, i wana discuss something are you free right now ??
<d_ed> if the container wrapper could (in the container) symlink $SNAP to /somestaticpath (or even mount it) we could drop a lot of patches I needed to do
<sgclark> kyrofa: well yeah not being able to work until Wednesday is a huge issue to me.
<kyrofa> sgclark, understood. Which of those two paths sound better?
<kyrofa> (note that we're working on streamlining our release process, but we aren't quite there yet)
<sgclark> kyrofa: lets go with build from source
<bull> any snap developer here i have a question , why snapcraft reload repo info or apt-get update ?? whats the benefit of that ??
<kyrofa> (d_ed, I'll be right with you, sorry)
<kyrofa> sgclark, sweet, it's all in go. Are you familiar with that at all?
<sgclark> I have zero experience with go sorry
<kyrofa> sgclark, oh no apology necessary, just needed to know where you were coming from
<zyga> jdstrand: ok, I'm making the release then
<bull> seriously i mean , whats the need of icons and stuffs ?? why it grabbing repo info  every-time it building snap ??
<kyrofa> sgclark, go builds stuff by using a workspace. So create a directory (e.g. I use ~/src/go), and define the GOPATH environment variable to point to it
<kyrofa> sgclark, also, install golang-go
<ChrisWarrick> where do snap packages put their binaries?
<d_ed> sgclark: as I can't push to your git repos. Add these to all qt5_launch: https://paste.kde.org/pspuvyitz
<bull> ChrisWarrick, in /snap
<ChrisWarrick> bull: not overwriting stuff? awesome.
<kyrofa> sgclark, let me know when you've got that
<bull> ChrisWarrick, snap installs binary there , it can install more then one version of app
<ChrisWarrick> bull: which is awesome
<bull> ChrisWarrick, yes no overwriting , with deb installs
<ChrisWarrick> bull: I feared it would overwrite my ânormalâ (pacman) apps
<bull> ChrisWarrick, yes
<bull> ChrisWarrick, no
<sgclark> kyrofa: done
<ChrisWarrick> ChrisWarrick, maybe
<sgclark> d_ed: ok ty
<bull> kyrofa, you are a snap developer ??
<bull> i have some questions
<kyrofa> sgclark, now run `go get -d -v github.com/snapcore/snapd/...`. That will download snapd and its dependencies into $GOPATH/src/github/snapcore/snapd
<kyrofa> bull, indeed
<bull> kyrofa, why snapcraft reload repo info or apt-get update ?? whats the benefit of that ??
<bull> kyrofa,  whats the need of icons and stuffs ?? why it grabbing repo info  every-time it building snap ??
<kyrofa> sgclark, once that has finished cd into $GOPATH/src/github/snapcore/snapd and run the `get-deps.sh` script
<kyrofa> (which will just check out the correct commits of its dependencies)
<gouchi> hi
<kyrofa> bull, I don't understand what you just said. You mean why does it run `apt-get update` before it fetches debs?
<bull> yeah
<kyrofa> sgclark, let me know when you've got that
<kyrofa> bull, well... what would happen if it didn't?
<bull> kyrofa, it can use system's cache instead and get packages
<gouchi> can somebody make a test with my package ? Because I can't find what is wrong with it, I don't get error with scanlog
<bull> system's apt-cache i mean , and get current libs or pulls , with which developer had build his package with
<mhall119> bull: it's always better to just ask, others in here are way more knowledgeable than I am
<kyrofa> bull, snapcraft tries to make sure it always uses the most up-to-date stuff
<bull> kyrofa, you getting my point ?? also why it wipes that cache with snapcraft clean ?? why will he need download that cache approx 28mb in size here in my case everytime he build snap ??
<bull> mhall119, i started it already :)
<kyrofa> bull, to be fair, you're right. Snapcraft could be a lot smarter about this, and it will be eventually, but it's not there yet
<bull> kyrofa, snapcraft says it will package libs with which you build your software , so why it get new versions of libs ?? say - i build a app today and foo.lib is version-2  today now if i wana that lib always with in my snap , why snapcraft will force me the new version of foo.lib ??
<kyrofa> bull, it does package libs with software. When it builds the software, it pulls down the most recent version of the lib available. Once the snap is made, that lib stays at that version. If the snap is re-generated, snapcraft will again pull down the most recent version available
<kyrofa> bull, if you want the ability to hold at specific package versions, then please log a bug
<bull> yeah man thats what am saying , what if i wana stay with lib version 2 not 3 or 4 ?? why it will force me use version 4 (newer)??
<kyrofa> bull, because that's not a feature that has been requested :)
<kyrofa> d_ed, back to your question: you're right. One of the biggest stumbling blocks of snaps is that it requires its contents to be relocatable
<kyrofa> d_ed, so for example, an autotols project often writes its prefix into binaries, thereby making itself non-relocatable
<bull> kyrofa, am here since morning bro , i really appreciate the whole progress you guys done , i just wana make snap better and better , i was trying build my app deskie which is a qt application , all i see is snap is not that much capable right now so this was just a thought ,which should be implemented , i mentioned it here cause you are one of those who develop snap.
<kyrofa> bull, I appreciate the feedback
<d_ed> so far I've been patching KDE stuff
<d_ed> pulling it into new env vars, or things relative to the binary
<d_ed> which works...we needed some for Windows deployment anyway
<kyrofa> d_ed, often times such projects will also support command-line flags pointing it to alternative directories etc, but not all of course
<kyrofa> d_ed, we're working on an ld preload solution that might help
<kyrofa> d_ed, but that's a little yucky
<kyrofa> (and not done yet)
<d_ed> overriding all stat() and open() ?
<kyrofa> Hey sgclark, once you complete those other steps, run `go install github.com/snapcore/snapd/...` and you'll end up with several snap* binaries inside $GOPATH/bin/
<d_ed> that's somewhere between amazing and mental
<kyrofa> d_ed, hahaha
<d_ed> (why ld preload it, you control the linked glibc don't you?)
<kyrofa> d_ed, yeah, but we can handle preloading in snapcraft, making glibc changes is a bit heavier
<kyrofa> d_ed, here's another hack for you, introduced to me by attente: use /snap/<snapname>/current as the prefix, and use a custom plugin that moves it after it's been installed, and now the prefix is valid at runtime
<gouchi> How can I debug if I got no error with scanlog ?
<d_ed> does current point to the latest possible, or the one the user will be running
<kyrofa> sgclark, finally, to use the newly build snapd, use https://github.com/snapcore/snapd#testing-snapd-on-a-snappy-system
<kyrofa> sgclark, also make sure $GOPATH/bin is in your path
<kyrofa> d_ed, the running one
<kyrofa> d_ed, or "active" one
<kyrofa> d_ed, I very much prefer proposing command-line flags upstream to make them relocatable, but that's not always an option
<kyrofa> gouchi, does the application in question have a log? Or write to syslog?
<kyrofa> gouchi, you can include things like strace in the stage packages and use it
<sgclark> kyrofa: I am so sorry, distracted. I will continue with backlog
<kyrofa> sgclark, heh, if anyone understands that I do
<kyrofa> sgclark, the backlog should get you to where you need to be, ping me if otherwise
<kyrofa> sgclark, and I'm sorry about the issues :(
<d_ed> kyrofa: ok, thanks
<bull> kyrofa, where to raise an issue about snapcraft ? give github link please
<kyrofa> bull, https://bugs.launchpad.net/snapcraft/+filebug
<bull> its on github too ??
<gouchi> kyrofa: I will change the wrapper so that it shows the log
<kyrofa> bull, code is on github, bugs tracked on launchpad
<bull> oh
<bull> nice
<bull> kyrofa, what you think ,about what i said earlier ?? it should be in snapcraft or its useless ?? i mean i put a bug or not :D
<kyrofa> bull, you said a log of things. Which bug are you thinking of logging?
<sgclark> kyrofa: ok on run_checks now
<kyrofa> sgclark, ah yeah, good idea
<bull> why it cleaning apt cache all the time and reloading it before build everytime
<kyrofa> bull, sure, go ahead and log a bug, then the team can read it over
<bull> okay :)
<sgclark> All good, what could possibly go wrong lol
<kyrofa> bull, no promises of course
<kyrofa> sgclark, like that?
<bull> haha
<croepha> so, https://developer.ubuntu.com/en/snappy/guides/porting/ says that you need to make an snap... but it doesn't really say how one is supposed to do that
<sgclark> kyrofa: lol yeah
<mhall119> croepha: you mean a kernel or OS snap? or an application snap?
<croepha> s/make an snap/make an oem snap/
<mhall119> ok :)
<sgclark> kyrofa: I am back in business, thank you so very much!
<mhall119> niemeyer1: do we have docs for making OEM snaps?
<kyrofa> sgclark, wonderful! Sorry again, glad you're back up and running
<sgclark> np, not something you could have foreseen
<croepha> mhall119 I need to make an image with a custom kernel, im not sure what I mean by OEM, thats the terminology from the porting guide
<croepha> is "OEM snap" synonymous with "Gadget snap"?
<davidcalle> croepha: this porting guide is quite outdated, yes, OEM snap is the 15.04 terminology, gadget is series 16 (the one we are releasing these days), but they are the same thing
<croepha> davidcalle: ok thanks, then I think I have what I need
<davidcalle> croepha: ok
<gouchi> kyrofa: http://www.hastebin.com/jusimureva.coffee
<willcooke> it works, it works, it works!!!!  http://imgur.com/snYkPJO
<gouchi> kyrofa: I can't add options to the wrapper it seems
<gouchi> kyrofa: or it crashed before
<popey> willcooke: yay!
<gouchi> if somebody wants to make a test here is the source https://lufi.io/r/lioXiR-TT-#iBd88U+emCC9MY8LInCgbwvMAhPJanixfgK1z0JrAYQ= to build
<gouchi> but you will need snapd >= 2.0.9
<kyrofa> sgclark, just FYI, we also have https://launchpad.net/~snappy-dev/+archive/ubuntu/edge which is updated daily but is obviously less stable
<bull> sleep is coming goodnight guys :/
<mhall119> willcooke: awesome!.....what is it?
<willcooke> mhall119, PCB design tool:  http://fritzing.org/home/
<kyrofa> sgclark, note that I was just given the magic to request new builds to be placed there as well, so I just started a build containing the neon fix
<sgclark> kyrofa: ok ty
<sgclark> I still seem to have the wrapper issue, but rebuilding to be sure
<kyrofa> sgclark, this fixes the apparmor issue, remind me again what the wrapper issue was?
<sgclark> kyrofa: well I tried to rebuild but now I can't install snaps http://paste.ubuntu.com/17409817/
<kyrofa> sgclark, did you run snapd?
<kyrofa> sgclark, does `snap list`  give you the same error?
<sgclark> kyrofa: nm I blame the flu. copy paste fail
<kyrofa> sgclark, blech, you and sergiusens both!
<sgclark> :(
<sgclark> kyrofa: ok confirm snapd is running still same error. but it is late and I am sick. I will try again tomorrow.
<kyrofa> sgclark, okay, go to bed! Tomorrow you can try just installing snapd from that PPA, might be easier
<kyrofa> sgclark, I learned about that PPA after I walked you through the src, by the way :P
<kyrofa> Sorry about that
<sgclark> kyrofa: all works, sorry, my brain is not 100% wrapper error gone too
<kyrofa> sgclark, yay!
<sgclark> :)
<zyga> jdstrand, slangasek, mvo: FYI, snap-confine 1.0.30 released and ready to go downstream
<zyga> mvo does the ubuntu SRU
<zyga> I pushed it to fedora, arch and soon gentoo
<zyga> https://github.com/snapcore/snap-confine/releases/tag/1.0.30
<popey> anyone else getting this? https://bugs.launchpad.net/snapcraft/+bug/1593409
<ubottu> Launchpad bug 1593409 in Snapcraft "snapcraft cleanbuild 500 internal server error" [Undecided,New]
<popey> cleanbuild just doesn't work here
<tsimonq2> popey: nope, mine builds fine
<popey> hm
<sergiusens> popey I replied to your bug in the report
<sergiusens> kyrofa sgclark I am not so sick anymore, it is only my wife and kid now
 * sergiusens wants them crossed off from the sick list as well!
<sgclark> :( for them :) for you.
<sgclark> I am on the road to recovery. but it was rough, and on my Switzerland sprint :(
<popey> sergiusens: you were right
#snappy 2016-06-17
<mhall119> sergiusens: if you're around tomorrow, I could really use your help with some cmake/pkg-config problems I'm having
<Shibe> in a snappy system, will apt still be used for core parts of the system such as kernel and drivers?
<mhall119> sgclark: d_ed: we've started sending out a weekly email higlighting snap work from the community, do you have a few bullet points about what you've been doing that I can include?
<nhaines> Shibe: no.
<nhaines> I give up.  I'm trying to snapify a script that calls sox via play, and I can't get any progress past "play FAIL sox: Sorry, there is no default audio device configured".
<nhaines> The "pulseaudio" interface is defined and connected.  I don't know whether or not I'm supposed to have PulseAudio installed in the snap (it doesn't seem to make a difference) or for that matter, why sox works immediately on a classic system and has no configuration inside a snap.
<nhaines> I have installed libsox-fmt-pulse.  I come back to it every week and it's been five weeks and I'm stumped.
<elopio> nhaines: does it fail even with --devmode ?
<elopio> thomi: hey, I see in keybaise that you have an invitation available... :)
<elopio> *keybase
<thomi> elopio: I sure do - you want one?
<nhaines> elopio: it does!
<elopio> thomi: yes please.
<thomi> elopio: PM me your email address
<elopio> nhaines: please report a bug. Sounds like sox needs configuration, which I have no idea how to do.
<nhaines> elopio: after 5 weeks of trying, neither do I!  :)
<nhaines> But I hate to report a bug if it's really me just being dumb.  :)
<elopio> nhaines: that's what I do all day!
<nhaines> heh  :)
<nhaines> What project do I file against in LP?
<elopio> nhaines: snappy
<nhaines> Now to figure out how to protect my suuuuuper secret proprietary one-line sox command trade secrets!
<Shibe> <nhaines> Shibe: no.
<Shibe> okay, so how will drivers and kernels be installed/updated in snappy?
<Shibe> isn't each snap isolated from the rest of the system?
<nhaines> Shibe: drivers will be part of the gadget snaps and kernels will be part of the kernel snaps.
<Shibe> nhaines: is there any information about these "gadget/kernel snaps"?
<nhaines> https://developer.ubuntu.com/en/snappy/ under System Overview
<nhaines> Also probably https://developer.ubuntu.com/en/snappy/guides/porting/
<ePierre> hello!
<ePierre> I'm trying to create a snap from a Python package. I've managed to create the snap, but when I try to run it, I have the following issue:
<ePierre> locale.setlocale(locale.LC_ALL, '')
<ePierre>   File "/home/pierre/dev/rapid/parts/rapid/install/usr/lib/python3.5/locale.py", line 595, in setlocale
<ePierre>     return _setlocale(category, locale)
<ePierre> locale.Error: unsupported locale setting
<ePierre> argh. Now I get another error when trying to re-build the snap. â "ImportError: No module named 'DistUtilsExtra'" although in my snapcraft.yaml, I have
<ePierre> build-packages:
<ePierre> - python3-distutils-extra
<ePierre> looks like snapcraft doesn't downloaded this package before trying to build...
<ePierre> (but it worked before and I don't know how)
<nhaines> https://bugs.launchpad.net/snappy/+bug/1593558
<ubottu> Launchpad bug 1593558 in Snappy "sox not configured for pulseaudio when packaged in a snap" [Undecided,New]
<trijntje> I've installed a snap as user1, but I can't use it as user2. When I want to install it for user2, I get a message that the snap is already installed. Is that a known limitation or should I file a bug?
<trijntje> hmm, it looks like /snap/bin is not in the PATH of the new user I created with adduser
<qengho> trijntje: $ grep /snap /etc/profile.d/*
<trijntje> /etc/profile.d/apps-bin-path.sh:# Expand the $PATH to include /snap/bin which is what snappy applications
<trijntje> /etc/profile.d/apps-bin-path.sh:PATH=$PATH:/snap/bin
<trijntje> qengho: I've added /snap/bin to my PATH as a temporary fix
<trijntje> It happens both for users added with adduser and via the gui. Should I file a bug against snapd for this problem?
<dholbach> hey hey
<trijntje> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1593578
<ubottu> Launchpad bug 1593578 in snapd (Ubuntu) "new users don't have /snap/bin in PATH" [Undecided,New]
<qengho> trijntje: What shell do new users have? Check /etc/passwd .
<trijntje> qengho: /bin/bash, same as the first user
<qengho> trijntje: Is anything in their home clobbering PATH var? Also see /etc/skel/ .
<trijntje> qengho: no, only /etc/skel/.profile adds $HOME/bin to PATH.
<trijntje> echo $PATH
<trijntje> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
<nhaines> dholbach: morning!
<dholbach> hi nhaines
<qengho> trijntje: $ ls -l /etc/profile.d/apps-bin-path.sh
<trijntje> $ ls -l /etc/profile.d/apps-bin-path.sh
<trijntje> -rw-r--r-- 1 root root 101 mei  3 08:00 /etc/profile.d/apps-bin-path.sh
<qengho> trijntje: That doesn't make sense. Something you said is wrong. At login, bash "runs" /etc/profile, which runs /etc/profile.d/*, which sets PATH to include /snap/bin . Put a "echo hi" in /etc/profile.d/apps-bin-path.sh to see if/that it's running.
<trijntje> qengho: you are right. If I do a real login, snap is in the path. I was just using 'su user' from a terminal, and if I do that its not in the path
<nhaines> dholbach: snapcraft frustrates me, as I've been unable to build absolutely anything.  But I've destroyed whole development systems over and over in lxc containers while my laptop's 16.04 LTS install remains pristine, and *that's* been really pleasant.  :)
<trijntje> qengho: what does this mean for the bug? Is it invalid/expected behaviour?
<d_ed> mhall119: * patched parts of KDE frameworks to support KIO in snappy
<d_ed> mhall119: thus fixing downloading/file browsing
<qengho> trijntje: well, the bug-report title should be changed to mention "su".
<dholbach> nhaines, maybe if you post your snapcraft.yaml somewhere, somebody can help you?
<dholbach> nhaines, or you ask a more specific question?
<trijntje> qengho: I've added this to the bug report, thanks for your help
<ePierre> hey there
<ePierre> I'm trying to create a snap for this app: https://launchpad.net/rapid
<ePierre> I bzr branched the code (bzr branch lp:rapid), then created a snapcraft.yaml file, but I cannot build it
<qengho> trijntje: In the mean time, $ su other -
<ePierre> it worked once (but then I couldn't run the program, which is another issue), and since then, whenever I try to rebuild, I get an error
<qengho> That's all. sic
<ePierre> both snapcraft.yaml and error are here: http://paste.ubuntu.com/17426643/
<ePierre> does anyone have a clue of what's going on?
<qengho> ePierre: also use "--debug" as arg to snacraft.
<ePierre> qengho, ok. It provides a bit more info, but nothing interesting I think
<nhaines> dholbach: I did!  It's in the bug report.  :)  https://bugs.launchpad.net/bugs/1593558
<ubottu> Launchpad bug 1593558 in Snappy "sox not configured for pulseaudio when packaged in a snap" [Undecided,New]
<dholbach> cool
<qengho> ePierre: "cd parts/rapid/install; pip3 install"  # What is wrong with pip3 install there? How should you install?
<qengho> ...if this were not a snap, what are install instructions?
<nhaines> dholbach: although my attempt at snappifying hollywood didn't go anywhere either, which is sort of a shame.  :)
<dholbach> bring it up on the mailing list
<nhaines> Okay.  I'm shy of mailing lists when the more probable cause is my own incompetence.  :)
 * nhaines tries to remember what the mailing list is caled this week.
<ogra_> snapcraft@snapcraft.lol
<ogra_> ;)
<nhaines> ogra_: :D
<nhaines> The list admin should really use the [snapcraft] prefix.
<svij> ogra_: you forgot the "lists." before snapcraft.lol! :P
<ogra_> ouch, indeed
<ogra_> nhaines, so that you cant read the subject in dekko you mean ?
<ogra_> yep, good idea :)
<ePierre> qengho, there is an install script: https://launchpad.net/rapid/pyqt/0.9.0a3/+download/install.py
<qengho> ePierre: plugins are only smart about standard ways of installing software parts. You could make your own plugin that runs that. Extend python3 module, perhaps.
<trijntje> What is the proper way to create a snap for a program that can read files outside of the users home (eg /bigdata)
<nhaines> ogra_: do that I can find them in Thunderbird.  Is there some strange Dekko bug?  :)
<zyga> good morning
<ogra_> nhaines, no, just a strange screen width of phones :P
<ogra_> prefixing subjects is a pretty bad habit since it pushes the actual info you want to the right ... if your screen isnt particulary wide the text you want to read might not be readable anymore
<nhaines> ogra_: that's what rotating the phone sideways is for, of course.  ;)
<ogra_> sure ...
<nhaines> The actual info I want tends to be "why am I getting these emails?"
<ogra_> i get that by looking at the "To" address :)
<nhaines> ogra_: I don't have time for that.  :)
<ogra_> then use a proper filter ;)
<trijntje> is it possible to have a snapped program read a file from outside the users home directory? 'my-app /path/to/data/file'
<ogra_> not at the moment
<morphis> zyga: ping
<ogra_> well ... if you install with --devmode it might
<zyga> morphis: hi
<morphis> zyga: do you have time to take a last look at the modem-manager interface?
<zyga> morphis: little but I can have a quick look now
<trijntje> ogra_: I'll give devmode a try, thanks
<morphis> zyga: we would like to get it merged, jdstrand already gave his +1
<morphis> abeato: ^^
<pmp> morning, I finally succeeded in building a custom kernel (which is correctly configured to working with ubuntu-core) for raspi with IIO support \o/
<nhaines> Yay!
<pmp> I finally could run a command from a snap which tries to access iio-devices
<pmp> and it fails ! Yay!
<nhaines> \o/
<pmp> I'm using lsiio which access sysfs
<pmp> my goal is to create a bug on launchpad which will make the devs create an appropriate interface - unless there is already one?! Hence my report here before posting a bug.
<pmp> (I will also try to write an article/report on how I did to create an IIO-kernel for raspi based on 4.7-rc3 - it wasn't torture but not far from it. Thanks to ogra_ for supporting me all the time
<trijntje> ogra_: putting 'devmode' in the snapcraft.yaml file did not work, but installing the snap with --devmode did. Thanks for the advice
<dpm> seb128, good morning. I tried your suggestion last night http://paste.ubuntu.com/17426218 and that made dconf happy - thanks! The app started, but then apparmor blocks it as it's trying to write to /var/cache/fontconfig/
<ePierre> qengho, thanks! I'll dig a bit more and perhaps discuss with the owner of the software about it
<seb128> dpm, great for dconf! unsure about the fontconfig issue though
<dpm> no worries, I'll keep investigating
<seb128> dpm, first time I see that issue, you use the standard wrapper?
<dpm> seb128, parts of it. It's the qt5-launch wrapper, to which I had to add some bits from the gtk wrapper for a qt app that uses gtk theming
<seb128> dpm, is XDG_CACHE_HOME set?
<dpm> seb128, yeah, that's one bit that I took from the gtk wrapper: https://github.com/dplanella/qt5conf/blob/with-gtk/qt5-launch#L53
<seb128> dpm, sorry I don't know offhand
<dpm> np, thanks anyway
<ogra_> trijntje, yeah, the entry in snapcraft.yaml just makes sure that a snap from the store blocks when you install it without --devmode ...
<trijntje> ogra_: I see. I was still able to install it though, I just got the same 'permission denied' error when I tried to read the file
<ogra_> trijntje, yeah, but you installed it locally ... the a snap install from the store should behave differently
<ogra_> we dont actually stop you from shooting both your feet when you sideload stuff ;)
<trijntje> ogra_: that makes sense. I'll mostly be creating snaps for myself and some colleagues, so foot-shooting is no big deal ;)
<ogra_> just wear these heavy duty shoes then ;)
<didrocks> dholbach: dpm: did you get issues with snapcraft cleanbuild? I'm trying from snapcraft-example godd, run "snapcraft cleanbuild"
<didrocks> I'm getting a lot of E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/f/file/python3-magic_5.25-2ubuntu1_all.deb  500  Internal Server Error
<didrocks> in my new lxd container
<didrocks> it doesn't refresh?
<dholbach> it worked for other projects earlier
<dpm> didrocks, it worked for me yesterday, I've not tested it today. I think someone mentioned this on gitter yesterday, and `lxd init` helped them
<dholbach> let me try godd
<didrocks> thanks :)
<didrocks> keep me posted
<dholbach> it wfm with godd - looks like snapcraft 2.11 can get all build-deps - trying with trunk
<dholbach> hum... it install snapcraft 2.11 in the lxc container
<dholbach> so yeah... it works
<slvn> hello, I tried the "pulseaudio" interface on my snap, and it didnot seem to work. I have blocked message from app armor
<didrocks> I'm going to try lxd init
<didrocks> already ran :/
<didrocks> hum, unsure what's happening
<tsimonq2> didrocks: there's an open bug by Alan Pope reporting the 500
 * tsimonq2 finds it
<didrocks> oh great!
<didrocks> popey: you have the same issue as well, did you get it fixed?
<popey> didrocks: I am not here, but I did fix it
<popey> nuke lxd/lxc config from orbit and start again
<popey> it was lxc/lxd networking at fault, not snappy
 * popey disappears in a puff of aether
<didrocks> popey: always the big restart button! Many things, and good week-end! :)
 * tsimonq2 chases after popey but to no avail, he is gone (:P)
<tsimonq2> popey: have a good weekend :)
<ePierre> When I try to build a snap from a Python3 project, what happens in snapcraft exactly? Cause in the project I'm trying to build, it requires a few packages to be installed (e.g. python3-gi), and they are installed on my system, and they are also in build-packages: section, but somehow the setup.py script doesn't seem to have access to them when I launch snapcraft
<zyga> ePierre: you want them in stage-packages
<zyga> ePierre: they are required at runtime, not just at build-time
<zyga> ePierre: gi is gobject introspection
<zyga> ePierre: that requires the actual shared objects (random .so files)
<zyga> ePierre: the .gir files
<ePierre> zyga, indeed... it seems to build properly now
<zyga> ePierre: and then python[23]-gi itself
<jdstrand> dpm: the access to /var/cache/fontconfig is non-fatal and almost certainly not why your app didn't work (consider the fact that it wants to write to a directory it doesn't have access to anyway-- that dir is root owned and your app runs as you)
<jdstrand> it is a weird fontconfig thing
<dpm> jdstrand, I figured out the /var/cache/fontconfig issue, as you say, it was a red herring. It turns out that the app ships a fonts.conf file that specifies that directory as the first to use in a list. I tried to alter that list with a local.conf file, which didn't work, and then figured out that the app was not starting because of a missing 'network-bind' plug, which snappy-debug hadn't flagged in previous tests
<dpm> after it did, I added the plug and it then worked
<pandaadb> Hi - I am trying to package a java server application with snappy for the first time. My jenkins server builds the things and I have a url for that (hardcoded for now).
<pandaadb> What I would like to do is to download it (with auth)
<pandaadb> is there a wget plugin?
<pandaadb> or would that be the pull plugin
<dpm> jdstrand, by the way, am I using snappy-debug correctly? It does not seem to work as expected -> http://paste.ubuntu.com/17428561
<jdstrand> dpm: you said 'does not start the app', but it does-- it is tailing the log and will hang there until it has something to report
<jdstrand> dpm: you can run it as non-root, but if you do you run the risk of hitting kernel rate limiting for log output
<jdstrand> dpm: so, in earlier tests it might have been rate-limited or stopped before it hit the denial
<jdstrand> (the app stopped before it hit the denial)
<dpm> ack
<dpm> jdstrand, so regarding the usage of snappy-debug, then it's better to launch the app in another terminal to at least see the UI?
<jdstrand> dpm: there is no ui. think of it as a fancy 'tail -f /var/log/syslog'
<jdstrand> well, there is no gui
<jdstrand> there is cli output
<dpm> jdstrand, right, I just thought that that would launch the app's UI rather than holding it
<Mikaela> Is there any ETA for Firefox and LibreOffice snaps appearing?
<tsimonq2> Mikaela: AFAIK there's already a LibreOffice snap
<tsimonq2> Mikaela: http://news.softpedia.com/news/libreoffice-5-2-beta-2-now-available-as-a-snap-for-ubuntu-linux-other-distros-505263.shtml
<tsimonq2> that's from two days ago
<Mikaela> nice
<pandaadb> Is there a place where the plugins are documented?
<pandaadb> e.g. the curl plugin has no docs doing snapcraft help curl
<tsimonq2> dpm, dholbach: ^
<pandaadb> Maybe i should take a step back and find out if I am using this for the right purpose? I have the server app that is already built. I want to create a snap package that can be run anywhere. For this all i really need is to download the zip, unzip it in a location and setup the properties. After that it only needs to run
<morphis> zyga: you had time for the modem-manager interface?
<ogra_> morphis, not zyga, you know he is slacking all day :)
<morphis> ogra_: I know, but it looks like nobody else can then approve my PR :-)
<dholbach> pandaadb, https://developer.ubuntu.com/en/snappy/build-apps/plugins/
<dholbach> there's no `curl` plugin, it's a part: https://wiki.ubuntu.com/Snappy/Parts
<pandaadb> hey - thanks
<dholbach> anytime :)
<pandaadb> so downloading a zip somewhere is not what I am meant to do? I am starting to think I am using snappy for the wrong purpose
<pandaadb> Oh okay - so using a "curl" part simply downloads curl into my snappy package so that curl is available
<zyga> morphis: I'm still reading it
<zyga> morphis: I'll land it shortly
<zyga> morphis: it's just very long :)
<morphis> zyga: awesome! :-)
<zyga> morphis: I think you will be happy to hear about that you may soon get auto-connecting network-manager
<zyga> morphis: internally plugs and slots will auto-connect within one snap
<morphis> zyga: you make my dreams become true :-)
<dholbach> pandaadb, yep and downloading a zip sounds reasonable (https://github.com/ubuntu-core/snapcraft/blob/master/demos/tomcat-maven-webapp/snapcraft.yaml does it too)
<pandaadb> ah tar-content can download anything
<Son_Goku> zyga yo
<pandaadb> snapcraft help tar-content does not recognize the plugin though for help (add authentication and such)
<Son_Goku> zyga, is SELinux support for snaps coming soon?
<Son_Goku> I'd rather not have to throw SELinux into permissive mode for this
<zyga> Son_Goku: hi
<zyga> Son_Goku: I'm not working on it yet but I can help someone that is interested and experienced in selinux
<zyga> Son_Goku: the model supports it from day one
<Son_Goku> I work in both the Fedora and Mageia communities, so I'm happy to help if you need anything
<zyga> Son_Goku: that's great!
<Son_Goku> and protip, Fedora COPR will soon offer Mageia as a release target
<Son_Goku> Mageia 6 anyway
<Son_Goku> since we're gradually moving onto the same tooling as Fedora for package management
<zyga> Son_Goku: I think the first thing that should be doable is a way to run snapd in a mode where some interfaces are available and some are not
<zyga> Son_Goku: and when an interface is not yet implemented for selinux, snaps using those have to be installed in devmode
<zyga> Son_Goku: on fedora we could enable seccomp pretty easily I think
<Son_Goku> yes
<Son_Goku> that should cover most of it
<zyga> Son_Goku: the first step towards that would be to make snap-confine allow seccomp while not yet using apparmor
<zyga> Son_Goku: that should be pretty simple, it's roughly one or two lines and an optional compile on one file (have a look, it should be very fast to implement)
<zyga> Son_Goku: for selinux itself I'd like to have something simple we could implement to prototype the idea
<zyga> Son_Goku: I think the network interface (the thing that lets snaps talk to the network) is the first thing we could try
<Son_Goku> unfortunately can't touch things requiring a CLA
<Son_Goku> it gets too messy for me to contribute to stuff like that
<Son_Goku> :(
<Son_Goku> best I can do is help you along
<Son_Goku> do you not already talk to NetworkManager?
<Son_Goku> all variants of Fedora use NetworkManager as the default management interface
<Son_Goku> well, except Cloud, which uses systemd-networkd
<zyga> Son_Goku: as it is very well defined, a lot of the snaps need just that and we could try that
<zyga> Son_Goku: why not? is your employer against that?
<zyga> Son_Goku: it's not about network manager
<zyga> Son_Goku: there are two interfaces: network, which lets you create AF_INET sockets and a few other things
<zyga> Son_Goku: and network-manager, which lets you talk to n-m over dbus
<zyga> Son_Goku: those are totally separate
<zyga> Son_Goku: if you cannot work with the CLA in any way then I guess you'll have to wait until someone else steps up and can sign the CLA or that your situation changes
<Son_Goku> it's not that I can't, but because the CLA involves copyright assignment, it has to be reviewed
<Son_Goku> certain types of CLAs are easier to deal with than others
<Son_Goku> and lawyers scare me :)
<Son_Goku> in the meantime, it seems like it'd be a good idea to learn Go, though not really a fan of the language
<zyga> Son_Goku: again, network and network-manager are totally different
<zyga> Son_Goku: network lets you run a program like wget
<zyga> Son_Goku: it lets wget use a few syscalls
<zyga> Son_Goku: and perhaps read a few typical files (/etc/resolv.conf)
<zyga> Son_Goku: are you familiar with the particular CLA used here? are you sure it's impossble to sign?
<zyga> (for you)
<Son_Goku> not sure actually
<Son_Goku> but I was familiar with the ones used in older projects I tried to contribute to
<Son_Goku> upstart, etc.
<Son_Goku> why isn't snapcraft part of the snap project?
<zyga> Son_Goku: the same codebase or the same group on github?
<Son_Goku> snapcraft is in ubuntu-core rather than snap-core
<Son_Goku> does snapcraft only work with ubuntu?
<zyga> Son_Goku: it is a combination of reorgs to the code
<ogra_> currently, yes
<zyga> Son_Goku: currently snapcraft does currently only work on ubuntu but this is being changed
<zyga> Son_Goku: it should be able to build snaps on any OS
<ogra_> its just python ... might not be hard to port to other distros
<zyga> Son_Goku: probably as a snap itself
<Son_Goku> O.o
<pandaadb> hey - i am trying to pull a jdk. I read this: If you only need to embed a Java runtime, add a part with the jdk type.
<pandaadb> how does a part with a type look like?
<Son_Goku> if it's a snap, that'd make it hard to consume things like rpms and debs, wouldn't it?
<ogra_> why
<pandaadb> It keeps telling me to use a plugin but i would like to only add the jdk
<zyga> Son_Goku: not really, it would be easy to run it anywhere snapd runs
<ogra_> as long as it knows where to get them and how to unpack them
<zyga> pandaadb: I think the word "type" is really "plugin" today
<pandaadb> oh okay. So that one tells me that source is mandatory
<Son_Goku> oh geez
<Son_Goku> it needs arch translations
<qengho> Son_Goku: Snapcraft is one of many possible tools to make snap packages. For a while, snap packages were made with "cp" and "vi".
<Son_Goku> ew
<Son_Goku> vi!?
<qengho> Yes. UCB. not vim.
<zyga> Son_Goku: snaps are just squashfs filesystems with meta/snap.yaml file
<zyga> Son_Goku: they can be made in any way you want
<Son_Goku> that's more gross than vim
<qengho> Okay.
<Son_Goku> but wow
<Son_Goku> so it's a loop with stuff inside plus a declaration file
<qengho> Son_Goku: Anyway, you asked why. Snapcraft came after snap, as an idea to help snaps, not as The Only Ordained Way To Make Snaps Forevermore.
<zyga> yep
<Son_Goku> I don't see debs as a plugin in snapcraft
<Son_Goku> so how does it consume debian packages/repos?
<qengho> Son_Goku: Anypart can include debs.
<ogra_> it pullse the binaries from the ubuntu archive
<ogra_> *pulls
<ogra_> and unpacks them so you get your depending libs and all
<qengho> Son_Goku: "stage-packages: [...]"
<Son_Goku> oh, so it's integral to it rather than being a component of it
<ogra_> right
<ogra_> it could use rpms
<ogra_> or fooples ... or shrobs
<ogra_> :)
<ogra_> whatever helps you to fulfill your requirements to run your snap
<ogra_> (even a tarball full of binary blobs you pre-built would work)
<qengho> ogra_: package names will not match, so it will matter what kind of system you're building on as to whether a snapcraft.yaml "stage-packages" will work. I think it's safer+better to say "this always gets debian packages".
<ogra_> sure ... but nothing stops you to do non-standard hackery
<pandaadb> hm. when using the jdk plugin, i need to define a source (i think it is ignored). But when doing snapcraft snap, it doesn't build my snap anymore :/
<ogra_> pandaadb, did you run snapcraft clean first ?
<pandaadb> no, let me try that
<pandaadb> it seems to be updating my repositories and then in the end tells me my security is a "danglink link" i think
<ogra_> ah, you need to make sure to not have links that point to somewhere outside the snap
<pandaadb> ah that's maybe because I had to add security certificates to my local java
<pandaadb> and they are not really needed for the snap i am building, but rather so i can talk to our shitty maven repos
 * pandaadb tries to remove link
<pandaadb> Or is there maybe a way to have the jdk part be completely independent?
<qengho> pandaadb: No. If you need it, you must pick it and ship it in the snap.
<pandaadb> oh by that i meant that it should just download everything and not try to link to something local
<pandaadb> I think maybe the issue is that I am using the oracle jdk for development, but the snapcraft is downloading the openjdk of a different version
<pandaadb> the simlink doesn't even exist (the one it is looking at)
<pandaadb> i guess that's what dangling means
<pandaadb> seems to be a known issue: https://bugs.launchpad.net/snapcraft/+bug/1500505
<ubottu> Launchpad bug 1500505 in Snapcraft "snapcraft produces snaps with dangling external symlinks" [High,Fix released]
<Son_Goku> ogra_ actually, I'd suggest that it should be able to handle either debian or rpm packages
<ogra_> Son_Goku, well, as qengho said above, then your snapcraft.yaml cant be universall
<ogra_> since the names for stage packages will differ
<Son_Goku> the output is universal, though
<ogra_> well, the idea is also that you can just grab an upstream snapcraft.yaml and it will just build
<Son_Goku> so declaring a "from <distro>" is hard?
<ogra_> so while other package managers will be possible to hack in, i guess snapcraft as a snap (which would then just use debs) will likely become a default
<Son_Goku> :/
<ogra_> butu why would you care at all
<ogra_> you do snap install snapcraft ... feed it your snapcraft.yaml and out comes a snap
<ogra_> what you care for is your source and how to get it to users and running, no ?
<pandaadb> Okay - so my snap did not package, because jdk needs a source. But since I didn't get why, i added the string "some source". This is obviously not a location, which is why my snap broke. I set it to "." and now it packages
<ogra_> :)
<qengho> pandaadb: Are you getting source from somewhere and compiling it, or wrapping up some existing debianubuntu package in a snap?
<ogra_> Son_Goku, the execution environment should nnot matter at all in the end
<pandaadb> qengho, i am trying to package up my java app (build with gradle) and make it run
<pandaadb> the next step will be to write a gradle plugin as I am not using maven
<pandaadb> and then i will attempt to build it from source
<Son_Goku> I care about the source because it can matter
<qengho> Ah, then you can put it next to snapcraft.yaml and say "source: pandaadbdir"
<pandaadb> Is te root directory $SNAP or is it @SNAP_DATA ?
<pandaadb> oh okay - that is what the source is for
<pandaadb> found it, it's SNAP
<qengho> pandaadb: SNAP is snap/.   SNAP_DATA is a /var/ something. SNAP_USER_DATA is a /home/~user/ something.
<willcooke> I need to provide my own .pro file to build this thing (the one that comes with it is "broken" - I will look at fixing it later).  I had added it in to my git repo in parts/<project>/src/  - but then when I tested it from scratch, of course git wont clone in to a non-empty dir.  So is a suitable hack to have another step in my yaml to copy the file over after the checkout has happened?
<pandaadb> perfect :) thanks a lot
<qengho> pandaadb: install snap "hello-world" and run hello-world.sh .
<willcooke> s/checkout/clone
<pandaadb> thanks!
<ogra_> Son_Goku, so use source for everything (you can do that) and no binary packages at all
<pandaadb> this is awesome. Remind me of docker. But with docker if feel so restricted to the container I built. If I made a mistake or i want to change something inside my container, i am kind of screwed
<Son_Goku> but that pulls in ubuntu sources, right?
<Son_Goku> I can't use srpms or something else
<ogra_> it is just quite some effort and will take extra build time ... but technically nothing stops you from building *all* the bits from source
<ogra_> it pulls the sources you point to
<ogra_> (it will use ubuntus GCC ... but thats it)
<ogra_> i'm talking about upstream tarballs (you can just point to an url) or git trees
<ogra_> nothing requires that you actually use stage-packages at all
<pandaadb> can snappy packages be run with sudo? i think my server can not start because it does not have permissions
<ogra_> if it is a server it already runs as root
<ogra_> did you define a daemon line in your snapcraft.yaml ?
<pandaadb> oh okay, that may be the certificate dangling stuff then
<ogra_> https://github.com/ubuntu/snappy-playpen/blob/master/tinyproxy/snapcraft.yaml
<pandaadb> ogra_, no - gradle creates a wrapper that uses java_home and just runs it with the classpath env
<ogra_> see how i did it for tinyproxy there
<ogra_> ( you need "daemon: simple" in the "apps:" part)
<pandaadb> what does the plugs do?
<qengho> willcooke: Hmm, you could abstract it a bit. Make a ./Makefile next to snapcraft.yaml , and massage it together in your build-step? pull, pull, cp, and build in the makefile.  So, plugin:make and source:. ?
<mhall119> d_ed: are your KDE patches in upstream, or are they only in an Ubuntu or Neon archive?
<qengho> willcooke: that^ will not work in out build servers, though.
<qengho> only pull stage has access to network.
<willcooke> qengho, ah, good point.
<willcooke> Can the copy plugin help me I wonder.
 * willcooke reads
<willcooke> kyrofa, sucessfully built using your new qmake plugin, thank you!!
<kyrofa> willcooke, excellent, thank you!
<kyrofa> willcooke, it'll probably go through some more renditions, but now I know those variables are the ones you need
<kyrofa> willcooke, so you should be good once it lands
<willcooke> cool!  I will comment on the PR
<kyrofa> I'd appreciate it
<mhall119> sergiusens: are you in today?
<pandaadb> ogra_, after adding those lines my snap became not startable (e.g. after installing it I can't just type in server.run)
<pandaadb> http://pastebin.com/E1GS4Gaj
<willcooke> qengho, I could just write a plugin to mangle my source I think
<qengho> willcooke: Yes. Ew. :(
<willcooke> \o/
<willcooke> snapcraft.common.link_or_copy might help me
<seb128> kyrofa, sergiusens, is there a snapcraft way/plugin to move files around in the snap before it's packed?
<kyrofa> seb128, you can use reorganize
<kyrofa> seb128, errr, organize
<qengho> willcooke: I'd do some terrible relative thing. ../../otherpart/build/
<seb128> kyrofa, thanks
<willcooke> qengho, I think it knows where everything will be, so an absolute path should be do-able, and then I can just symlink it
<willcooke> oh, seb128 - in this Qt project I'm building I'm seeing errors about pixbuf stuff, like we saw for Gtk.  I'll  hit you up for some hints in a bit if you're free?
<seb128> willcooke, sure
<seb128> willcooke, I'm iterating over my evince snap
<seb128> getting there, good stuff
<willcooke> seb128, \o/
<seb128> I've a git version starting on xenial and working (can open pdf) including translations (but done in an hacky way)
<ogra_> pandaadb, it should just auto-start ... check with journalctl and systemctl
<pandaadb> is that what the daemon is for?
<ogra_> yeah
<ogra_> it makes snapcraft create a systemd unit
<pandaadb> and the service name is that smae?
<pandaadb> so in my case: sudo service media-server.run start ?
<ogra_> snap.tinyproxy.tinyproxy.service
<ogra_> thats what i get for tinyproxy
<pandaadb> ah i will give it another try
<ogra_> systemctl status snap.tinyproxy.tinyproxy.service
<ogra_> that gets me info if it runs
<seb128> jdstrand, you set bug #1576308 as fix commited but it still doesn't work out of the box due to missing xdg_runtime_dir, do you want to re-use that bug or should we open a new one?
<ubottu> bug 1576308 in snapd (Ubuntu Yakkety) "gsettings doesn't work with snap confinement" [High,Fix committed] https://launchpad.net/bugs/1576308
<ogra_> (and replacing status with stop or start will then start/stop it)
<didrocks> seb128: missing, as, the env isn't exported?
<didrocks> (or access)
<seb128> didrocks, like the /run dir is not mounted in the snap env
<seb128> I guess we could create a new one and set the variable
<seb128> unsure if that wouldn't confuse dconf though
<pandaadb> ooi - is there a plan to just move away from apt-get to snap completely?
<seb128> since the service is the user session one
<didrocks> seb128: just for my interest, what is the .pid or .lock that is used?
 * didrocks doesn't see anything obvious
<seb128> didrocks, in that dir?
<didrocks> yep
<seb128> iirc desrt said that there was a file writing in there during writes
<didrocks> ah, so it can be transient
<seb128> which client apps use to know when to read the new value or something
<seb128> it's transient
<seb128> it's just there during writes
<didrocks> yeah, so maybe with separated one, we would have multiple writesâ¦
<morphis> mvo_, niemeyer: is there somebody else who can finish reviewing https://github.com/snapcore/snapd/pull/1226 and merge it so we get it released soon?
<seb128> slangasek, jdstrand, mvo_, the "socketall/i386" fix|workaround from snapd 2.0.8 isn't right, http://launchpadlibrarian.net/265014833/snapd_2.0.5_2.0.8.diff.gz suggests it's only allowed if network-bind is used, shouldn't be allowed in any case?
<matteo> snap-confine is responsible of setting some env vars, like ld library path ot the dynamic loadeer?
<morphis> matteo: what do you mean by dynamic loader?
<matteo>  /snap/ubuntu-core/current/lib/ld-linux.so.2
<pandaadb> mmm snappy does not seem to have permissions to start jetty on part 8085
<pandaadb> (and 8081)
<morphis> matteo: ah
<morphis> matteo: it should or some of the generated scripts
<matteo> like /snap/bin/htop
<matteo> that's the htop generated script http://pastebin.ubuntu.com/17431353/
<matteo> http://pastebin.ubuntu.com/17431370/
<matteo> the latter also has the wrapper
<pandaadb> I think it might be openjdk being packaged that is not allowed to access any ports?
<jbicha> my CPU was running at 100% yesterday
<jbicha> I checked my processes and saw that it was java
<jbicha> I killed java and it just came back to life
<jbicha> and then I realized it was because I had installed the cassandra snap
<jbicha> so I removed that because I didn't need it anyway, not sure if that's expected behavior for it or not
<jbicha> (cassandra was a featured app briefly in a dev snapshot of Ubuntu's GNOME Software)
<jbicha> reported it here because I don't know where to report issues with snaps
<seb128> to the packager usually I think
<seb128> ev in that case I think?
<jbicha> ok I see snap find tells me that
<jbicha> I hadn't used the cli, just GNOME Software which doesn't give much info at all
<ogra_> olli|, poke .... about the bug reporting link in the topic
<matteo> 2.0.9 is the last tag on github?
<pandaadb> okay it's really odd, but my java app will not start up. It tells me i have no privileges for the ports it wants to start on
<pandaadb> i can use the jvm in /snap and start it manually
<pandaadb> i can use the shell scripts that start it manually
<pandaadb> that all works, but running it as a service does not
<didrocks> pandaadb: did yu install your snap in --devmode?
<didrocks> you*
<pandaadb> yes
<pandaadb> is that bad? :D
<didrocks> no, that was a potential issue you may have (like permission issues)
<didrocks> something you can try:
<pandaadb> so i should move it to strict?
<didrocks> no no, you should always start in devmode
<didrocks> ah, you declared it that way
<didrocks> but when you installed your snap
<didrocks> you did run: snap install <snap_name> --devmode
<didrocks> right?
<pandaadb> no
<didrocks> here you go :)
<pandaadb> just sudo snap install <name>
<didrocks> reinstall it in devmode
<pandaadb> you are my hero!
<pandaadb> :) :)
<pandaadb> thanks!
<didrocks> (the declaration in snapcraft.yaml is to enforce people to type the --devmode option in the future once snapd enforces it)
<didrocks> yw! :)
<didrocks> pandaadb: once you are happy with your snap, you can turn it into strict mode
<didrocks> and add confinement
<didrocks> http://snapcraft.io/create/
<didrocks> you have here a service example
<didrocks> you can read "confinement and devmode
<didrocks> and "plugs-and-slots: integration with the system and other snaps"
<didrocks> which is exactly about web servers, as it seems to be your use case :)
<pandaadb> yep :)
<pandaadb> yeah, i have to admit, i read about snappy and got so excited that i just started trial-and-error runs while reading at the same time
<ogra_> pandaadb, but if you need network, look at my tinyproxy snapcraft.yaml from above
<ogra_> just add network and netwro-bind to the plugs line for your daemon
<didrocks> ogra_: better to direct people to the documentation, I did hilight the needed section :)
<ogra_> didrocks, i dont even know where the documentation lives ... i work by example :)
<didrocks> ogra_: you should at least know where it lives to point your community to it :p
<ogra_> pandaadb, follow the documentation that didrocks will point you to in a minute ;)
<didrocks> ogra_: s/will/did/
<pandaadb> ah he did above :)
<pandaadb> thanks
<didrocks> see above ;)
<didrocks> yw!
<pandaadb> yes - i am reading about it now. hehe - my next question would have been "it started but i can't curl it" but now I see :)
<ogra_> oh, "create" lists the possible plugs ?
<didrocks> ogra_: no, just this particular case (webserver)
<ogra_> ah
<didrocks> let me find the page about plugs and slots
<didrocks> https://developer.ubuntu.com/en/snappy/guides/interfaces/
<pandaadb> yey :) It runs!
<didrocks> confined? excellent :)
<pandaadb> still in dev mode for now
<ev> jbicha: can you send me (ev@ubuntu.com) the /var/log/syslog file from that machine?
<pandaadb> Only learned about snappy today :) I just figured it would be cool to package my application like that
<didrocks> yeah, it is! :)
<pandaadb> So is it a usecase to have a private snappy repo, so that one can distribute to servers like that
<pandaadb> And then handle updating and all with it
<pandaadb> it's the awesome version of docker :)
<didrocks> pandaadb: you can control channels and also (in the near future), the way that updates will roll to your users from the main store
<didrocks> and even have snaps that are private to you or your friends (in devmode IIRC)
<pandaadb> ah perfect. Yeah i was missing a couple of things that i could not work out before
<pandaadb> e.g. i could not work out how to add authentication to tar-content, so that i could download a zip from my build server
<pandaadb> though it seems super easy to write custom plugins or extend some. Or frankly, just use snappy as a build server instead since it builds things automatically
<joc_> kyrofa: hi, i'm making slow but steady progress though my snapping project using your plugin, still don't think i've encountered anything missing from the plugin that is blocking me
<kyrofa> joc_, great thanks for letting me know!
<joc_> kyrofa: my options sections are getting quite big though!
<kyrofa> joc_, just because of the project, or are there things you think the plugin should be handling?
<didrocks> pandaadb: yeah, you can inherit and write your own public for those use cases
<kyrofa> didrocks, you're building snaps in the playpen? Are you just making an lxc on travis and building there?
<joc_> kyrofa: this is the yaml https://github.com/jocave/telegram-app-snap/blob/master/snapcraft.yaml
<joc_> kyrofa: there is one arch specific lib path in there that i haven't managed to modify in the build
<kyrofa> joc_, the L$SNAPCRAFT_STAGE/usr/lib/x86_64-linux-gnu ?
<joc_> yep
<kyrofa> joc_, you actually shouldn't need that anymore as of yesterday. Can you try removing it and see what happens?
<kyrofa> joc_, assuming you're running a current version of my branch anyway
<joc_> kyrofa: sure, ill make sure i'm up to date and try it
<didrocks> kyrofa: unfortunately, as I have to use docker to ship latest snapcraft (remember that their builders is 14.04 LTS at best), I can't run lxd inside docker
<didrocks> kyrofa: that's what I tried today :)
<didrocks> (well, this last 30 minutes :p)
<didrocks> that would help to do a cleanbuild though
<pandaadb> so for my snap, this obviously has to download tje jdk as a dependency, which makes my snap a bit big. Does snappy know about those dependencies (e.g. if i package a second server and install it, will it duplicate the jre?)
<kyrofa> didrocks, right, which is why I assumed you were using lxc or something
<didrocks> kyrofa: I've not looked at nested lxc
<didrocks> (yet)
<didrocks> but plan to as option #1 failed
<kyrofa> didrocks, talk to elopio_, he's done it
<didrocks> and sharing images as well?
<didrocks> (would be great to not have to install snapcraft each time)
<kyrofa> didrocks, no, I think he spun one up each time
<didrocks> would be interesting to ensure we can distribute images
<didrocks> even better for people to reproduce any issue
<didrocks> let's see, I'll devote some time in looking at this
<kyrofa> didrocks, you could also use the launchpadlib from 14.04 to spin up builds in LP
<willcooke> seb128, here's what I'm seeing:  http://paste.ubuntu.com/17432569/
<kyrofa> didrocks, anyway, this is something that I want as well, so let me know if you need a hand
<kyrofa> didrocks, then I'll steal it from you
<willcooke> it's a Qt project though, so I dont understand why that is happening.  Pehaps it's normal
<didrocks> kyrofa: yeah, we need though to think about credentials :)
<seb128> willcooke, let me copy that in a /msg
<elopio_> didrocks: we abbandoned travis for more complex thing, because the docker nightmare in there was ugly. Do you want to use our jenkins?
<didrocks> kyrofa: same, on my list to see how to have Travis CI handling that correctly, I have used the LP api a lot as you can infer over years ;)
<kyrofa> didrocks, for LP? True. I figured we'd create a custom LP user, generate a token, and encrypt it in the .travis.yml
<didrocks> elopio_: we need to have the results publically available, is that possible?
<kyrofa> Yes I can imagine!
<didrocks> elopio: a lot of people in the community as access to it :)
<elopio> didrocks: we are moving to jenkaas, which will be public as I understand.
<elopio> we can start getting ready the jobs for when the last server details are ready.
<elopio> fgimenez: you said jenkaas will be public, right?
<didrocks> elopio: would be happy to be on board thus! :)
<jbicha> ev: https://paste.fedoraproject.org/380584/
<fgimenez> elopio, yes, afaik it's already accessible https://jenkins.canonical.com/ubuntu-core/
<joc_> kyrofa: yep you were correct, i don't appear to need that line now
<kyrofa> joc_, awesome :)
<kyrofa> Thank willcooke
<joc_> thaks willcooke
<joc_> or thanks
<elopio> fgimenez: you also mentioned a way to send back the results to github with the plugin, right? Or I am imagining this?
<willcooke> :)
<niemeyer> morphis: Yeah, these interfaces are sitting there for too long
<morphis> niemeyeryes
<morphis> niemeyer: you want to have a look or how are we getting those further?
<fgimenez> elopio, we can customize the commit status url and point it to $JOB_NAME/$BUILD_NUMBER/testResults, not sure if we can actually send the results to gh
<fgimenez> elopio, we can also show a line in the status with a summary of the results, iirc we had this enabled at some point..
<niemeyer> morphis: I'll have a look to see what the next steps should be
<elopio> fgimenez: ah, yes, I was imagining things.
<morphis> niemeyer: awesome!
<niemeyer> morphis: Sorry for the delay on this one.. we must not take so long to get interfaces in
<morphis> niemeyer: yes, that would be great
<willcooke> dpm, I have a Qt project which also uses gdk pixbuf.  It should be safe to add some pixbuf stuff to the wiki qt5 launch script I think.  Can you point me to where it lives to I can try some local changes first?
<dpm> willcooke, actually... there is a branch of qt5conf for those cases, it's the 'qt5conf-with-gtk' launcher as a wiki part, and its code lives here: https://github.com/dplanella/qt5conf/blob/with-gtk/qt5-launch
<willcooke> dpm, ah! Awesome! Thanks
<dpm> willcooke, it doesn't have the gdk pixbuf bits yet, but I think it's just what you need :)
<ev> jbicha: can you snap install cassandra, wait a couple of minutes, then pastebin `journalctl -b`? I think there will be more interesting output there.
<willcooke> cool, I can add them, thanks dpm
<ev> and anything else you have in logs that points at Cassandra :)
<willcooke> seb128, do you know if your gtk launcher script became a wiki part already?
<jbicha> ev: do I need to use --devmode?
<seb128> willcooke, dpm made one
<willcooke> perfect, thanks seb128 dpm
<seb128> willcooke, https://wiki.ubuntu.com/Snappy/Parts
<seb128> gtkconf
<willcooke> aha!
<aatchison> Good morning
<dpm> willcooke, note the part in the wiki points to the 'devel' branch in github, that's the right one to look at for the launcher
<willcooke> has anyone written a script to parse the depends for a deb and convert them in to yaml for copy&paste in to a snapcraft.yaml yet?
<kgunn> jdstrand: not sure if you have time, but mir interface PR is really cleaned up
<kgunn> not sure if you wanna look one more time
<aatchison> I've got my snap building again (I pushed a dependency to pypi.python.org, so no more pip flags are required,) but now I have this issue. http://paste.ubuntu.com/17433513/ Should I be setting some sort of data directory?
<aatchison> It looks like it's still trying to run site packages from my build directory
<kyrofa> aatchison, yeah it looks like the build process is writing the builddir somewhere, is that possible?
<kyrofa> aatchison, as some sort of search path, maybe
<aatchison> hmm
<aatchison> I'll keep fiddling. Here is my project if anyone would like to take a look: https://github.com/MycroftAI/snapcraft-mycroft-core
<jbicha> ev: https://paste.fedoraproject.org/380611/
<seb128> it's a bit unclear to me how the apps: section of the snapcraft.yaml works
<seb128> if I package calc, can I get a "calc: calc" command?
<ChrisWarrick> Does sna[Cp support Fedora 23?
<seb128> or does it need to be snapname.calc: ?
<seb128> didrocks, ^ do you know?
<mhall119> sergiusens: ping
<kyrofa> seb128, not sure what the confusion is
<kyrofa> seb128, are you asking about the YAML, or about how it's presented to the user after the snap is installed?
<seb128> kyrofa, both,sometime it seems renamed in /snap/bin and sometimes not
<Chipaca> seb128, if the app is named like the snap, you get to have the barename
<seb128> kyrofa, also I created a .desktop with Exec=/snap/bin/cmd
<Chipaca> seb128, that is, snap foo have two apps: foo and bar. So you get /snap/bin/foo and /snap/bin/foo.bar
<seb128> but the Exec command is missing in the /var/lib/snapd/applications version
<kyrofa> seb128, so yeah, in /snap/bin it's typically <snapname>.<appname> unless snapname == appname
<seb128> Chipaca, ah, thanks
<seb128> Chipaca, kyrofa, do you know any reason why snap would remove the Exec? it's there in the prime dir
<kyrofa> seb128, from the desktop file?
<Chipaca> ChrisWarrick, I think so? in fact i think in 23 you don't need to turn off selinux (as AIUI the thing in 24 that breaks snapd is not there in 23)
<Chipaca> ChrisWarrick, but I could be wrong! zyga knows more, but he's EOW'ed
<didrocks> seb128: this is the /create page btw :)
<didrocks> but yeah, basically if app name == snap name, it's stripped
<ChrisWarrick> Chipaca: I like not having selinux on
<seb128> didrocks, thanks
<didrocks> otherwise, it's always snap_name.app_name
<Chipaca> ChrisWarrick, tut tut :-)
<Chipaca> ChrisWarrick, then it should work fine; give it a spin!
<seb128> kyrofa, http://paste.ubuntu.com/17434418/
<Chipaca> seb128, read the docs?
<Chipaca> seb128, https://github.com/snapcore/snapd/blob/master/docs/meta.md#desktop-files
<seb128> Chipaca, which ones? http://snapcraft.io/create/ has no mention of it
<seb128> Chipaca, that goes back to my previous question, I'm in the case where cmd=snapname
<seb128> so I don't have a snap.cmd
<seb128> so I can't have a .desktop?
<Chipaca> ah, that might need clarifying
<Chipaca> seb128, Exec=<the name of the thing in /snap/bin>
<seb128> oh, ok
<Chipaca> which is, granted, problematic and needs revisiting
<seb128> why is the full path invalid?
<Chipaca> seb128, that's even more problematic
<Chipaca> seb128, what's the full path?
<seb128> Chipaca, /snap/bin/evince
<seb128> which is what I used
<Chipaca> seb128, there could be situations where the binary isn't there
<seb128> Chipaca, which is why we have TryExec
<Chipaca> bah. THe case for it not being in bin is a bad one, but it could happen
<Chipaca> more possible is that the snap is installed in somewhere other than /snap/ but we'd still put the executable it in /snap/bin
<Chipaca> seb128, seb128 tryexec is not supported and will be removed, as it says in the docs
<seb128> Chipaca, that doesn't make sense to me, but that's an argument for another day
<seb128> Chipaca, I don't want to maintain a fork of the .desktop, I just want to use the upstream one with the Exec seded
<Chipaca> seb128, and not an argument to be had with me, and not for IRC
<seb128> Chipaca, anyway, trying now with "evince" instead of "/snap/bin/evince", thanks
<Chipaca> seb128, at some point that'd have to change, but we'll let people know somehow
<seb128> k
<Chipaca> otherwise you risk it breaking
<Chipaca> that is
<Chipaca> snap names could change
<seb128> you mean the mountpoints?
<Chipaca> so if for legal reasons we suddenly have to rename evince to potato or whatever, suddenly the cmd is no longer "evince" but potato.evince
<Chipaca> but that work is way in the future still
<Chipaca> (and i doubt it'd be a problem for evince in particular!)
<seb128> yeah
<seb128> but that .desktop is generated at install time
<Chipaca> yes
<seb128> so in practice it's easy to ensure the Exec is kept in sync
<seb128> but let's discuss that on the list another day
<Chipaca> +1
<Chipaca> especially not this close to eow, and especially not this week
 * Chipaca is exhausted
<seb128> Chipaca, that works, thanks
<seb128> snap replaced evince by /snap/bin/evince for me
<seb128> which is a bit ironic :p
<seb128> when I did that myself it removed the key
<seb128> also something should probably display a warning in that case
<Chipaca> seb128, snap is unionized
<Chipaca> seb128, you tried to do its job!
<seb128> like "exec cmd invalid and removed"
<seb128> do you know what component I should open that bug against?
<seb128> snapcraft? snappy?
<Chipaca> that's snapd itself
<seb128> snapcraft could warn about the invalid syntax
<Chipaca> certainly
<Chipaca> in fact snapcraft could help a lot with writing the .desktop
<Chipaca> (i thought it did)
<seb128> that's the discussion to have on the list :p
<seb128> imho it should automatically use upstream ones when available
<seb128> seding the Exec and Icon if needed
<pandaadb> Hi - Am I right that snaps are not supposed to share any resources? E.g. with lots of products you'll need things like java installed.
<pandaadb> Would you just package a new java lib into each snap?
<pandaadb> Or would one rather have a java snap which uses slots (I think that's right) to expose a java interface for others to use?
<pandaadb> Or is there a plan to have very common libraries integrated in the framework? Like python and such?
<willcooke> seb128, dpm - that pixbuf stuff has stopped the errors
<willcooke> thanks!
<seb128> great
<seb128> yw!
<willcooke> dpm, just created a PR - but lemme test one more time...
<ev> jbicha: sorry for the delayed reply. The problem, I think, is that you donât have the mount-observe interface connected, e.g.
<ev> snap connect cassandra:mount-observe ubuntu-core:mount-observe
<ev> but really the problem is that we put Cassandra in the GUI where it wouldnât be obvious that you need to manually connect up that interface
<dpm> willcooke, awesome. I'm heads down with an e-mail, but I'll merge your PR in a bit, thanks!
<ev> apologies there to willcooke, seb128, and attente
<willcooke> dpm, no hurry
<willcooke> ev, we didn't land that bit yet, so I think we're ok :)
<seb128> I think jbicha did beta test the candidate version
<willcooke> ahh
<ev> jbicha: if youâre curious, mount-observe needs to be manually connected in a confined snap because we want you to explicitly acknowledge letting the snap see your mountpoints
<ev> also, I believe snaps are going to grow hooks that fire once an interface is connected. This would let us sleep cassandra until that interface connection dependency was satisfied
<gouchi_> hi
<gouchi_> is it necessary to provide drirc ?
<ev> sergiusens, elopio: looks like weâre good to land https://github.com/ubuntu-core/snapcraft/pull/578 ?
<elopio> ev: done.
<ev> star, thank you!
<elopio> thanks to you.
<kyrofa> elopio, are we running any of snapcraft CI on other archs yet?
<elopio> kyrofa: I can trigger them. They are not run automatically yet.
<elopio> kyrofa: want me to check something?
<kyrofa> elopio, no, but this ldd crawling thing is very architecture-dependent... I'm nervous playing with it
<elopio> kyrofa: you can trigger a run yourself: http://jenkins.elopio.net:8080/job/github-snapcraft-autopkgtest-cloud/build?delay=0sec
<kyrofa> elopio, and they actually pass?
<elopio> kyrofa: I'm having one example failing in i386. I haven't seen the rest yet.
<elopio> they should pass, mostly :)
<elopio> kyrofa: use bos01 as the region, and the available architectures are ppc64el, arm64, amd64 and i386
<kyrofa> elopio, alright, thanks :)
<elopio> kyrofa: I can also give you access to those slaves, so you can start a machine and ssh into it.
<kyrofa> elopio, ah, I may take you up on that once I have a good test case
<kyrofa> Messing with this makes me miss C++
<g_> hello
<elopio> kyrofa: what about getting crazy today and skipping the stand up?
<kyrofa> elopio, haha, sure
<g_> hey guys
<g_> i have a question about using snappy to run services
<kyrofa> g_, hey there! Sure, what's up?
<g_> so i currently have a suite of programs that i build a single deb to install
<niemeyer> jdstrand: Spread rev 6 up for review, for when you have a spare moment
<g_> they are made for ubuntu 12.04 and i made upstart scripts for each of them
<niemeyer> jdstrand: Any idea of when we'll get home auto-approved?
<g_> i saw that snappy has its own daemon starting system
<g_> how does that work?
<g_> what sort of flexibility does it have for starting after dependent services
<g_> it seems pretty simplified from the documentation ive seen at snapcraft
<g_> ideally i could build a snap which the user could configure which services to start since one of them would want to be disabled most of the time
<g_> also work across different distros
<swartzr> Are there any permission sets for snaps that allow accessing mounted devices?
<Chipaca> g_, that sounds tricky to do
<Chipaca> g_, as you say, it's pretty simplified
<Chipaca> swartzr, I *think* that's still TBD but should be coming in the next week or thereabouts (but I could've misunderstood what zyga was going to work on next, as i missed the standup today)
<Chipaca> swartzr, there are two separate things, one about giving a snap a directory, and another about giving a snap a device
<Chipaca> swartzr, I don't think I've seen something about giving a snap a "mounted device"
<Chipaca> swartzr, not sure how that's different from the other two
<swartzr> Chipaca Well the device is already mounted so the directory would work
<Chipaca> phew :-)
<swartzr> Chipaca thanks for the info. Looks like I'll have come back to it in a while when that feature gets added.
<Chipaca> swartzr, or get it working in devmode and add the interface and drop devmode when it's ready
<Chipaca> that's what devmode is for, fwiw
<swartzr> Chipaca yes!! that would work beautifully. It is an internal business app so devmode is really not a problem
<Chipaca> swartzr, next week's release would also enable getting devmode snaps from the store
<Chipaca> right now you can publish devmode snaps, but snapd doesn't know how to get them
<Chipaca> (as the store doesn't hand them out unless asked explicitly)
<Chipaca> they also don't appear in searches
<swartzr> Chipaca maybe I'll publish it to the store it could be useful to others. Probably will open source it also.
<Chipaca> \o/
<Chipaca> swartzr, note that a devmode snap can't be in a "stable" channel
<Chipaca> just beta and edge
<Chipaca> but that shouldn't stop you :-)
<tianon> are there any more detailed docs about getting 16-series snaps secured appropriately?  I've been messing with plugs, but I'm working on an updated "docker" snap so it's likely going to require a custom apparmor/seccomp profile anyhow (current old-style snap even allows switching to/from "privileged" mode/profiles via an included script), but I can't seem to find anything substantial about how to do thâ¦
<tianon> â¦at properly (because using "old-security" seems like the wrong approach) so any pointers would be very appreciated (even if they have to be pointers to parsing code or something) :)
<kyrofa> g_, indeed, as you rightly pointed out the service system is very simple
<kyrofa> g_ you kinda need to synchronize them manually I'm afraid
<swartzr> Thanks for the help Chipaca. Looking forward to snappy's future.
<swartzr> really impressed by how easy it is to create a snap
<Chipaca> tianon, augh, this might be a bad time to take a poke at properly confining docker-style services
<tianon> lol
<Chipaca> tianon, we know what we have to do, but we're not there yet
<tianon> yeah, that's the sense I'm getting while reading docs, etc
<Chipaca> tianon, I'm a bit far from the people doing that work (and it's friday and i've already popped open a beer and dinner is in the oven, so grains of salt), but
<Chipaca> tianon, basically we want to have something like a vm-manager interface
<Chipaca> when i last followed this discussion it wasn't clear whether that was generalisable or whether it'd have to be a docker interface
<Chipaca> which would be worse, but perhaps more practical
<Chipaca> worse because then any other vm manager would need their own chunk of work
<Chipaca> but such is the nature of this
<tianon> yeah, that's fair
<Chipaca> tianon, jamiebennett might know more, but he's in the same tz as i am
<Chipaca> tianon, so if he hasn't kicked back for the weekend i want to know why
<tianon> would it be possible to hack something together in the interim with a custom plug or something?  (hopefully I'm not too horribly misunderstanding too many snap concepts O:) )
<Chipaca> also the sun is out, which is rare
<tianon> :D
<tianon> crap, have to go, but appreciate your time <3  (and will idle, so feel free to leave me novels)
<Chipaca> tianon, interfaces are written (described?) in go, so the hackage would be very similar to the actual work
<Chipaca> tianon, devmode devmode devmode
<tianon> ah
<tianon> yeah
<tianon> was afraid of that
<tianon> thanks :)
<Chipaca> tianon, also, mailing list
<Chipaca> helps us prioritize things if we see the demand
<Chipaca> (irc doesn't bring too much visibility to demand, just to firefighting)
<Chipaca> smells like dinner is ready
 * Chipaca out
<johnsno> Hi, any plans or existing forks of snapd for OS X ? Windows ?
<jamiebennett> johnsno: No plans but we do welcome patches ;-)
<jamiebennett> johnsno: In all fairness, Ubuntu runs on Windows 10 so it is not beyond the realms of possibility
<jamiebennett> johnsno: macOS would definitely be interesting
<jbicha> ev: thanks for looking into it
<jbicha> yes I was just beta-testing, I don't actually know anything about cassandra, I was just clicking buttons :)
<ali1234> any plans to make that win10 stuff use snappy core rather than just being a regular filesystem?
<jbicha> it's still 'broken' from the cli, in that 'snap install' doesn't run that other cmd or ask the user to run it either
<jbicha> sleeping would at least be better than 100% cpu
<jamiebennett> ali1234: again, at this time no but anythings possible
<ali1234> it seems logical... i mean is it even possible to dist-upgrade the win10 image?
<kyrofa> elopio, https://github.com/ubuntu-core/snapcraft/pull/580 is ready for a look
<jamiebennett> kirkland knows more than I on this, I've not really played with the Ubuntu on Win 10 stuff yet. Its really cool so definitely something on my todo list.
<johnsno> jamiebennett: Ok thank you, I will try to work on macOS support on my free time
<jamiebennett> johnsno: That would be awesome, please let me know how you get on
<gouchi> what is a snapcraft option to rebuild the snap package if I just modified snapcraft.yaml or my wrapper ?
<gouchi> because I tried snapcraft prime && snapcraft snap it doesn't take my modification
<gouchi> everytime I need to do snapcraft clean && snapcraft build
<kyrofa> gouchi, you can clean individual steps with `snapcraft clean -s <step>` or just clean the whole thing
<gouchi> oh ok I will try this thank you
<kyrofa> gouchi, which part of the YAML did you change?
<ev> jbicha: sure thing, and if you find anything else odd with the Jenkins or Cassandra snaps, do let me know :)
<bull> hello guys :)
<gouchi> now it ok for the yaml
<gouchi> I need to tweak my wrapper
<bull> why snapcarft will not pull stage and prime new stuffs if we updated entries in snapcraft file after a build ???
<bull> kyrofa, hi ,
<bull> anyone know how to force snapcraft pull to check if files was modified and it have to pull  new enteirs ???
<bull> i update my snapcraft file and do snapcraft pull and it says already ran as of now , is there a way to do force pull recheck snapcraft entries and do pull for new stuffs ??
<kyrofa> bull, you need to clean the pull step
<bull> doing snapcraft clean everytime after editing snapcraft.yaml file and redo everything from scratch looks stupid
<bull> kyrofa,  is it a bug ???
<bull> or i have to fire a new in launchpad ??
<kyrofa> bull, you're telling it to pull new and potentially different stuff than what you previously told it. The way it currently makes sure it does what you need is blowing away what was there before and grabbing what you asked for
<bull> also stage will not stage new entries after updating entries in yaml file
<bull> kyrofa, you not getting me , am saying if i added some new libs to yaml file under parts , why pull will not know tthat i added new stuff there just download new stuff and add it to part dir
<bull> why anyone will have to download all the downloaded packages and stuffs that he downloaded before ?? just if he adds something new
<kyrofa> bull, you're saying you added brand new parts and snapcraft didn't notice them?
<bull> am saying i added new libs under stage-packages and snapcraft did not noticed them
<kyrofa> bull, yes, that's a bug
<bull> why it need clean everything ?? if added a new entry ?? this is my question , as a normal user am asking this question , this makes me hate snapcraft thousands of people gonna test it , and am sure 500 will notice this !!
<kyrofa> bull... we talked about this yesterday, and you already logged a bug for it
<bull> my bug was about cleaning downloaded packages after hitting clean command
<bull> this is soething different
<kyrofa> bull, that's exactly what this is. In order to make sure it fetches the stage packages you updated, it removes the ones that were there already
<bull> kyrofa, fox example take our normal ubuntu system , if i added something new in source file , to get some new stuffs , will apt clean my older packages ??? before i issue apt-get update ??
<bull> what apt do is get the new updates and merge it into older one and allow you download new content
<bull>  am just comparing the methodology am not saying make it apt :D , apt work very efficiently and the reason is its methodology
<bull> snapcraft looks much like doing stupid things in this case !!!
<bull> i hope you will pass these as a feedback snapcraft is new project and am providing these suggestion to make it better and sensible to users , cause am in social media hate someone criticize ubuntu and its technologies :) like a guy was talking crap about snapcraft - like 1.1gb libreoffice and shit
<jcastro> bull: the openoffice snap is like 280 megs, not 1.1gb
<ali1234> jcastro: only after everyone complained :)
<bull> am not ceo of ubuntu or canonical and not forcing these changes - make snapcraft simple and sensible , people not gonna accept it like am not yet happy with its progress , people do not see what and how hard you guys are working in back , what they see is how they will have their application run on your platform , so they will drop snapcarft and snap at the first when they will spend their whole day making their app to run on ubuntu , for example my application y
<bull> esterday i spend my whole day packaging my app which runs fine with normal debian packaging , after successfully packing it into snap it wont run and end up with segmentation faults etc i did all logical things and what i got at end is i spend my whole day packaging an app which still dont runs cause it is packed in snap  format
<bull> ali1234, your are right , i read an article about it on a famous website where thousands of linux and ubuntu users visit everyday , i was talking about the same
<swartzr> I'm snapping a python app but can't for the life of me figure out how to use a requirements file that is in my source tree. Can anyone help?
<swartzr> I added requirements: requirements.txt but snappy doesn't pick it up
<bull> simply , since we are dealing with dependencies within our packages and we are writing them in snapcraft.yaml we shpuld be able to change them anytime without dealing with what snapcraft is thinking about them we have to make snapcraft work like that ,
<bull> kyrofa, i hope you will be noticing all this , am not a member of your team but consider me as a good tester :) m big fan of snapcraft but i would love to make it simple and sensible
<hguant> quick question - is there a good resource for creating custom plugins?
<tianon> Chipaca: ah, totally makes sense; thanks so much :)
<Chipaca> hguant, not sure if kyrofa is still around for that one
<Chipaca> hguant, but either him or sergiusens are the people who might be able to point you in the best direction to look
<bull> kyrofa, i filed a bug about that issue , please read it here , is that okay ??? https://bugs.launchpad.net/snapcraft/+bug/1593868
<ubottu> Launchpad bug 1593868 in Snapcraft " snapcarft will not pull, stage and prime new stuffs i added to snapcarft.yaml file after a build " [Undecided,Confirmed]
<hguant> Chipaca no worries - is there a mailing list I can ask in, or should I just lurk 'round here till one of them is on?
<Chipaca> hguant, snapcraft@lists.ubuntu.com
<hguant> Chipaca thanks!
<Chipaca> hguant, https://lists.ubuntu.com/mailman/listinfo/snapcraft
<Chipaca> yw!
<bull> Chipaca, hi
<Chipaca> bull, hi
<bull> i just files a bug against snapcraft on launchpad , as a user of snapcraft do you think my writing is worth ??? https://bugs.launchpad.net/snapcraft/+bug/1593868
<ubottu> Launchpad bug 1593868 in Snapcraft " snapcarft will not pull, stage and prime new stuffs i added to snapcarft.yaml file after a build " [Undecided,Confirmed]
<Chipaca> bull, i'll let the snapcraft devs dig into that one
<bull> ty Chipaca
<Chipaca> i'm not sure you're saying snapcraft should cache the old things it downloaded, or track the difference between edits
<Chipaca> in either case, it sounds hard :-)
<bull> it should not be hard , am just saying - snapcraft should download the new libs and do stage prime again
<bull> instead of cleaning everything , and doing things from scratch
<Chipaca> bull, and if the libs have interdependencies, such that the presence of libX modifies the way libY builds?
<bull> also snapcraft should not delete the downloaded items by apt , deleting those debs and downloading them again make no sense :D
<bull> Chipaca, thats why am saying it  should stage and prime again
<Chipaca> bull, just in case you forget, i don't dev snapcraft
<Chipaca> however
<Chipaca> caching debs is the job of apt-cacher-ng or whatever the cool kids use these day
<bull> i dont know why developers didn't caught it lol
<Chipaca> not sure we want to duplicate that particular effort
<bull> Chipaca, currently i dont think snapcraft is a good packaging tool :P
<bull> you cant do nothing with that ??
<Chipaca> bull, you're entitled to that opinion
<bull> lol
<bull> developers have to deal with guys like me so that they ca fix the bugs :D
<jcastro> is there a clean way to not have snaps show up in tools like df? It's manageable now but the list keeps getting bigger every day
<bull> jcastro, df you mean by tool which report file system disk space usage
<jcastro> yes
<bull> why you wana hide snaps from df ?? if am not getting you wrong
<Chipaca> jcastro, does âdf -h | awk '$6!~/^.snap/{print}'â count?
<jcastro> yeah I was digging around the manpage for something that just will whole hog filter out /dev/loop things
<bull> damn :/
<Chipaca> jcastro, or âdf -hT |grep -v squashâ
<bull> will one of you will brief me what you guys doing ??
<bull> Chipaca, help me :3
<Chipaca> bull, with what?
<bull> why jcastro wana hide snaps from df??
<bull> just for knowledge
<Chipaca> bull, because he's installed 200 snaps?
<jcastro> http://paste.ubuntu.com/17451287/
<Chipaca> bull, or he's obsessively punctilious
<jcastro> not quite 200, but at this rate ...
<Chipaca> yeh
<bull> wow :D
<Chipaca> jcastro, I don't think we want to patch df :-) but maybe skipping squashfs with grep is good enough
<jcastro> yeah, at first that seemed like a good idea but then I thought it through
<bull> jcastro, those /dev/loops are snaps ??
<Chipaca> jcastro, yes
<Chipaca> um
<Chipaca> bull, yes
<bull> :)
<bull> Chipaca, i will make my qt application opensource tonight , what license should be good if i don't want people to repblish it without asking me or make money from my work .?? thanks
<Chipaca> bull, you can't make it opensource and not make it opensource
<bull> why ?? i will publish it to github ,
<Chipaca> bull, if it's opensource, people can republish it
<Chipaca> that's kinda how it works
<bull> i wana allow users to learn from it but i dont want anyone to republish it , so that he/she can make money from it  by remob=ving my rights
<bull> okay i let them republish it , but how can i stop someone from removing my rights from the code :/ is there any such opensource license ??
<Chipaca> bull, what do you mean by "removing your rights from the code"?
<bull> Chipaca, that i am the author of that code
<bull> :(]
<Chipaca> bull, that is an unalienable right
<Chipaca> :-)
<bull> i should not use any license then :???
<Chipaca> bull, so if people remove you as author, they'll be committing a crime of some sort? or doing something bad. i'm not a lawyer.
<Chipaca> also if you wrote the code in your own time, you have copyright over the code
<bull> its getting offtopic here , sorry guys i have to stop it now
<bull> i wrote code myself :D
<Chipaca> so any floss license preserves those things
<bull> gpl 3 ??
<Chipaca> bull, my recommendation would be that you do your research and don't just decide based on what somebody tells you
<bull> you are a goof friend :* thanks for help
<Chipaca> bull, http://choosealicense.com/ might be a good place to start
<bull> i was snapping that app but after snapping it show unreliable output wheni run it
<bull> ty :) Chipaca
<Chipaca> i'm off for the weekend
<Chipaca> o/
<bull> i choosed gpl3
<bull> Chipaca, can i find you here , when i wana talk to you ?? i will not always seeking help from you i just want you as a friend :P
<bull> Chipaca, :/
<mhall119> bull: what's going on with your snap?
<bull> mhall119,  hi :)
<bull> its not working like yesterday
<mhall119> where's it stopping today?
<bull> so am putting my code in repo so someone can build snap for it :P
<mhall119> ok
<palasso> bull: check this out as well https://tldrlegal.com/
<bull> no network or x11 issues today
<mhall119> (no network) issues
<mhall119> or no (network issues)
<mhall119> ? :)
<bull> mhall119,  qt was reporting network issues yesterday
<mhall119> but that's fixed now?
<bull> palasso, thanks :)
<bull> mhall119, yes it is fixed
<bull> am keeping all these bugs in mind so i will help someone if he/she faces same :)
<bull> mhall119, am publishing the code
<bull> under gpl3 license :D
<bull> mhall119,  you there ?
<mhall119> bull: yeah, end of day already and getting ready for dinner though
<bull> i uploaded it here https://github.com/keshavbhatt/Deskie
<bull> i want your help creating snap for it please :(
<bull> desktop icon also not detected automatically :/ idk whats wrong with it
<bull> i will create a new branch there to where i will make snap recipe  for deskie please contribute there ...
<sgclark> you have to put the icon in setup/gui atm. I am working on a way to automate that, I have desktop files working ( automated )
<sgclark> and it has to have the name of icon.png
<bull> sgclark, will you give me a pastebin of your example .desktop file so i can see the icon entry in it??
<bull> as i already having the same setup still it dont work mean i need mosify something in .desktop
<sgclark> oh. I see. in that case no most kde apps are also missing that entry, I have a pile of bug reports to file when I get home...
<bull> okay sgclark
<sgclark> which is why my automation for icons is broken :)
<bull> good night guys feeling sleepy :( i have uploaded the first snapshot og deskie here https://github.com/keshavbhatt/Deskie
<bull> there is a new branch fo snapping the application
#snappy 2016-06-18
<nhaines> Hey, is there any documentation for building snaps on Launchpad?  I can't seem to find specifics, and someone was asking in /r/Ubuntu.
<jdstrand> tianon: regarding docker snap-- you need to create an interface for docker. talk to me next week (I'm traveling this weekend and will be back to work on tuesday) and I'll advise
<jdstrand> niemeyer1: re home autoapprove. I started that work but had testsuite issues in snapd. I asked for some help but didn't get it at the time and then the sprint got in the way. I will be driving that next week
<jdstrand> niemeyer1: spread approved
<vasa1> Trying out the 287MiB version of LibreOffice5.2beta. It appears that File, Open doesn't see files on other partitions *if* the distro is Lubuntu 16.04 or Xubuntu 16.04.
<vasa1> No issues with Unity on 16.04.
<vasa1> Reported here: http://ubuntuforums.org/showthread.php?t=2327088&p=13505534#post13505534 and following posts
<sgclark> I find it very funny that many folks in KDE are getting invitations to a hackfest, except the actual person working on snappy, who do I bug to get such an invitation?
<pikor> Hi. Can we have a private repository for snap ? Any doc about that ?
<jamiebennett> sgclark: Feel free to drop me an email at jamie.bennett@canonical.com with the details
<croepha>  i think im missing somethign basic here, im getting a tar: ./usr/bin/cpp-5: Cannot change ownership to uid 0, gid 0: Operation not permitted on snapcraft stage, but im just using the ubuntu provided g++ package...
<sgclark> jamiebennett: sorry what details?
<jamiebennett> 12:42 sgclark: I find it very funny that many folks in KDE are getting invitations to a hackfest, except the actual person working on snappy, who do I bug to get such an invitation?
<jamiebennett> Lets talk about it over email, got to run now
<sgclark> yeah I said that. I am still unclear what details you want :(
<sgclark> ok
<croepha> so, im just trying to get started with one of the demo snapcraft.yaml files, so basically copied https://github.com/ubuntu-core/snapcraft/blob/master/demos/py3-project/snapcraft.yaml and when I try to do `snapcraft stage` i get errors like `tar: ./usr/bin/pybuild: Cannot utime: Operation not permitted` any ideas what im doing wrong?
<palasso> sgclark: hey I was wondering are the snapcrafts you made in some repo?
<palasso> I mean publicly accessed source repo
<sgclark> https://github.com/snappy-packages
<palasso> tyvm
<jcastro> wow sgclark, that's a lot!
<sgclark> will be more coming soon, traveling home this weekend.
<sgclark> I am also writing automation scripts to make it even faster.
<palasso> sgclark: haven't looked at them, I'm wondering is there a way to make kde frameworks be shared somehow or is everything bundled? I haven't read it all in regards to snapcrafting and although I think there was some feature called frameworks I think it's deprecated, so how it's going?
<sgclark> not atm. I am told they will support using other snaps libraries in snaps soon. So for now I am only building deb based snaps until they make it so.
<palasso> ahh ok ty
<sgclark> because snapcraft exploded when I tried to make 50 parts for the framework dependency chain.
<sgclark> it was spectacular
<palasso> lol
<ali1234> does the all-snap image work on raspberry pi 3 yet?
<falsecam> hi guys, I have some troubles packagaging an app including a library. I'm not shure if the library cannot be found because of wrong working directory or if there is another error. I always get only the output "Bad system call"
<falsecam> here is my snapcraft.yaml file http://pastebin.com/pk5pzsfT maybe someone has an idea.
<falsecam> if i run SNAP=/snap/lenna/x1/ /snap/lenna/x1/command-lenna.wrapper then everything works
<falsecam> maybe someone has a hint for me? thank you
#snappy 2016-06-19
<ayan> i'm working on a snap with an executable that calls seccomp().  app armor (i think) blocks it even though the snap was built using 'devmode' confinement.
<ayan> (really it is tor-browser.)
<ayan> https://git.launchpad.net/~ayan/+git/tor-browser-snap/tree/snapcraft.yaml
<ayan> also tor-browser has pretty restrictive file permissions.  i wrote a simple plugin to walk the staged directly and fix the permissoins before creating the snap.  i'm not sure if this is the best way to do it:
<ayan> https://git.launchpad.net/~ayan/+git/tor-browser-snap/tree/parts/plugins/x-tor-browser.py
<Shibe> will X be bundled with each DEs snap?
<Chipaca> sgclark: what hackfest?
<Chipaca> sgclark: ah, jamie already responded :-)
 * Chipaca still doesn't know what hackfest
<Chipaca> croepha: what filesystem are you doing the build on?
<Chipaca> ali1234: you can try the all-snap images, but I don't know if we expect them to work yet
<Chipaca> ayan: I'd suggest bringing that up on the mailing list (as it'll require input from people that aren't here today)
<Chipaca> Shibe: I doubt X will be bundled in snaps. I also doubt a DE will have a snap. But who knows? we'll see where people take it!
<Shibe> Chipaca: how else will DEs be installed in a snappy system?
<Chipaca> Shibe: in an all-snap system, that's a very good question and one that has been on my mind before
<Chipaca> Shibe: all-snap systems are more aimed at IoT-kind of places though, at least until we make snappy rich enough to support things like DEs
<Shibe> Chipaca: another thing is, what about dconf? I know that gtk apps use dconf for certain things and also for seeing what gtk theme to use
<Chipaca> IoT and servers, i should add
<Shibe> will you have to theme gtk on a per-app basis?
<Chipaca> that is, ~single-purpose systems
<Chipaca> Shibe: a related question: how do you snap a theme?
<Shibe> yeah
<Shibe> that is indeed a good question
<ali1234> another related question is how do you snap development tools?
<Chipaca> these are nice juicy questions
<ali1234> currently you need a chroot to do any kind of serious development
<Chipaca> ali1234: you do?
<ali1234> yes
<ali1234> there is no snap containing snapcraft
<Chipaca> ali1234: in an all-snap system, i presume?
<ali1234> yes
<Chipaca> ali1234: right
<Chipaca> we need to circle back to all-snap systems soonish, to shore up that side of the store
<ali1234> all-snap systems are the only type of system worth considering, because if you don't have an all-snap system, you don't need snaps to begin with
<Shibe> also btw, how was the size of libreoffice snap reduced from 1.1gb to the regular 200?
<ali1234> Shibe: by removing debug symbols
<Chipaca> ali1234: well... I disagree, but I can also see why you'd think that
<Shibe> ali1234: debug symbols were consisting of that 1.1gb?
<ali1234> Chipaca: there's this idea of using snaps to let upstream ship packages themselves whenever they want. this specifically is in my opinion a recipe for disaster if it is done on a regular "as it is now" ubuntu
<Chipaca> Shibe: the libreoffice snap that was talked about a lot was built for testing the whole thing and included debug symbols to figure out what went wrong when it did
<Shibe> ok
<Chipaca> Shibe: the person has since renamed that to libreoffice-debug and built the debug-less libreoffice at 200M
<Shibe> well that's nice
<ali1234> Chipaca: i've even heard people saying that for example, nvidia could distribute their drivers in a snap...
<Chipaca> ali1234: why is it a recipe for disaster?
<Shibe> btw will each app bundle mesa individually?
<Shibe> I think in flatpak the application recieves the raw device node (/dev/nvidia-uvm on nvidia i think) and the application includes the libgl/mesa
<Chipaca> I've got to go, I'll read up when I get back
<Chipaca> o/
<ali1234> Chipaca: i's a recipe for disaster because it necessitates including dependencies inside the snaps
<ali1234> that is a problem which you can ignore as long as snaps don't compose the base system
<ali1234> but for all-snap you basically have no choice but to deal with it
<ali1234> hence, my worry is that all-snap will be sidelined because it's too hard, and instead we just get a poor compromise that doesn't actually improve things at all
<ali1234> to put it another way: "snaps on a classic desktop" is a bit of a cop out, in my opinion
<ali1234> i mean sure it's a stepping stone, don't get me wrong... but snap has to go beyond that
<ogra_> it is just an additional playground, thats all ... the plans for all snap images in IoT havent changed ... nor has the idea of providing phone and pocket-desktop images
<notadrop> hello
<ogra_> not sure where you expect the compromise to be
<ali1234> i don't expect compromise... i want an all-snap system to be able to do literally everything tht ubuntu can do today
<ali1234> without having to install "ubuntu classic" in a chroot
<ali1234> because then all you've done is moved the problem
<ogra_> it will probably not behave exactly like a classic system ... but you will eventually be able to do all you want
<ali1234> it doesn't have to be exactly like it, it just has to do the same things with the same amount of effort :)
<ogra_> things in a new world might be done differently, but stil provide your desirent behaviour
<ogra_> or results rather
<ali1234> and the same amount of disk space? ;)
<ogra_> it will  just take a little more time for specific bits
<ogra_> why not
<ali1234> "why not" -> because developers are lazy :)
<ogra_> who knows, probably we might get to a point where they even need less diskspace ... snappy is still very young (compared to 20+ years of deb), i dont see why such improvements shouldnt come in the future
<ali1234> 20+ years is too long to wait
<ogra_> first of all all basics should be done right ...
<ogra_> i didnt say it has to take that long :)
<ogra_> just that debs had this time to mature
<ali1234> in 20 years people will be complaining that snap is out of date and no good and trying to rewrite it
<ogra_> cool :=
<ogra_> :)
<ogra_> (that means it will still be around ;) )
<ali1234> that's best case :)
<ogra_> nah, best case is that iin 20 years people will still like snaps because they evloved in the right direction
<ali1234> although i feel like if snap just becomes another way to package things for regular ubuntu then it wont be around in 20 years... flatpak will win
<ogra_> but the replace in 20 years case is a good one nontheless ;)
<ogra_> let the upstreams decide ...
<ali1234> you know which one they will choose
<ogra_> i see which one they choose today
<ali1234> upstreams wont decide it, all the other distros will
<ogra_> ??
<ogra_> you mean they would denny opensource code in their distro ?
<ali1234> no
<ogra_> so how will thhey decide anything
<ali1234> debian does not deny upstart code in their distro?
<ali1234> yet still nobody uses it
<ogra_> if snaps are the way an upstream provides hiw stuff and the distro has snap support (even if you need to install it) ... then you will enable it
<ogra_> *his
<ali1234> if all distros support both, but flatpak works significantly better due to being what the distro itself chooses to ship a majority of packages, then upstreams will choose it too
<ogra_> distros are the least bits her that have any influence as long as they dont block snappy to enter their system ... upstreams count
<ogra_> if all uppstreams would decide to all go appimage ... what would you think distros would support
<ali1234> upstreams will choose whatever is best supported
<ogra_> and i'm only talking about the app delivery here ... they will indeed still use whatever base system they want
<ogra_> right ...
<ogra_> and we're at a point where multiple systems exist
<ogra_> lets just see what upstreams will chose
<ali1234> upstreams will wait to see what distros choose
<ali1234> basically, if distros do not convert to something like all-snap, then upstreams will continue to not use anything
<ali1234> afaik flatpak and appimage can't do all-snap?
<ogra_> why would any distro go to all-snap
<ogra_> not even ubuntu will
<ali1234> that's a problem
<ogra_> all-snap is for special use-cases
<ogra_> ubuntu wont drop traditional deb based installs
<ali1234> a distro would go all snap only for one reason: because it is an improvement over the current way of making a distro
<ogra_> heh
<ali1234> but of course you have to make that be true first
<ogra_> i rather think a distro will simply throw out all toplevel apps and will start focusing and improving their work on core ... simply because it frees manppower
<ali1234> if that doesn't happen then distros won't do it, and upstreams will just containue shipping tarballs and crappy binaries
<ali1234> yes, exactly
<ogra_> (why woould a distro care about gimp or libreoffice if upistream already provides a proper way to get it )
<ogra_> so in the end it improves life of everyone ...
<ali1234> why would a distro care about gcc if upstream provides a proper way to get it?
<ogra_> because their existing packaging system requires them to have gcc in their distro
<ali1234> answer: because as distro maintainers they actually need to use it
<ogra_> yes, and there are existing established mechanisms to do so to build a distro
<ali1234> so it boils down to: which next gen package system supports development tools best?
<ali1234> and currently the answer is none of them
<ogra_> huh
<ogra_> snapcraft is well supported :)
<ogra_> and it fulfills my needs as a developer
<ali1234> oh, there is a snap containing snapcraft?
<ogra_> nope
<ali1234> well then
<ogra_> there will likely be one (thats trivial)
<ogra_> but thats not the point
<ali1234> can i make an ubuntu builder using all-snap?
<ali1234> what about a launchpad snap?
<ogra_> you have to ask the launchpad people if they plan to snap it ... else ... feel free to go ahead
<ali1234> these are the kind of things distro maintainers will want
<ogra_> sure
<ali1234> if you don't give them this, they won't care about supporting snap well enough that upstreams will want to use it
<ogra_> i dont see why they couldnt get it
<ali1234> i hope they will be able to in the future
<ogra_> if someone asks ... or if someone even sends code for this, it will happen
<ali1234> they're not going to write it themselves
<ali1234> developers are lazy remember?
<ogra_> havent said that :)
<ali1234> no, i did
<ali1234> distros won't accept it unless it is spoon fed to them
<ogra_> the point is that the demand needs to be expressed ... which happpens via whishlist bugs usually :)
<ogra_> and these get fixed at some point
<ogra_> and again, i dont see why distros would need it
<ali1234> that's not the point
<ogra_> snap is not there to replace distros
<ali1234> it should be
<ali1234> because distros suck
<ali1234> distros dont need to do anything
<ali1234> distros didn't need systemd, they chose it because it made their life easier
<ogra_> sure
<ali1234> imagine the average guy packaging software for debian
<ali1234> how does snap make their life easier?
<ogra_> why does he package for debian
<ogra_> and what
<ogra_> i dont see why a systemd debian packager would care for snap
<ali1234> not systemd
<ogra_> but i also dont see the need for a gimp package in debian if upstream already provides a snap and debian has snap support available
<ali1234> let's take as an example gcc... or maybe clang
<ogra_> yeah, they are components snapcraft uses when you roll your package :)
<ali1234> okay
<ali1234> so as the clang packager for debian, how does making sure my package works correctly with snapcraft make my life easier?
<ogra_> and will still be available through distro channels, since the distro itself needs them to build the distro
<ogra_> why would you do that ?
<ali1234> yes, that is what i am asking
<ogra_> the snapcraft maintainers will
<ali1234> who are the snapcraft maintainers?
<ogra_> if someone uses a snap with clang and hits a bug, he will file it and either the snapcraft maintainers or the person with the problem will eventually write code to fix it
<ogra_> as clang upstream you simply have to accept the patches
<ali1234> or you know.. they will just use flatpak instead
<ogra_> what for
<ali1234> instead of snap
<ali1234> or they mght just not bother at all
<ogra_> why would you package a complier in an app delivery system instread of the build tool for the app delivery system
<ali1234> because a compiler is an app?
<ogra_> (i dont see why it wouldnt be possible to snap up gcc or clang, i just dont see the benefit of it)
<ali1234> if you can't see the benefit of it, then why do you expect anyone else to?
<ogra_> ?
<ogra_> i dont ?
<ali1234> and if you don't expect anyone else to see the benefit, why do you expect anyone to use snap at all?
<ogra_> i think snapping compilers is pointless ...
<ogra_> you are the one who claims it isnt :)
<ali1234> okay, where do you draw the line?
<ali1234> what about secondary build tools like make or cmake?
<ogra_> at the level where the distro doesnt provide the bits to build itself
<ali1234> ultimately my point is that "next generation packaging tool" will require support from *everyone* to be successful. it won't get that support unless it offers something to everyone it needs support from
<ogra_> what i can imagine is that you eventually have tool bundles ... like "qt-build-env" that comes with all tools you need in a snap and offers you a high level way to work on your project ... more like sdks than single tools
<ali1234> that would be an excellent step along the way
<ali1234> and already a massive improvement over what we have now for a large number of people
<ogra_> right ... i dont see that gcc standalone would make much sense ... but in context of such a bundle it would be one tool that would be used in the process
<ali1234> installing an ubuntu-sdk snap would sure be nicere than an ubuntu-sdk chroot
<ogra_> thats an implementation detail
<ali1234> gcc standalone would make sense... there are plenty of use-cases where you dont need anything else
<ali1234> like developing for arm microcontrollers for example
<ali1234> i guess you might include a tiny libc in that too
<ali1234> so like avr-gcc/avr-libc
<ogra_> you could have a snap that mounts your project dir inside an lxd container and execs the build process there when you issue the build command ... all you as developer should care about is that you can work on your code and issue a command to build or debug the code ...
<ali1234> i regularly use binutils standalone too... since it has a decompiler
<ali1234> and strace
<ogra_> or it could be a chroot ... or a cloud instance or whatever :)
<ali1234> but here is the thing
<ali1234> having a snap which contains a full ubuntu chroot with every dev tool ever installed inside it violates the "uses the same amount of disk space" principle
<ogra_> whats that principle exactly ? :)
<ali1234> the one i invented
<ogra_> (also, why in the world would you build such a thing)
<ali1234> i wouldn't... i would just use regular ubuntu
<ali1234> but you want people to use snap right?
<ogra_> and thats fine
<ogra_> as a delivery mechanism for their products
<ali1234> here's the thing
<ogra_> and if there is a bundled snap that provides a specialzed build env for their products that eases their life by bundling, then too
<ali1234> i won't really trust snap as a delivery mechanism until i see the software i use delivered with it
<ogra_> thats a weird POV i must say
<ali1234> i don't think it is
<ogra_> i want to get my shit done ... whatever makes that easiest to me is what i use ...
<ali1234> nobody wants to be an early adopter
<ogra_> and i want to get my stuff inot hands of users
<ogra_> these are two distonct requirements
<ali1234> well if you want to get your stuff into the hands of users then you pick android apks...
<ogra_> i dont see why they would have to be fulfilled by the same thing
<ogra_> except that i dont develop android apps
<ali1234> then you cant really make an argument for picking tools based on distribution
<ogra_> (though i dont see why snapcraft culdnt have android execution env support
<ogra_> )
<ogra_> like i dont see why snappy couldnt have a wine execution env ... so that windows applications could be delivered
<ogra_> s/snappy/snapcraft
<ogra_> in any case i see the two parts as distinct steps ... development vs delivery
<ali1234> i don't
<ali1234> there is too much overlap
<ogra_> not sure where
<ali1234> where does a tool like glade fall?
<ogra_> they are two sepearate steps
<ali1234> what about text editors
<ali1234> what about an IDE?
<ogra_> what about them
<ali1234> are they a development tool, or something that should be delivered as an app?
<ogra_> no, they are a tool that shoulld be part of a dev-env snap as i described above
<ali1234> so you would just have a gigantic snap with every development tool in it?
<ogra_> why would you use glade standalone
<ogra_> withhout buulding somethign with it
<ogra_> no
<ali1234> why would i want glade installed if i am writing a Qt application?
<ogra_> why would i put every development tool into it
<ali1234> okay, which development tools would you put in it?
<ogra_> i would put the tools that fit the project into it
<ali1234> so each developer would need to make their own monolithic development tools snap?
<ogra_> if there is a glade app it will likely buuld gtk stuff
<ali1234> with whatever tools they want in it
<ogra_> so i would put the gtk build deps, a compiler and whatever else is needed into it ... along with glade itself
<ali1234> what is the developer of qgtkstyle supposed to do?
<ogra_> i wouldnt put Qt libs in
<ogra_> dunno ... how many are there :)
<ogra_> they would probably take my snap and enhance it
<ali1234> probably about four or five... you know like every open source project ever
<ogra_> because that just means two extra lines in the snapcraft.yaml i provide
<ali1234> yeah and then waiting six hours for all that stuff to build :)
<ali1234> this does not sound very apealing to developers to me
<ogra_> dunno why you would have to wait 6h for a snap to be built by snapcraft
<ogra_> i havent seen such a snapcraft project yet :)
<ogra_> (though they will undoubtly exist some day)
<ali1234> because you removed half the stuff from the distro because it isn't needed any more
<ali1234> can you build a snap out of other snaps?
<ogra_> also why do you care ... as that potential glade developer you just snap install glade-dev-env
<ogra_> or as the one using qtgtk crossover stuf you install glade-and-qt-dev-env from someone else
<ali1234> that ends with every application having it's own dev-env snap
<ogra_> ?
<ali1234> in the same way that currently every snap needs to have a copy of all it's dependencies embedded
<ali1234> the same thing ends up happening in the -dev snaps
<ogra_> dev-env ...
<ali1234> yes, -dev-env
<ogra_> you use a toolkit, so you have the bits needed included
<ali1234> yeah except that in the real world just using a toolkit is not enough
<ogra_> well, you define what else is needed in yur snapcraft yaml
<ali1234> so then you fork the toolkit dev-env snap, add that one extra library you need, and rebuild it, and now you have a unique dev-env for your app
<ogra_> or your toolkit pffers you to add the needed bits on demand ;)
<ogra_> *offers
<ali1234> snapcraft can only install what the distro includes
<ogra_> s/toolkit/dev-env/
<ali1234> and we removed all non-build-essential things from the distro because snap is way better, remember?
<ogra_> and ?
<ali1234> and so the only way to get the thing you need is as a snap
<ali1234> but you're not going to snap development tools
<ogra_> i dont need the distro to have my dev-env package use the upstream git tree of Qt
<ogra_> i can just define it in my snapcraft.yaml to use that
<ali1234> snapcraft itself is not available in a snap...
<ogra_> as i said, that will change
<ali1234> so first thing you have to do is make a snap with snapcraft in it
<ogra_> but thats  a minor detail
<ali1234> it's not exactly minor in my opinion
<ogra_> again .. snap is just a delivery mechanism
<ali1234> t isn't really though
<ogra_> rolling a snapcraft snap is likely not very hard ...
<ogra_> just takes time that nobody has right now because thats currently not really a pressing prob for anyone
<ali1234> tar.gz is a delivery mechanism
<ogra_> the 50 or so upstreams that started fiddling with snaps over the last two weeks or so surely didnt have issues with using snapcraft in its current state
<ali1234> heh
<ali1234> well, i hit problems at every turn
<ogra_> file bugs :)
<ali1234> but i am not just trying to ship packages on standard ubuntu
<ogra_> right
<ogra_> and i doubt you will ever see gcc go away as a deb
<ogra_> or make
<ali1234> i don't want to see that
<ali1234> what i want is for apt to be a thing that is only used by snapcraft
<ali1234> and every single byte of binary code on my drive to be installed by snap
<ogra_> well, in certain setups that will be the case
<ali1234> in *every* setup
<ali1234> and without having loads of dupes of the same thing installed
<ali1234> right now i have about 10 copies of gcc installed and i'm not even using snaps yet
<ogra_> why do you have that ?
<ali1234> several different cross compilers
<ali1234> the problem is that everyone ships monolithic development SDKs
<ali1234> for example http://wiibrew.org/wiki/DevkitPPC
<ali1234> you know what would solve this problem?
<ali1234> if upstream gcc released a snap for every release/host/target combination
<ali1234> a standalone gcc snap
<ogra_> well, write a snapcraft.yaml and send it to them ... i'm sure they wouldnt refuse
<ogra_> (i still dont see the need ... you would likely also want make, binutils and such stuff in such a snap)
<ali1234> yes
<ali1234> but i'd only need one
<ogra_> (probably even libc)
<ali1234> instead of having 10 different ones
<ali1234> like currently ubuntu has packages for mingw which i use
<ali1234> it doesn't have one giant package that also includes make
<ali1234> that would be a step backwards in my opinion
<ogra_> well ...
<ogra_> i think we are back at the beginning of the conversation now
<ali1234> yes
<ogra_> deduplication or whatever will surely be looked at at some point
<ogra_> until then, just use a classic system or a classic shell in an all-snaps system (which should be back when we have actual images)
<ali1234> 99% of the software i write is for my own use
<ali1234> so for me, snappy has to be more than just a distribution system
<ali1234> because once i build the software i already have it
<ogra_> bah
<ogra_> ogra@styx:~$ sudo snap remove telegram-sergiusens
<ogra_> error: cannot remove "telegram-sergiusens": snap "telegram-sergiusens" has changes in progress
<ogra_> seems the panel systray icon keeps running which confuses snapd .. now i cant either install or remove it
 * ogra_ tries a reboot
<ogra_> hmm, nope
<ogra_> funnily the snap mount is definitely gone after reboot
<ogra_> ah, but snap install works again ... something at leat
<ogra_> *least
<aisrael> I'm having trouble getting my wireless dongle to work after upgrading to kernel 3.19.1-12. I'd installed linux-firmware_1.158_all.deb, but even after reinstalling it the only modules I have are for 3.19.0-51. Any idea what I'm missing?
<ehbello> hello!
<ehbello> I was packaging my first snap following ubuntu guides about snapcraft but it does not install in Ubuntu Core 15.04/stable
<ehbello> It seems to be incompatible
<ehbello> what version of Ubuntu Core must I use?
<ehbello> "failed to install: open /tmp/read-file847258171/unpack/meta/package.yaml: no such file or directory"
<ehbello> I'm using Ubuntu 16.04 to develop this snap
<ehbello> ok... I answer to myself... Ubuntu 16.04 has snapcraft 2.x and Ubuntu Core 15.04/Stable has snapcraft 1.x but still there is no release of 16.04
<tsimonq2> ehbello: snapd =/ snapcraft
<tsimonq2> ehbello: you should be looking at the all-snap images anyways
<ehbello> tsimonq2: i'm sorry... i mean snapd, obviously
<ehbello> @tsimonq2: ok, all-snap images... I now understand what it means: https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html
<nothal> ehbello: No such command!
<ehbello> tsimonq2: ok, all-snap images... I now understand what it means: https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html
<ehbello> tsimonq2: thanks
<ehbello> :D
<tsimonq2> ehbello: nice :)
<tsimonq2> you get everything squared away?
<ehbello> tsimonq2: I get an error following this example to generate a "stable" release: https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#Image_generation_.2816_and_higher.29
<ehbello> tsimonq2: 'failed to install "canonical-pc" from "stable": canonical-pc failed to install: exit status 2'
<ehbello> tsimonq2: how can I get a valid list of values for 'gadget' parameter?
<ehbello> tsimonq2: answer: https://developer.ubuntu.com/en/snappy/guides/gadget/ :)
<tsimonq2> ehbello: to be honest, I don't know
<tsimonq2> oh nice :D
<ehbello> tsimonq2: ok, thanks anyway :D
<ehbello>  
<ehbello>  
<ehbello> tai271828: FYI: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001735.html
<ehbello> tai271828: sorry
<ehbello> tsimonq2: FYI: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001735.html
<ehbello> tsimonq2:  this link is needed to fix the problem:`ln -s /bin/true /usr/local/bin/udevadm`
<tsimonq2> oh cool
<tsimonq2> that's good that you got it fixed :)
#snappy 2017-06-12
<mup> PR snapd#3416 closed: tests: fix for test interfaces-openvswitch <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3416>
<mup> PR snapd#3468 opened: debian: add missing  Type=notify in 14.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3468>
<mup> PR snapd#3458 closed: tests: check that locale-control is not present on core <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3458>
<mup> PR snapd#3454 closed: spread: add fedora snap bin dir to global PATH <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3454>
<morphis> mvo: thanks!
<mup> PR snapd#3452 closed: tests/main: check for confinement in a few more interface tests <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3452>
<mup> PR snapd#3451 closed: tests/main: use dir abstraction in a few more test cases <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3451>
<zyga> good morning
<mup> PR snapd#3443 closed: Unity7 interface grows gtk2/3 settings and user's specific ini <Created by didrocks> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3443>
<mvo> fgimenez: if you de-conflict 3391 I am happy to merge it
<mvo> morphis: my pleasure, thanks for working on this!
<fgimenez> mvo: sure thx! on it
<morphis> mvo: np, more to come :-)
<mup> PR snapd#3405 closed: tests: fix for upgrade test when it is repeated <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3405>
<mvo> morphis: 3222 has a conflict and test failures (probably unrelated) - could you merge master and de-conflict, hopefully this can go in then :)
<mvo> fgimenez: no rush :)
<morphis> mvo: yeah will start working on these PRs in a bit
<mvo> morphis: ta
<fgimenez> mvo: snapd#3391 is ready thx :) btw when you have some time (not urgent) it would be great to create these test snaps under the shared account in prod: https://code.launchpad.net/~snappy-dev/+snap/test-snapd-system-observe-consumer https://code.launchpad.net/~snappy-dev/+snap/test-snapd-autopilot-consumer https://code.launchpad.net/~snappy-dev/+snap/test-snapd-upower-observe-provider
<mup> PR snapd#3391: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3391>
<pachulo> I'm working on a MuseScore snap: https://github.com/pachulo/musescore-snap and trying to get the MuseScore devs to make it "official": any tips on doing it?
<ogra> pachulo, dont they have some "how to contribute" doc on their website ?  i'd try to follow it (make a PR on github etc)
<pachulo> I've already did something like this: https://github.com/musescore/MuseScore/pull/3204
<mup> PR musescore/MuseScore#3204: Add snap package <Created by pachulo> <https://github.com/musescore/MuseScore/pull/3204>
<ogra> well, then wait for answer :)
<pachulo> should I recommend them to use https://build.snapcraft.io/ to create the snaps?
<pachulo> ogra:
<ogra> well, thats up to them but yes, show them the possible ways of making use of your code :)
<pachulo> does it makes sense to have different snapcraft.yaml for the different channels all in the master branch of the project?
<zyga> pachulo: I would kepe them in separate branches, not sure what the actual difference between those is though
 * Chipaca ~> coffee
<mup> PR snapd#3465 closed: hooks: re-org of some hooks types <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/3465>
<morphis> Pharaoh_Atem: `zypper si -d` doesn't help for local srpm's, it only works with packages listed in the archive
<abeato> ogra, hi, do you know how can I force generation of core file on program crash, in UC16?
<ogra> abeato, you should be able to do the same stuff apport does i think
<ogra> (iirc it pokes around in sysfs to make file dumps happen)
<abeato> ogra, ok, will check, thanks
<abeato> mvo, is 2.27 already in candidate? or latest changes (including androidboot) are only in edge?
<mvo> abeato: only in edge, we have no pushed 2.26 out, some small issue in specific revert cases still
<abeato> mvo, got it, thanks
<pedronis> mvo: fgimenez: hi, have we found out more about those revert problems? is still related to profiles or something else?
<fgimenez> hi pedronis, the core-revert test now shows the problem with the changes at snapd#3466, this is syslog of the testbed after the failure http://paste.ubuntu.com/24815993/ looks like the problem is related to "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process" after the revert
<mup> PR snapd#3466: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3466>
<pedronis> ok, profiles, thanks
<pachulo> is it possible to upload a snap for different archs in the webui of the store?
<daker> pachulo: i think yes, the store will automatically detect the arch
<pachulo> but if I want to upload the snap for x86 & for amd64?
<ogra> then the store simply generates a revision per arch ... it check the meta/snap.yaml inside your snap
<pachulo> ah, ok, different revisions per arch
<pachulo> that makes sense
<pachulo> and how do you make the snap availabe in the stable channel? In the webui I can only pusblish to "beta" and/or "edge"
<ogra> id your snap confinement: strict and grade: stable ?
<ogra> s/id/is/
<ogra> only stable snaps with strict confinement can go into stable
<pachulo> ok
<pachulo> thanks for the info ogra !
<ogra> np :)
<niemeyer> Mornings
<mup> PR snapd#3469 opened: many: add "release.BuildStamp" to identify the current build <Created by mvo5> <https://github.com/snapcore/snapd/pull/3469>
<Chipaca> oops, i done goofed
 * Chipaca fixes
<fgimenez> mvo: ogra we are still getting errors with the new kernel snaps published to beta due to missing /dev/ram* https://travis-ci.org/snapcore/spread-cron/builds/241982348 should we change the tests to stop using them? the related bug recently expired bug #1677622
<mup> Bug #1677622: missing ramdisks in latest amd64 kernel snap <kernel-da-key> <linux (Ubuntu):Expired> <https://launchpad.net/bugs/1677622>
<ogra> fgimenez, well, that seems to be a userspace tool issue if i read ppisati's comment correctly
<ogra> you could just run mknod before mkfs
<fgimenez> thanks ogra, i'll try that with beta's kernel
<ogra> fgimenez, i also think it might be realted to https://github.com/snapcore/snapd/pull/3010
<mup> PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3010>
<ogra> (i suspect the mount attemmpt makes the kernel actually create the device (just y theory though))
<ogra> s/y/a/
<fgimenez> ogra: not sure, we noticed the problem before snapd#3010 was proposed, the first errors are from 2017-03-15 https://travis-ci.org/snapcore/spread-cron/builds/211518618#L668
<mup> PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3010>
<ogra> hmm, k
<ogra> https://launchpad.net/ubuntu/+source/snapd/2.23.1 landed on 2017-03-14
<ogra> quite some changes in there
<ogra> and https://launchpad.net/ubuntu/+source/linux/4.4.0-67.88 went into beta on the 15th
<ogra> also not a small changeset
<mup> PR snapd#3470 opened: interfaces/builtin: sync connected slot and permanent slot snippet <Created by morphis> <https://github.com/snapcore/snapd/pull/3470>
<mup> PR snapd#3471 opened: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <https://github.com/snapcore/snapd/pull/3471>
<fgimenez> mvo: i didn't receive yet the test snaps emails, should i have them already?
<mvo> fgimenez: you should, let me double check
<fgimenez> mvo: thx!
<mvo> fgimenez: probably primary email vs not primary sso email again, sorry for that
<fgimenez> mvo: np :) already received, thank you!
<jdstrand> noise][: hey, fyi, https://dashboard.snapcraft.io/dev/snaps/7807/rev/1/ says 'manifest not available'
<noise][> jdstrand: you are getting an err on the page?
<jdstrand> noise][: https://dashboard.snapcraft.io/dev/snaps/7809/ too
<jdstrand> noise][: sorry, if I go to Overview, then review capabilities
<jdstrand> Manifest (snap.yaml)
<jdstrand> manifest not available
<noise][> ah, i see
<noise][> weird - can you file a bug on https://bugs.launchpad.net/snapstore and i'll get someone to take a look ASAP
<jdstrand> sure
<jdstrand> noise][: https://bugs.launchpad.net/snapstore/+bug/1697459
<mup> Bug #1697459: Manifest (snap.yaml): manifest not available <Snap Store:New> <https://launchpad.net/bugs/1697459>
 * zyga lunch and small break
<zyga> re
<morphis> zyga, mvo, Pharaoh_Atem: https://github.com/snapcore/snapd/pull/3449 is ready for another review and merge :-)
<mup> PR snapd#3449: tests/lib: generalize RPM build support <Created by morphis> <https://github.com/snapcore/snapd/pull/3449>
<Pharaoh_Atem> morphis: why are you not using `dnf builddep` or `zypper si`?
<morphis> Pharaoh_Atem: as zypper si doesn't work
<morphis> it works only for packages coming from the archive
<morphis> and with that I couldn't find a good abstraction and left the comming thing in I had before
<Pharaoh_Atem> you gave it the full path of the RPM, not just the rpm name?
<morphis> correct
<morphis> it complains about not being able to find that package
<Pharaoh_Atem> wow, that's... dumb
<morphis> giving it just a name works fine
<morphis> if you find a better way on suse I am all ears but want to get this in as I have a lot more on my plate at the moment
<Pharaoh_Atem> can you pull all the deps into an array, ignore the ones that are rpmlib() ones, and then just pass that as an arg to zypper install / dnf install?
<Pharaoh_Atem> because the way you're doing it now is really slow
<mvo> jdstrand: it looks like we need to revert http://paste.ubuntu.com/24841683/ this is using new symbols and things break on revert- this is 17389627 - it looks dangerous though. what is your opinion here? instead of reverting we could hold a stable release back until the seccomp-bpf branch is finished and lands.
<mup> PR snapd#3463 closed: client, daemon: expose service commands (start, stop, etc) <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3463>
<morphis> Pharaoh_Atem: that is what I am doing right now
<Pharaoh_Atem> ah, I see where you're passing the array
<Pharaoh_Atem> I missed that
<morphis> :-)
<Pharaoh_Atem> then the only piece left is that spurious --nocheck on rpmbuild -bs
<morphis> let me drop that
<morphis> actually why doesn't rpm complain if it is there and not used?
<morphis> Pharaoh_Atem: done
<jdstrand> mvo: which stable would we hold back?
<mvo> jdstrand: 2.25 is currently in candidate but never progressed to stable because when 2.24.1 -> 2.25 -> 2.24.1 reverts happen some snaps (like network-manager) fail to start because of seccomp symbols
<mvo> jdstrand: and we found during testing that the above commit is also problematic
<jdstrand> that whole PR has a bunch of new symbols
<jdstrand> I've started looking at the bpf PR
<jdstrand> I don't know what kind of timeframe you are looking for at this point
<jdstrand> I'd be inclined to wait for the bpf at this point
<jdstrand> mvo: ^
<mvo> jdstrand: ok, that is something to discuss I think, I can't make this decision alone, but I have the same feeling, it feels like whack-a-mole currently and the risk is that we break things. seccomp-bpf I can pick-up again and its pretty safe
<mvo> jdstrand: but I definitely want your input if all things I do there are sound :)
<jdstrand> mvo: I will be looking at the PR in depth
<jdstrand> mvo: note I already commented on it regarding missing tests
<mvo> jdstrand: tests about the >= etc syntax? those should be ported in a different way, let me look for the link
<jdstrand> mvo: so all the reverts are making me uneasy because there is risk in getting the revert wrong and getting the unrevert wrong in the future
<mvo> jdstrand: https://github.com/snapcore/snapd/pull/3431/files#diff-be7cfe1e5aff69d70d80b1c2cabcaaccR148 is the testing, it uses a bpf.VM and gives it the same inputs as the kernel would give it. is your concern that you want sometimg more integration-ish? or am I missing someting in those tests that I overlooked?
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<jdstrand> mvo: the tests I commented on were cmd/snap-confine/tests. the will definitely need to be ported in a different way, but the PR doesn't show them
<mvo> jdstrand: yeah, I agree, I don't feel good about those reverts either.
<jdstrand> mvo: I suspect that the porting will be done in two ways: syntax checks in TestCompile and functional tests to spread
<mvo> jdstrand: aha, I see, something more integration test-ish then, I make that a priority in my morning. it should be unit tested now but you are right, integration type tests in this style are missing
<jdstrand> mvo: where the spread tests will consist of rewriting the seccomp filter
 * mvo nods
<jdstrand> mvo: it's more than just integration though. there are a ton of syntax tests. eg test_restrictions_working_args_socket
<jdstrand> they won't be hard to port or anything, just saying more is needed in TestCompile
<jdstrand> in addition to integration/spread tests
<mvo> jdstrand: thank you, indeed, I will work on it in my morning. it looks straightfoward to port to TestCompile fortunately
<jdstrand> mvo: yes. there are relatively few things that need to go to spread otoh
<jdstrand> mvo: thanks for taking care of that
<mvo> jdstrand: yeah, thanks a lot for your feedback
<jdstrand> np
<jdstrand> more will be coming :)
<mvo> jdstrand: thank you. I updated the forum thread on the 2.25 issue, feel free to jump in and add your opinion
<jdstrand> ok
<mup> Bug #1697492 opened: systemd fails to run /lib/systemd/system-sleep/wpasupplicant script when wpa-supplicant is installed <Snappy:New> <https://launchpad.net/bugs/1697492>
<ogra> abeato, urgh ... we have a wpa-supplicant snap ?
<abeato> ogra, we do... was needed for some wowlan stuff in caracalla
<ogra> abeato, i doubt that can work, given that we have a wpa-supplicant in the core snap too
<ogra> unless you block that or make it unexecutable somehow
<abeato> ogra, it does, mostly, see https://github.com/snapcore/core-build/blob/master/config/lib/systemd/system/wpa_supplicant.service.d/snap.conf , that is how the one in core is blocked
<ogra> ah, i remember landing that, yeah
<ogra> but that only blocks execution, you still have all the files and scripts in the rootfs
<ogra> thats a really tricky bug
<ogra> we cant just hack the default script
<abeato> yeah, it is quite ugly thing
<abeato> I agree...
<abeato> I'm not sure how this could be solved, maybe the path should have been to add patches to wpa-s in xenial instead
<ogra> well, if you think that coulld solve the need for a snap ... xenial is there, SRUs are always possible :)
<abeato> sure... I'll think about that and leave the bug there open for the moment
<ogra> abeato, hmm, i wonder what happens if you ship a /writable/system-data/lib/systemd/system-sleep/wpasupplicant in your gadget snap
<ogra> (if that gets copied into place etc)
<ogra> might be possible to override the default file from the gadget that way
<abeato> ogra, good idea, will give that a try
<ogra> i know we allow copying a bunch of things ... mot sure if /lib is included in that though ... (the ubuntu-image source might know :) )
<mup> PR snapd#3472 opened: interfaces, tests: add mising dbus abstraction to system-observe and extend spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3472>
<cachio_> Chipaca, are you working in a store related change? is it something that could be addressed https://travis-ci.org/snapcore/snapd/builds/241920749#L2050 ?
<mup> PR snapd#3473 opened: tests: fix create-key by generating entropy in case the current it is not enough <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3473>
<niemeyer> mvo: Still here?
<bdmurray> Is this an issue with the kubelet snap or snappy itself? https://errors.ubuntu.com/problem/19272ebc18709d4407dba0438a536d56bb143069
<ogra> bdmurray, https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390
<niemeyer> cachio_afk: Some feedback on 3437
<mup> PR snapd#3437 closed: tests: apt autoclean <Created by sergiocazzolato> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3437>
<bdmurray> ogra: ah, thanks
<ogra> ogra@bbb:~$ sudo classic
<ogra> cannot open cookie file /var/lib/snapd/cookie/snap.classic
<ogra> hmm, whats that ? that wasnt there yesterday, since todays core refresh i seem to get it everywherre
<ogra> (i end up just fine in the classic shell after the message)
<niemeyer> morphis: snapd#3222 is good to go assuming one trivial tweak mentioned there
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<mup> PR snapd#3461 closed: debian: add missing "make -C data/systemd clean" <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3461>
<morphis> niemeyer: thanks, will fix that tomorrow!
<niemeyer> morphis: Thank you!  Glad to see that one in
<morphis> niemeyer: lets see how friendly travis is tomorrow to me :-)
<niemeyer> morphis: I've heard things have been improving much there
<morphis> niemeyer: yeah they did :-)
<ssbash> hi everyone!
<cachio> niemeyer, please when you have a minute could you take a look to the PR 3473?
<niemeyer> cachio: Will do
<cachio> tc
<cachio> tx
<ssbash> Does anyone know how to fix python path issues? I'm experiencing the same problems from this post https://askubuntu.com/questions/906199/how-to-setup-pythonpath-for-a-snap-package
<ssbash> Basically my python package is in the site packages directory, but I am getting the error that my command cannot find my package
<ssbash> cachio do you have any experience dealing with python path issues?
<nacc> ssbash: so the wrapper script doesn't set PYTHONPATH at all (should be viewable from the shell session, i think)
<ssbash> i checked the shell session, this is what it returns https://paste.ubuntu.com/24844778/
<cachio> ssbash, let me see
<ssbash> here is the error message http://paste.ubuntu.com/24844781/
<ssbash> also here is the snapcraft.yaml http://paste.ubuntu.com/24844790/
<nacc> ssbash: so i think the issue is site-packages vs. dist-packages, but i'm not sure why
<ssbash> env PYTHONPATH variable seems to be correct as I have specificed in the .yaml file. However my python script is still not picking up on the package.
<ssbash> ok, how could I move the install location of my package to a dist-package?
<nacc> ssbash: it's strange, i think the python plugin should be handling that for you
<ssbash> It's automatically moved to site-packages, since I use setup.py to build
<nacc> ssbash: i wonder if the python2.7 site.py needs to be udpated
<cachio> ssbash, what do you have in the requirements.txt?
<nacc> ssbash: again, not something you should have to do, either way
<ssbash> I'm not sure what you mean by the python 2.7 site.py? I've specified the python plugin that this is a pyhton 3.5 project. Also here is my requirements.txt http://paste.ubuntu.com/24844809/
<cachio> ssbash, did you try creating a wrapper and setting up the pythonpath on there?
<ssbash> like a virtualenv? I'm confused what you mean by wrapper
<cachio> ssbash, I mean a bash script able to call the python module
<cachio> ssbash, let me take a look to the lib to see why it is givving that error
<nacc> or try to do that form the shell itself (spin up the interpreter from your snap shell)
<nacc> ssbash: i just was thinking through how site-packages works normally
<ssbash> cachio: this is the command wrapper that snapcraft created. #!/bin/sh export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH" export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu" export LD_LIBRARY_PATH="$SNAP/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH exec "$SNAP/usr/bin/python3" "$SNAP/bin/wr
<ssbash> whoops http://paste.ubuntu.com/24844868/
<ssbash> I dont see any mention of the python path in  the wrapper
<cachio> ssbash, no
<cachio> ssbash, did you check the project was correctly downloadedÂ¡?
<cachio> ssbash, I am talking about wraticus
<ssbash> oh, yes I've check that the entire package and sub packages have been downloaded in site-packages.
<cachio> ssbash, what I have done with good results is to create a wrapper script where I setup all the veriables that I need and also I make the call the to command
<cachio> let me check for an example
<cachio> ssbash, there is some doc on https://snapcraft.io/docs/build-snaps/metadata
<cachio> section Using wrappers
<cachio> ssbash, does it work for you?
<ssbash> I'm still a bit confused. how could I specific the python path in the wrapper without hard coding a path?
<cachio> you can do, export PYTHONPATH=PYTHONPATH:blablabbla
<ssbash> PYTHONPATH: $PYTHONPATH:$SNAP/lib/python3.5/site-packages would that be work?\
<cachio> and then exec "$SNAP/usr/bin/python3" "$SNAP/bin/wraticus.py" "$@"
<ssbash> ok and then point the command to this new wrapper executable
<cachio> yes
<ssbash> ok ill give it a try
<ssbash> cachio I added the wrapper command. python still isnt able to find wraticus.
<cachio> ssbash, can you share the wrapper?
#snappy 2017-06-13
<ssbash> http://paste.ubuntu.com/24845115/
<cachio> the error is the same?
<ssbash> yea, "ImportError: No module named 'wraticus.lib'; 'wraticus' is not a package"
<cachio> and the snapcraft.yaml?
<ssbash> http://paste.ubuntu.com/24845159/
<ssbash> pretty much unchaged aside from the script
<ssbash> I tried it both with and without the environment specifications
<cachio> ssbash, https://paste.ubuntu.com/24845181/
<cachio> https://paste.ubuntu.com/24845185/
<cachio> there you have an example
<cachio> using a wrapper
<ssbash> ok should I move the environment block to the parts section?
<cachio> you create a part with the wrapper
<ssbash> http://paste.ubuntu.com/24845323/ this is my lastest version, I'm still getting the 'wraticus is not a package' error
<cachio> ssbash, does it exist?
<cachio> $SNAP/bin/wraticus.py
<cachio> and it calls to the lib?
<francis[m]> Any recipes to make a snap from a deb?
<zyga> good morning
<zyga> francis[m]: you can use snapcraft and stage-packages
<zyga> francis[m]: look at the array of snapcraft examples on the web
<francis[m]> zyga (IRC): i looked around
<francis[m]> But apart from some no longer maintained projects i didnt find
<francis[m]> Will look at snapcraft
<francis[m]> Thx!
<luk3yx> If I want to include a binary from /usr/bin in a snap, what's the best way to do it?
<zyga> francis[m]: https://github.com/search?utf8=%E2%9C%93&q=stage-packages+extension%3A.yaml&type=Code&ref=advsearch&l=&l=
<zyga> luk3yx: stage-packages as this binary is typically packaged itself
<luk3yx> zyga: Okay, I'll try that.
<zyga>  good luck
<zyga> note that stage packages are not always the best way to make a snap, but they are the quickest for sure
<luk3yx> It works, thanks.
<sborovkov> Hello, stupid question but I never used uboot before, if I add some binary to the boot-assets in the gadget snap from what path would it be available in uboot when booting?
<morphis> ogra: ^^
<morphis> zyga: you will love https://github.com/morphis/spread-images/commit/628d428c655f1004dcadb91bfd3d5eebd44ce804
<zyga> looking
<zyga> nice :-)
<morphis> zyga: if we can't fix pacman in the archive lets import packaging bits and make sure they are taken care of, then whoever maintains the pkg can pull these into the main archive
<zyga> yes, I think that's the natrual way to handle this
<zyga> then anyone can propose improvements to the snapd tree (no need to be a distro maintainer)
<zyga> and we can work with timothy or anyone else to synchronize with upstream packaging
<ogra> sborovkov, usually from / in the system-boot partition ... unless you push it to a raw place via the gadget snap like i do in https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/
<ogra> sborovkov, if you mean from the uboot shell, then "fatls mmc <devicenumber> <partition>" is your friend to find it ...
<ogra> i.e. if system-boot is yuor first partition on the first SD: "fatls mmc 0 1"
<ogra> (or "...mmc 0 0")
 * zyga needs a coffee
<sborovkov> ogra: ah, alright, yes I am building the gadget snap. Trying to add splash screen
<ogra> sborovkov, heh, i have that half done here for the default gadgets ... :)
<ogra> (but it is more of a pet project so i only work on it every now and then)
<sborovkov> ogra: is there some standard mechanism (or it's going to be developed) to hide login promt on the first boot? First boot takes quite awhile and that would look bad for user to see login promt at that time...
<sborovkov> also, is I understood you correctly when adding bmp file to the boot-assets it would be available from /? so I can add splashscreen=/boot-assets/Screenly.bmp?
<ogra> sborovkov, well ... depends ... in IoT i would expect most boards to only have a serial console and operate completely headless ...
<ogra> same goes for core based cloud images
<ogra> no, you wouldnt use boot-assets/ ...
<sborovkov> Alright, understood thanks
<ogra> if it sits directly on your system-boot partition you'd use splashscreen=Screenly.bmp
<ogra> if i were ou i'd just add it to the gadget, build an image with it, stop the boot on the u-boot console and develop the scripting for it in there ... (then later add it to uboot.env.in)
<ogra> so that you can check for paths and the like with fatls/fatload etc
<ogra> https://www.denx.de/wiki/DULG/UBootSplashScreen and https://www.denx.de/wiki/DULG/UBootBitmapSupport should be helpful
<sborovkov> thanks!
<mup> PR snapd#3457 closed: tests: add refresh --time output check <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3457>
<mup> PR snapd#3474 opened: tests: fix ipv6 disable for ubuntu-core <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3474>
<ogra> koza, hmm ... i only actually use the hummingboard with HDMI and kbd attached, did you try that ? (i only opened the case once but didnt touch any jumpers, the board is as it got it from madper)
<ogra> *as *I* got it
<ogra> koza, it should work fine from microSD
<morphis> zyga-suse, zyga-fedora: two of you now? :_)
<zyga-suse> morphis: yes, on each system, ubuntu too but I think I can manage with just two IRC accounts :)
<morphis> hehe
<zyga-suse> sadly irc doesn't do multi-client very well
<morphis> zyga-suse: https://paste.ubuntu.com/24848692/ , that is what we get now on the Pi 1 or Pi Zero with that patch I did
<zyga-suse> morphis: that's nice
<zyga-suse> morphis: btw, one idea
<morphis> not optimal but that is something we can improve later
<zyga-suse> morphis: if the core snap for the architecture cannot be found, link to a forum thread
<zyga-suse> morphis: and encode the architecture in the URL
<morphis> why not
<zyga-suse> once it gets found we do nothing more
<zyga-suse> and meanwhile people will have a place to go to and discuss
 * ogra finds it funny that hexchat actually turns zyga from violet to "SuSE green" when he renames himmself to zyga-suse 
<ogra> -m
<niemeyer> o/
<zyga-suse> oh really? :D
<zyga-suse> nice :)
<cachio> Chipaca, hey
<cachio> Chipaca, I have seen some tests failing because of an error 502
<cachio> Chipaca, downloading apps
<cachio> Chipaca, have ouy seen that?
<pstolowski> zyga-suse, hey, re snap-confine and security tag vs snap name matching - do we have strong incentive to get rid of regexp in verify_security_tag? because if not, the fix is going to be very simple with captured text
<Chipaca> cachio: yes; was that yesterday, or today?
<cachio> yesterday
<cachio> I saw it twice
<Chipaca> right
<Chipaca> yesterday the store had some issues
<zyga-suse> pstolowski: I'd say we fix the immediate issue and then iterate on improvements (regexp removal)
<Chipaca> cachio: https://r.chipaca.com/sauc.cgi?maxDays=2
<pstolowski> zyga-suse, sounds good to me
<cachio> Chipaca, are those store metrics?
<Chipaca> cachio: from the perspective of a very cheap shared hosting
<cachio> Chipaca, linode provided that?
<Chipaca> cachio: no, that's me
<Chipaca> cachio: in any case it's back to the usual ~1 error in a 24 hour period
<koza> ogra, lunch this time, ah you are lucky with the board. could you take a photo of the board for me. i could verify if all the jumpers are in correct positions. the dos that I could find over the net are not quite detailed.
<ogra> koza, that will take a bit, i need to open the case again :) ...
<ogra> koza, just to make sure we have the same thing, you have a hummingboard GATE with case ?
<koza> ogra, I have hummingboard gate w/o case (but I have been told this is the same pcb, case is an optional accessory) https://www.solid-run.com/product/hummingboard-gate/#configuration
<ogra> koza, https://wiki.solid-run.com/doku.php?id=products:imx6:hummingboard has a table for the jumper
<ogra> bridging 3+4 and 5+6 should do it
<ogra> (at the very bottom)
<koza> ogra, this is what I bridged :-) thts is why I want to super verify everything
<ogra> gimme a bit ... going to the office and grabbing my board and a screwdriver :)
<koza> ogra, sure, thanks
<mup> PR snapd#3453 closed: tests/main/manpages: install missing man package <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3453>
<morphis> niemeyer: thanks!
<ogra> koza, oh, interesting
<ogra> koza, no jumpers at all !
<ogra> which would mean OTG boot ... but i guess it falls back to SD if no OTG is connected or some such
<koza> ogra, interesting
<ogra> well, try it ... perhaps it boots then for you too
<ogra> btw, i use a 12V 1A PSU
<ogra> (an old thing from some broken netgear switch that happened to have the right plug size)
<ogra> so you should be fine with your 12V2A
<koza> ogra, trying now, exactly 2A should be fine; one thing how your serial is connected? mine is to the 3-pin uart connector which is on the edge half way between microSD slot and the boot-mode pins
<ogra> the default cmdline has "console=ttymxc0,115200 console=tty0 " so you should see something on serial if it is wired correctly
<ogra> i have never used serial on it
<ogra> HDMI worked just fine ... i actually didnt open the case when working on the image
<ogra> only after i had that up ... to take a look how it looks inside
<koza> ogra, got it
<ogra> but there is that thing labeled UART on the board with three pins
<koza> ogra, yeah but there is another one but just holes w/o pins soldered which is a bit confusing which one to use
<ogra> well, surely the one with pins :)
<ogra> i doubt they want you to solder pins onto the one without before you can boot ;)
<koza> ogra, hopefully :-)
<ogra> getting the order right might be a bit of trial and error though
<koza> ogra, at least the jumpers are clear now :-)
<ogra> dont you have a TV or HDMI monitor you could try ?
<koza> ogra, I have, no signal though
<ogra> give it a bit
<ogra> the u-boot stuff might not be displayed ... only once the kernel loads
<ogra> aha
<ogra> there is another UART on the GPIO pins it seems
<ogra> https://wiki.solid-run.com/doku.php?id=products:imx6:hummingboard:hardware:hbpbgpio
<ogra> scroll to the bottom
<ogra> pin 6, 8 and 10
<ogra> 6 being GND
<Chipaca> niemeyer: one argument for not having oddjob just implement execute-command is that I won't be able to reuse the code from the systemd package afaict
<koza> yeah but the gate version has the gpio ports laid out differently, like four pins in each row; there are though three responsible for UART but we just have been discussing them - these do not have pins
<Chipaca> bah, it'll be a rather big refactor
<Chipaca> niemeyer: but i can probably make it shallow enough that you'll still like it :-)
<koza> ogra, like here https://www.solid-run.com/wp-content/uploads/2015/09/hummingboard-gate-03.jpg
<ogra> well, i guess it is just split into two rows ... the prob is to find where pin1 is on that :P
<koza> ogra, left top corner 2nd set of three holes (labeled J35) is a UART too
<ogra> ah
<niemeyer> Chipaca: It feels like the commands to be run there are trivial enough, but I definitely have a much vaguer understanding of the issue than you do at this point
<ogra> yep, i see that on my board
<koza> here they say it is uart http://download.solid-run.com/pub/solidrun/HummingBoard%202/HummingBoard2%20Schematics%20rev%201.2.pdf (bottom of page 6)
<Chipaca> niemeyer: this is true; most of the code in systemd is around things other than these direct commands
<Chipaca> status and logs and such
<Chipaca> niemeyer: I'll take a stab at it :-)
<niemeyer> ð
<Chipaca> OTOH maybe this evolvs to be the other way around, with start-snap-services using oddjob directly
<Chipaca> anyhow, to the code
 * zyga-fedora goes for lunch
 * zyga-suse goes for lunch too
<ogra> are you lunching together ?
<ogra> koza, just to make sure, the SD was definitely written correctly ?
<ogra> (if you plug it into the PC it shows the two partitions ?)
<koza> ogra, just been checking this; yes two
<ogra> ok
<koza> ogra, perhaps Im using too big card, mine is 32G
<ogra> that shouldnt matter to find the kernel and the system-boot partition
<koza> indeed
<ogra> mine only shows the u-boot stuff occasionally on HDMI though ...
<ogra> not on every boot
<ogra> if it doesnt show it, the screen sits at "no signal" for like 20-30sec, then flashes to black screen and after another few sec i ger kernel messages
<ogra> *get
<koza> nothing here; screen has switched off before it printed anything; I'll try with 2nd card just to ruleut issue with card
<ogra> +1
<ogra> if we have the same board there is no reason that yours shouldnt boot
<koza> exactly
<ogra> perhaps my monitor is special :P
<Chipaca> pedronis: do you remember if the tomb that's the second arg of state.HandlerFunc is used to abort?
<Chipaca> trying to track down how abort happens and it's a little elusive
<koza> monitor and board, the extra feature is "it works" ;-)
<mup> PR snapd#3473 closed: tests: pull from urandom when real entropy is not enough <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3473>
<niemeyer> cachio: ^^^ This is in as a step forward, but let's please do the changes we discussed and get random fixed in a more reliable way
<cachio> niemeyer, yes, already working on that
<niemeyer> Thanks!
<niemeyer> morphis: Ok, so which one do you want sanpshotted?
<cachio> ogra, could you please point me to see how you are feeding the entropy pool for ubuntu core?
<ogra> cachio, we dont ... as i explained in the forum, we just force the kernel to do it proper and dont use any userspace tools
<morphis> niemeyer: spread-54 as archlinux-64
<cachio> ogra, ok
<ogra> cachio, and for the kernel the cmdline option is needed
<cachio> ogra, ok, I'll try to do that
<niemeyer> morphis: spread-54 is being cleaned by spread, and the arch disks are not even there
<morphis> niemeyer: hm.. sounds like I have to redo that one again
<niemeyer> morphis: :(
<niemeyer> morphis: #3222 is almost ready.. just needs to drop that extra function and it's good to go
<pedronis> Chipaca: yes
<morphis> niemeyer: wasn't that much work
<ogra> koza, ok, i bit the bullet andf wired up mine with FTDI ... i'm on J25 wired black,white green when the SD card slot is pointing at me ... i get serial output just fine
<mup> PR snapd#3410 closed: cmd/hotfix: add hotfix tool <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3410>
<cachio> niemeyer, so, I can do what is being done for ubuntu core, and add a boot command line option for the entropy
<niemeyer> morphis: Is there something ready to be looked at?
<cachio> niemeyer, but, it requires a reboot
<niemeyer> cachio: So we can't do it.. we don't want to add another reboot on that pipeline
<morphis> niemeyer: not yet, being in a meeting but will do that afterwards
<ogra> koza, http://people.canonical.com/~ogra/image20170613_164358179.jpg ... in my terminal i use "screen /dev/ttyUSB0 115200"
<niemeyer> cachio: We want something closer to what we discussed today in the call
<cachio> niemeyer, ok
<ogra> koza, also ... which image exactly are you using ... daily or daily-stable (i only ever use daily here)
 * zyga-suse returns to work
<ogra> zyga-suse, did you bring zyga-fedora along with you ? :)
<koza> ogra, i think stable, will go for daily then
<koza> lol :-)
<ogra> koza, well, the gadget is the same on both so you should definitely see serial output frrom uboot
 * ogra tries the different images 
 * koza will try once is done with meeting
<ogra> so daily-stable seems fine here, i'm in console-conf
<koza> ogra, i see, must be sth with my board then
<ogra> how did you write the SD ? perhaps something went wrong there
<koza> sudo dd if=/home/konrad/Downloads/ubuntu-core-16-hummingboard.img of=/dev/sdb bs=32M
<koza> ogra, ^^
<ogra> sounds about right ...
<ogra> xzcat /datengrab/images/snappy/daily-stable/current/ubuntu-core-16-hummingboard.img.xz | sudo dd of=/dev/sdc bs=32M
<ogra> thats what i just used (got a local copy of the all-snaps fiolder here)
<ogra> koza, oh,.... did you make sure that the card was unmounted before dd'ing to it ?
<ogra> mine gets automounted by nautilus and i have to sudo umount /dev/sdc1 and 2 first
<ogra> if you dont do that you get a corrupt card
<ogra> (or like US people might call it a "trump card" :P )
<psftw> I should NOT be running snapcraft as root, right?
<ogra> right
<psftw>  <3 ogra
<psftw> so I have a package which depends on a PPA ;-)
<ogra> if it needs root permissions it is clever enough to ask for it during the process
<psftw> https://github.com/docker/docker-snap/blob/master/snap/snapcraft.yaml#L68
<psftw> ^ installs the PPA to host to support the build process
<psftw> should I just prepend "sudo" to appropriate commands ?  wonder if that would work on the launchpad build machines.
<ogra> i think in LP it simply runs as root anyway
<ogra> there are no users in the buildd setups
<psftw> thank you, will give it a shot
<ogra> koza, oh, interesting fact (not relevant for your prob though) is that serial doesnt accept any input
<koza> ogra, could not unmount indeed (slow re still in a mtg)
<ogra> koza, yeah, no worries i'm noot impatient :)
<ogra> *not
<ogra> hmm, i really wonder why my serial only has output ... but no input
<morphis> niemeyer: spread-13 it is now
<niemeyer> morphis: On it
<morphis> niemeyer: thanks!
<niemeyer> morphis: The image is 1.7G
<morphis> niemeyer: 1.2G is it for me, again block-level thing but nothing more I can cleanup
<niemeyer> morphis: Just for comparison
<morphis> ah ok
<niemeyer> ubuntu 16.04, is 608MB
<niemeyer> 32 bits is 872
<niemeyer> 16.10 is 610
<niemeyer> fedora is 1.4GB, opensuse is 1.5, and now arch is 1.7GB
<ogra> crazy ... why are they so excessively big ?
<niemeyer> morphis: What might be going on there?  Block or not those images are growing and growing
<niemeyer> morphis: We have a limit in how much we can take in space, not to mention those bits need to move around
<morphis> niemeyer: I don't really know, I got the image with 1.9G and reduced it to 1.2G
<niemeyer> morphis: All of the sizes above are block wise
<morphis> ok
<niemeyer> morphis: My guess is that either there's data being left around, or that there's a ton of software that is not relevant for our tests in place
<ogra> koza, and just FYI http://paste.ubuntu.com/24849651/ is the serial log of my most recent boot
<morphis> niemeyer: https://paste.ubuntu.com/24849664/
<morphis> that is on the file level
<mup> PR snapcraft#1364 opened: lxd: Inject snapcraft and core snaps into the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1364>
<niemeyer> morphis: Yeah, so 1.2GB on usr.. what is there?
<morphis> niemeyer: usr/lib
<morphis> usr/share is 289M and usr/lib 789M
<niemeyer> morphis: Yeah, so there's likely a *ton* of libraries in there, right? :)
<morphis> the difference to debian/ubuntu is that the packages are not really split into sub packages like -docs etc
<morphis> niemeyer: sure but removing more than I did break the system
<niemeyer> morphis: Yeah, I can understand that removing certain things might break the system.. we don't want to remove those
<niemeyer> morphis: But are you saying that every single library in there is a strict requirement?
<niemeyer> morphis: I'd look for large trees of packages which are not relevant for us
<niemeyer> That's what I did with the Ubuntu images, and why they are small
<niemeyer> I wasn't the one cooking 14.04.. it's 1.45G as well
<mvo> jdstrand: hey, I am looking into porting the sh based tests for snap-confine current, I put a bunch of things into the unit tests, I wonder if you have suggestions/opinions about the spread based part of this, one way would be a direct port like https://github.com/snapcore/snapd/pull/3431/commits/5dafe3f80c0afc1378be975f5a14d7c27c03d3b2#diff-c0e64403c5c43941d93df36f87c53bb5R6 but that feels slightly overkill to do for all the old sh-based tests,
<mvo> how do you feel about it?
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<morphis> niemeyer: https://paste.ubuntu.com/24849689/
<mvo> jdstrand: maybe can can have a short HO or something later to discuss how to best test this
<morphis> niemeyer: that are the packages which are left
<fgimenez> hey jdstrand, i needed to add some changes to the test-snapd-autopilot-consumer snap, could you please take a look (no rush at all)? https://dashboard.staging.snapcraft.io/dev/snaps/8405/rev/5/ if you can take a look to prod too (same snap) that would be great https://dashboard.snapcraft.io/dev/snaps/7807/rev/2/
<niemeyer> morphis: Pretty small.. still, have you tried to take stuff out of there?
<morphis> niemeyer: sure
<niemeyer> morphis: licenses is likely just the text.. reiserfsprogs would be surprising to be a requirement, etc
<niemeyer> morphis: tzdata, we don't care
<morphis> but that one is really just 577kb
<morphis> tzdata breaks glibc
<morphis> hm, why was make still in there but 1.47M just
<niemeyer> morphis: Yes, the difference between size bit-wise and size block-wise is that every block is 4kb..
<niemeyer> morphis: make isn't a big deal.. we'll need to get it in anyway
<mup> PR snapd#3475 opened: Change main store host to api.snapcraft.io <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3475>
<niemeyer> morphis: The 320MB in var.. what are they mostly about?
<mup> PR snapd#3476 opened: snap-confine: validate SNAP_NAME against security tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/3476>
<pstolowski> zyga-suse, ^ when you have a moment..
<mvo> jdstrand: I get some lunch now, lets catchup later
<zyga-fedora> yep, looking
<zyga-fedora> pstolowski: make fmt
<pstolowski> zyga-suse, note, I deliberately removed two "paranoid" checks, not sure if they were adding any value at that point.. just repeated cheks
<pstolowski> zyga-fedora, ah, sorry
<zyga-fedora> pstolowski: 2 comments
<pstolowski> thx
<pstolowski> zyga-fedora, done
<zyga-fedora> pstolowski: can you add some tests that show that a valid snap name and valid security tag that don't match are not passing verification please?
<zyga-fedora> pstolowski: perhaps at the end of the test function you modified
<zyga-fedora> pstolowski: // Good name and security tags that don't match each other
<zyga-fedora> pstolowski: and then some tests
<pstolowski> zyga-fedora, I added one test
<pstolowski> zyga-fedora, look for "nonmatchingname"
<pstolowski> ah perhaps it belongs to the "..names we know are good" section
<pstolowski> or as you say
<pstolowski> a new one
<jdstrand> mvo: sorry, still heads down in the bpf review
<jdstrand> mvo: ping me when you get back
<zyga-fedora> pstolowski: I added two more comments
<morphis> niemeyer: that is the pkgdb again which I just have temporarily until I logout
<morphis> niemeyer: then /var is down to 24M
<morphis> niemeyer: https://paste.ubuntu.com/24849997/ is the size breakdown per package
<niemeyer> morphis: Cool, thanks
<morphis> but nothing of the top ones can be remove without breaking the system
<niemeyer> morphis: I went ahead and created the image so you're not blocked for the rest of the week
<morphis> niemeyer: really? I am still logged in :-)
<niemeyer> morphis: But this is our largest image yet.. would be nice to drive it down at some point
<morphis> wondering if Linode uses a different fs block size for these images
<niemeyer> morphis: Nope, 4kb
<morphis> right
<morphis> niemeyer: but I agree that these larger images sizes are not really what we want
<morphis> wondering how much is this related to the fact that other distros pay less attention to properly splitting source packages into multiple binary packages
<morphis> niemeyer: found another one, now down to 901M according to df
<niemeyer> morphis: Ah, nice!
<morphis> niemeyer: give me a few more minutes before you snapshot again
<niemeyer> morphis: Sounds good, just ping me.. I'll take the machine off the pool to make sure we're not losing that
<morphis> thanks
<pstolowski> zyga-fedora, pushed
<zyga-fedora> pstolowski: thanks
<zyga-fedora> pstolowski: +1
<zyga-fedora> pstolowski: I requested a 2nd review from jdstrand
<pstolowski> zyga-fedora, thanks!
<morphis> niemeyer: ok, don't get it much smaller, lets take what we have
<niemeyer> morphis: Ready to snapshot 13?
<morphis> niemeyer: yes!
<niemeyer> Ok, there we go
<niemeyer> morphis: I must be looking at the wrong machine
<niemeyer> morphis: Size didn't change at all
<niemeyer> morphis: It's also suspect that you didn't get logged off earlier
<morphis> ah!
<niemeyer> morphis: Are you still logged in now?
<morphis> niemeyer: yes, which one did you look at?
<niemeyer> :P
<niemeyer> morphis: Okay, we're definitely not looking at the same machine
<niemeyer> morphis: 13..
<morphis> .spread-reuse.yaml tells me 20 .. wtf
<niemeyer> morphis: Aha!
<niemeyer> Okay, let me check
<morphis> niemeyer: don't tell me it's much smaller now :-)
<niemeyer> Well, I hope it is!
<niemeyer> morphis: 1.25G, well done!
<morphis> niemeyer: not well enough :-)
<niemeyer> morphis: Machine back up and running, snapshot done
<morphis> thanks!
<niemeyer> morphis: Thank you!
<morphis> niemeyer: if we don't talk anymore, enjoy your long weekend!
<niemeyer> morphis: Thanks a lot
<Chipaca> niemeyer: 23   Done    2017-06-13T17:04:51Z  2017-06-13T17:04:51Z  [/usr/bin/printf hello]
<Chipaca> niemeyer: also, http://pastebin.ubuntu.com/
<Chipaca> still need to look into aborting it
<niemeyer> Chipaca: Suspect there's a number missing on that second line :P
<Chipaca> maybe
<Chipaca> who knows
<Chipaca> niemeyer: http://pastebin.ubuntu.com/24850224/
<Chipaca> silly "this field is required" error
<Chipaca> niemeyer: the âINFO helloâ thing is noteworthy
<niemeyer> Chipaca: Yeah, I was just thinking about it
<Chipaca> niemeyer: I'm spawning a couple of goroutines and updating the task's log as stdout/stderr change
<niemeyer> Chipaca: I don't think we do that in hooks except when it errors
<niemeyer> Chipaca: WHich is perhaps a good idea
<morphis> niemeyer, zyga-suse, mvo: was there anything special you guys did with the loop-devices each snap create to prevent them from showing up in the desktop launcher?
<Chipaca> niemeyer: probably for the best :-)
<Chipaca> i'll throw away the goroutines and just use a pair of buffers
<niemeyer> Chipaca: +1
<niemeyer> Chipaca: and then, I think we want to tune the summary, but that was probably just for demonstration's purpose, right?
<Chipaca> yeah.... demonstration...
<Chipaca> :-)
<niemeyer> Suppa, thanks
<Chipaca> niemeyer: whoever creates the task sets the summary, so they'd have more context to add
<Chipaca> the task summary itself i think will stay about the same
<niemeyer> Yeah, +1
<Chipaca> (helps debugging)
<Chipaca> the change summary would be the contextual one, i mean
<niemeyer> Chipaca: About the same as what?
<Chipaca> e.g. on the change summary "restarting services: foo1 foo2"
<Chipaca> on the task summary, "systemctl restart snap.foo1.service snap.foo2.service"
<niemeyer> Chipaca: The task summary should follow the style we use elsewhere I think
<niemeyer> Chipaca: Same for the change summaries, actually
<Chipaca> niemeyer: can i have an example?
<niemeyer> Chipaca: We even have a style for when there are too many things to report, IIRC
<niemeyer> % snap changes
<niemeyer> ID   Status  Spawn                 Ready                 Summary
<niemeyer> 488  Done    2017-06-13T12:24:58Z  2017-06-13T12:25:09Z
<niemeyer> Clearly NOT THAT
<niemeyer> Where did the summary go?
<Chipaca> niemeyer: no i mean for the specific case of this
<niemeyer> Bizarre
<Chipaca> I can see e.g. Done    2017-06-12T13:04:42Z  2017-06-12T13:04:42Z  Remove aliases for snap "test-snapd-service"
<niemeyer> Chipaca: Yeah.. Restart service "foo.baz" on snap "baz"?
<Chipaca> niemeyer: so the same as the change summary?
<niemeyer> Yeah, if we have nothing better
<niemeyer> Here are some example for the ghost change above
<Chipaca> so just set by the caller
<niemeyer> https://www.irccloud.com/pastebin/1EgvoizI/
<Chipaca> niemeyer: but a difference is that those tasks are always doing that thing, afaik
<niemeyer> Chipaca: I don't see how that would justify an entirely different style
<Chipaca> whereas this task is always just doing exec of something it doens't know the significance of
<Chipaca> that's why i asked you for an example for this case in particular
<niemeyer> E.g. we literally have a task saying 'Stop snap "lxd" services'  above
<Chipaca> yes, in a task that just does that
<niemeyer> Yeah..?
<niemeyer> I hope all these tasks just do what they claim :)
<Chipaca> my point is that this task gets told âexecute systemctl restart snap.lxd.serviceâ
<Chipaca> which is a long way from "restart lxd services"
<niemeyer> Chipaca: Sorry, I'm trying to be difficult.. I just don't understand the point.. in my mind we have a pretty clear pattern for task summaries, and should follow suit for this one task as well.. all these tasks we see above have different implementation details across each other
<niemeyer> Even then, we have a one-liner summary that is user oriented and worded in similar terms
<Chipaca> niemeyer: can you, please, for the third time, give me a concrete example of what you want this task summary to look like?
<niemeyer> Chipaca: I already provided an example above (17:16).. but I think something even simpler, like "Restart service foo.bar" when it's a single one, or "Restart service foo.bar and bar.baz" when two, or something similar to what we do when aggregating snap names in the API otherwise, should do.. WDYT?
<niemeyer> Chipaca: and again, yes, I think it's fine to have change and task with the same summary if they are indeed matching each other
<Chipaca> thank you
<Chipaca> i needed to be clear on whether the summary was going to get passed in or not
<Chipaca> this does mean we lose track of exactly what was executed, although I guess I could log it
<niemeyer> Chipaca: I don't think we need to log what's executed.. that's an implementation detail, same as for other tasks
<Chipaca> ok
<jdstrand> mvo: hey, since I didn't hear from you, this should make it easier: https://github.com/snapcore/snapd/pull/3431/commits/5dafe3f80c0afc1378be975f5a14d7c27c03d3b2#r121744025
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<pedronis> Chipaca: HookTask gets the summary passed in, IÂ suppose you want the same
<mvo> jdstrand: thanks a bunch, I have some obligations here for at least one more hour, thanks a lot for your comments and also for the verification code!
<mvo> jdstrand: and agreed that it is valuable to have one integration test with bad syntac
<jdstrand> mvo: whenever you get back to it, I gave input for read/stat as well as the path checks. I also responded to Gustavo's comment. basically, check your mail :)
<jdstrand> mvo: I'm continuing to look at this PR
<Chipaca> pedronis: yeap
<jdstrand> mvo: (not saying you haven't checked your mail, just saying more is coming)
<cachio> ogra, do you know another way to increase entropy, I can't reboot the machine so I cant add that command line
<ogra> cachio, not really, but perhaps the security guys do ...
<ogra> tyhicks, jdstrand ^^
<cachio> tx
<tyhicks> cachio: do you have a hwrng device available?
<cachio> tyhicks, I need it for a vm
<mup> PR snapd#3447 closed: debian: unify built_using between the 14.04 and 16.04 packaging branch <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3447>
<cachio> and I need to increase the entropy
<tyhicks> cachio: is the VM using pollinate?
<cachio> I have used pollinate and rngd-tools but we are seeing a segfault which is breaking our tests
<cachio> tyhicks, yes, we are currently using pollinate but we want to change it
<cachio> tyhicks, https://forum.snapcraft.io/t/error-creating-key/964
<cachio> tyhicks, some tests are failing because the entropy is too low and snapd cand generate a key
<cachio> tyhicks, it happens when there is a seg faul as it is described in the forum
<tyhicks> cachio: have you looked into fixing the rngd segfault?
<cachio> tyhicks, no
<cachio> tyhicks, no idea how to do it
<mup> PR snapd#3429 closed: interfaces/snapd-control: also allow use of /usr/bin/snap <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3429>
<tyhicks> cachio: I need some time to read through that forum thread
<tyhicks> cachio: this is not a trivial problem
<cachio> tyhicks, ok, any advice about what I could start doing?
<tyhicks> cachio: not yet - I need to understand your problem
<cachio> tyhicks, ok
<tyhicks> cachio: you said that the tests are running in a VM - do you have admin rights on the host?
<cachio> tyhicks, yes
<tyhicks> cachio: you could set up virtio-rng to feed entropy from the host into the guest via a virtual hwrng
<cachio> tyhicks, ok
<cachio> tyhicks, I'll try with this one
<cachio> tyhicks, virtio-rng is just for virtual environments?
<tyhicks> cachio: yes
<tyhicks> cachio: it is only helpful in VMs where the host has set up a virtio-rng device for the VM
<tyhicks> cachio: what's the oldest version of gpg that you'll need to operate on?
<cachio> tyhicks, I need to run snapd test in real hardware and in vms, that are from different sources, for example we currently used linode in the cloud and qemu
<tyhicks> cachio: then virtio-rng may not work for you
<tyhicks> (you're less likely to hit lack of entropy issues on real hardware but maybe you still have that problem on real hardware)
<cachio> tyhicks, is there any way to feed manually the entropy pool
<cachio> tyhicks, with fake random data?
<tyhicks> cachio: that's what you're doing with rngd
<tyhicks> cachio: fixing the segfault is the easiest solution
<cachio> tyhicks, ok, I'll report it
<tyhicks> cachio: rngd is community maintained (in universe) so it isn't likely to get attention in normal circumstances
<tyhicks> cachio: how urgent do you need it fixed?
<cachio> tyhicks, it is for our snapd test suite
<cachio> there are several tests failing because of that
<tyhicks> cachio: ok - first step is to report the bug
<tyhicks> cachio: then we'll all need to figure out who is going to work on fixing it
<tyhicks> rngd is simple so I'm hoping the fix won't be too difficult
<cachio> tyhicks, well that's something really good
<cachio> niemeyer, we were discussing a solution to the lack of entropy problem
<niemeyer> cachio: hey
<niemeyer> cachio: Ok, and what's up there?
<cachio> niemeyer, so, the best approach to deal with this is to fix the issue that it is causing the segfault in rngd
<tyhicks> to be clear, the rngd hack of using /dev/urandom as the HWRNG device should only be used for testing environments
<cachio> tyhicks, of course, this is our case
 * tyhicks nods
<cachio> niemeyer, so the change that I did, won't be needed
<niemeyer> cachio: Yeah, that's the most reasonable.. but what's the ETA for the fix?  Do we need to do anything meanwhile to make sure we're not getting tests hanging?
<cachio> niemeyer, we can leave my patch with the note, and once it is fixed, I'll remove it
<cachio> niemeyer, I know it is not the best approach
<cachio> niemeyer, but it is a temporal workaround
<niemeyer> cachio: That has the issues we discussed.. can we cheaply do one of the changes we discussed today?
<niemeyer> cachio: In practice that fix will take a long time to propagate to all the kernels we care about
<niemeyer> Ah, not kernels, it was rngd isn't it?  Either way, same case
<tyhicks> niemeyer: the fix will be to rngd, not the kernel, but your point still stands
<cachio> niemeyer, the change is in rngd
<niemeyer> Anybody else? ;)
<tyhicks> :)
<tyhicks> niemeyer: is it possible for you to pre-generate a key that will be used for all test runs?
<tyhicks> (include it in the test suite and put it in place before each test run)
<cachio> tyhicks, the issue is that there are tests that are testing the create-key
<cachio> tyhicks, so, for those cases we can't pregenerate the keys
<tyhicks> cachio: it isn't necessarily correct to pump up the system with fake entropy for those tests, either
<tyhicks> in the field, create-key will be used on low entropy systems
<tyhicks> (there's no perfect solution to this problem)
<tyhicks> the create-key tests could be skipped when /proc/sys/kernel/random/entropy_avail is below a certain threshold
<cachio> tyhicks, well that could be a solution
<cachio> niemeyer, what do you think?
<tyhicks> possible permanent solutions:
<cachio> niemeyer, we can't pre-create keys, manually feed the pool is not cheap
<tyhicks> 1) fix rngd (fix has to propagate to all affected distros that you test on)
<tyhicks> 2) write your own version of rngd that knows how to feed fake entropy to /dev/random
<tyhicks> 3) remove /dev/random and mknod it back using the device major/minor of /dev/urandom (I'm not certain that this will work)
<cachio> tyhicks, well, how much effort should be needed for 2)
<cachio> ?
<niemeyer> cachio: We don't want to skip the test like this.. otherwise this might be completely broken and we'll never know
<tyhicks> cachio: crack open the rngd sources to see - you'd essentially be forking it
<niemeyer> tyhicks: How to feed entropy into the kernel?
<niemeyer> tyhicks: If it's just a matter of piping data somewhere, which I hope it is, it might be much simpler than forking rngd
<tyhicks> niemeyer: it is an ioctl()
<tyhicks> niemeyer: the random(4) man page details it
<tyhicks> the Configuration section of that man page also touches on my option #3 above (the mknod command)
<tyhicks> I need to get back to some other work now
<tyhicks> I hope those suggestions are helpful
<cachio> tyhicks, sure, tx
<niemeyer> tyhicks: Indeed, thanks
<niemeyer> cachio: You said earlier we already had the /dev/random trick at the pepare level?
<cachio> niemeyer, yes
<niemeyer> cachio: If that's the case, why are we redoing it in that function?
<cachio> niemeyer, it is because the entropy pool is cleaned when the segfault happens
<cachio> niemeyer, I could make something generic, to regenerate entropy when is it under 700 for all the tests
<niemeyer> cachio: Yeah, I get it, but isn't the /dev/random tweak already in place?
<cachio> niemeyer, it is done at the begening of the test suite
<niemeyer> cachio: Yes, so why do we need to do that every time the function is called?  Why isn't it simply a restart?
<cachio> niemeyer, you mean just to restart it? not check for the entropy level?
<cachio> niemeyer, for each test?
<niemeyer> cachio: Why do we have that environment line change every time
<cachio> niemeyer, echo "HRNGDEVICE=/dev/urandom" > /etc/default/rng-tools =
<cachio> this one?
<niemeyer> Yes :)
<cachio> niemeyer, it can be done just the first time
<cachio> in the prepare
<niemeyer> cachio: Then, I don't think I get the whole picture.. when it crashes, it restarts, right?
<cachio> when it crashes it does not restart
<niemeyer> cachio: Oh?
<cachio> niemeyer, that's why I am doing this
<niemeyer> cachio: Why would it not restart?  Isn't it a systemd unit as usual?
<cachio> you mean rng-tools?
<cachio> I'll take a look to see why it is not restarting
<niemeyer> cachio: Thanks
<niemeyer> cachio: Maybe that's the only thing we need to fix
<ryebot> My snap has a configure hook that attempts to write to the file $SNAP_DATA/args. Most of the time it works, but on some (identical) lxc containers, I get an apparmor denial: http://bit.ly/2reFFt5
<ryebot> Any idea what might be going wrong, and why it's not going consistently wrong?
<kyrofa> ryebot, that should be non-fatal, it's a snapctl denial, nothing to do with you directly
<kyrofa> It's noisy though, and last I heard work was ongoing to fix it
<ssbash> hey if anyone has a second I'm still having trouble with getting my python path wrapper command to work?
<ryebot> kyrofa: thanks
<ssbash> here is the bash script: http://paste.ubuntu.com/24851223/ snapcraft.yaml: http://paste.ubuntu.com/24851218/ and the error message:http://paste.ubuntu.com/24844781/
<mup> Bug #1697770 opened: can't run juju from snap: "Too many levels of symbolic links" <Snappy:New> <https://launchpad.net/bugs/1697770>
<ssbash> cachio? do you see any probkems with my bash script or snapcraft.yaml?
<ryebot> kyrofa: Alright, red herring apparmor logs aside, any reason my snap wouldn't be able to write to $SNAP_DATA? http://bit.ly/2rXVwzm
<kyrofa> ryebot, no, that seems weird indeed. Can I take a look at the configure hook itself?
<ryebot> kyrofa: certainly, one second
<ryebot> kyrofa: http://paste.ubuntu.com/24850838/
<kyrofa> Huh, yeah, I really have no explanation for that. Particularly why it's flaky. I assume you've verified that the only denial you're seeing is the snapctl one?
<ryebot> kyrofa: let me check. I've also been advised to check the host as well, so let me do that too.
<cachio> niemeyer, so, basically, rng-tools tools is not configured to restart after a crash
<cachio> it is stopped when the crash happens
<kyrofa> ryebot, ahhhh, running in lxc?
<cachio> niemeyer, so I can make some changes to autorestart, but it could have different implementations based on the distro
<cachio> niemeyer, or I can check in the prepare-each if the service is stopped and start it again
<cachio> once I start it the entropy is recovered
<ryebot> kyrofa: yes
<ryebot> kyrofa: sorry, second time I haven't made that clear enough in these parts :\
<kyrofa> ryebot, yeah I run snaps on lxc as well, snapd doesn't run quite right there
<kyrofa> ryebot, typically you don't need to. But snapd and lxc share a lot of the same tech, and they don't always get along
<ryebot> gotcha
<ryebot> anyway, yeah, only snapctl
<ryebot> kyrofa ^
<kyrofa> Nothing on the host either?
<ryebot> correct
<kyrofa> ryebot, sorry, I really don't know what's happening. You'll need to wait for someone in snapd
<ryebot> kyrofa: no worries, thanks for reaching out!
<kyrofa> It'd be nice to see snapd add lxc to their test suite
<kyrofa> Weird breakages will probably continue until that happens
<bdx> is there a ruby/rails plugin laying around anywhere?
<kyrofa> bdx, ruby is pretty easy, talk to elopio. Rails is a little harder because bundler likes symlinks
<kyrofa> I just haven't gotten the time to finish one. I'd love to see one though, if you work on it
<bdx> kyrofa: I've been looking into it pretty heavily ..... I'm having trouble understanding what I need to do in the snap world to even start ....
<bdx> kyrofa: so, 1) need ruby - it would be best to create a plugin for ruby im guessing
<kyrofa> bdx, yes, that's something elopio is working on. I suppose bundler support could be added there, in which case it would work for rails as well
<kyrofa> Obviously Gemfiles are not unique to rails
<bdx> then use the ruby plugin and the git plugin together
<bdx> yeah
<kyrofa> There is no git plugin-- those are sources. You won't need to do anything special there, they're part of core snapcraft
<bdx> kyrofa: awesome
<kyrofa> bdx, here, let me show you an example, but you really should talk to elopio about the ruby plugin, I know he was wanting to work with someone to do it
<bdx> kyrofa: great thanks
<kyrofa> bdx, how familiar are you with ruby, by the way?
<bdx> kyrofa: I can read and write it, but dont prefer it ... I have 30+ prod rails deploys via charms
<bdx> so my rails charms are on point - i feel like this would set me up to be ready to snap them
<kyrofa> Indeed
<kyrofa> bdx, here's the cmake plugin as an example: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/cmake.py
<kyrofa> bdx, here's some basic info for how to write plugins and test them in your own tree instead of needing to patch snapcraft: https://snapcraft.io/docs/build-snaps/plugins
<bdx> excellent, thanks for these
<bdx> would lthe nodejs plugin be more similar you think?
<ssbash> http://paste.ubuntu.com/24851807/
<kyrofa> Yes perhaps so. I do think we should support multiple versions of ruby
<bdx> it seems like nodejs would be more similar in the sense that there are multiple versions of node that the plugin should be able to handle
<kyrofa> Yep
<ssbash> hi can someone explain why my snap is deliberly ignoring the python path i've set for it?
<nacc> ssbash: if you run snap run --shell and then run your command with your pythonpath set, you should be able to debug it live
<bdx> kyrofa: I'm also wondering how much the gemfile should matter .... some consider it a best practice to define their ruby version in their gemfile
<kyrofa> bdx, interesting, I've never done that. What tool consumes it? Bundler can't install it, right?
<kyrofa> I'd lean more toward using .ruby-version like what rvm might place there
<bdx> elopio
<ssbash> nacc: I tried running env to seee what the pythonpath was, and it print out "PYTHONPATH=:/snap/wsnap/x1/lib/python3.5/site-packages"
<bdx> elopio: I would love to connect concerning a ruby snap - jamesbeedy@gmail.com
<bdx> so
<bdx> kyrofa: http://imgur.com/a/g44Sb
<ssbash> everything seems to be set correctly, I have no idea why the snap command isnt working
<bdx> I think it acts more like a stop check
<bdx> if your rubyversion doesnt match, bundler wont install
<nacc> ssbash: but now your PYTHONPATH doesn't include the dist-packages? what is the error you get?
<ssbash> "ImportError: No module named 'wraticus.lib'; 'wraticus' is not a package"
<kyrofa> bdx, interesting, okay. I say keep it simple in the first rev, just accept a `ruby-version` option, fetch the source, and build it
<ssbash> wraticus is definitely in the site-packages directory
<kyrofa> bdx, then we can start looking into those things once we have a basic plugin working
<nacc> ssbash: ok, in your snap shell, run python and try to import wraticus
<nacc> ssbash: and then try to import wraticus.lib
<bdx> kyrofa: entirely ... I'll keep investigating, and try to get in touch with elopio
<kyrofa> bdx, I've given him your contact info in another channel as well, he's probably out to lunch
<kyrofa> Please let me know if I can help
<ssbash> nacc: I'm able to import both wraticus and wraticus.lib
<nacc> ssweeny: hrm
<bdx> kyrofa: your insight has been super helpful, thanks. I'm going to give the cmake and nodjs plugins a glance over this evening and try to get a strwman up
<kyrofa> bdx, any time :)
<bdx> I'll send you guys a ping tomorrow (hopefully with some progress)
<kyrofa> Good deal, I'll be here!
<ssbash> nacc: is there anything I can do? here is my snapcraft.yaml for reference: http://paste.ubuntu.com/24851218/
<bdx> kyrofa: so you think I should keep away from system ruby, and look to use a ruby version manager instead, due to the ease of changing versions etc etc?
<kyrofa> bdx, I definitely suggest not using system ruby. As for what TO use, well, I'm not sure. First cut I'd just build ruby from source
<nacc> ssbash: and what does snapify.sh contain?
<kyrofa> bdx, I doubt any ruby version manager is going to support deploying that ruby somewhere specific, whereas you can always install ruby in a snap
<nacc> ssbash: and if you run snapify.sh from your shell session, does it work?
<ssbash> nacc: http://paste.ubuntu.com/24851223/
<kyrofa> bdx, for example, rvm supports per-user rubies and system-wide rubies, but not "put that ruby <here>" as far as I know
<ssbash> nacc: running it from the shell session gives me the same "ImportError: No module named 'wraticus.lib'; 'wraticus' is not a package"
<nacc> ssbash: line 2, should be PYTHONPATH=$PYTHONPATH:...
<nacc> ssbash: you are removing the dist-packages from your path :)
<nacc> ssbash: specifically, the wrapper that's calling your wrapper is (i think) setting the snap's dist-patckage in the path and you're then eliding them
<bdx> kyrofa: yeah ... I was thinking more along the lines of a simple api via the plugin that manages ruby versions through the version manager
<ssbash> oh ok
<bdx> but yeah possibly not ... I'll just try to get something super basic working
<kyrofa> bdx, well, the plugin (and snapcraft in general) is only involved when creating the initial snap. Once the snap it created, it needs to be standalone
<bdx> I see
<ssbash> nacc: ill give it a try
<kyrofa> So the ruby must be in the snap at the end, regardless of how you get there
<bdx> so the plugin cant offfer up an api that can be used throughout the lifecycle of the snap?
<bdx> I see
<kyrofa> Right, the plugin is gone by the time the snap is running. Snapcraft builds snaps, and has nothing to do with running them (that's snapd)
<bdx> possibly the plugin could grab the ruby version from the Gemfile if it exists then, and just download and build that version of ruby
<kyrofa> Right
<kyrofa> (though it'd be easier to just start with the user telling the plugin "give me this version of ruby"
<kyrofa> )
<bdx> yeah, ok
<ssbash> nacc: still not working, I'm getting the same error
<ssbash> could it be an issue with my setup.py file? where are python packages supposed to be installed by default
<kyrofa> ssbash, have you tried just via pip? Ignoring snaps all together? Does it work then?
<nacc> kyrofa: good enough
<nacc> kyrofa: err, good idea! rather :)
<ssbash> kyrofa: this package is a local. It's not on pip.
<kyrofa> ssbash, I mean the typical: make a virtualenv, source it, pip install .
<kyrofa> Or setup.py install if you prefer
<niemeyer> cachio: Isn't it super trivial to setup systemd units to restart on crash? I think that's actually the default behavior isn't it?
<ssbash> kyrofa: it works in my virtualenv.
<kyrofa> ssbash, is your code public? Can I take a look?
<ssbash> its not public, the best I can do is share the directory layout http://paste.ubuntu.com/24852053/
<kyrofa> Yeah that doesn't help I'm afraid
<ssbash> kyrofa: oh ok thank you for your input
<cachio> niemeyer, it is not a systemd unit
<cachio> it is a system v service
<niemeyer> Okay, so maybe that's the fix? Making it one?
<cachio> niemeyer, well, that should not be difficult but not sure for other distros
<cachio> niemeyer, I'll give a try
<niemeyer> cachio: Thanks! It might end up nicely as we won't have to worry about it anywhere else
<cachio> niemeyer, It is a systemd service too, and it is configured to "no restart" :)
<cachio> niemeyer, I'll change that
<niemeyer> So all you need is an override file
<cachio> niemeyer, yes
<cachio> or replace Replace=no with Replace=always
<elopio> bdx: hello! With kyrofa we made this to get started: https://github.com/travis-ci/travis.rb/pull/515/files
<elopio> bdx: now we want to turn it into a plugin. Your help there would be awesome.
<elopio> cjwatson: build.snapcraft.io should be able to find the snapcraft.yaml when it's in the root, right?
<elopio> ah, nevermind. The problem is that it's not in the master branch.
<cjwatson> elopio: Yeah I must finish the branch to at least allow a different default
#snappy 2017-06-14
<mup> PR snapd#3477 opened: tests: fix snap create-key by restarting automatically rng-tools <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3477>
<chrisblazek> hello, looking for support to get i2c enabled for snappy
<chrisblazek> is it possible, if so, how do I go about enabling it? thanjs
<chrisblazek> welp
<zyga-suse> good morning
<mup> Bug #1697880 opened: Add "search" as an alias for "find" in snap command <Snappy:New> <https://launchpad.net/bugs/1697880>
<Chipaca> niemeyer: feedback on bug 1697880 appreciated
<mup> Bug #1697880: Add "search" as an alias for "find" in snap command <Snappy:Confirmed> <https://launchpad.net/bugs/1697880>
<Chipaca> good morning all
<pstolowski> o/
<zyga-ubuntu> hey
<Chipaca> what's the expected state of a change after an "abort" succeeds?
<morphis> didn't we mark the interfaces-openvswitch spread test as manual? I see it failing again a numer of times today
<morphis> fgimenez: ^^
<fgimenez> morphis: afaik the PR for marking it as manual was finally closed because other fixes seemed to solve the openvswitch flakyness, sergio knows the details better
<morphis> fgimenez: hm, whatever was changed I still see it timing out
<fallentree> Hey all. Question. I'd like to deploy a python application as a snap, for our clients. I want to host X instances of each, per server. They're all the SAME application, but different client and different config. Is it possible to install a single snap multiple times (presumably with different names)?
<mvo> zyga-ubuntu, zyga-fedora: snap-confine in the bind mount magic sets up /var/lib as a symlink, correct?
<zyga-ubuntu> mvo: not quite
<zyga-ubuntu> mvo: /var/lib is a tmpfs and there's a symlink farm to the core snap and to (on classic) one specific location in hostfs
<zyga-ubuntu> mvo: why? anything broken?
<mvo> zyga-ubuntu: mostly wondering about the permissions, they are quite permissive 1777
<Chipaca> pedronis: you around?
<pedronis> Chipaca: yessish, had a bit of hard time sleeping last night
<Chipaca> pedronis: ouh :-(
<Chipaca> pedronis: I don't know how to properly abort a task it seems, as its change either ends up in Done or in Error
<Chipaca> pedronis: but it's not urgent if that's too ish-y
<pedronis> Chipaca: abort in which sense ?
<Chipaca> i've got plenty of other things to work on :-)
<Chipaca> pedronis: 'snap abort nn'
<pedronis> what do you expect ?
<Chipaca> pedronis: shouldn't it say something other than Done or Error in snap changes if you've successfully aborted it?
<pedronis> no,  you get the abort, cannot finish, return error -> Undo the rest -> Error
<pedronis> at least that's how hook do this for example
<ogra> koza, did you get anywhere yet ? btw ... http://people.canonical.com/~ogra/hummingboard-gate-serial.jpg
<pedronis> Chipaca: AbortStatus is not a final status, is just  a marker status  afaiu
<Chipaca> yeap, it's Abort not Aborted
<koza> ogra, hey, nowhere near; replaced hdmi cable and microSD card; tried images, etc.. notning new
<ogra> damn ...
<pedronis> Chipaca: this are ready states:   DoneStatus, UndoneStatus, HoldStatus, ErrorStatus
<ogra> koza, there seems to be a difference between revisions. mine has "REV1.2" printed next to the name on the PCB
<koza> ogra, rev1.2 is here too
<ogra> koza, do you know if solid run offers any reference images ... and did you try one yet to make sure it isnt a HW issue ?
<koza> ogra, no I did not and I do not know of any. Trying to get this info from Linaro folks who - I have been told - are using this board.
<ogra> koza, seems there are https://wiki.solid-run.com/doku.php?id=products:imx6:software:os:debian
<ogra> https://images.solid-build.xyz/IMX6/Debian/
<koza> ogra, are you sure about tX and RX, here http://download.solid-run.com/pub/solidrun/HummingBoard%202/HummingBoard2%20Schematics%20rev%201.2.pdf They say TX is in the middle (Page 2, search for J25) and you marked RX there
<ogra> koza, yes, i am ... i got it wired like this here
<koza> ogra, ok, just double checking
<koza> yes, good idea try this debian img
<ogra> white is definitely in the middle ... i had initially mixed up gnd and green, that works but doesnt recognize input (obviously ... if TX is wrong :P )
<ogra> so i'm 100% sure thats the correct wiring
<koza> got it
<mup> PR snapd#3478 opened: tests: extend upower-observe test to cover snaps providing slots <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3478>
<Chipaca> pedronis: should this manager auto-abort things when it's told to stop?
<pedronis> Chipaca: that should happens automatically
<Chipaca> pedronis: it doesn't seem to
<pedronis> task runner kills on the tombs
<pedronis> s/on the/all the tombs/
<Chipaca> pedronis: i'll push code in a bit to see if i'm doing something wrong
<ogra> ppisati, is there any reason why our linux-generic armhf build doesnt enable any allwinner SoCs ?
<ogra> (seems there are many upstreamed already, but not enbled)
<ogra> *enabled
 * zyga-ubuntu finally groks async/await python
<Chipaca> pedronis: i'm definitely doing something wrong :-) if you could take a look at https://github.com/snapcore/snapd/compare/master...chipaca:oddjob it'd be helpful
<Chipaca> pedronis: the failing test is the one with printlns in it; it never gets past the "before stop" line
<Chipaca> i thought it was waiting for the exec to finish (as i had a "sleep 1h" in there originally), but it's not that
<Chipaca> wait maybe it's the lock
<Chipaca> dammit
 * zyga-ubuntu hugs Chipaca 
<Chipaca> pedronis: fixed the lock issue, pushed, still have questions (TestExecStop fails, with the change still in Doing)
<morphis> fgimenez: another failure of the openvswitch test: https://travis-ci.org/snapcore/snapd/builds/242746311
<fgimenez> morphis: does this happen only on debian? we could disable it only on that system if that's the case
<morphis> fgimenez: I saw it on ubuntu and debian today
<morphis> so doesn't seem to be specific to a system
<fgimenez> morphis: ok, i'll propose a PR for marking it as manual
<morphis> thanks
<mup> PR snapd#3479 opened: tests: mark interfaces-openvswitch as manual due to prepare errors <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3479>
<pedronis> Chipaca: just a heads up, I think there are some thing the that don't follow naming conventions
<Chipaca> that's ok, i can change the conventions :-P
<pedronis> Chipaca: EnsureBefore doesn't do anything interesting if you don't use overlord.Loop or Settle fwiw
<Chipaca> I might have just copied that from my testing code in api.go (not committed)
<zyga-ubuntu> morphis: I need to skip our call today
<pedronis> Chipaca: you are hitting the new code that make sure we retry downloads across stopping of snapd
<pedronis> Chipaca: Stop provoked errors are turned into Retry
<Chipaca> ahh
<pedronis> let me give you a pointer
<Chipaca> yes i saw that code but it didn't click
<morphis> zyga-ubuntu: ok
<pedronis> Chipaca: here, https://github.com/snapcore/snapd/blob/master/overlord/state/taskrunner.go#L168
<sborovkov> ogra: hello, you said you were doing something about splash screen support so wanted to ask you if you saw this linker error? (I added #define CONFIG_SPLASH_SCREEN to include/configs/rpi.h) /build/snaps/pi3-gadget/u-boot/common/splash.c:94: undefined reference to `bmp_display'
<Chipaca> pedronis: easiest approach is to just document them as retried on stop, then :-)
<ogra> sborovkov, nope, did you set CONFIG_CMD_BMP in your config ?
<pedronis> Chipaca: Stop != Abort basically
<pedronis> not sure it makes sense for all potential uses of Exec
<pedronis> but that's the current state of things
<sborovkov> ogra: yeah that fixed that error. I did not add that define because wiki page said that by enabling splash screen bmp support would be enabled automatically
<ogra> the internet is full of lies ;)
<Chipaca> pedronis: agreed on that
<Chipaca> pedronis: wrt naming conventions, you meant about Manager/NewManager vs OddJobManager/Manager, or something more than that?
<pedronis> yes
<pedronis> that sort of stuff
<pedronis> and oddjob vs oddjobstate
<Chipaca> ah
<pedronis> and splitting oddjob.go into two
<pedronis> files
<Chipaca> does it deserve the "state" ending?
<pedronis> well  it makes manager, all the things with one have that name
<pedronis> and yes everything now has *state/*state.go vs *state/*mgr.go
<pedronis> afaict
<Chipaca> ok
<pedronis> Chipaca: and *mgr  has manager and handlers (unless and there's a lot and then we have handlers.go)  and *state has things making Tasks/Tasksets and query function helper taking state.State
<sborovkov> ogra: after rebuilding uboot, the only binary I should replace in the gadget snap should be uboot.bin? I see that there is a bunch of other binaries but I am not sure where they are coming from
<pstolowski> jdstrand, hi! do you have a moment to take a look at https://github.com/snapcore/snapd/pull/3476 ? it's a small change
<mup> PR snapd#3476: snap-confine: validate SNAP_NAME against security tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/3476>
<ogra> sborovkov, yeah ... i usually do my development on a running install and just replace it on the system-boot partition ...
<sborovkov> ogra: thanks
<ogra> only uboot.bin should be fine (make sure you have the uboot.ppatch in use though, else it wont find uboot.env)
<ppisati> ogra: no real reason, we just didn't have any hw to test it
<Chipaca> pedronis: would it be reasonable to have a helper in oddjobstate that did an NewChange and the whole dance?
<pedronis> Chipaca: we don't do that usually
<ogra> ppisati, but it wouldnt break any existing stuff to enabled it, would it ?
 * ogra is just rebuilding a test deb here with just allwinner SoC turned on in the config 
<ogra> (i have a banana pro here that i never booted, and orange pi and nano pi ordered ... )
<ppisati> ogra: are you on a board spree? :)
<ppisati> ogra: if it's multiplatform, it should be ok
<ogra> ppisati, kind of ... i'm waiting for some 96boards to get delivered ... and since that takes so long i boredly start to add other boards :)
<ppisati> ogra: nonetheless, when you have something that works for you, we'll test on all the supported hw
<ogra> cool
<ogra> i'll let you know
<Vamsi_> Hi! I am a trying to install ubuntu core on Raspberry pi 3. I am facing an error during the installation in that, it is not accepting my email address. This is the error I am facing
<Vamsi_> Creating user failed:  error: while creating user: cannot create user "email ID": Get https://login.ubuntu.com/api/v2/keys/emailID: dial tcp: lookup login.ubuntu.com on 10.58.194.16:53: no such host
<zyga-fedora> Vamsi_: this looks like DNS issue
<zyga-fedora> Vamsi_: are you using the wifi connection?
<Vamsi_> nope. I am using a wired internet connection.
<Vamsi_> zyga-fedora: What could be the possible error? Becuase the error was reported the 1st time after it took a while to contact the server.
<zyga-fedora> no such host indicates that this is a DNS issue and that login.ubuntu.com is the domain that cannot be resolved
<Vamsi_> Okay. Please don't mind me asking, but I am what I call as a noob_level developer. So could you please guide me as to how to solve this issue?
<zyga-fedora> Vamsi_: I don't know, try checking your network
<Vamsi_> okay. thank you.
<ogra> yeah, sounds like a network issue
<mup> PR snapd#3480 opened: overlord/oddjobstate: new package for running commands as tasks <Created by chipaca> <https://github.com/snapcore/snapd/pull/3480>
<ogra> Vamsi_, the network config worked without any error on the page before ?
<Chipaca> pedronis: ^ PR up
<Vamsi> ogra: yup. No error on page.
<ogra> thats weird ... it should work (surely does for me, i do regular test installs of the pi ... though using the daily edge image)
<ogra> Vamsi, is 10.58.194.16 a properly working nameserver in your LAN usually ?
<ogra> seems that is what your board gets as DNS entry (judging by the error message)
<Vamsi> yup. It is a properly working name server
<ogra> well, the error looks like it can not resolve "login.ubuntu.com"
<ogra> do you have another machine that uses this DNS server where you could check if you can reach login.ubuntu.com ?
<Vamsi> Yes I have another machine. Although... um... How do I check this?
<ogra> just try "ping login.ubuntu.com" or if you have a desktop/UI on thereand a browser, go to login.ubuntu.com in there
<Vamsi> tried this on another linux machine and this is what I got:
<Vamsi> --- login.ubuntu.com ping statistics ---
<Vamsi> 10 packets transmitted, 0 received, 100% packet loss, time 9198ms
<ogra> hmm
 * ogra just notices that he cant ping that either ... but a browser works
<ogra> seems the login.ubuntu.com machine simply denies pings ... so a ping wont help as test
<ogra> Vamsi, better try: wget http://login.ubuntu.com/
<ogra> that should download an index.html file
<ogra> and you should see "200 OK" somewhere in the output when you run this
<Vamsi> Yup I see 200 OK.
<ogra> ok, then it isnt the DNS server
<ogra> hmm
<Vamsi> Okay! I realised the mistake I was doing.
<ogra> Vamsi, oh, wait, did you literally type "emailID" into the user field in the setup screen ?
 * ogra just noticed the url :)
<Vamsi> I was using a different network for my notebook as compared to the one for the raspbery pi
<ogra> ah
<Vamsi> The network I was using for the raspberry pi was one with a number of restrictions.
<ogra> yeah
<Vamsi> ogra: After you suggested the wget http://login.ubuntu.com/ i noticed that the address was different and that's when I realised that I was using a different network.
<ogra> :)
<Vamsi> Thanks mate!
 * ogra crosses fingers that it works with the new network
<jdstrand> pstolowski: yes
<mup> PR snapd#3481 opened: tests: add avahi-observe interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3481>
<Vamsi> ogra: Okay. Now I am stuck at another place. The installation is now stuck in the page that lists all the host key fingerprints
<ogra> Vamsi, that isnt stuck, it means you are finished ... there should be an ssh command in the output that you can use to connect to your board
<Vamsi> oh okay. Thanks. I actually did connect to my board now. I was expecting to automatically to restart or omething.
<Vamsi> Thanks :)
<ogra> enjoy :)
<mup> PR snapd#3482 opened: asserts: support timestamp and optional disabled header on repair <Created by pedronis> <https://github.com/snapcore/snapd/pull/3482>
<pedronis> mvo: Chipaca: ^
<mvo> pedronis: thanks
<mvo> pedronis: I check it in a wee bit, still wrestling with seccomp and snap-confine :/
<pedronis> Chipaca: will we still need snapd#3462 ?
<mup> PR snapd#3462: systemd: refactor service ops to also be exposed more directly <Created by chipaca> <https://github.com/snapcore/snapd/pull/3462>
<mup> PR snapd#3462 closed: systemd: refactor service ops to also be exposed more directly <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3462>
<Chipaca> pedronis: maybe not, but I might pull some of the commits into a new pr instead
<pedronis> ok
<Chipaca> hurra for being more careful with my commits \o/
<sborovkov> ogra: how do you even get into autoboot console on the rpi? at least for me even though it says press any key to cancel autoboot it just goes on with booting no matter what I am pressing on my keyboard
<ogra> sborovkov, is it actually counting down ?
<ogra> might be we did set bootdelay=0 because it causes issues with addon boards
<sborovkov> ogra: i even tried increasing it to 15 seconds... but nothing happens
<ogra> so you would need to set bootdelay to something higher ... on the running pi you can use "fw_printenv/fw_setenv"
<ogra> hmm
 * ogra has no pi wired up atm ... 
<ogra> https://github.com/snapcore/pi3-gadget/blob/master/prebuilt/uboot.env.in says we default to bootdelay=2 though
<ogra> sborovkov, and you are sure your serial is wired up correctly ?
<sborovkov> ogra: I set it to 15 in the boot settings :-) Ok I guess something wrong with my setup
<ogra> check if you accidentially flipped TX and GND wires
<mup> PR snapd#2592 closed: many: add support for session dbus services via snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2592>
<morphis> zyga-fedora, zyga-ubuntu, mvo: can you guys review and approve https://github.com/snapcore/snapd/pull/3479 ?
<mup> PR snapd#3479: tests: mark interfaces-openvswitch as manual due to prepare errors <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3479>
<zyga-fedora> looking
<zyga-fedora> merged
<mup> PR snapd#3479 closed: tests: mark interfaces-openvswitch as manual due to prepare errors <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3479>
<mup> PR snapd#3460 closed: ifacestate: only re-generate all security profiles if the system-key changes <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3460>
<mup> PR snapd#3468 closed: debian: add missing  Type=notify in 14.04 packaging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3468>
<mup> PR snapd#3469 closed: many: add "release.BuildStamp" to identify the current build <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3469>
<mup> PR snapd#3471 closed: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3471>
<pedronis> Chipaca: do we need timeout support for those Exec tasks, like we have for hooks ?
<Chipaca> hmmm
<Chipaca> pedronis: I don't think we do right now
<pedronis> Chipaca: ok, I'll do the actual full reviewing tomorrow
<Chipaca> pedronis: no worries
<Chipaca> pedronis: try to get some sleep
<mup> PR snapcraft#1183 closed: First step; ruby support <Created by justincan> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1183>
<Chipaca> zyga, out of the blue (no core refresh) 'snap try' stopped working again
<Chipaca> and snap install
<Chipaca> (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented) followed by (cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented)
<Chipaca> zyga-fedora: zyga-ubuntu ^
<Chipaca> how did i fix this?
<kyrofa> Haha, no suse today eh?
 * Chipaca purges snapd and starts over
<Chipaca> gah, that didn't work
<bdx> kyrofa, elopio: I have a strawman here https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c
<bdx> how can I test this?
<bdx> kyrofa, elopio: any insight there would be appreciated
<bdx> I'm thinking I need to use the cmake plugin though
<kyrofa> bdx, have you tried using it just as a local plugin?
<bdx> what would my snapcraft.yaml need to look like to do that?
<bdx> I would have a ruby part, with `plugin: x_ruby` ?
<kyrofa> bdx, take this plugin and put it in snap/plugins/x-ruby.py
<kyrofa> bdx, then in snap/snapcraft.yaml, you can use it like `plugin: ruby`
<bdx> got it ... not `plugin: x_ruby`?
<bdx> or `x-ruby`
<bdx> ahh, ok, x_ruby
<kyrofa> No, snapcraft has (flawed, IMO) logic to look for x-ruby.py if you just use "ruby"
<mup> PR snapcraft#1258 closed: python-plugin: support pip list columns mode <Created by sdeancos> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1258>
<bdx> kyrofa: here is what I'm experiencing http://paste.ubuntu.com/24858016/
<kyrofa> bdx, what did you name your plugin file?
<kyrofa> x_ruby.py or x-ruby.py?
<bdx> x_ruby.py
<kyrofa> Use a hyphen
<kyrofa> Take heed of that warning, though-- refer to the cmake plugin (or another in-tree plugin) for a more up-to-date __init__
<bdx> oohok
<bdx> thx
<mup> PR snapd#3483 opened: tests: dependency packages installed during project prepare <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3483>
<bdx> https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md#initializing-a-plugin
<bdx> "DEPRECATED: the plugin used by part 'ruby' needs to be updated to accept project options in its initializer. See https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md#initializing-a-plugin for more information"
<bdx> that link doesn't seem to exist :(
<bdx> I can't create a issue on snapcore/snapcraft for this either
<bdx> there is no issues tab
 * zyga-fedora is mentally drained and takes a break/walk
<kyrofa> bdx, whoope
<kyrofa> bdx, bugs at https://bugs.launchpad.net/snapcraft, please
<kyrofa> That's definitely one
<kyrofa> bdx, but just copy the __init__ declaration from cmake, or another plugin in snapcraft
<kyrofa> (you're just missing a parameter there)
<bdx> kyrofa: ok, done
<bdx> kyrofa: so I backed of a bit
<bdx> http://paste.ubuntu.com/24858444/
<bdx> the issue I seem to be hitting ... http://paste.ubuntu.com/24858448/
<bdx> apt  needs an update before the build_packages install
<kyrofa> bdx, you mean if you run `apt update` before this that works?
<bdx> kyrofa: well trying these commands in a fresh lxd
<kyrofa> bdx, no, it's libxslt1-dev
<kyrofa> bdx, but is that just for building ruby?
<bdx> kyrofa: yeah ... if I launch a fresh instance, and try to `apt install libxslt1-dev`, it fails
<bdx> kyrofa: if I `apt update`, `apt install libxslt1-dev` succeeds
<kyrofa> bdx, yes that makes sense. But snapcraft runs apt update, you're just using the wrong name there
<bdx> oh my -
<bdx> thanks
<bdx> that got me going
<bdx> thanks for bearing with me
<kyrofa> bdx, you're doing awesome man, no bearing needed
<kyrofa> bdx, where are you getting that list of deps for ruby, out of curiosity? That's quite a bit more than I typically use
<bdx> kyrofa: https://github.com/battlemidget/juju-layer-ruby/blob/master/lib/rubylib.py#L51,L54
<kyrofa> Are you sure they're all required?
<bdx> kyrofa: I just now tried spinning up a lxd and pulled down a ruby tar
<kyrofa> Ruby builds with just gcc g++ make libz-dev libssl-dev libreadline-dev, I think
<bdx> oh reall
<bdx> let me give that a try
<kyrofa> You might be missing features that way though, but we should know for sure
<kyrofa> (when I deploy my rails projects, that's what I use to build ruby)
<bdx> kyrofa: that is all that was needed
<bdx> I'll swap those deps out
<kyrofa> Nice. A little lighter
<bdx> kyrofa: now I'm getting http://paste.ubuntu.com/24858731/
<kyrofa> bdx, ah, try zlib1g-dev
<bdx> libz-dev jus installed for me on a fresh lxd though ... grrr
<kyrofa> Virtual packages...
<bdx> lol ... whatever that means
<kyrofa> elopio, that's ringing a bell for me. Is there a reason those don't work?
<kyrofa> I remember hearing you talk about that
<kyrofa> bdx, yeah, I think this is a bug
<bdx> kyrofa: where can I find the issue tracker for snapcraft?
<kyrofa> bdx, https://bugs.launchpad.net/snapcraft
<bdx> ahh nice, thx
<kyrofa> bdx, yeah: https://bugs.launchpad.net/snapcraft/+bug/1660666
<mup> Bug #1660666: build-packages fails on pure virtual packages <Snapcraft:Confirmed> <https://launchpad.net/bugs/1660666>
<bdx> ahh nice
<bdx> well, nice thats its being tracked already
<kyrofa> Knew it sounded familiar
<elopio> bdx: can you install the snapcraft snap from the edge channel?
<bdx> kyrofa: what is this telling me http://paste.ubuntu.com/24858783/?
<bdx> do I need to pass some init values to the call to super or something
<bdx> yeah
<kyrofa> bdx, that you need a better definition of __init__. Refer to any other plugin snapcraft
<kyrofa> plugin in, rather
<bdx> https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/make.py#L95
<kyrofa> Huh... yeah wait
<bdx> I grabbed it exactly as it is there
<bdx> if I comment out pull() I don't get the error
<bdx> ooh
<bdx> scratch that
<bdx> http://paste.ubuntu.com/24858822/
<bdx> ^ that will build
<kyrofa> Wut
<kyrofa> Yeah something is busted here... let me poke at it
<bdx> http://paste.ubuntu.com/24858839/ - uncommenting either of the declarations in init will cause that error to surface
<kyrofa> I wonder if the importing is breaking things
<bdx> ooh, my bad
<bdx> uncommenting         self._ruby_dir = join(self.partdir, 'ruby')
<bdx> works
<bdx> its only the self._ruby_tar that breaks it
<bdx> ooh, possibly I'm missing an arg to Tar()
<bdx> I am
<bdx> geeeeh!
<kyrofa> Oh jeez, I just find that too
<kyrofa> The deprecation warning is a little trigger happy, and masks the real issue
<kyrofa> You're just missing source_dir
<kyrofa> I say log another bug
<kyrofa> :P
<kyrofa> You're on a roll today!
<bdx> once `snapcraft` succeeds, I end up with a ruby-test_0.1_amd64.snap file
<bdx> I install the snap with `sudo snap install --devmode ruby-test_0.1_amd64.snap`
<bdx> how can I introspect the snap now that it is installed?
<kyrofa> bdx, well first of all, none of the plugins I've seen so far from you actually builds ruby
<kyrofa> Right?
<bdx> kyrofa: correct, I'm just trying to poke around to make sure what I've done so far produces the expected results
<kyrofa> bdx, the short answer is: look in the prime/ dir, that represents what goes into the final snap
<kyrofa> Sounds good
<kyrofa> Once the prime step ends, all the snap step does is mksquashfs prime
<bdx> ahh
<bdx> kyrofa: alright, I'm going to take a shot at the pull and build steps
<bdx> kyrofa: this seems to be building successfully https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c
<bdx> kyrofa: should I use a chdir context manager to chdir into the directory created from untaring the ruby tar, and run the `./configure`, `make`, `make install` commands?
<kyrofa> bdx, no, snapcraft gives you a few tools you can use
<kyrofa> Let me find you an example
<kyrofa> bdx, yeah, check out the nodejs plugin
<kyrofa> bdx, you'll see `self.run([...] cwd=blah)`
<bdx> kyrofa: so I need to define the dir rootdir/<extracted ruby dir> to use with the run() function then right
<kyrofa> You got it
<bdx> `install_dir = join(installdir, "ruby-{version}".format(version=self.options.ruby_version)
<bdx> self.run(['./configure'], cwd=install_dir)
<bdx> `
<bdx> like that?
<kyrofa> Assuming the ruby tarball is unpacked into install_dir, yeah (more like a build_dir in my mind)
<bdx> yeah, totally ... so the tar gets unpacked into `join(self.partdir, 'ruby')`
<bdx> so I would want that dir
<bdx> ok
<bdx> got it
<mup> PR snapcraft#1342 closed: nodejs: run install and commands in source-subdir <Created by Saviq> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1342>
<bdx> kyrofa: I think I'm on the right track here, mind having another look https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c
<kyrofa> bdx, yeah that's getting there, although I suggest always using lists for `self.run()` (you're mixing lists with strings)
<bdx> ahh, gotcha, fixed now https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c
<kyrofa> Yes, much better
<bdx> so next I need to symlink the binary? something similar to this https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/make.py#L112,L117 ?
<kyrofa> Right, this will build ruby, but as it is right now it'll install it _on the host_ instead of into the snap
<kyrofa> (and fail unless you're using sudo, of course)
<kyrofa> So you'll want to either install it with DESTDIR, or configure a prefix. I'd try destdir first
<bdx> kyrofa: I'm having a hard time connecting the dots on how that is done
<kyrofa> bdx, you want ruby to end up in `self.installdir`
<bdx> oh I do?
<bdx> ok
<kyrofa> bdx, yeah let's back up a bit. Do you have much experience using snapcraft?
<kyrofa> I want to fill some of the holes for you, just need to know where to start
<bdx> kyrofa: outside of following the tutorials, no
<bdx> none
<kyrofa> bdx, so you probably know that every part in snapcraft goes through a lifecycle of steps
<bdx> yes
<kyrofa> pull -> build -> stage -> prime
<kyrofa> Then once all the parts go through that lifecycle, the "snap" step runs
<bdx> 10-4
<kyrofa> The plugins are responsible for the first two steps: pull and build
<bdx> ok
<kyrofa> Everything else is part of snapcraft core
<bdx> ok
<kyrofa> There's a very simple agreement between plugins and snapcraft to do the handoff between build and stage
<kyrofa> That is: anything in parts/<partname>/install will end up in stage
<bdx> ok, and the stage gets mounted?
<bdx> or stage is the last step executed before snap
<kyrofa> Nope. The stage step takes everything in every part's install dir and combines them into a single stage/ dir
<bdx> ok
<kyrofa> Sometimes you'll run into conflicts when that happens if multiple parts provide the same file, etc.
<bdx> got it
<kyrofa> Once stage has happened, the prime step takes stuff from each part's installdir AGAIN and combines it into the prime dir
<kyrofa> Once that has happened for all parts, the snap step runs mksquashfs on the prime dir and you're done
<kyrofa> So, bringing this full circle: ruby needs to end up in the part's installdir, or it won't end up in the snap
<bdx> https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c#file-ruby-x-py-L32
<kyrofa> The plugin knows where the installdir is via `self.installdir`
<bdx> needs to be `self._ruby_dir = join(self.installdir, 'ruby')
<kyrofa> No, because then all the ruby SOURCE will end up in the snap-- you don't want that either
<kyrofa> You're fetching/unpacking/building ruby off to the side, I like that
<kyrofa> But you need to INSTALL it into the installdir
<bdx> ahh
<bdx> not the same dir where I built it
<kyrofa> Take a look at the make plugin, how it uses DESTDIR
<kyrofa> Indeed
<bdx> otherwise it would just get discarded too
<bdx> ok
<kyrofa> That wouldn't happen anyway: by default ruby will install onto the system
<bdx> yeah so I'm really confused about that lol
<bdx>         self._ruby_dir = join(self.partdir, 'ruby')
<bdx> oops
<bdx> https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/make.py#L72,L74
<kyrofa> Oh yeah.. not the simplest example. The cmake plugin then!
<kyrofa> :P
<bdx> so, self.sourcedir in cmake then?
<bdx> https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/cmake.py#L73
<kyrofa> self.sourcedir is where the project your plugin will be building will be fetched
<bdx> I need something similar to the _build_environment() then?
<kyrofa> Oh darn, no, cmake inherits from make, so still confusing
<bdx> yeah...
<kyrofa> Scratch that plan. So by default, when you run ./configure, it prepares itself to install into /usr/bin, or /usr/local/bin, etc.
 * bdx sobs uncontrollably 
<kyrofa> :P
<bdx> totally
<kyrofa> If you want it elsewhere, you have two options: either ./configure --prefix=elsewhere, and then `make install` puts it elsewhere
<kyrofa> Or ./configure like normal, and when running `make install` actually run `make install DESTDIR=elsewhere`
<kyrofa> I suggest trying the latter option first
<bdx> yea, ok
<kyrofa> Where "elsewhere" is self.installdir
<bdx> ok, yeah this makes sense
<kyrofa> So now we're fetching and building ruby in a disposable place, but installing it into the snap so we can use it at build AND runtime
<bdx> yes, I see that now
<bdx> kyrofa: I've implemented those bits here https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c
<kyrofa> Yeah give that a shot, see if ruby ends up in prime
<kyrofa> Oh wait
<kyrofa> I suggest moving -j arg to the `make`, `make install` probably doesn't need it
<kyrofa> It'll be slow
<bdx> entirely
<bdx> kyrofa: great progress
<bdx> kyrofa: here is `$ snapcraft` <- http://paste.ubuntu.com/, here is what my directory tree looks like http://paste.ubuntu.com/24859583/
<bdx> https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c
<bdx> I'm not seeing the ruby binary anywhere
<kyrofa> bdx, testing...
<kyrofa> bdx, the DESTDIR line needs to be a `make install`
<bdx> ooho whooops
<kyrofa> That'll fix things. Although it looks like it uses usr/local. I suggest trying prefix=/ in the configure step to see if things end up in bin
<bdx> yeah
<bdx> kyrofa: https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c - getting close
<kyrofa> Looking good!
<bdx> http://paste.ubuntu.com/24860014/
<kyrofa> Is that prime/bin/ ?
<bdx> yea
<kyrofa> Nice, now for the challenging part: gems
<bdx> kyrofa: after I run `sudo snap install --devmode ruby-test_0.1_amd64.snap`
<bdx> shouldn't my new ruby bin from the snap show up when I run `whereis ruby`
<kyrofa> bdx, no, you need to declare it as an app if you want to just be able to run ruby out of it
<kyrofa> It won't work anyway though, as the environment isn't setup for it
<bdx> kyrofa: I see, ok
<bdx> kyrofa: I just want to make use of that ruby bin from within a snap
<bdx> so I don't need to expose it as an app
<bdx> that is the idea I take it
<kyrofa> Indeed: the goal of this plugin is not to package RUBY as a snap, but a ruby APPLICATION
<bdx> I should make another function to call after _ruby_install() in the build step then?
<bdx> possibly `_gem_install()' and `_bundler_install()`?
<kyrofa> Exactly what I was thinking
<kyrofa> Start with gems, just a list
<bdx> I want bundler installed by default
<bdx> should I hard code that?
<kyrofa> You only need bundler if there's a Gamefile, right?
<bdx> yeah
<kyrofa> Wow, sorry, getting tired
<kyrofa> Gemfile
<bdx> yeah
<kyrofa> So yes, but bundler will be a little harder than just gems
<bdx> so check for that first, if exists then use the _gem_install() helper
<bdx> to install bundler
<bdx> then call `bundle install`
<kyrofa> Well, I see two classes of people who might want to use this plugin. Those who have a quick Ruby script and no Gemfile, but knows they need gems, and larger projects that have an established Gemfile
<kyrofa> I think it'd be pretty easy to support both, don't you think?
<bdx> yeah
<kyrofa> So I'd start by adding a new option to the schema called "gems" that accepts a list of gem names, and then use your compiled ruby to install them
<bdx> ok
<kyrofa> After we get that working, we can move to bundler
<kyrofa> You're going to need an env() function, by the way. Make sure you define at least RUBYLIB, GEM_HOME, and GEM_PATH
<bdx> ok
<bdx> something along the lines of https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/cmake.py#L84
<kyrofa> bdx, no, that's build-time only, you'll want it at runtime as well. Something like this: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/catkin.py#L206
<kyrofa> But not as complicated
<kyrofa> That function is part of the plugin API
<kyrofa> Just return a list of environment variable definitions
<kyrofa> bdx, I'm sorry to desert you, but I've got to run for the day. I'll be back tomorrow, though :)
<bdx> np
<kyrofa> Good work!
<bdx> thank you for all your help today
<kyrofa> Any time
#snappy 2017-06-15
<bdx> kyrofa, elopio: https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c
<bdx> I think I just need to figure out how to set those env vars now ..... should I just set them in os.environ ?
<elopio> bdx: we usually pass them in the env argument for the run methods
<bdx> elopio: ok, how are the actually set though?
<elopio> bdx: take a look here, for example https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/go.py#L190
<bdx> this is where I went next, is this legit https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c ?
<bdx> checking
<bdx> I see
<bdx> I feel like I'm on the right track
<elopio> bdx: it looks pretty good, yes. Why don't you make a pull request? We can continue reviweing it there, and the comments and changes will be very useful for when we have to modify the code in the future.
<bdx> ok
<elopio> bdx: I usually start with a very very simple integration test, to make sure that the plugin covers the basic case. And then continue making it more complicated, one step at a time.
<elopio> you can take a look at the integration_tests directory.
<bdx> alright, thanks
<mup> PR snapcraft#1365 opened: Add Ruby Plugin <Created by jamesbeedy> <https://github.com/snapcore/snapcraft/pull/1365>
<mup> PR snapcraft#1337 closed: autotools: don't force uniqueness on configflags <Created by Saviq> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1337>
<zyga-ubuntu> good morning
<zyga-ubuntu> sorry for joining so late
<Chipaca> mwhudson: o/
<mup> PR snapd#3484 opened: tests: add autopilot-introspection interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3484>
<Chipaca> raahghghghg
<Chipaca> zyga-ubuntu: help please
<zyga-ubuntu> Chipaca: yes?
<zyga-ubuntu> Chipaca: as much as I can be today
<Chipaca> zyga-ubuntu: I can't get rid of these stupid "cannot update mount namespace" things
<zyga-ubuntu> Chipaca: hmm
<Chipaca> zyga-ubuntu: frehsly booted, fresh snapd state, make hack, running from master. Can't install nor try a single thing.
<zyga-ubuntu> Chipaca: disable reexec
<zyga-ubuntu> and compile and install snap-update-ns
<zyga-ubuntu> that should be enough
<Chipaca> doesn't make hack do that?
<zyga-ubuntu> Chipaca: no, it only does that snap-confine parts
<zyga-ubuntu> (feel free to improve it though
<zyga-ubuntu> as the name implies, it's just a hack
<Chipaca> I didn't take the name to imply it was a hack, but that it let you hack
<Chipaca> :-/
<Chipaca> zyga-ubuntu: actually, strange thing: hello-world does install
<zyga-ubuntu> it did, but it needs update since we added update-ns
<Chipaca> zyga-ubuntu: test-snapd-python-webserver does not
<zyga-ubuntu> curious
<zyga-ubuntu> well
<zyga-ubuntu> we only update ns if there's a bound ns
<zyga-ubuntu> if there's none, we don't even try
<Chipaca> zyga-ubuntu: why does it complain on the first 'try' of a snap package? core was already installed
<Chipaca> ("a snap package" -- test-snapd-python-webserver)
<zyga-ubuntu> complain on try? can you expand on that please?
<Chipaca> zyga-ubuntu: sudo snap install --edge core
<Chipaca> zyga-ubuntu: worked fine \o/
<Chipaca> zyga-ubuntu: sudo snap try tests/lib/snaps/test-snapd-python-webserver/prime
<zyga-ubuntu> with core from edge it should be all fine since snapd will use assests from the core snap, most likely
<Chipaca> zyga-ubuntu: http://pastebin.ubuntu.com/24863432/
<zyga-ubuntu> oh oby
<zyga-ubuntu> boy
<zyga-ubuntu> that's a long way to say "not implemented"
<zyga-ubuntu> did you rebuild snapd too?
<Chipaca> this is running a snapd from master, yes
<zyga-ubuntu> ok, you have to copy snap-update-ns to /usr/lib/snapd/ then
<zyga-ubuntu> snapd master, if it doesn't reexec, will use internal tools from distro location
<Chipaca> siigh
<Chipaca> yes that did it
<Chipaca> i'll push a branch to have 'make hack' do that as well
<zyga-ubuntu> thank you
<Chipaca> i already have enough grey hair
<zyga-ubuntu> interestingly, I think snapd could hold internal tools
<zyga-ubuntu> less binaries
<zyga-ubuntu> less divergence
<zyga-ubuntu> but anyway, back to qemu
<pedronis> Chipaca: hi, I reviewed your PR
<Chipaca> pedronis: i saw! thanks
<Chipaca> pedronis: I didn't realise the usual case was just to leave the tomb unended
<pedronis> maybe it's not true
<Chipaca> shouldn't taskrunner kill the tomb when removing it from the map?
<pedronis> now that IÂ think
<pedronis> I think we do kill it
<Chipaca> 		tomb.Kill(handler(t, tomb))
<pedronis> yea, sorry
<Chipaca> that's done before delete(tombs, tomb)
<pedronis> then the converse is true though
<pedronis> trying to Kill the process is strange
<pedronis> given we know it has finished
<Chipaca> how do we know it's finished?
<Chipaca> I mean
<Chipaca> if you abort, the tomb gets killed, but if you don't have something looking at the tomb and killing the process when the tomb gets killed, nothing kills the process
<Chipaca> so, many, commas
<pedronis> I'm saying if you get back from  Wait you will still get to Kill
<Chipaca> ah, yes
<Chipaca> pedronis: but process doens't have an Alive() call
<Chipaca> hmm
<pedronis> you need your own book keeping
<pedronis> anyway that's why I suppor runHookAndWait is so outside-in
<Chipaca> but I don't really have to do my own book keeping
<Chipaca> nothing bad happens if I kill it and it's already dead
<Chipaca> it's now extra-dead \o/
<Chipaca> maybe I should add a comment?
<Chipaca> or! maybe i only kill it if it's in AbortState?
<pedronis> well that pid could be reused
<pedronis> now you kill the bad process
<pedronis> Process is just a glorified int
<Chipaca> if the pid is reused there's no way to tell one way or another
<Chipaca> which is why in general pids aren't reused
<pedronis> Chipaca: ?
<Chipaca> pedronis: unless you're forkbomming or something
<Chipaca> they cycle around very slowly
<Chipaca> pedronis: anyway my point is that the only thing we have for a process is the int, there isn't any magic to be had
<pedronis> Chipaca: my point is that the logic in runHook shows that you can avoid these doubts
<pedronis> to some extent
<Chipaca> pedronis: you realise that does pretty much the same thing?
<Chipaca> pedronis: or am I missing something?
<pedronis> ?
<pedronis> it doesn't call Kill if Wait returned
<pedronis> so our definition of same is not the same :)
<Chipaca> ah!
<Chipaca> missed the return in the select
<Chipaca> /o
<pedronis> anyway, I'm probably just getting super nitpicky
<pedronis> Chipaca: interesting there's not a lot of hook specific in  runHookAndWait , wondering if it could be turned into a osutil helper and used by both managers
<Chipaca> I'm in the middle of doing exactly that :-)
<pedronis> it kills the whole group etc
<pedronis> seems the best approach medium term
<mup> Bug #1698107 opened: Ubuntu Core images should include ntfs-3g <Snappy:New> <https://launchpad.net/bugs/1698107>
<Chipaca> would it be ok if a hook, when told to abort, had a log message of "command aborted" instead of "hook aborted"?
<Chipaca> pedronis: ^ asking you becaus pstolowski is out today :-/
<Chipaca> I'm going with "yeah it's fine"
<pedronis> a log to where?
<pedronis> there's no logging in runHookAndWait atm
<pedronis> Chipaca: are you passing a task to this new helper? not just a tomb?
<Chipaca> pedronis: the error returned from this is logged to the task
<Chipaca> there's a couple of "hook"s in those errors that I'm replacing wiht "command"s
<Chipaca> it'll seem obvious given the context, i think
<pedronis> Chipaca: if you look we prefix those with run hook %q: anyway, so that's fine IÂ even think you can just have "aborted"
<pedronis> from the helper
<pedronis> Chipaca: indeed if you are adding things that print the full command, probably better to do it one level up
<Chipaca> yeah, but then "cannot abort:" makes me feel weird
<Chipaca> (as opposed to "cannot abort command:"
<Chipaca> )
<Chipaca> it's probably just me though
<pedronis> run hook %q:  cannot abort  command  works
<pedronis> without command works to
<pedronis> my commend was mostly  about "command aborted"
<pedronis> we are not aborting the command
<pedronis> we are aborting the task
<pedronis> conceptually
<pedronis> to abort the task we need to abort the command
<pedronis> anway may just be how brain works
<mwhudson> Chipaca: hola
<Chipaca> mwhudson: q'acelga, caeza!
<mwhudson> Chipaca: sorry i actually only know one word of spanish
<Chipaca> mwhudson: âwhaduuuppâ
<mwhudson> heh
<Chipaca> but only in a small area of where i grew up in the world
<Chipaca> mwhudson: about this exec thing, were you planning to backportify it?
<pedronis> s/brain/my brain/
<mwhudson> Chipaca: hadn't really thought about it too hard
<mwhudson> Chipaca: we'd only really care about the golang-1.6-go in xenial, right?
<mwhudson> Chipaca: would the fact that the core snap would then be built with the workaround in place mean that it wouldn't matter so much if other distros didn't get the kernel fix for ages?
<Chipaca> mwhudson: it's probably more complicated than that, because re-exec means the first exec is from whatever-snapd-is-in-distro
<mwhudson> if so, then i think it sohuld be backported
<mwhudson> right, i'm not sure at which layer the re-exec happens
<mwhudson> if it's snapd-from-distro -> snapd-from-core that's ok right?
<mwhudson> because the snapd-from-core -> snap-confine exec would be protected, and that's the one that screws up
<Chipaca> hmmm
<Chipaca> mwhudson: you're correct on that one
<Chipaca> mwhudson: they all hit the silly pthread thing, but only the setuid one hits the in-kernel race itself
<Chipaca> ("silly pthread thing" being the EAGAIN because of losing the race with clone)
<mwhudson> ah yeah
<Chipaca> that one goes away with this lock, by the way, but I didn't feel like making the case for removing the retry
<mwhudson> ah yeah
<mwhudson> the retry was added for some other reason too iirc
<Chipaca> ah ok
<Chipaca> anyhow, you're correct that the one we care about is the one that exec's snap-confine, and that's (usually) the in-core one
<mwhudson> ok backporting makes sense then
<Chipaca> usually because in some scenarios the distro snapd can be ahead of the core snapd in which case no reexec happens
<mwhudson> did ian's comments on gerrit make sense?
<Chipaca> but that should be rare
<Chipaca> yes! done and pushed patchset 3
<mwhudson> looks nice and simple
<mwhudson> Chipaca: so yeah create a task on golang-1.6-go and assign it to me once ian seems happy?
<mwhudson> (create a xenial task too, if you have perms for that?)
<Chipaca> will do (or pester people to do)
<Chipaca> mwhudson: thanks!
 * zyga-ubuntu takes a break to find some cool air
<Chipaca> pedronis: three commits added (split in three just for easier review and logging) to #3480
<Chipaca> snapd#3480
<mup> PR snapd#3480: overlord/oddjobstate: new package for running commands as tasks <Created by chipaca> <https://github.com/snapcore/snapd/pull/3480>
<Chipaca> mup: ya lazy git
<mup> Chipaca: I apologize, but I'm pretty strict about only responding to known commands.
<Chipaca> you say that, but you sure like responding to unknown commands more than you like responding to known ones
<pedronis> that's funny definition of strict
<pedronis> unless there's a strict definition of responding behind it
<zyga-ubuntu> 32+C makes my mind suffer
<mup> PR snapcraft#1366 opened: cli: Add --version command <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/1366>
<pedronis> Chipaca: +1 with a couple small wonderings
<pedronis> thank you
<pedronis> found a small bunch of Uppercase errors doing some related spelunking
<Chipaca> pedronis: wrt the "cannot RunAndWait", does it show that those were this >< close to be panic(...)?
<pedronis> yes
<Chipaca> :-)
<morphis> fgimenez: https://paste.ubuntu.com/24864240/ doesn't look too bad I would say :-)
<morphis> most of them fail because somehow `snap debug confinement` is broken
<fgimenez> morphis: nice! \o/
<morphis> also need to get a proper version for the deb package.. 2.26.4+git3.g2494bc0.dirty looks broken :-)
<Chipaca> pedronis: would âinternal error: osutil.RunAndWait needs ...â be alright? I can't seem to get the name out of the errors without the message losing meaning
<pedronis> yes, that's fine
<Chipaca> pedronis: you mind if I amend a commit instead of pushing a new one?
<pedronis> it's ok because it's holiday somewhere
<pedronis> ;)
<Chipaca> bah, never mind, i'd have to go amend a commit two up
<Chipaca> then rebase
<Chipaca> 's a mess
 * zyga-ubuntu wants to hit his head against the wall
<zyga-ubuntu> oooh. frell
 * zyga-ubuntu wasted hour looking for the missing \n that kept stuff stuck
 * zyga-ubuntu tries to join standup 
<sborovkov> ogra_: hello, i am a bit confused about uboot. once I have image on the disk do I need to load into memory basically every time to display it as a splash screen with fatload first?
<sborovkov> ogra_: I am just confused what address I should be loading my image to tbh
<Chipaca> the rumours of that being the last iteration of the go patch were greatly exaggerated
 * zyga-ubuntu lunch
<jdstrand> didrocks: hi! is gtk-3-demo expected to work with wayland? (not in strict mode of course-- I'm asking for when I pick up the waylond interface work)
<jdstrand> wayland*
<didrocks> jdstrand: no, it's just a quick showoff (that's why I didn't want to add a .desktop file) to show that themes are working with current desktop
<didrocks> jdstrand: I saw you rejected it because of thisâ¦
<jdstrand> didrocks: well, I can approve it, but note that with no desktop file if it shows up in the unity launcher and someone pins it, it will be launched unconfined
<jdstrand> didrocks: when run from the command line, does it show up in the unity7 launcher?
<didrocks> jdstrand: yeah, it's not really for end user (and will probably will removed shortly)
 * jdstrand would love to see someone fix that bug btw
<jdstrand> didrocks: can you request a manual review?
<didrocks> jdstrand: it does, but I have the deb binary installed here
<didrocks> jdstrand: sure, thanks!
<didrocks> jdstrand: so, I would need to clean the whole cache and things (but yeah, I opened a bug about the unity7 cache, unsure it will get fixed though)
<didrocks> done
<zyga-ubuntu> re
<Chipaca> mi
 * Chipaca 's probably done that one before
<Chipaca> ooh, âomnidirectional snappingâ
<zyga-ubuntu> what? :D
<Chipaca> zyga-ubuntu: http://www.businesswire.com/news/home/20170614005246/en/Omnidirectional-Snapping
<stokachu> can someone look into [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645) during snapcraft?
<pedronis> Chipaca: are you up to review s/http.StatusOK/200/ etc ? it will probably be big and tedious
<Chipaca> pedronis: sure
<stokachu> im blocked on building snaps atm because of that ssl verification error
<stokachu> is anyone around that can look into that?
<stokachu> noise][: ^
<kyrofa> niemeyer, do I need special forum powers to make a wiki?
<stokachu> kyrofa: have you seen ^
<noise][> we're on it, should be fixed shortly
<stokachu> noise][: ok thank you
<pedronis> I think is being worked on atm
<noise][> and I'm fixing the monitor we were apparently missing for it :/
 * zyga-ubuntu defeated another issue in intrd testing
<noise][> stokachu: resolved now, sorry for the inconvenience
<stokachu> noise][: np thanks!
<pachulo> I have a doubt about the store: is it possible to use build.snapcraft.io to build the snaps for the beta channel of an application but at the same time still manually upload the ones for the stable one?
<noise][> pachulo: build.snapcraft.io will release to edge, and then you can release those same revisions to other channels OR upload manually other revisions and release them to channels you choose
<noise][> does that help?
<pachulo> yeah! thanks noise][ !
<mup> PR snapcraft#1360 closed: cli: stop leaking green text <Created by kyrofa> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1360>
<kyrofa> \o/
<pedronis> Chipaca: seems there's a new bunch of shellcheck failures in prepare.sh etc
<Chipaca> augh
<Chipaca> fgimenez: can you add shellcheck to the ubuntu-16.04-64 image? or does that require a gustavo?
<fgimenez> Chipaca: yes we need him, i can prepare an instance with the required changes but we need an snapshot from it and create an image from that snapshot, gustavo does that part
<Chipaca> ok
<mup> PR snapd#3485 opened: tests: fix nightly suite <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3485>
<mup> PR snapd#3486 opened: many: switch to use http numeric statuses as agreed <Created by pedronis> <https://github.com/snapcore/snapd/pull/3486>
<pedronis> Chipaca:  ^
 * Chipaca looks
<Chipaca> pedronis: is it bad that I know by heart what 418 is, but not what 405 is?
<pedronis> not bad, but peculiar :)
<cjwatson> Chipaca: snap
<Chipaca> :-)
<pedronis> Chipaca: anyway feel to add where I should add a comment
<pedronis> *feel free
<Chipaca> so far i've only had to double-check the 405
<pedronis> anyway there IÂ didn't add the comment also becasue there's BadMethod on the other side
<pedronis> though it's really MethodNotAllowed to be precise
<Chipaca> pedronis: feel free to rename the handler if you wish
<Chipaca> handler/responder/whatever it's called
<Chipaca> but anywa, +1
<pedronis> thx
<kyrofa> My french press broke. I have to make every cup via pour over. Someone pity me
<stokachu> noise][: if an automatic snap is setup in the store but the alias is removed from the snapcraft.yaml will it still try to auto connect that alias?
<stokachu> conjure-up currently owns the juju top level alias
<stokachu> noise][: i guess we need to remove that check from the store because both juju and conjure-up can't be installed alongside each other
<stokachu> noise][: https://forum.snapcraft.io/t/please-remove-juju-alias-from-conjure-up/1016 just when you have time
<om26er> morphis, ping
<morphis> om26er: pong
<om26er> morphis, re: snapd on raspbian, how reliable is that for now ?
<om26er> ...or stable
<morphis> it's based on the 2.26.4 release of snapd, doesn't have confinement yet but works for most snaps
<morphis> we're currently validating most things by running our extensive test suite on it
<om26er> ok, any effort to make snapd installed by default on Raspbian ? snaps on that environment by default make great sense and would make our lives easier
<om26er> I know its a bit early to ask, but still.
<noise][> stokachu: doing..
<om26er> morphis, re: Pi zero, is debian going to be in the core snap, given Ubuntu is not available on that arch.
<stokachu> noise][: ty!
<morphis> om26er: right now there is no core snap available for the Pi zero as Ubuntu doesn't support armv6l
<om26er> will Ubuntu support armv6l in future ?
<om26er> (I presume not)
<morphis> om26er: we're soon introducing something called base snaps
<om26er> morphis, i.e. a core snap that is not Ubuntu based ?
<morphis> somewhat
<morphis> you will have a generic core snap which ships snapd and a base snap for raspbian
<morphis> but this is still in design on nowhere done
<lasconic> hi there
<lasconic> is there a way on build.snapcraft.io to point to a github branch ?
<lasconic> pachulo: hi ;)
<om26er> morphis, are you in touch with Raspbian community or is that an isolated effort ?
<morphis> om26er: it's not isolated
<morphis> but nothing I can talk about yet
 * om26er would very much like to be able to install snaps on RPi by default. Makes our work very simple for cases where we need to do PoCs on Pi.
<cjwatson> lasconic: not at this time, sorry: https://github.com/canonical-ols/build.snapcraft.io/issues/701
<cjwatson> er not that one
<cjwatson> https://github.com/canonical-websites/build.snapcraft.io/issues/440
<lasconic> cjwatson: thanks, I added my voice
<cjwatson> lasconic: no need
<cjwatson> but thanks for the data point
<lasconic> cjwatson: it never hurts to feel that there is an actual need
<noise][> stokachu: Note it seems you have a `ln -s conjure-up.juju /snap/bin/juju` in your configure hook that was confusing me (thx to pedronis for figuring that out)
<stokachu> noise][: yea we're still wanting new users to be able to run `juju` if they have never installed it before
<stokachu> but other who want juju + conjure-up to not conflict as well
<stokachu> snap doesn't have a nice way to tell a user that if they want both then need to unalias conjure-up.juju
<pedronis> well there's snap prefer
<pedronis> in 2.25+  and install --unaliased  in 2.27+
<pedronis> on 2.24 that alias will probably prevent to install a juju snap anyway
<stokachu> yea that was the issue
<stokachu> some people wanted both
<pedronis> even if it's not in snap aliases
<pedronis> the logic for that in 2.25+ and 2.24 is different
<pedronis> stokachu: I think is worth pinging Gustavo about this issues when he's back
<stokachu> we will want to keep it a single command `sudo snap install conjure-up --classic` so maybe adding `--unaliased` to that?
<stokachu> or would be nice for snap to just prompt the user
<stokachu> ok, i can post some thoughts to the forum too
<noise][> fwiw, now if i install conjure-up, then juju, I get the juju snap's juju (with snapd 2.24)
<stokachu> noise][: yea that i think that's intended, cory_fu_ ^?
<pedronis> noise][: interesting, I thought that wouldn't work
<noise][> right, that's what i would expect at least, was just replying to pedronis comment
<pedronis> I'm probably misremembering some detail
<pedronis> I'm quite sure it's expected to work with 2.25
<noise][> https://pastebin.ubuntu.com/24866018/
<stokachu> noise][: that is weird
<mup> PR snapcraft#1362 closed: Only install golang-go if it is not found in PATH <Created by chrisglass> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1362>
<cory_fu_> stokachu: Yeah, that's the expected behavior.   Defer to the juju snap if it's installed before or after
<stokachu> cory_fu_: ok cool
<cory_fu_> stokachu, noise][, pedronis: FWIW, though, the juju provided by conjure-up never shows up as an alias because it's not a proper snapd alias.  That was the only way I could make it defer automatically
<pedronis> it's a bit of a hack tbh
<pedronis> otoh the full feature set to deal with this was deemed too complex, so as I said worth pinging Gustavo when is around
<Chipaca> kyrofa: I can probably get you an aeropress sometime tomorrow
<kyrofa> Chipaca, I need to get one of those for travel anyway. I'm tired of hotel instant coffee
<Chipaca> kyrofa: I'm told (but couldn't confirm) that there are manual burr grinders that slot into the aeropress's plunger for a very compact travel coffee thing
<noise][> https://www.amazon.com/gp/product/B0044ZA066/
<noise][> Porlex Mini Stainless Steel Coffee Grinder
 * genii 's ears perk up for a moment at the mention of coffee
<kyrofa> Oh, that's an excellent idea!
<ryebot> anyone else seeing slow downloads from the snap store? I'm getting like 150 KB/s from an aws box
<bdx> kyrofa: thanks for the review!
<kyrofa> ryebot, yeah, ctrl+c and try again. Some of the cdn endpoints suck
<kyrofa> bdx, no problem :)
<ryebot> kyrofa: ack, thanks
<kyrofa> ryebot, I think half of them are in tanzania
<mup> PR snapd#3486 closed: many: switch to use http numeric statuses as agreed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3486>
#snappy 2017-06-16
<zyga-ubuntu> o/
 * zyga-ubuntu feels useless today
<zyga-ubuntu> 30C since early morning
<sborovkov> ogra_: Hi. Still trying to get splash screen working. I managed to load it to the RAM. Can read it with bmp info as well. bmp display though does nothing :-( I put image with wrong color depth initially and bmp display actually displayed that in the error message. But after fixing the image it does not complain about anything but does not show anything on the screen as well. Any ideas?
<ogra_> sborovkov, not really, no
<sborovkov> ogra_: oh well I will try using $splashscreen variable as well instead of bmp display. I am not sure how .env.in works - can I write this splashimage=fastload .... ; 0x100000; Or should I be adding loading the bmp into the memory to the bootcmd?
<ogra> i think you just want the var set (afaik u-boot actually checks for it)
<sborovkov> ogra: yeah but I need the code to load image into the memory somewhere
<ogra> sure, add some code that checks if "bmp info $splashimage" returns something ... if not, run a script to fatload ...
<sborovkov> ogra: what code is actually ran when it's starting? I was adding load to the bootcmd. Not sure if that might be too late?
<ogra> i'd add it to loadfiles
<sborovkov> splashimage=0x02000000 ... loadsplashimage=fatload ${devtype} ${devnum}:${bootpart} $splashimage /screenly.bmp && bmp info $splashimage; Meh. This code executes. Show info about image. But splash image is never displayed.
<ogra> ty adding $filesize to the fatload catt
<ogra> *try
<sborovkov> no, that gives absolutely same result. Displays that the same amount of bytes was read.
<ogra> where do you call bmp disaply btw ?
<ogra> *display
<sborovkov> ogra: I tried adding it to the bootcmd, and then to loadfiles. At the end of that command
<sborovkov> also I actually have that splashimage and splashsize variables defined...
<pedronis> zyga-ubuntu: Chipaca: hi, I merged the use of numeric http statutes last night
<morphis> fgimenez: ping
<zyga-ubuntu> pedronis: thank you
 * zyga-ubuntu is exhausted by the heat
<fgimenez> hey morphis
<morphis> fgimenez: if you want you can give https://github.com/morphis/snapd/tree/f/raspbian-as-external a try now
<fgimenez> morphis: sure! will let you know how it goes
<morphis> SPREAD_TRUST_TEST_KEYS=false SPREAD_SRU_VALIDATION=1 spread -v -resend -reuse external:raspbian-8-arm-32:tests/main/ still gives a few test failures when using that branch but most are because the branch is based on lastest master and we're testing 2.26.4
<morphis> rebasing on release/2.26 isn't that easy as it misses all the pkgdb changes
<mup> Bug #1632388 changed: console-conf wifi only setup on pi3 Ubuntu Core image not possible <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1632388>
<fgimenez> morphis: ok thanks, SPREAD_SRU_VALIDATION is for forcing snapd to be installed from "-proposed"? if that's the case maybe we could rename it
<morphis> fgimenez: yeah, I abusing it a bit here
<fgimenez> morphis: np :)
<morphis> fgimenez: https://github.com/snapcore/snapd/compare/master...morphis:f/raspbian-as-external#diff-6eea9b76e2bf27f60519f7b5c98333c9R222
<morphis> fgimenez: but yeah, renaming might be good
<fgimenez> morphis: aha IMO makes sense if we rename SRU_VALIDATION to SNAPD_FROM_{ARCHIVE,PROPOSED,..} or something, if not the SRU implies ubuntu
<fgimenez> morphis: yep
<morphis> +1
 * zyga-ubuntu -> coffee
<zyga-ubuntu> re
 * Chipaca ~> lunch
<fgimenez> morphis: btw i'm looking into the errors of the suite running against staging on opensuse it turns out that this error http://paste.ubuntu.com/24872100/ is because of wrong quoting, go's version is fine
<morphis> ah!
<morphis> sounds like a double quote
<fgimenez> morphis: yes, quoting all the string and evaluating it works, now i'm getting http://paste.ubuntu.com/24872106/ maybe the binary wasn't built with the testing keys, will dig further
<morphis> fgimenez: that smells like you miss https://github.com/snapcore/snapd/pull/3450
<mup> PR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>
<morphis> need to fix these PRs later today
<fgimenez> morphis: yes! exactly that :) thx
<mup> PR snapd#3487 opened: tests: reenable help test on ubuntu and debian systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3487>
<mup> PR snapd#3488 opened: tests: prevent quoting error on opensuse <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3488>
<fgimenez> morphis: about the execution on raspbian it looks like external:raspbian-8-arm-32:tests/main/classic-ubuntu-core-transition makes the whole thing fail, it reinstalls the snapd package https://github.com/morphis/snapd/blob/f/raspbian-as-external/tests/main/classic-ubuntu-core-transition/task.yaml#L33 and seems to fail because of a missing "--force-yes"  http://paste.ubuntu.com/24872205/
<fgimenez> morphis: other than that, and considering what you mentioned about release/2.26 and master, things look good http://paste.ubuntu.com/24872209/
<fgimenez> sorry the link to where snapd is installed without --force-yes is https://github.com/morphis/snapd/blob/f/raspbian-as-external/tests/main/classic-ubuntu-core-transition/task.yaml#L34
<Chipaca> fgimenez: standup?
<fgimenez> Chipaca: sure omw!
<morphis> fgimenez: yeah have similar results
<morphis> fgimenez: hm, force-yes doesn't exist on raspbian?
<fgimenez> morphis: yes, i needed it to install snapd before executing the suite
<morphis> yes
<morphis> did the same, is that how SRU_VALIDATION is supposed to work?
<morphis> maybe we can tweak the code a bit more to install snapd if missed from either propose (for ubuntu) or just the archive
<morphis> fgimenez: hm, apt-get on raspbian has support for -f -y
<fgimenez> morphis: mm from the log http://paste.ubuntu.com/24872205/ we are sending just "apt install -y snapd" in distro_install_build_snapd, probably from https://github.com/morphis/snapd/blob/f/raspbian-as-external/tests/lib/pkgdb.sh#L220, probably adding -f there should fix it
<morphis> ah
<morphis> let me add that
<Vamsi> Hi. I just installed snappy core on raspberry pi 3 and followed all the steps to install the demo snaps like "hello". However, after installation I assumed that just typing in the name of the snap is the command to invoke the snap. However, I get the following error:  -bash: hello: command not found
<Vamsi> Have I missed out on something while setting up the environment?
<ogra> take a look in /snap/bin
<ogra> is there a "hello" ?
<ogra> snaps can ship multiple binaries ... even daemons, so "typing in the name of the snap is the command to invoke the snap" is often enough not true
<ppisati> guys, is there an ETA for snapcraft 2.30/2.31 to land in xenial?
<ogra> kyrofa, ^^^
<Vamsi> ogra: I get an error saying that such a directory does not exit :|
<Vamsi> exist*
<ogra> are you sure you are on ubuntu core ?
<ogra> :)
<kalikiana_> Question: http:/v2/system-info gives me snap-mount-dir (ie. "/snap"). Is there an API that returns "/var/lib/snapd/snaps"? Or is it safe to assume that folder always exists?
<Vamsi> ogra: I logged into the pi that running on core from my notebook and installed the snap. So I believe I am on the core?
<ogra> Vamsi, which core image did you install =
<ogra> ?
<Vamsi> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz
<Vamsi> this one
<ogra> well,  that definitely has /snap
<ogra> (and should also have /snap/bin)
<Vamsi> ogra: What happens when I am in the devmode?
<ogra> you mean if you installed a snap with --devmode ?
<Vamsi> yup
<ogra> then the security oprions for the binaries get turned off
<ogra> *options
<Vamsi> What I was doing was that I was following the "get-started" instructions as given in the link: https://developer.ubuntu.com/core/get-started/developer-setup
<ogra> ogra@sabrelite:~$ snap install hello
<ogra> hello 2.10 from 'canonical' installed
<ogra> ogra@sabrelite:~$ ls /snap/bin/hello
<ogra> /snap/bin/hello
<ogra> that should be identical on all ubuntu core installs ...
<kalikiana_> ogra: Are both /snap and /var/lib/snapd/ guaranteed on all systems with snapd?
<Vamsi> So here it was mentioned that i could have a development environment right on the pi itself and thus proceeded to install the classic environment... After which my host changed from vamsi3012@localhost to (classic)vamsi3012@localhost.
<ogra> kalikiana_, not sure on classic systems ... (especially on non-ubuntu ones) ... thats a question for the cross-distro guys i guess
<ogra> Vamsi, AH!
<ogra> Vamsi, ok, then you are in the classic environment
<Vamsi> ogra: there is no bin folder :|
<kalikiana_> ogra: Any suggestion whom to ask?
<ogra> Vamsi, i dont think you can see any snap stuff in there
<Vamsi> yes. the classic environment
<ogra> kalikiana_, try morphis or zyga-ubuntu
<kalikiana_> Thanks!
<ogra> Vamsi, right, that pretends to be a classic ubuntu installation (like ubuntu-server) and has no direct access to /snap ... you need to exit ... then you can execute snaps
<Vamsi> oh okay. And... um... where can I find a reference to these commands? I'd like to build my knowledge base on that.
<ogra> Vamsi, this classic env is really only for building ... to install and run a snap you have built in there you should exit (ctrl-d) and do all snap stuff from the outside
<Vamsi> oh okay. Thanks :)
<ogra> (also typing "exit" and hitting enter works)
 * Chipaca walks in on ogra talking dirty again
<ogra> haha
 * ogra throws little orangepi-zero's at Chipaca 
<Vamsi> So just for to clarify my understanding: Classic environment to develop snaps on the host itself. And exiting this then enbles you to install the snap you just developed?
<ogra> yeah
 * Chipaca uses a SoundBlaster 16 ISA card as a tennis racket to return it
<ogra> with the --dangerous option
<ogra> (to tell the system it is not from the store (i.e. sideloaded))
<Vamsi> oh okay.
<Vamsi> ogra: I am so used to developing on an IDE that I feel an idiot on the command line. Is there an IDE for developing snaps :| :|
<ogra> i dont think so ...
<ogra> i mean ... snaps are just a package format ... use your normal IDE and then copy the tree to the board and call snapcraft there ... or some such
<kyrofa> ppisati, it's in proposed, testing looks good as far as I'm aware (though elopio will know more). I think it'll land soon
<elopio> ppisati: the SRU is ready, but they don't land things on Friday. So Monday.
<kyrofa> kalikiana_, I don't think /snap is guaranteed at least... I don't think fedora uses it
<ogra> they could just wrok through the weekend ... then they could land things on friday too :P
<kyrofa> But I think that's less of a concern for us right now, since snapcraft won't run there as a snap anyway
<jdstrand> ogra: hey, I grabbed https://code.launchpad.net/~ogra/+junk/linux-generic-bbb and am trying to build a local kernel in a classic chroot on bbb. is that expected to work?
<ogra> jdstrand, no idea, never tried :)
<kyrofa> (thanks for pinging me ogra, I would have missed that)
<ogra> jdstrand, it creates a chroot (or even two stacked ones)
<ogra> that might not work inside classic
<jdstrand> ogra: basically, I'm trying to simply go from linux-generic deb that I've got from somewhere else and making a snap
<ogra> jdstrand, hah, funny coincidence ... i'm just trying the same with a patched deb to add allwinner support
<jdstrand> ogra: the chroot operation and the bind mounts work, but I don't know everything that is needed
<ogra> though i kept the kernel side for the WE ... i'm just done with the gadget
<jdstrand> (as in, I don't know that the classic chroot has everything in it that the makefile is expecting in the chroot it uses
<ogra> jdstrand, well, http://bazaar.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk/view/head:/Makefile is what it runs
<ogra> the "all:" target just deboostraps a chroot and installs the debs in there
<ppisati> elopio: cool, ta
<ppisati> kyrofa: ^
<jdstrand> ogra: yeah, quite familiar with the script at this point (been playing with it since yesterday :)
<jdstrand> but the one you linked to is slightly different than your junk bzr branch I mentioned, so perhaps I should try that
<ogra> well, if chroot and the mounting of /proc and /sys work i dont see why classic would get in your way
<ogra> jdstrand, oh, right ... we split the Makefile at some point and only kept the snapcraft.yaml
<ogra> but there shouldnt be huge differences ...
<kyrofa> jdstrand, you're building a kernel on a bbb? Multi-day waitfest?
<jdstrand> kyrofa: building as in extracting a deb and snapping that
<kyrofa> Oh, well :
<kyrofa> Nevermind :P
<kyrofa> I was impressed with your resolve
<ogra> jdstrand, oh ... note that all these Makefiles assume the image PPA to be enabled on the host
<ogra> jdstrand, you want to add that to your classic env
<jdstrand> ogra: curious if you would expect this makefile with snapcraft run on classic snap rpi2 to produce a snap for bbb
<ogra> else you dont get the initrd scripts
<jdstrand> ogra: oohhh!!!
<jdstrand> that's probably it
<ogra> the snap LP builds have that set by default. i totally forgot about that
<jdstrand> I could boot a kernel but it would drop into the initramfs
<ogra> yeah
<ogra> missing the core initrd scripts
<ogra> (or using a very old version at least)
<jdstrand> ogra: so classic or the chroot that the makefile generates needs it?
<ogra> cp /etc/apt/sources.list chroot/etc/apt/sources.list
<ogra> ;)
<ogra> the outer env needs it in the sources.list
<ogra> the Makefile calls the above cp
<jdstrand> right, but I made some modifications to the makefile to add to the chrrot's sources.list
<jdstrand> just wondering if that is enough
<ogra> (i should perhaps adjust the makefile to call add-apt-repository instead
<ogra> )
<ogra> (instead of blindly assuming it is set in sources.list)
<jdstrand> ogra: ok, this ppa: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
<ogra> yep
<jdstrand> ok. I'm cautiously optimistic now :)
<jdstrand> ogra: thanks!
<ogra> good luck ... :)
<ogra> (i'm around for any additional questions ...)
<jdstrand> ogra: I thought you were off yesterday and today. I saw you chatting here so thought I'd ask. sorry if you are off and just lurking
<ogra> i was off yesterday, yeah
<ogra> not today though
<jdstrand> ok, good. glad I didn't bother you :)
<ogra> :)
<ogra> GRR ... so the allwinner u-boot binaries can only be built with gcc-6 ... and indeed we dont have a gcc-6-cross backport in xenial
<ogra> this will result in awful snapcraft.yaml hackery to create an artful chroot to do the build in :(
<ogra> (and indeded all boards i want are also only supported in 4.11+ ... more hackery :/ )
<ogra> (on the kernel side that is)
<bdx> kyrofa, elopio: would you mind shedding some light on what the next steps for the ruby plugin might be? I've thought of some things to test and wanted to run those by you guys also.
<elopio>  bdx: well, next step from my point of view is to fill those integration tests :) That will give us a clear idea of what works.
<bdx> I want to test for the existence of the compiled binary files: erb, gem, irb, rake, rdoc, ri, and ruby
<elopio> I'll give it a try today with my travis test subject.
<bdx> following the build step, I feel like the thing I want to test is "do the things I built exist?", right?
<bdx> ok
<elopio> right.
<elopio> also, that only those and nothing else is left in the install directory.
<bdx> ok
<mup> PR snapd#3489 opened: tests: add bluetooth-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3489>
<jdstrand> ogra: hey, well, I don't have a kernel yet with the new Makefile, but I think I'm close.
<jdstrand> ogra: this is what I see in the classic chroot: http://paste.ubuntu.com/24874108/
<jdstrand> ogra: before I added to ENV := ... FLASH_KERNEL_SKIP=yes
<jdstrand> ogra: so I am trying that again. hopefully with that I'll get a snap and with the ppa initramfs tool I'll get a bootable system
<jdstrand> ogra: is FLASH_KERNEL_SKIP=yes safe? it seemed to have the same end result (though not the same mechanism) as what I saw in the buildd logs for your linux-generic-bbb
<jdstrand> I'm guessing it is. we don't want to flash anything, and I did have a booting kernel before (it was the initramfs that was the problem)
<jdstrand> ogra: if you are interested for Makefile improvements, I did:
<jdstrand> ENV := DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANG=C FLASH_KERNEL_SKIP=yes
<jdstrand> and in 'all:
<jdstrand> echo "deb http://ppa.launchpad.net/snappy-dev/image/ubuntu xenial main" >>chroot/etc/apt/sources.list
<jdstrand> $(ENV) chroot chroot apt-key adv --recv-key --keyserver keyserver.ubuntu.com 78E1918602959B9C59103100F1831DDAFC42E99D
<jdstrand> ogra: btw, that FLASH_KERNEL_SKIP=yes with the initramfs from the image ppa did the trick. thanks for your help
<ryebot> Hey guys, anyone else getting failures trying to install the core snap? http://bit.ly/2syZ2Rp
<mup> PR snapcraft#1367 opened: catkin plugin: add support for ROS Lunar <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1367>
#snappy 2017-06-17
<jaggz> You guys still need people with the frozen step: "[-] Run configure hook of "core" snap if present" ?
<jaggz> mine's doing it..
<jaggz> fresh install in Debian-stretch of snapd, snap install meshlab (not sure how to install my meshlab-201612.snap file directly yet) and it installed core and is sitting there on the rotating progress of that line
<zyga-ubuntu> jaggz: hey
<zyga-ubuntu> jaggz: which version of snapd is that? (on that fresh install)
<jaggz> zyga-ubuntu, 2.21-2+b1
<zyga-ubuntu> jaggz: and can you run "snap version" now please
<jaggz> snap    2.21-2+b1
<jaggz> snapd   2.24
<jaggz> series  16
<jaggz> debian  9
<jaggz> zyga-ubuntu
<zyga-ubuntu> jaggz: interesting
<zyga-ubuntu> jaggz: is the configure hook still running?
<jaggz> Mm. I think i eventually killed it
<zyga-ubuntu> jaggz: you can continue if you kill "snapctl" process that you may have
<zyga-ubuntu> jaggz: right, what does "snap list" say about core now?
<jaggz> It's my first time using snap btw.. first day seeing it! :)
<zyga-ubuntu> I'm sorry for the bumpy experience
<jaggz> No snaps installed, it says
<jaggz> Aw, thanks. :)
<zyga-ubuntu> yeah, it reverted when the configure hook failed
 * zyga-ubuntu thinks
<zyga-ubuntu> not sure really
<zyga-ubuntu> you can perhaps try this
<zyga-ubuntu> sudo snap install core --beta
<zyga-ubuntu> I mean this bug was fixed but releases to debian are harder so the version in the distribution is older
<jaggz> It's working on it :)
<jaggz> It went in..
<jaggz> I didn't try the original non-beta twice, btw
<zyga-suse> great
<zyga-suse> jaggz: so once you have the core installed
<zyga-suse> jaggz: you can try installing other things
<jaggz> Yeah installing meshlab now
<jaggz> Not from the .snap i think though.. just did snap install meshlab
<jaggz> Now to learn where snap puts these things
<zyga-suse> jaggz: what do you want to know specifically?
<zyga-suse> jaggz: where it stores your data? the code?
<jaggz> Found the path.. /snap/
<jaggz> The snap is a binary distribution, not source, right? I didn't notice a compilation, and the .snap download file i found on the web was amd64
<zyga-suse> yes
<zyga-suse> jaggz: we are working on adding meta-data so that snaps that are FOSS can declare where the source is and how to build it
<jaggz> Nice
<jaggz> It's an awesome project
<jaggz> About time too
<zyga-suse> :-)
<zyga-suse> Thank you for using Debian
<jaggz> Lol
 * zyga-suse uses fedora, suse and ubuntu all the time but I don't have a debian machine to get the real experience
<jaggz> Strictly Debian for years now for me
<jaggz> Except one Ubuntu server
 * zyga-suse cannot wait for debian 10 when we'll finally have snap confinement in place
<jaggz> Guess I should read up on it more
<jaggz> To know what your talking about :)
 * zyga-suse returns to packing his life into boxes
<Chipaca> jdstrand: âsnap install --edge test-snapd-service-notifyâ for your consideration
#snappy 2017-06-18
<Guest23564> look my blog http://casamoney.it and earn money in page Power information.
<genii> Guest23564: Advertising in #ubuntu channels is not allowed
#snappy 2018-06-11
<mup> PR snapd#5294 opened: Update SELinux Policy <Created by kevinanderson1> <https://github.com/snapcore/snapd/pull/5294>
<mborzecki> morning
<Son_Goku> mborzecki, night :)
 * Son_Goku is nearly about to go to sleep
<mborzecki> Son_Goku: an goodnight :)
<mborzecki> s/an/and/
<zyga> good morning
 * zyga is somewhat tied after yesterday
<zyga> it is good that there is some rain this morning
<mborzecki> zyga: hey
<zyga> hi :)
<mborzecki> it rained a bit here, pity it was the only rain in 2 weeks or so
<zyga> it still rains here, forecast says it will all day
<zyga> ok, kids off to school
<zyga> first (or I forget) social security payment
<zyga> then work
<mvo> pstolowski|afk: 5288 has (ironically) an econnreset test failure :)
<mvo> pstolowski|afk: might be yet another interessting corner case
<mborzecki> mvo: hi
<mvo> hey mborzecki
<zyga> ok, all taxes and payments done
<zyga> now back to patches
<mup> PR snapd#5295 opened: cmd/snap-mgmt: remove system key on purge <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5295>
<mborzecki> trivial PR ^^
<mvo> mborzecki: do we do this in debian/postrm already? or does it need to be done there as well
<mborzecki> mvo: snap-mgmt --purge is used on fedora, opensuse, arch
<mvo> mborzecki: I know, I mean, do we need this on debian/ubuntu as well?
<mvo> mborzecki: or did we add it there already
<mborzecki> mvo: aah, let me check :) i automatically assumed that it's correct there
<mvo> mborzecki: maybe it is :)
<mborzecki> mvo: well it does rm -rf /var/lib/snapd
<mvo> mborzecki: heh, that should cover it
<mvo> mborzecki: thanks for checking
<mborzecki> mvo: np
<mborzecki> mvo: btw. do you have any idea why the repair timer may be getting stopped before the test?
<mvo> mborzecki: no idea, that is a bit mysterious
<mborzecki> mvo: i've restarted 5285 but the log on friday showed that snapd.snap-repair.timer was being stopped just before the test
<mborzecki> (kudos to systemd guys for actually collecting and showing this in systemctl show ..)
<pstolowski> morning
<mvo> mborzecki: I did a quick git grep over the tests dir but nothing jump out that would touch the repair service
<mborzecki> pstolowski: hey
<mup> PR snapd#5294 closed: Update SELinux Policy <Created by kevinanderson1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5294>
<mup> PR snapd#5295 closed: cmd/snap-mgmt: remove system key on purge <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5295>
<mborzecki> zyga: thanks!
<mborzecki> when mounting a snap fails, does the journal contain anything useful?
<zyga> mborzecki: as much as the kernel provides
<abeato> hi, how can I get more information when I see this sort of trace?: "handlers.go:372: Reported install problem for "core" as 680c957c-6d4a-11e8-a5bb-fa163e839e11 OOPSID"
<mborzecki> zyga: i'm wondering if we should try and grab the output of journalctl -u <failed-unit>.mount at least
<zyga> abeato: this goes to errors.ubuntu.com
<zyga> mborzecki: mmmmm
<zyga> mborzecki: in tests or in general
<mborzecki> zyga: in tests
<zyga> I think in tests we do (by extension of capturing lots of output)
<zyga> in general would be interesting
<mborzecki> zyga: in test's we don't, the tests run journalctl -u snapd .. which will not include the mount unit stuff
<abeato> zyga, ok, but there is no other information that can be looked into in the system?
<zyga> I think you can see more in "snap changes"
<zyga> and "snap tasks NNN"
<abeato> zyga, got it, thanks
<Chipaca> abeato: the error report is going to contain things that are in the log (before it talks about the error report), or in the tasks log
<Chipaca> or general system info
<abeato> great
<Chipaca> abeato: otherwise, https://errors.ubuntu.com/oops/680c957c-6d4a-11e8-a5bb-fa163e839e11
<mborzecki> zyga: pff, i see it now, there's something logged :/ but not much
<zyga> Chipaca: heyo :)
<Chipaca> zyga: 'sup
<Chipaca> abeato: in particular: ERROR [--root / enable snap.network-manager.networkmanager.service] failed with exit status 1: Created symlink from /etc/systemd/system/multi-user.target.wants/snap.network-manager.networkmanager.service to /etc/systemd/system/snap.network-manager.networkmanager.service.
<Chipaca> abeato: which is not particularly helpful :-)
<Chipaca> abeato: no doubt you have better debug info locally
<abeato> Chipaca, right, I just saw that in "snap change 1"
<abeato> weird thing, then it retried and the second time it worked :/
<Chipaca> also, whoa, 96 bogoMIPS
<Chipaca> speed fiend
<abeato> hehe, yes, it is a pretty slow processor
<Chipaca> mborzecki: what're you trying to do?
<zyga> 96 tail movements in turtle graphics
<mborzecki> Chipaca: was wondering if there's something more to collect when we fail to mount a snap
<Chipaca> zyga: tail *recursive*?
<zyga> Chipaca: ouch ;)
<Chipaca> mborzecki: AFAIK no
<Chipaca> mborzecki: systemd doesn't even report the errno of the mount call
<zyga> because there is none
<zyga> I mean
<mborzecki> Chipaca: right, that's the protocol part
<zyga> not one, it uses libmount
<zyga> lots of more complexity and features handled
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> if you need to do foo, and you do it by using libfoo, that does not get you off the hook of handling foo errors properly
<mborzecki> errors go to /dev/foo
<Chipaca> I mean, you're responsible for the libraries you use as well as the code you write
<Chipaca> mborzecki: only in 4.16.17 compiled on even days of the month though
<zyga> mborzecki: /dev/foo?
<mborzecki> zyga: s/f/p/ if you wish :)
<zyga> ah
<zyga> well
<zyga> you are actually close ;)
<zyga> there is a new kernel interface for mount errors
<zyga> and it is a special device
 * zyga looks for the patch
<mborzecki> no wai
<mborzecki> zyga: link?
<Chipaca> mborzecki: too late
<Chipaca> mborzecki: EVERYTHING IS ~~SPIDERS~~ block devices
<mborzecki> btw. on friday i got my car back from the shop, the damage cost ~1800eur to fix, fortunately i'm not paying :P
<zyga> I cannot find the patch
 * zyga looks through bookmarks
<Chipaca> mborzecki: whoa
<pedronis> hi
<zyga> hey :)
<mup> PR snapd#5296 opened: daemon: paging is not a thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/5296>
<Chipaca> mvo: if I had a feature I needed to be in 2.34, what's the latest it can land on master?
<Chipaca> (without causing undue work to other people i mean)
<Chipaca> also, that pr ^ is the shortest I've done in ages :-)
<Chipaca> popey: you should snap OpenNFSv3 just to confuse people
<Chipaca> needs some care in writing the description so you don't really know if you're getting a filesystem or a racing game
<popey> hah
<Chipaca> 'from scratch rewrite of NFS with a focus on performance and interoperability', say
<zyga> mborzecki: I think your PR is bigger
<mup> PR snapd#5297 opened: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
<mborzecki> pedronis: just to be sure i'm not missing something, InstanceKey in snap action == InstanceKey in current snap in context right?
<mvo> Chipaca: for 2.34 would be good to land this week or early next week
<Chipaca> mvo: ok
<Chipaca> mvo: thanks
<mup> PR snapd#5296 closed: daemon: paging is not a thing <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5296>
<pedronis> mborzecki: yes, for refreshes
<mborzecki> pedronis: thx
<mborzecki> pedronis: i'm close to finishing with the changes in store, once i push the patch, i'll send you a link for a quick review in case i did something overly stupid there
 * zyga -> coffee
<mup> PR snapd#5298 opened: store, image: have 'snap download' use v2/refresh action=download <Created by chipaca> <https://github.com/snapcore/snapd/pull/5298>
<Chipaca> pedronis: ^ info inch-pebble
<pedronis> Chipaca: thx, I'll look after the break
<Chipaca> pedronis: somewhat trepidatious as it almost seemed to easy :-)
<Chipaca> too*
<Chipaca> in other news: you'll be shocked to hear snapd doesn't work in WSL
<Chipaca> (there's a bug about it an' all)
<zyga> Chipaca: is it snapd or general code around it that breaks?
<Chipaca> zyga: WSL doesn't support daemons
<Chipaca> zyga: WSL doesn't support systemd
<zyga> daemons are supported
<zyga> but systemd is not
<Chipaca> zyga: ah, release notes I read said No, but that was a while ago
<zyga> yeah, it is recent
<mborzecki> well, snaps under wsl, on windows, that would be fun
<zyga> mborzecki: well, once they support mount namespaces we could
<zyga> drop all sandboxing
<zyga> and handle mounting snaps with something else (unpack?)
<Chipaca> zyga: fuse :-)
<Chipaca> (does it even)
<Chipaca> i mean, windows does have the idea of mounting stuff
<zyga> Chipaca: WSL does some special things to windows filesystem
<zyga> so not easily
<Chipaca> zyga: if we really wanted to pursue this we might be able to get in touch with people at ms
<zyga> mborzecki: hey look https://github.com/snapcore/snapd/pull/5297 is green now
<zyga> I feel I should swap this review for your uber rename one
<mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
<zyga> this needs a 2nd review https://github.com/snapcore/snapd/pull/5283 and is pretty short and simple
<mup> PR #5283: snapstate: get rid of needsMaybeCore <Created by mvo5> <https://github.com/snapcore/snapd/pull/5283>
<zyga> https://github.com/snapcore/snapd/pull/5230 needs a 2nd review and is otherwise ready
<mup> PR #5230: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230>
 * cachio afk
<zyga> jdstrand: hello, can you please enqueue some time to look at this https://github.com/snapcore/snapd/pull/5170#issuecomment-396216845
<mup> PR #5170: interfaces/builtin: add adb-support interface <Blocked> <Decaying> <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<pedronis> Chipaca: I think we might have an ubuntu-image test using the fakestore, so it probably needs to learn about download
<Chipaca> pedronis: only one spread error, and it seems unrelated to my change
<zyga> mvo: can you please weigh in on https://github.com/snapcore/snapd/pull/4996
<mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
<zyga> is that ready for landing or is more stuff needed
<pedronis> Chipaca: ok, I'm probably misremembering then
<zyga> mvo: can you please add a reference to the apt bug on https://github.com/snapcore/snapd/pull/5122
<mup> PR #5122: snap: add support for `snap advise-snap --from-apt` <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5122>
<Chipaca> pedronis: maybe fakestore implemented enough of v2 refresh for it to work :-)
<Chipaca> pedronis: tests/main/snap-download talks to the real stores tho
<pedronis> Chipaca: possibly,   no I remembered right:  /main/prepare-image-grub/task.yaml  seems to use the fakestore, maybe a double check that it works for semi-reasonable reasons would be good
<Chipaca> ah, prepare-image
<pedronis> ah, it uses the fakestore only for assertions
<pedronis> Chipaca: anyway it probably is a good idea to make sure the fakestore could handle download
<pedronis> given we are in the middle of introducing it
<pedronis> Chipaca: but yes, seems it should just work, afaict there's just a Action == "refresh"Â in all the relevant cocde
<Chipaca> pedronis: we could make it barf on unknown actions, or sth
<Chipaca> seems fine as is though
<mvo> zyga: re 4996> does it need a gustavo review to ensure names (e.g. ifaceRepokey) are agreed upon?
<zyga> mvo: the name was changed since earlier reviews (AFAIR by pedronis) so .. not sure
<pedronis> it was changed by mborzecki picking one of couple of suggestions
<pedronis> I made I think
 * Chipaca ~> lunch
<mborzecki> right, i took over 4996 for a while and addressed all (most) comments
<zyga> mvo: can you look at https://github.com/snapcore/snapd/pull/4416
<mup> PR #4416: tests: performance measurements for basic snapd commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4416>
<zyga> you reviewed it before
<zyga> and it's the only PR from 2017:D
<pedronis> mvo: the choices were snap-interfaces or snap-profiles or snap-interface-profiles
<mvo> pedronis: its fine with me, just want to ensure gustavo is happy about the naming as well
<mvo> (as he usually cares a lot about this)
<pedronis> mvo: then you need to wait, but it's been like this since forever
 * zyga -> lunch
<mvo> zyga: I looked at 4416 - it looks like your question ("how its supposed to be used") is not answered
<pedronis> mvo: it's going to be used when we reload profiles
<mvo> pedronis: yeah, sorry, I was replying to a different PR (the performance measure one)
<pedronis> ah
<mvo> pedronis: I will +1 the other one, one sec
<pedronis> I saw the 4**6  IÂ didn't read the middle number
<pedronis> s
<pedronis> it seems
<mvo> pedronis: :) no worries
<mvo> pedronis: just shows we still have too many open
<pedronis> that is true
<mvo> pedronis: looks like 5221 just needs this tiny tweak that pawel suggests and then it can go in as well(?)
<pedronis> mvo: yes, IÂ will do the change today
<pedronis> I'm also working on actually using this
<mvo> pedronis: nice
<mvo> mborzecki: how did you create test-snapd-appstreamid? via a snapcraft file?
<mvo> mborzecki: aha, nevermind, found it
<mborzecki> mvo: yup ;) glad that you found it
<mvo> mborzecki: I make it arch: all, it breaks on non amd64 tests right now:)
<mborzecki> right, iirc i've only published amd64 snap
<mvo> mborzecki: yeah, no worries, I take care of it
<mborzecki> mvo: ok, great
<mup> PR snapd#5299 opened: tests: publish test-snapd-appstreamid for any architecture <Created by mvo5> <https://github.com/snapcore/snapd/pull/5299>
<pedronis> Chipaca: I did a pass over the download one
<mvo> pedronis: if you have a spare cycle I would love to get an opinion on 5276
<pedronis> mvo: it looks good, but IÂ think we want like for core,base,kernel,gadget to make sure  snapd  is done first (even if seed.yaml order isn't what we expect)
<pedronis> I added a comment there too
<mup> PR snapd#5300 opened: tests: skip security-dev-input-event-denied on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/5300>
<Chipaca> mborzecki: https://www.gumtree.com/p/bicycles/unisex-optima-cougar-mountain-bike./1302194477
<Chipaca> mborzecki: https://www.gumtree.com/p/bicycles/gents-bike-ladies-bike/1302156061
<mborzecki> Chipaca: those look legit
<Chipaca> mborzecki: told you
<Chipaca> not sure why but bikes have very low resale value in uk
<mborzecki> Chipaca: hmm weird, it's like cars then, isn't it?
<popey> also, gumtree -> stolen goods
<zyga> my connection broke at around when cachio was talking so I just returned home then
<Chipaca> popey: not always though
<popey> Sure.
<Chipaca> you do need a sketchometer though
<Chipaca> sketchy-o-meter
<zyga> hmmm
<zyga> guys, does anyone have a theory why there are all the test failures recently?
<zyga> any specific change that triggered it
<Chipaca> zyga: I blame multicasts on broken packets
 * Chipaca puts away his BOFH excuse generator
<zyga> for instance, what broke
<zyga> + systemctl is-active snapd.snap-repair.timer
<zyga> inactive
<zyga> mborzecki: can you please look at v
<zyga> https://github.com/snapcore/snapd/pull/5297
<mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
<Chipaca> mvo: #5294 confirmed wrt cla
<mup> PR #5294: Update SELinux Policy <Created by kevinanderson1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5294>
<jdstrand> roadmr: hi! would you mind flipping on requash enforcement?
<roadmr> jdstrand: sure! flipping now
<jdstrand> roadmr: thanks!
<roadmr> jdstrand: where "now" is now. I'ts just been flipped to ON
<mvo> Chipaca: confirmed that the CLA is singed or not signed?
<roadmr> jdstrand: also we'll get r1089 rolled out today \o/
<jdstrand> roadmr: thanks! :)
<jdstrand> roadmr: unrelated to that, fyi, this seems stuck: https://dashboard.snapcraft.io/snaps/inoxision-webclient/revisions/115/
<jdstrand> roadmr: as does https://dashboard.snapcraft.io/snaps/falkon/revisions/45/
<roadmr> jdstrand: let me unwedge them
<jdstrand> thanks
<roadmr> jdstrand: interesting, inoxision-webclient says "Task 47c953d4-cb72-4618-9df6-5de67275e931 failed. ". I'll unwedge for now but will have a closer look at that task id later
<jdstrand> yeah, thanks
<roadmr> jdstrand: falkon is ready to roll, inoxision-webclient should be in a couple of mins (it's a large snap)
<mborzecki> off to pick up the kids
<mborzecki> zyga: i'll take a look when i get back
<zyga> thanks
<zyga> jdstrand: hey :)
<zyga> mvo: signed
<zyga> jdstrand: you may find https://github.com/snapcore/snapd/pull/5297 interesting :)
<mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
<mvo> zyga: cool, thanks
<jdstrand> hey zyga :)
<mup> PR snapd#4700 closed: interfaces: add the dvb interface <Created by ThyMYthOS> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4700>
<Chipaca> mvo: signed
<mup> PR snapd#5300 closed: tests: skip security-dev-input-event-denied on s390x/arm64 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5300>
<popey> Wimpress: ping!
<Wimpress> popey: Pong?
<Chipaca> pedronis: do you remember offhand how to get the thing 'snap download' expects for auth?
<pedronis> Chipaca: in which sense?
<Chipaca> pedronis: UBUNTU_STORE_AUTH_DATA_FILENAME=~/.snap/auth.json doesn't work
<pedronis> that doesn't work, because we don't store the store macaroons anymore there
<pedronis> only the local one
<Chipaca> pedronis: we didn't have a 'snap grab-the-auth' command?
<pedronis> Chipaca: we don't yet
<pedronis> Chipaca: but snapcraft export-login works
<pedronis> one sec
<Chipaca> ah there we go :-)
<Chipaca> hm, looks like my snapcraft macaroni has expired or sth
<pedronis> Chipaca: just give it  --acls  package_access
<Chipaca> huh, export-login asks you to log in again?
<pedronis> yes
<pedronis> anyway as I said you need different acls than your usual login
<pedronis> sorry, I mean, than the usual snapcraft macaroon
<Chipaca> right
<Chipaca> pedronis: wrt checking channel & revision, any reason not to let them through and have the store error?
<Chipaca> is there a path in which we set both?
<Chipaca> if we let them through, we get: error: cannot find snap "http": cannot download snap "http": Both revision and channel are present in the request for this Snap. It should be one or the other exclusively.
<pedronis> Chipaca: you an do snap download --channel=foo --revision=#  no?
<Chipaca> (and yes I'll drop the 'cannot find' thing)
<pedronis> are you saying for this it's good enough?
<Chipaca> pedronis: I'm saying it's weird to check it at this level
<Chipaca> pedronis: better to check it in cmd_download
<pedronis> ah, ok
<Chipaca> and at this level just let it through
<Chipaca> IOW, I'd drop the one in snapstate
<Chipaca> rather than adding it to image
<pedronis> please don't drop the one in snapstate
<pedronis> if you do, you need to add checks in a lot of places
<Chipaca> aw! you're no fun anymore
<Chipaca> :-D
<pedronis> not a lot, but enough that is hard to keep track
<Chipaca> pedronis: my 2nd favourite thing would be to move it into store itself
<Chipaca> unless your point is that we'd have to have that code in fakestore as well?
<pedronis> ?
<Chipaca> pedronis: ok to move it from snapstate to store?
<pedronis> fakestore is a server
<pedronis> Chipaca: yes, but remember this applies only to install and download
<Chipaca> yes. what's the name of the thing that mocks Store though.
<pedronis> ah, the other fake store
<pedronis> but yes
<pedronis> Chipaca: there's an argument to  do it both places tbh
<pedronis> belt and suspenders
<pedronis> as they say
<mup> PR snapd#5301 opened: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
<mvo> mborzecki: there is an nmap netcat?
<mvo> mborzecki: woah, I had no idea, fun
<mborzecki> Son_Goku: fedora netcat comes from nmap right? cc mvo
<Son_Goku> yes
<mborzecki> Son_Goku: ack, thx
<Son_Goku> redhat / fedora netcat is nmap's variant
<ondra> kyrofa ping
<zyga> mvo: FYI, https://github.com/snapcore/snapd/pull/5301#pullrequestreview-127623720
<mup> PR #5301: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
<zyga> pstolowski: I need a 2nd review on https://github.com/snapcore/snapd/pull/5278
<mup> PR #5278: cmd/snap-update-ns: add IsSnapdCreatedPrivateTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278>
<zyga> it's a PR with one new simple function
<kyrofa> Hey ondra, what's up?
<ondra> kyrofa hey
<ondra> kyrofa I've got problem with snapcraft on one machine
<mvo> zyga: thank you, just replied and updated the test. thanks for noticing. I can look into doing this on apparmor init as well if you feel this is cleaner
<ondra> kyrofa it gets stacked in pull stage on 99%
<zyga> mvo: I had a look and I don't know how to do it easily
<zyga> mvo: as we'd need the revno for core
<zyga> mvo: in apparmor.Backend.Initialize
<zyga> mvo: let me look at your patch first
<kyrofa> ondra, every time? Have you run in debug mode?
<mvo> zyga: aha, right
<zyga> mvo: ah, debian 9
<zyga> mvo: if this passes on Sid I'm happy then
<zyga> mvo: the rest can be re-factored separately
<ondra> kyrofa every time and on different projects now
<zyga> mvo: any idea why it didn't fail before?
<ondra> kyrofa I have wiped ~/.cache/snapcraft but some result
<kyrofa> ondra, no errors, though? Is this pulling build- or stage-packages?
<ondra> kyrofa I think stage packages
<mvo> zyga: its a new test, I added it to check that things really work as we expect them to work
<ondra> kyrofa https://paste.ubuntu.com/p/k3rfJT6RmG/
<ondra> kyrofa and then it will sit here forever
<zyga> mvo: https://github.com/snapcore/snapd/pull/5301/commits/e6eb26c46718747e7e328dba1db24958f45cda7f#r194454976
<mup> PR #5301: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
<zyga> I see
<kyrofa> ondra, huh, that's just fetching indexes
<kyrofa> Er, indices
<zyga> please make this modification and if it passes I'm +1
<zyga> having no 2nd phase tasks would be a major simplification
<pstolowski> zyga: looking
<mvo> zyga: ok, will do tomorrow (or feel free to just tweak yourself). I need to go and play hockey now :)
 * mvo waves
<zyga> :)
<ondra> kyrofa running apt-get update passes fine
<ondra> kyrofa I do have multiple architectures on that machine though
<kyrofa> ondra, hmm, that could make things a little odd. Try running `snapcraft pull --enable-geoip` as well
<ondra> kyrofa so it was working fine, can't really say when it broke, not apparent reason there
<ondra> kyrofa loads of errors with that option
<ondra> kyrofa and indeed errors are related to arm64 and armhf
<ondra> kyrofa interestingly I have another machine with similar setup, same errors there, but build still works
<pstolowski> zyga: 1 comment
<ondra> kyrofa OK so it looks like snapcraft is trying to be smarter and it's not actually following /etc/apt/sources.list
<kyrofa> ondra, when you ctrl+c is while it's hung there, do you get a traceback?
<ondra> kyrofa there I have correct setup for each arch
<ondra> kyrofa https://paste.ubuntu.com/p/Mb9zBYFZY5/
<zyga> pstolowski: thank you, looking now
<zyga> pstolowski: replied now
<Luke> how does snapcraft decide what to include in the install/stage after the build phase? Is it just any file or change that is applied outside of the build dir?
<kyrofa> ondra, huh, it really is just the apt api sitting there
<kyrofa> ondra, I'm really not sure what's happening there
<kyrofa> ondra, what happens if you remove the multiarch stuff?
<ondra> kyrofa then I won't be able to cross build :)
<kyrofa> ondra, haha, you can't right now anyway ;)
<mup> PR snapd#5278 closed: cmd/snap-update-ns: add IsSnapdCreatedPrivateTmpfs and tests <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5278>
<ondra> kyrofa lol
<kyrofa> I'm just throwing darts at the wall, trying to figure out what's causing it to get caught up
<ondra> kyrofa fair point :P
<zyga> thank you pawel!
<ondra> kyrofa testing it now
<ondra> kyrofa so I removed arches with dpkg, I left them in sources, which seems to be ignored somehow anyway
<ondra> and that is same result, stacked at 99%
<kyrofa> sergiusens, any idea what would cause the apt API to do that ^ ?
<ondra> kyrofa and 'snapcraft pull --enable-geoip' passes without error
<kyrofa> ondra, wait, that finishes the pull step?
<ondra> kyrofa ha and now that continues to pulling other parts
<kyrofa> Innnteresting
<kyrofa> It sounds like one of the repos being used it having issues, then
<ondra> kyrofa so calling snapcraft will hang, calling ''snapcraft pull --enable-geoip' will complete pull stage
<kyrofa> ondra, yeah, by default it just uses archive.ubuntu.com, but with geoip will use your country prefix
<ondra> kyrofa I'm running it in the cloud, so god knows what that actually is
<kyrofa> Oh, fun
<sergiusens> ondra: please post on the forum
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<zyga> jdstrand: do you think we could fast-track https://github.com/snapcore/snapd/pull/5297
<mup> PR #5297: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <https://github.com/snapcore/snapd/pull/5297>
<zyga> and land it?
<jdstrand> zyga: I'll move it to the top of the list, but the others need to wait. I owe morphis a review
<zyga> ack
<zyga> thank you
<zyga> it's a large and very boring review
<zyga> so I just want to land it to help me out and not conflict
<ondra> sergiusens https://forum.snapcraft.io/t/snapcraft-getting-stacked-at-99-during-pull-stage/5876
 * zyga explores a descriptor leak that makes no sense
<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#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
 * zyga found the bug but first walk
<kyrofa> zyga, if I have an `environment:` keyword in the root of my YAML, that applies to all apps and hooks, right?
<zyga> kyrofa: let me check
<zyga> kyrofa: I'd say yes
<zyga> but I'll look
<zyga> kyrofa: ha
<zyga> so it looks buggy
<zyga> kyrofa: ah, sorry
<zyga> it looks good
<zyga> so yes,
<kyrofa> zyga, alright, something odd is happening on my hook... still investigating
<zyga> we take the global (snap-global) environment
<kyrofa> Thanks for the quick check!
<zyga> then take the per app environment
<zyga> oh, hook you say?
<zyga> kyrofa: curious
<zyga> kyrofa: hooks don't take environment at all
<zyga> kyrofa: yes, hooks just take the snap-level environment keys
<zyga> and with that I'm off for another round of bicycling
<roadmr> yeay zyga
 * cachio afk
<mup> PR snapd#5302 opened: snap: don't include newline in hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5302>
<kyrofa> zyga, that's ^ the problem I was hitting
<zyga> kyrofa: I saw that just now. I will review it first thing tomorrow
<kyrofa> Thanks zyga
<zyga> Thank you x10 for the patch!
<wililupy> question: what is '/var/lib/snapd/hostfs' used for?
<zyga> wililupy: hey
<wililupy> hi zyga!
<zyga> wililupy: it is used at runtime to host the / of the host system
<zyga> technically when a snap application runs it constructs some temporary directories and then makes moves all of the root filesystem (/) to /var/lib/snapd/hostfs, replacing the / with something else
<zyga> then hostfs is used as a "view" to the rest of the filesystem
<wililupy> zyga: thats what I thought. I have a weird apparmor error trying to confine my snap and the path.
<wililupy> I created an interface with the rule: /var/lib/snapd/hostfs/{,*} rw,
<zyga> what is the denial you are getting, exactly?
<wililupy> Jun 11 22:52:36 dpdk-test kernel: [ 1408.757203] audit: type=1400 audit(1528757556.659:90): apparmor="DENIED" operation="open" profile="snap.dpdk-wililupy.testpmd" name="/var/lib/snapd/hostfs/mnt/huge/" pid=2546 comm="testpmd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga> Right
<zyga> I think what we want instead is to mirror /mnt from the host
<zyga> and add it to removable media or a new interface
<zyga> there's a thread about that on the forum
<wililupy> and mnt/huge is not there
<zyga> I will make a patch for this tomorrow
<zyga> (it's 1AM for me)
<wililupy> zyga: no problem. Its for a hugepages interface I am working on (https://github.com/wililupy/snapd/blob/master/interfaces/builtin/hugepages_control.go)
<zyga> I can quickly say that https://github.com/wililupy/snapd/blob/master/interfaces/builtin/hugepages_control.go#L35 is probably not going to fly
<zyga> as this gives full write access to the host
<zyga> why /mnt/huge? isn't there a standardised place for huge pages elsewhere?
<wililupy> zyga: I'm following their testing documentation and that is the path they use in their example.
<zyga> can you refer to that?
<wililupy> zyga: http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#running-dpdk-applications
<zyga> mount | grep huge
<zyga> hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
<zyga> unless dpkd requires that specific path
<zyga> wililupy: could you open a forum thread about this effort? it will be easier to sync this way than on IRC
<wililupy> Sure thing. Get some sleep.
<mup> PR snapd#5297 closed: cmd/snap-update-ns: use RCall with SyscallsEqual <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5297>
#snappy 2018-06-12
<mup> PR snapcraft#2159 closed: many: extract lifecycle ordering into own module <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2159>
<mborzecki> morning
<zyga> Good day
<zyga> mborzecki: thank you for the review
<mborzecki> zyga: hey
<mborzecki> zyga: sorry for doing it late, went for a quick bike route, prepped the dinner and only then came back to do the review
<zyga> No worries
<zyga> kyrofa: found a bug in hook environment
<zyga> There is a pr
<zyga> I think we need to respin 2.33
<mborzecki> hmm, why were there newlines used in hook env?
<zyga> no idea
<zyga> old bug
<zyga> I think we used to have the same bug in app env
<zyga> but it was fixed for apps
<mborzecki> right, it was fixed for apps back in 2.23
<mborzecki> and the \n was introduced in 2.11
<zyga> hey mvo
<zyga> some bad 2.33 news perhaps
<mvo> hey zyga
<mvo> zyga: good morning - tell me more please
<zyga> there's a small PR that fixes an embarrassing issue in hooks
<zyga> https://github.com/snapcore/snapd/pull/5302
<mup> PR #5302: snap: don't include newline in hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5302>
<zyga> so maybe new 2.33 needed
<mvo> zyga: what is the impact of the issue?
<zyga> hooks that use environment get broken values
<zyga> the newlines mess something up apparently
<mvo> zyga: uh, ok. is this a regression?
<zyga> ha, good question
<zyga> if so it is very old
<zyga> mborzecki found that it got broken in 2.11
<mvo> zyga: ok, thanks for the investigation!
<zyga> mvo: all the kudos go to kyrofa
 * mvo hugs kyrofa 
<mborzecki> introduced back in 2.11, 2.23 fixed AppInfo.Env(), but hooks env was left intact (probably because \n seemed special to begin with)
<mvo> zyga: does http://paste.ubuntu.com/p/ggZryMrdQm/ ring a bell (cc mborzecki )
<mvo> zyga: i.e. [Mon Jun 11 13:21:08 2018] audit: type=1400 audit(1528723268.368:2393): apparmor="DENIED" operation="signal" profile="snap-update-ns.test-snapd-service-watchdog" pid=1 comm="systemd" requested_mask="receive" denied_mask="receive" signal=abrt peer="unconfined"
<mvo> this is an autopkgtest failure on arm64
<zyga> this says that "systemd" running with the snap-update-ns.test-snapd-service-watchdog label (I presume a C helper?) cannot receive SIGABRT from an unconfined process
<zyga> so if something kills snap-update-ns it won't get the signal
<zyga> I think that warrants a patch
<mborzecki> hmm
<mborzecki> there were some changes recently to signals
<mborzecki> from jdstrand, about receiving the signals from unconfined processes or somesuch
<zyga> mvo: I'll make a PR in a sec
<mborzecki> nvm, that change from jamie was about signals from other snaps
<mborzecki> mvo: is the system in which this happens super slow? maybe it hit the watchdog timeout already (i.e. while the snap is still starting) in which case systemd sends sigabrt
<zyga> mvo: #5303
<mup> PR #5303: interfaces/apparmor: allow killing snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5303>
<mup> PR snapd#5303 opened: interfaces/apparmor: allow killing snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5303>
<mvo> mborzecki: its an arm64 it is probably not fast, not sure if super slow though, let me try to guestimate
<zyga> mvo: wait, did something enable the watchdog along the way?
<mvo> mborzecki: a full testsuite run take 3h15 which there, on amd64 its ~1:15h or so
<mvo> zyga: I think this is part of the test
<mborzecki> zyga: it's part of the test
<zyga> ah
<zyga> ok
<mvo> mborzecki, zyga do you think this denial is just noice or could it be the reason for the failure?
<zyga> it's not noise for sure,
<zyga> apparmor is fun
<zyga> you can confine a process so that it cannot be SIGKILLed
<zyga> just deny signals
<zyga> and that's that
<mvo> mborzecki: we give it 20s to restart, no? so even slow shouldn't be that slow
<mvo> mborzecki: (?)
<mborzecki> mvo: it's using update-ns profile, iirc that's suppsoed to be used when s-c runs s-u-n (zyga?)
<mborzecki> and then it switches to the app profile
<mvo> its fun, the fatest is actually ppc64el afaict
<zyga> mborzecki: that's correct
<zyga> snap run foo -> snap-confine -> snap-update-ns.foo -> snap.foo.foo
<zyga> that's the profile transition chain
<mborzecki> mvo: so what happens, is that it's still runnign with s-u-n profile while it gets abrt, hence the quesion about that host being super slow :P
<zyga> what I don't get is how it can run comm="systemd"
<zyga> that's weird
<pstolowski> mornings
<zyga> pstolowski: good morning
<mvo> zyga, mborzecki I upload it to comisc to get another autopkgtest run with this fix in
<mborzecki> pstolowski: hey
<zyga> pstolowski: can you please look at #5302
<mvo> hey pstolowski
<zyga> mvo: is you do a new upload then please consider the hook
<mup> PR #5302: snap: don't include newline in hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5302>
<mvo> zyga: yeah, I will mark it for 2.33
<zyga> let pawel review it
<mvo> zyga: this will be a cosmic only upload
<zyga> I think the patch can be reduced
<zyga> Kyle did some refactoring there as well
<mborzecki> zyga: i'm looking at #5303 and #5174, the comment in 5174 mentions that we allow receiving signals from uconfined in the base abstraction (the template right?)
<mup> PR #5303: interfaces/apparmor: allow killing snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5303>
<mup> PR #5174: interfaces/default,process-control: miscellaneous signal policy fixes <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5174>
<zyga> mborzecki: base abstraction is something else
 * zyga looks
<mvo> zyga: just looked at it, fun bug (the env one)
<zyga> mborzecki: snap-update-ns is not including any abstractions
<zyga> this is why (probably) it has this issue
<zyga> mvo: I think 5303 ought to be seen by jdstrand
<zyga> but he won't be around until afternoon
<mup> PR snapd#5302 closed: snap: don't include newline in hook environment <Created by kyrofa> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5302>
<pedronis> pstolowski: hi,  I need to reuse code similar doAutoConnect but checkConnectConflicts doesn't quite fit as it is, otoh IÂ noticed there are some simplications that can be done there now that we moved the checks before/out of the connect bit, I'll propose a small PR with just that, that you can look at
<pstolowski> pedronis: hey, sounds good, thanks
<mborzecki> people seem to be building the aur package on most interesting setups, got one report that building fails, the guy is using clang (with ld), and ld is not there (?), another one https://paste.ubuntu.com/p/YbyN6Mtpvn/ i think it's behind some proxy that either cuts the network or does some bad stuff to the headers
<mvo> zyga: thats fine, no worries about 5303
<mvo> zyga: afternoon is early enough
<mvo> zyga: so far its only an issue on arm64
<zyga> ack
<Chipaca> nack
 * Chipaca plays  it safe
<zyga> quack
 * Chipaca 's space bar is still not debouncing properly
 * zyga plays it eco
 * Chipaca plays 'It' in C#
 * Chipaca notes C# is D because # == â¯â¯ but most people don't care
<Chipaca> huh, wikipedia actually says # is 1.5 semis
<Chipaca> oh well, i've been lied to before this
<Chipaca> and by better people than my music teacher
<mup> PR snapd#5304 opened: overlord/ifacestate:  simplify checkConnectConflicts and also connect signature <Created by pedronis> <https://github.com/snapcore/snapd/pull/5304>
<pedronis> pstolowski:  ^  ,  I will look over the disconnect one in a little bit
<cjwatson> I've certainly never seen double-sharp notated in any way other than â¯â¯ or ðª
<pstolowski> pedronis: thanks
<mup> PR snapd#5299 closed: tests: publish test-snapd-appstreamid for any architecture <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5299>
<mborzecki> pedronis: do you think i should push the store changes to #5253?
<mup> PR #5253: snap: introduce new fields for parallel snap installation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5253>
 * zyga -> brief walk
<pedronis> mborzecki: we need to think a bit
<pedronis> how we want to proceed
<mborzecki> pedronis: the renames and snapsup changes should be fairly benign
<mborzecki> (or at least not break things)
<mborzecki> and subsequent reviews would be much smaller
<pedronis> mborzecki: but some bits are not just renames, those bits need tests of some form
<pedronis> also landing will disrupt Chipaca's work
<mborzecki> pedronis: i think we should land Chipaca's pr first, pulling in master to my branch is not a problem
<pedronis> mborzecki: either you are not blocked, it's probably a good time to separately write some failing spread tests and mangers_test.go you want to pass at some point
<pedronis> mborzecki: I need to look at the rename PRs to see what is  doable there
<pedronis> mborzecki: John's PR need a 2nd review btw
<mborzecki> pedronis: have it open already :P
<popey> if I build a snap against base: core18, will it automatically connect to the interfaces in core18?
<popey> I can't see any way to identify which base snap the app snap is connected to
<pedronis> popey: that is still to be defined, but really core interfaces are system interfaces  (core was just use to attach them somewhere), so unlikely they would connect to a base in the new world
<popey> hm. i have a core18 snap which just dies on its arse, and I can't see what it's connected to
<pedronis> on classic system right now they connect ot core
<jamesh> maybe you could hang the implicit interfaces off the snapd snap?
<pedronis> that's one of the ideas floating around
<pedronis> but I was confused, that discussion really applies to core systems
<pedronis> popey: they will connect to "core", the problem is that nothing probably brings it in unless it's already there
<popey> i have core and core18 installed
<pedronis> ok, then they should connect to core
<zyga> re
<popey> but I want them to connect to core18
<pedronis> nothing changed about that on classic
<pedronis> popey: that doesn't mean anything
<popey> I built the app in an 1804 container
<pedronis> that's not releated to intefaces
<pedronis> what interface is giving you problems?
<popey> i dont know, I'm trying to debug
<pedronis> there might be corner cases about intefaces that give access to binaries, but even connected to core, you would get the binaries in core18
<pedronis> (of course the interfaces cannot give access to core18-only binaries)
<jamesh> popey: interfaces like "desktop" are about connecting to the host system: they don't have a whole lot to do with the minimal root file system shown in the sandbox
<jamesh> a desktop snap based on "core" is doing pretty much the same thing as a desktop snap based on "core18"
<popey> huh. okay. thanks.
<pedronis> IÂ mean there might be also an approach in which we do connect to the base (but it would be more about the base controlling the subset of host interfaces that make sense), that model though is quite a bit of changes from the status quo
<pedronis> we might do it at a later point (don't know)
<Chipaca> mborzecki: if spread fails, I'll add the validator
<Chipaca> mborzecki: otherwise I'll merge :-)
<mborzecki> Chipaca: it failed, but i restarted the build already :) not a blocker though, i can add it with my changes
<Chipaca> mborzecki: hah. Well then, if it fails *again* :-D
<pedronis> mborzecki: I think what we should do is that IÂ should look at the rename PR again (after IÂ have done some other things I owe though), and then we should try to have a HO
<Chipaca> pedronis: rename as in rename a snap?
<mborzecki> pedronis: ok
<mborzecki> Chipaca: rename as in snap.Info.Name() -> snap.Info.(Instance|Store)Name()
<pedronis> Chipaca: no, s/Name/InstanceName/ and frieends
<Chipaca> aww
<mborzecki> Chipaca: 5253 if you want to take a look
<Chipaca> i got my hopes up for a bit
<mvo> popey: what error do you see? could you pastebin or make the snap(craft.yaml) availabe? maybe we can help with the debug?
<popey> mvo: thanks. It's kdenlive. I've built the snap in an 18.04 container. It just dies. Nothing useful on the command line. Nothing much in dmesg
<popey> only an apparmor dnial trying to look at /proc/sys/kernel/core_pattern
<popey> so I presume it wants to core dump
<popey> I can send you the snap if you're interested
<mvo> popey: yeah, if you could make it available that would be great, at least I could give it a poke
<popey> do you have wormhole installed?
<pedronis> pstolowski: I added some comments to the disconnect hooks PR
<pstolowski> ty
<pedronis> pstolowski: do take a look at my PR when you have moment, it will conflicts but should also simplify some stuff in that PR
<pstolowski> pedronis: will do soon
<pedronis> mvo: did you see my comments in #5276 and #5301 ?
<mup> PR #5276: devicestate: support seeding from a base snap instead of core <Created by mvo5> <https://github.com/snapcore/snapd/pull/5276>
<mup> PR #5301: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5301>
<mvo> pedronis: yes, will work on those in a little bit
<mup> PR snapd#5305 opened: interfaces/policy: test that base policy can be parsed <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5305>
<mup> PR snapd#5306 opened: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5306>
<mborzecki> zyga: ^^
<zyga> I just saw this while opening my own PR
<zyga> looking
<pstolowski> pedronis: +1 with one remark re auto name
<mborzecki> google:ubuntu-16.04-64:tests/main/interfaces-contacts-service started failing recently
<mborzecki> https://paste.ubuntu.com/p/w9gC7PBWCX/
<zyga> mborzecki: reviewed
<pedronis> pstolowski|lunch: I listed some options there, but IÂ also agree  we could do  the rename later in your PR
<mborzecki> zyga: thx, pushing fixes in a minute
<Chipaca> pstolowski|lunch: is #1776466 something you have on your plate?
<mup> Bug #1776466: snap get with multiple values does not return json <snapd (Ubuntu):New> <https://launchpad.net/bugs/1776466>
<pedronis> mborzecki: I did a pass over the whole 5253,  there are some open questions and it doesn't seem landable atm as it is, let me know when you want to chat
<mup> PR snapd#5307 opened: cmd/snap-confine: allow hard-coded mounts to be optional <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
<mup> PR snapd#5283 closed: snapstate: get rid of needsMaybeCore <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5283>
<mup> PR snapd#5286 closed: snapstate: fix assumptions about core in setup phase2 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5286>
<zyga> mborzecki: can you please look at 5307
<zyga> mvo: 5303 needs a 2nd review
<zyga> jdstrand: thank you for the review!
<zyga> jdstrand: I need to make the list of hard-coded mount operations in snap-confine partially optional
<zyga> jdstrand: specifically the /mnt directory must not be required as some existing bases (probably just the test ones) don't have it
<zyga> jdstrand: I made a PR that makes this possible #5307
<mup> PR #5307: cmd/snap-confine: allow hard-coded mounts to be optional <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
<mup> PR snapd#5308 opened: tests: skip "try" test on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/5308>
<zyga> jdstrand: I chose to use mount directly to avoid adding a lot of boilerplate
<jdstrand> zyga: I'd need to look at it more closely. it isn't exciting that it is broken out the way it is, but it also isn't that much and might even be cleaner the way you did it
<zyga> jdstrand: I implemented the "full" way initially, that is extra function that doesn't fail, propagates the error, etc
<zyga> but then it could not do the nice error formatting anymore because as an utility it could not just drop privs
<zyga> so I went this way
<zyga> jdstrand: I have two branches on GitHub that show where this is going, the one with the full history is feature/legacy-mnt-iface
<zyga> I'm now adding spread tests to it
<jdstrand> ok
<zyga> this is the rough diff
<zyga> https://github.com/snapcore/snapd/compare/master...zyga:feature/legacy-mnt-iface?expand=1
<zyga> jdstrand: the only thing I wasn't sure about was the apparmor rule
<zyga> jdstrand: I used: +/mnt/*/** rwk,
<zyga> coupled with /mnt/ r,
<zyga> so that you cannot make new things in /mnt but you can see the existing ones and you can write to things there already
<zyga> (that was my intent)
<pedronis> mmh, now I got:  + lxd.lxc stop my-ubuntu --force
<pedronis> Error: The container is already stopped
<pedronis> Try `lxc info --show-log my-ubuntu` for more info
<pedronis> from the lxd test
<jdstrand> zyga: to achieve that in the most compatible way, you would want: /mnt/{,*/} r, /mnt/*/** rwk,
<pedronis> pstolowski|lunch: I adressed your comment in #5221
<mup> PR #5221: snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
<jdstrand> zyga: I also don't think 'legacy-mnt' is right. the fhs defines it as "This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run."
<jdstrand> zyga: in practice, users use it for more than temporary access though
<zyga> jdstrand: are you suggesting that we don't do any new interface or just call it in a different way?
<jdstrand> rename it
<zyga> I used the word legacy because typically people don't really do things like that (or care about using /mnt specifically). Most users just get auto-mounts via /media
<zyga> do you have a suggestion for a better name?
<mvo> pedronis: I updated 5276
<mvo> pedronis: and the other one (5301)
<mvo> pedronis: but no rush
<jdstrand> I'm not sure what. mount-local? local-mount? mnt?
<jdstrand> zyga: how about start with 'mnt' since it takes inspiration from 'home' with the understanding that it'll probably change in PR review
<zyga> +1
<jdstrand> zyga: I understand why you chose legacy, but it isn't actually a legacy interface. it serves a real purpose in the modern world (users use it wrong of course)
<jdstrand> anyway. I'll think about it
<jdstrand> we should all think about it :)
<zyga> jdstrand: sure, I don't mind changing the name at all
<zyga> jdstrand: once the prerequisites land I will rename it
<pedronis> mvo: I looked at 5301, the other one needs to wait, IÂ have standup and then another meeting
<jdstrand> zyga: just for completeness, I don't care for -support because it implies being able to do mount() operations and -observe isn't right cause it allows 'w'rite
<jdstrand> zyga: -control also implies mount()
<jdstrand> more so than -support
<jdstrand> so, yeah, not sure yet
<mvo> pedronis: ta
<Saviq> hi all, can someone please comment on bug #1776295 whether it's by design or indeed a bug?
<mup> Bug #1776295: `stop` and `disable` should kill all processes regardless of daemon stop-mode <snapd:New> <https://launchpad.net/bugs/1776295>
<zyga> Saviq: ack
<zyga> Saviq: replied
<Son_Goku> zyga, mvo, niemeyer: https://src.fedoraproject.org/rpms/plasma-discover/c/31053b99061eb17bb29f7fd1142c9bd614247238
<zyga> Son_Goku: very nice :)
<zyga> any issues?
<Son_Goku> well, discover no longer crashes when the plugin isn't installed :)
<Son_Goku> so that's a plus
<Son_Goku> however, the plugin crashes when no desktop portal implementation is installed
<Son_Goku> we're fixing that now in the KDE Plasma 5.13.0 rebase going on now
<Son_Goku> but yeah, basically since the snap plugin isn't horrifically broken anymore, I figure it's worth enabling
<Son_Goku> people using snapd on Fedora KDE will get the plugin installed automatically when they upgrade to Plasma 5.13
<cachio> mborzecki, hey
<zyga> joc: hey, you have some feedback on https://github.com/snapcore/snapd/pull/5279
<mup> PR #5279: interfaces/builtin: create socketcan interface <Created by jocave> <https://github.com/snapcore/snapd/pull/5279>
<mborzecki> zyga: https://github.com/bboozzoo/aur-snapd/pull/7
<mup> PR bboozzoo/aur-snapd#7: snapd: use budled release pacakage, bump to 2.33-2 <Created by bboozzoo> <https://github.com/bboozzoo/aur-snapd/pull/7>
<zyga> mborzecki: +1
<joc> zyga: yep thanks, did the fix for travis already, will address Jamie's comments now
<zyga> super, thank you
<mborzecki> cachio: https://paste.ubuntu.com/p/SdQpcvyQWk/ line 1670 is when the timer is started, then gets stopped and never comes back
<cachio> mborzecki, yes
<mborzecki> cachio: 1662 snap-repair starts
<mborzecki> there's 2 instances of snap-repair running?
<mborzecki> zyga: i've updated #5306
<mup> PR #5306: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5306>
<cachio> mborzecki, it ran this test at thtat time
<cachio> https://paste.ubuntu.com/p/yKYkVSyyDk/
<cachio> mborzecki, I think the tst ubuntu-core-snapd-run-from-snap is causing that
<cachio> I'll rereun just those two to see
<mborzecki> cachio: ok, use the same seed, and just one worker
<cachio> mborzecki, I am also running this to see how the env is after the test
<cachio> spread -shell-after google:ubuntu-core-16-64:tests/main/ubuntu-core-snapd-run-from-snap
<niemeyer> Son_Goku: Nice! Was it just a matter of enabling it or is this just the tip of a long series of patches?
<Son_Goku> now it's just a matter of enabling it
<Son_Goku> earlier iterations of the backend plugin were too unstable to use
<Son_Goku> the implementation in discover is better than the one in gnome-software, which needs to be rectified
<Son_Goku> there's a lot of issues with g-s because the work you guys have done in Ubuntu Software hasn't been getting upstreamed
<Son_Goku> I checked recently in gitlab.gnome.org, and I haven't seen any proposals to submit those changes
<Son_Goku> and since hughsie maintains the Fedora package _and_ upstream g-s, my hands are tied unless the Ubuntu g-s/u-s maintainer upstreams those changes
 * zyga needs to handle some errands (accountant), ttyl
<Son_Goku> I gotta go to work now...
<Son_Goku> niemeyer, could you try to follow up with the g-s maintainer in Ubuntu about getting the improvements upstreamed?
<Son_Goku> even the simplest thing of being able to see different tracks doesn't work in upstream g-s
<cachio> mborzecki, confirmed
<mborzecki> hah
<cachio> ubuntu-core-snapd-run-from-snap is the reason
<mborzecki> cachio: so the quesion is now, is that test doing something wrong, or is it something else?
<cachio> mborzecki, in the restore it is doint rm -f /run/systemd/system/snapd.*
<cachio> mborzecki, not sure yet, it is a weird test
<mborzecki> cachio: but it's rm -f units in /run
<mborzecki> maybe that daemon-reload is triggering this
<cachio> I am running a shell session now
<cachio> I'll debug it to see where it is making the mistake
<mborzecki> cachio: ok, i see now
<mborzecki> so snap-mgmt stop will stop all units (snap-repair.timer) among them
<kenvandine> zyga, to reproduce the theme mount problem, install gtk-common-themes from edge and gnome-calculator from candidate
<mborzecki> cachio: and in restore only snapd.{socket,service} are started
<kenvandine> and snap run gnome-calculator
<cachio> mborzecki, yes
<zyga> kenvandine: what was the denial that you got?
<kenvandine> 2018/06/12 10:17:13.182049 main.go:192: cannot change mount namespace of snap "gnome-calculator" according to change mount (/snap/gtk-common-themes/319/share/themes/Communitheme /snap/gnome-calculator/172/usr/share/themes/Communitheme none bind,ro 0 0): cannot create writable mimic over "/snap/gnome-calculator/172/usr/share": permission denied
<cachio> we should restore all the snapd units
<cachio> restart
<mborzecki> cachio: probably systemctl start snapd.snap-repair.timer in that test's restore section will be enough
<cachio> ok, let me try it
<mborzecki> cachio: we know that the timer is started by default and gets stopped in the test, so starting it in restore seems fair
<cachio> mborzecki, change made, testing now
<cachio> lets, see
<zyga>  kenvandine what does âdmesg | grep DENIEDâ say?
<kenvandine> [435791.168135] audit: type=1400 audit(1528813033.178:1735): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.gnome-calculator" name="/tmp/.snap/snap/gnome-calculator/172/usr/share/" pid=20539 comm="3" srcname="/snap/gnome-calculator/172/usr/share/" flags="rw, rbind"
<kenvandine> zyga, it doesn't like mounting it over /usr/share
<kenvandine> well $SNAP/usr/share
<kenvandine> if i change it to $SNAP/share it's actually fine
<mup> PR snapd#5305 closed: interfaces/policy: test that base policy can be parsed <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5305>
<zyga> What is the content definition?
<zyga> I will debug this asap but I need to run an errand now
<kenvandine>   gtk-3-themes:
<kenvandine>     interface: content
<kenvandine>     target: $SNAP/usr/share/themes
<kenvandine>     default-provider: gtk-common-themes
<kenvandine> zyga, ^^
<kenvandine> zyga, i can change my snaps to use $SNAP/share/themes instead
<kenvandine> but that also requires a change to the desktop helpers
<mup> PR snapd#5309 opened: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5309>
<zyga> Thank you. I have all the information now
<joc> jdstrand: was just working on the reply to the auto-connect question, it's there now
<jdstrand> joc: thanks!
<jdstrand> joc: yep, that was my thinking. thanks again :)
<Chipaca> pedronis: you know this code better than I do: does  the snap action call need any fields beyond download for the "install" action?
<mup> PR snapd#5310 opened: tests: fix snapd-repair.timer on ubuntu-core-snapd-run- from-snap test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5310>
<Chipaca> pedronis: looks like it also needs name, revision, snap id at least
<pedronis> Chipaca: sorry, in a meeting
<Chipaca> pedronis: no worries, mostly answered myself
<mup> PR snapd#5298 closed: store, image: have 'snap download' use v2/refresh action=download <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5298>
<kenvandine> zyga, you can ignore that issue... i found if i change the mount point it works fine and actually is probably more desirable
<pedronis> Chipaca: I'm not sure IÂ understand the question, you mean in terms of the result? or what we put in the action?
<Chipaca> pedronis: currently we get everything, and we only need â¦ a lot less than everything :-)
<Chipaca> so looking at asking for just what we need
<pedronis> Chipaca: ah, we need quite a few things though, type, snap-yaml  probably more
<pedronis> it's a bit hard to tell
<zyga> kenvandine: ack, though I will get to the bottom of this anyway
<Chipaca> pedronis: what do we need type and snap-yaml for?
<pedronis> Chipaca: sorry, you were maing for "download", not for "install" ?
<pedronis> *meaning
<Chipaca> pedronis: :-/ yes
<pedronis> Chipaca: you need to consiser the code in image.go too
<Chipaca> pedronis: I added fields until it stopped complaining, because that's the sort of deep analytical work I do
<Chipaca> hmm, that code does seem to use type
<pedronis> Chipaca: I see at least Type and Contact
<pedronis> and whatever is needed to compute NeedsDevMode
<pedronis> I also expect soon we will need base and snap-yaml
<pedronis> (to grab the base and default-providers)
<pedronis> arguably we could also change the code though, to open the downloaded file once we have checked the assertions
<Chipaca> pedronis: this only asking for the fields we want is what we want to do, right?
<pedronis> it's reasonable, but then what I suggest, reopening in the snap in image after the assertion check
<pedronis> is probably the best of both
<pedronis> worlds
<pedronis> we don't have to update the list
<Chipaca> pedronis: hmmmmmmm
<pedronis> Chipaca: it's not a complicated change IÂ think
<Chipaca> pedronis: I'll try
<pedronis> Chipaca: notice that you want also all the fields to populate sideinfo likely
<pedronis> I mean consulting the store and not asking those is probably wrong
<Chipaca> pedronis: yeah
<mup> PR snapd#5308 closed: tests: skip "try" test on s390x <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5308>
<pedronis> Chipaca: any particular reason to do this btw?  it's reasonable but prepare-image/download are propbably not super common in the gran scheme of things
<mup> PR snapd#5303 closed: interfaces/apparmor: allow killing snap-update-ns <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5303>
<Chipaca> pedronis: this felt like a low-hanging fruit and it turned out to be an araucaria
<pedronis> it's not a low hanging fruit
<pedronis> sorry
 * cachio lunch
<pedronis> also because image.go will need to learn more tricks soon
<Chipaca> grmbl
<Chipaca> I'll just use it for conncheck then
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> i mean, i still want to give actions the optional fields thing
<Chipaca> because, conncheck just wants the 'download' field
<Chipaca> (and that one happens more often than snap download :) )
<pedronis> yes
<pedronis> there is makes full sense and we are more in control
<mvo> yay autopkgtest for cosmic green!
<pedronis> mvo: re-reviewed #5276
<mup> PR #5276: devicestate: support seeding from a base snap instead of core <Created by mvo5> <https://github.com/snapcore/snapd/pull/5276>
<pedronis> pstolowski: did you forget, could you re-vote in #5221 ?
<mup> PR #5221: snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
<pstolowski> pedronis: done
<pedronis> thx
<pedronis> ah, mvo looked at the first version only:  niemeyer or mvo: IÂ need a re-review of #5221
<mup> PR #5221: snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
<mvo> pedronis: sure
<niemeyer> pedronis: My main blocker there was the syntax, which we agreed on that call. If that's sorted per discussion and you're happy about the other points, LGTM
<pedronis> niemeyer: yes, I changed the syntax to be as the last update in the topic
<binarycreations> Hello there, I am attempting to create my first snap. I am running Arch Linux with the 4.14.48-1-LTS kernel, I am trying to get my head around how all the concepts work. Is my current host OS going to be supported by snapcraft?
<binarycreations> I am getting a mount error when attempting to run snapcraft cleanbuild when following the getting started documentation
<mklvr> Is the recommended build host for snaps still 16.04?
<kyrofa> mklvr, today, yes
<mklvr> kyrofa, Thanks!
<pedronis> mvo: thx
<cachio> niemeyer, hey, when you have time, could you please take a look to this one?
<cachio> tx
<niemeyer> cachio: Which one?
<cachio> https://github.com/snapcore/spread/pull/60
<mup> PR spread#60: Garbage collection for google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/60>
<cachio> zyga, when you have 5 minutes #5310
<mup> PR #5310: tests: fix snapd-repair.timer on ubuntu-core-snapd-run- from-snap test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5310>
<cachio> thanks
<zyga> Ack
<cachio> tx
<zyga> cachio: looking
<cachio> zyga, tx
<mup> PR snapd#5310 closed: tests: fix snapd-repair.timer on ubuntu-core-snapd-run- from-snap test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5310>
<gouchi> Hi, I tried using controller with a snap app but it is not recognized
<gouchi> We connect joystick and hardware-observe interface and we are using udev
<gouchi> using /dev/input/jsX and /dev/input/eventX
<gouchi> I tested on 16.04 and 18.04
<gouchi> it seems something from here https://nopaste.xyz/?905527d7c2931bd4#pN7KjJSL5qdrVAzy4T5IhZ2yr7/q/0Uh6mzFM4mcN2w=
<gouchi> which is blocked but I don't have anything in the log
<gouchi> any idea ?
<gouchi> of course using --devmode it is working
<zyga> Hey gouchi
<zyga> There is a branch that improves this
<zyga> Can you try âsnap refresh âedge coreâ
<zyga> And see if that fixes it
<gouchi> zyga: thank you I will try it
<gouchi> zyga: nice it is working ! Thank you very much !
<gouchi> zyga: when this branch will be moved to stable ?
<zyga> gouchi: I need to check, either very soon or in the next month
<zyga> you can keep using edge for now
<mup> PR snapcraft#2152 closed: many: automatically redo step for specified part <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2152>
<gouchi> zyga: thank you
<mup> PR snapd#5311 opened: tests: start active system units on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5311>
<mup> PR snapd#5312 opened: store: switch connectivity check to use v2/info <Created by chipaca> <https://github.com/snapcore/snapd/pull/5312>
#snappy 2018-06-13
<mwhudson> hi
<mwhudson> is anyone around?
<mwhudson> seeding the snaps on the latest bionic live-server daily is taking an extraordinary amount of time
<mwhudson> like 4 minutes
<mwhudson> does anyone know anything about this?
<niemeyer> mwhudson: I haven't heard anything about it, and certainly not expected
<mwhudson> niemeyer: i forumed https://forum.snapcraft.io/t/extremely-slow-seeding/5891
<niemeyer> mwhudson: Thanks!
<mup> PR snapd#5313 opened: tests: enable fedora 28 again <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5313>
<mborzecki> morning
<Lin-Buo-Ren> https://forum.snapcraft.io/t/wildcard-syntax-in-organize-keyword/5895
<mup> PR snapd#5221 closed: snap: parse connect instructions in gadget.yaml <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5221>
<zyga> o/
<zyga> good morning!
<mborzecki> zyga: is pstolowski still collecting logs from econnreset?
<mborzecki> pstolowski: https://paste.ubuntu.com/p/8BgX5gJdXj/
<zyga> not sure
<zyga> getsockopt: connection refused
<zyga> econreset is driving me crazy
<mup> PR snapd#5304 closed: overlord/ifacestate:  simplify checkConnectConflicts and also connect signature <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5304>
<mup> PR snapd#5313 closed: tests: enable fedora 28 again <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5313>
<mup> PR snapd#5292 closed: interfaces/docker-support: update for docker 18.05 <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5292>
<mup> PR snapd#5285 closed: tests/main/{snap-repair,ubuntu-core-services}: add debug information <Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5285>
<zyga> https://github.com/snapcore/snapd/pull/5230 needs a 2nd review
<mup> PR #5230: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230>
 * zyga goes out with the dog
<zyga> re
<mvo> abeato: hey, nice work on the watchdog PR! how urgent is this for you? is 2.34 (~5 weeks away) ok? or do you need it quicker?
<mvo> 5276 needs a second review
<mvo> please :)
<mup> PR snapd#5301 closed: snapstate,ifacestate: remove core-phase-2 handling <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5301>
<abeato> mvo, it is fine to have it for 2.34, thanks for asking (we already have a working workaround and do not need this urgently, it is fine to have it in an update)
<mborzecki> mvo: 5276 needs deconflicting
<mvo> abeato: great, thank you
<abeato> yw
<mvo> mborzecki: indeed, done
<pedronis> mvo: hi, did you see this:  https://forum.snapcraft.io/t/extremely-slow-seeding/5891
<mvo> pedronis: not yet, let me check
<mvo> mwhudson: hey, about your forum post about seeding being slow. is this a regression, i.e. was the previous snapd quicker?
<pstolowski> morning
<pstolowski> mborzecki: thanks for the log, i think i have enough logs now
<pstolowski> i'll look at econnreset again now
<mborzecki> mvo: +1 on 5276, also restarted the build as it failed with interfaces-calendar-.. (one that's know to randomly fail)
<mvo> mborzecki: thank you
<mvo> mborzecki: and thank you :)
<pstolowski> pedronis: hey, is there any benefit of doing task.SetStatus(state.DoneStatus) at the very end of task handler? I remember moving it towards the end in the reviews, but now that i look at it i doubt it serves any purpose
<pedronis> pstolowski: it's mostly for consistency,  are you wondering if you need it, we do need it
<pedronis> pstolowski: the reason we need  is that we want to add th tasks/change to state in the same atomic write to state as we set the task to done, otherwise we risk having it done again (and add the tasks again)
<pedronis> or fail because to add them forever because self-conflicts of some kind
<pstolowski> pedronis: ok, i see; there are some comments in a few other places that do that but they don't tell whole story, thanks
<pedronis> pstolowski: it's usually related to having the task change the state in a significant non idempotent way
<pedronis> at which point we want to mark it done in the same atomic write
<mwhudson> mvo: yes it's a regression, haven't tried for a couple of weeks though
<pstolowski> pedronis: understood, thanks
<mvo> mwhudson: thank you, I tried to reproduce but no luck so far (booted it just two times though). any hints what I could be missing? I used the amd64 image in a standard kvm vm with -m 1500
<mwhudson> mvo: i'm trying your command line and it's hanging for me
<mwhudson> maybe i should reboot my system
<mwhudson> (as in, my  laptop)
<mvo> mwhudson: what commandline did you use? I can try that one on my box
<mwhudson> mvo: kvm -m 1500 -snapshot ~/isos/bionic-live-server-amd64.iso
<zyga> what's the URL to the iso
<mwhudson> earlier i was using -m 1024 so i was wondering if it was swapping in the system
<zyga> I can try here for one more sample
<mvo> mwhudson: heh, that looks eerily similar ;)
<zyga> my network has higher latency than landlines
<mvo> mwhudson: aha, I can try with smaller ram values
<mwhudson> mvo: usually i use -cdrom $ISO -hda target.img
<mvo> mwhudson: I was thinking if .au makes a difference
<mwhudson> if it's hitting the network, i have other complaints :)
<mwhudson> the cd is usually plenty fast here
<mwhudson> *cdn
<mvo> mwhudson: or .nz - yeah, I shouldn't
 * mwhudson downloads a snap at 11MB/s
<pedronis> pstolowski: it's usually:    do things that could error,   change the state,  mark it done
<pedronis> pstolowski: if a task is fully idempotent it can rely on taskrunner marking it done
<mwhudson> argh this vm booted after 4 mins but i forgot to pass -redir
<mwhudson> pedronis, mvo: http://paste.ubuntu.com/p/BQGMG4pZdM/ <- snap tasks 2
 * mwhudson reboots the host
<mborzecki> mwhudson: have you tried using virtio for net and drive btw?
<zyga> Done    2018-06-13T07:42:47Z  2018-06-13T07:44:35Z  Mount snap "core" (4650)
<zyga> this is certainly unexpected
<zyga> is this an SD card?
<zyga> unless this includes some waiting on other tasks
<pedronis> zyga: you need to look at the ready before, not the spawn
<pedronis> the spawn is not when they start running
<pedronis> is when they are created
<zyga> I see
<zyga> in that case it's still around a minute of waiting for mount
<zyga> that is curious
<pedronis> yes, also the time between the spawn and the first ensure ready is strangely long
<pedronis> 2018-06-13T07:42:47Z  2018-06-13T07:43:49Z
<zyga> each mount is slow
<zyga> mborzecki: what is the host storage like? is this a HDD or a SSD? which filesystem are you using
<zyga> er
<zyga> mwhudson: ^
<zyga> (bad tab)
<mborzecki> heh ;)
<mwhudson> baaaaaah rebooting my laptop fixed it
<zyga> pedronis: question about seeding
<zyga> pedronis: on line 28 we have "mark system seeded"
<zyga> but then we have more tasks below
<zyga> is that expected
<mwhudson> mborzecki: yes, too lazy to remember command line syntax for virtio
<mborzecki> mwhudson: fwiw it makes a huuge difference here ;)
<mup> PR snapd#5276 closed: devicestate: support seeding from a base snap instead of core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5276>
<mwhudson> mborzecki: ok, i'll try to teach it to my bash history :)
<Chipaca> moin moin
<Chipaca> I'm en route to the dentist; connection might be flaky
<mborzecki> zyga: https://www.youtube.com/watch?v=ofeCpN99FU8
<zyga> mborzecki: oh, nice, thank you
<zyga> mborzecki: apparmor logo looks a little bit like our flag :)
<Chipaca> zyga: mvo: anything else to note on the conncheck->info pr?
<mborzecki> zyga: what happened to the the dope penguin with gas mask on?
<Chipaca> asking because I wouldn't like to trigger a whole spread run for a small change only to then have to do it again :-)
<zyga> mborzecki: whaaat, I didn't know that was the previous logo
<mborzecki> zyga: https://gitlab.com/apparmor/apparmor this logo
<Chipaca> ooh, 'Add Vulkan abstraction' commit in apparmor
<Chipaca> (4 weeks ago)
<pedronis> zyga: not completely, it seems related to how auto-connect works
<pedronis> pstolowski: did you see: http://paste.ubuntu.com/p/BQGMG4pZdM/  the connects at the very end before mark seeded seems a bit wrong
<pedronis> zyga: pstolowski: ah
<pedronis> zyga: is the display that is off, they are sorted by id , not really time or sequence
<zyga> oh drat!
<zyga> indeed, I didn't see this
<zyga> should we change that
<pedronis> I don't know, is definetely more confusing now that we have tasks that add more tasks
<pedronis> they will all show up like that at end
<Chipaca> ttfn
<pstolowski> pedronis: oh, do we run things twice? does this auto-connection make sense at all?
<pedronis> pstolowski: it's because is a self autoconnection
<pedronis> pstolowski: we probably can fix that in auto-connect itself
<pstolowski> pedronis: i didn;t know we have self-autoconnection, what is it for?
<pedronis> pstolowski: tbh it's a bit of a corner case, but is quite important, docker uses it for example
<pedronis> pstolowski: it's usally when the server and the client of something are in the same snap, that's the docker case IÂ think
<pstolowski> pedronis: ok, what test is this?
<pedronis> pstolowski: test?
<pedronis> this is a real image
<pstolowski> pedronis: ah, allright
<pedronis> pstolowski: anyway, to fix this we would need to keep track of connection already requested in newconns using the connref ID
<pedronis> pstolowski: it's actually a bug btw, not just an opt, because of the hooks (in this case they don't exist, do nothing)
<pedronis> pstolowski: btw do we check in ifacestate.Connect if the connection already exist?
<pedronis> pstolowski: I know at some point doConnect would do nothing if the connection already existed, is that still true?Â or did we change it
<pstolowski> pedronis: performance review in a moment, will talk to you afterwards, i need to actually check hits
<pstolowski> *this
<pedronis> np
<pstolowski> allright, i'm back
 * zyga finished his self review 
<pstolowski> pedronis: we don't check if connection already exists
<pedronis> pstolowski: I think repo does, but because of the hooks is too late there
<pedronis> pstolowski: we should also add that
<pstolowski> pedronis: yes
<pedronis> pstolowski: so we need a check in ifacestate.Connect   and a check in doAutoConnect in the 2nd loop to make we don't add the same connection again
<mvo> zyga: I added a mount unit to 5284
<zyga> \o/
<zyga> thank you
<pstolowski> pedronis: i'll address this later today
<pedronis> thx
<jamesh> zyga: for https://github.com/snapcore/snapd/pull/5271, I think the only open question was yours about what to do about too-old versions of xdg-desktop-portal.
<mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
 * zyga looks
<jamesh> zyga: I don't have a good answer for that, but the PR doesn't introduce any new problems
<jamesh> (there's no --version option for any of the daemons, so it'd probably need per-packaging system checks)
<zyga> jamesh: ack
<jamesh> zyga: for snapd delivered via distro packages, we can use a "Conflicts:" header, but that doesn't help when snapd is delivered by the core snap
<zyga> jamesh: I think this is still a problem
<zyga> AFAIK older portal implementation would not confine non-flatpack apps
<zyga> so an older version of the portal is essentially a sandbox escape
<zyga> (well, for files)
<mvo> 5284 needs a second review (should be simple :)
<jamesh> zyga: so, I think the old xdg-desktop-portal  file chooser won't register files with the document portal when it thinks it is talking to unconfined apps (good), but our attempt to bind mount the document portal will fail because the application ID is in a different format (bad)
<jamesh> the bind mount failing is bad because it will reveal the entire document portal tree, potentially giving access to any files registered to flatpak apps
<zyga> mmmm
<zyga> and if we fail and don't start the app this has other negative side effects
<jamesh> we explicitly set the document portal mounts to ignore failures so it'd work when the portal code isn't present
<zyga> I need to jump to a call
<jamesh> okay
<zyga> jamesh: if we ignore the failure, does that ever leave the portal wide open for the app to see?
<zyga> could we fix that by perhaps bind mounting /var/lib/snapd/void there?
<jamesh> zyga: the apparmor policy lets the app access that mount point, so it is open
<jamesh> long term, I think it would be better to have a completely private $XDG_RUNTIME_DIR mounted at the usual /run/user/$uid
<jamesh> so if we failed to mount something in, then it just wouldn't be present
<Son_Goku> interesting
<Son_Goku> what brought this conversation on?
<Son_Goku> I was just having this convo with the Fedora Workstation guys
<jamesh> Son_Goku: I've been (slowly) working to integrate xdg-desktop-portal with snapd
<Son_Goku> yes, I saw the first bits land with snapd 2.33
<jamesh> Son_Goku: it works with xdg-desktop-portal 0.2 (patches have been accepted upstream), but fails open with 0.1.
<Son_Goku> wait what
<jamesh> if it failed closed, that would be okay
<Son_Goku> I need an unreleased version of xdg-desktop-portal now?
<Son_Goku> this is going to be a problem
<jamesh> 0.2 is released
<Son_Goku> this is the latest version: https://github.com/flatpak/xdg-desktop-portal/releases/tag/0.11
<jamesh> gah.  getting versions mixed up
<jamesh> 0.11 is the fixed version
<Son_Goku> ah
<jamesh> (not sure where 0.2 came from)
<Son_Goku> at the moment, I can't ship snapd 2.33 to Fedora 27, which I'm trying to fix right now
<jamesh> Son_Goku: I suspect it isn't as big a deal for Fedora, where we don't have AppArmor confinement in place
<Son_Goku> well, snapd's confinement is mostly useless anyway, so it's not a big deal in that respect
<Son_Goku> but it's still ugly since the document portal moved from flatpak into its own thing
<Son_Goku> and that is required for xdg-desktop-portal 0.11
<jamesh> yeah.  Alex moved it so the two services could share the same auth logic
<Son_Goku> yep
<Son_Goku> which means that flatpak in Fedora 27 has to be upgraded to...
<Son_Goku> which they don't typically do if they don't need to
<zyga> re
<mup> PR snapd#5314 opened: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<mborzecki> pedronis: just-renames PR ^^
<zyga> mborzecki: I'll co-review
<zyga> mborzecki: I haven't done it all yet but could we perhaps remove Name for a transition period so that no new code lands that uses Name vs InstanceName?
<pedronis> mborzecki: will look
<mborzecki> zyga: which Name? info.Name() is no more, it's been replaced by InstanceName()
<zyga> ah perfect
<zyga> that's exactly what I wantee
<zyga> *wanted
<zyga> to avoid API skew from PRs
<zyga> I'm at 1/3 of the diff
<mborzecki> zyga: happy scrolling :) and thanks for going though it
<zyga> pleasure :)
<zyga> Chipaca: ping
<Chipaca> zyga: bonk
<zyga> Chipaca: can you please look at the conversation on https://bugs.launchpad.net/snapd/+bug/1776295
<mup> Bug #1776295: `stop` and `disable` should kill all processes regardless of daemon stop-mode <snapd:Incomplete> <https://launchpad.net/bugs/1776295>
<zyga> I think what is being asked for is not supported by systemd but I want a 2nd opinion
<Chipaca> zyga: we can easily make explicit stop be harder than the systemd one, can't we?
<zyga> define explicit stop?
<zyga> is that something other than systemctl stop foo.service?
<Chipaca> zyga: snap stop blah
<zyga> mm
<Chipaca> zyga: or snap remove blah
<zyga> yes, that we can
<zyga> we can definitely do that
<Chipaca> behind the scenes we currently do systemctl stop
<Chipaca> we could easily do killall --user $USER instead
<Chipaca> that'll learn them to complain
<zyga> pastebin ~/.ssh/id_rsa
<zyga> yeah, it's good that we don't )
<zyga> anyway, this needs some thinking and discussion
<Chipaca> zyga: forum time?
<zyga> sounds good to me
<Chipaca> basically it'd mean "stop-mode" is for "internal" stoppage, and perhaps also for "restart", but explicit "snap stop" or "snap remove" would slay the whole namespace or w/e
<Chipaca> zyga: shall you, or should I?
<zyga> Chipaca: I can
<zyga> thank you :)
<Chipaca> zyga: perfect :)
<mborzecki> didn't we do systemctl kill --kill-who=all on snap stop?
<Chipaca> mborzecki: #1776295
<mup> Bug #1776295: `stop` and `disable` should kill all processes regardless of daemon stop-mode <snapd:Incomplete> <https://launchpad.net/bugs/1776295>
<Chipaca> mvo: was your "looks good" on #5312 a +1?
<mup> PR #5312: store: switch connectivity check to use v2/info <Created by chipaca> <https://github.com/snapcore/snapd/pull/5312>
<mborzecki> Chipaca: yes, that's i'm referring to, iirc this was discussed a bit while that change was introduced, basically systemctl stop stops all processes in cgroup, now since that no longer works because of stop mode, snap stop <service> was supposed to do the right thing
<Chipaca> mborzecki: that bug says it doesn't (but I haven't confirmed this)
<Chipaca> mborzecki: I also don't know if disable or remove dtrt
<mborzecki> hmm
<zyga> maybe I'm wrong
<Chipaca> zyga: never!
<zyga> but what I see is that there's a desire for different action on "systemctl stop" vs on "snap refresh"
<Chipaca> zyga: yep
<zyga> Chipaca: I need to tell my wife ;)
<mborzecki> Chipaca: hmmm
<Chipaca> zyga: you're never *locally* wrong
<mborzecki> Chipaca: so when you do snap stop <...> it ends up in servicestate.Control() which calls systemctl stop ... ?
<Chipaca> mhmm
<zyga> mborzecki: done
<mborzecki> zyga: as for apparmor & SNAP_NAME, jdstrand suggested introducing another variable in the templates and pick one depending on whether it's outside/inside mount ns
<mborzecki> anyways, to be ironed out
<zyga> mborzecki ack
<zyga> mborzecki: can you do a simple review for me
<zyga> 5315
<mup> PR snapd#5315 opened: cmd/snap-update-ns: introduce MimicRequiredError, make ReadOnlyFsErroâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5315>
<zyga> I'm trying to shrink my main patch
 * cachio afk
<niemeyer> Morning all
<zyga> hey hey :)
<niemeyer> mborzecki: #5030 needs love
<mup> PR #5030: packaging/amzn2: initial packaging of 2.32.5 for Amazon Linux 2 <Reviewed> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5030>
<mborzecki> niemeyer: i think it's ok to close it for now, it'll still be accessible and we can revive it (or build on what Son_Goku proposed) when needed
<niemeyer> mborzecki: But is it not needed?
<Son_Goku> for now, no
<niemeyer> mborzecki: I mean, we do want it building fine there as well
<Son_Goku> niemeyer, most likely, this will be obsoleted by eventual introduction of snapd into EPEL
<niemeyer> Son_Goku: Heya
<Son_Goku> niemeyer: Hi!
<mvo> Chipaca: woah, that merge was quick, did you click merge right after I clicked "approve"?
<mup> PR snapd#5312 closed: store: switch connectivity check to use v2/info <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5312>
<niemeyer> Son_Goku: Sorry for not responding quickly enough yesterday.. it's my understanding that all of our g-s are submitted upstream as well..
<Chipaca> mvo: got a notification of your approve
<Chipaca> mvo: mashed the merge button
<Chipaca> mvo: yes
<mvo> Chipaca: heh
<niemeyer> Son_Goku: The maintainer was also in a sprint in London with us just a week ago or so
<mvo> Chipaca: impressive
<Chipaca> mvo: thank you for the +1
<niemeyer> Son_Goku: Unfortunately it's a bit tricky to get things flowing when there's so much interest yet a disjoint set of needs
<Son_Goku> niemeyer, I'm mainly worried about the g-s plugin rotting to the point I'll be forced to disable it
<Son_Goku> the experience is... not great
<mvo> Chipaca: you did all the hard work!
<Son_Goku> niemeyer, the main gaps are snap channels and basic perm management
<Son_Goku> the snap channels one is a biggie, because it leads to a confusing experience in g-s
<niemeyer> Son_Goku: Yeah
<Son_Goku> the perm management is less important, because snapd confinement doesn't work in Fedora anyway
<niemeyer> Son_Goku: One idea we've been considering is shipping a snap-only version of it as a snap
<mup> PR snapd#5081 closed: interfaces/apparmor: add chopTree <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5081>
<Son_Goku> niemeyer, yes, I saw the snap-master branch of g-s
<Son_Goku> I'm not sure that's a good idea
<Son_Goku> I think it might be better to create an independent DE-agnostic tool
<Son_Goku> which would be useful for DEs that don't have a software center
<zyga> there's an elementary app called Snapper or something similar but I think the experience there is not good at all :/
<Son_Goku> Snaptastic
<niemeyer> Son_Goku: Best would be to have a single tool working everywhere with everything
<Son_Goku> but yeah, it's kind of weird
<zyga> snaptastic, thanks
<Son_Goku> but it could be an interesting foundation for the concept
<niemeyer> Son_Goku: But that's taking some time to sort out, and we want to make *something* available that sorts out the GUI side of things while we get the ideal in place
<Son_Goku> zyga, one idea would be to use the libyui foundation libraries to build a UI agnostic frontend
<Son_Goku> like what I did for DNF with dnfdragora: https://github.com/manatools/dnfdragora
<Son_Goku> that would even give a reasonable experience for people who'd like an aptitude-like interface for snap management
<Son_Goku> zyga: screenshots of dnfdragora are in https://blog.mageia.org/en/2017/07/21/dandifying-mageia-part-2/
<zyga> personally I don't think aptitude like approach is needed for snaps
<zyga> simply because you don't have the zoo of weird packages like -common or -bin or whatever
<Son_Goku> but you need a way for people to find and manage them
<zyga> gnome software has pretty close idea to a proper app store
<Son_Goku> well, then, get the snap channel support in g-s ;)
<popey> We did some design work on g-s last week.
<zyga> popey: cool, any mockups? :)
<popey> loads of sketches, its over to design now to do that
<mup> PR snapd#5284 closed: data/systemd/snapd.run-from-snap: ensure snapd tooling is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5284>
<zyga> mvo: do we need to do anything about https://github.com/snapcore/snapd/pull/5284#pullrequestreview-128293170
<mup> PR #5284: data/systemd/snapd.run-from-snap: ensure snapd tooling is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5284>
<mvo> zyga: you mean libexecdir?
<zyga> yes
<mvo> zyga: I replied iirc, is the reply unclear (or did I forgot to submit it :/
<zyga> I didn't see a reply
<mvo> zyga: """Thanks for checking. This code only runs on ubuntu-core systems, so we can hardcode the (known) libexecdir here.""" <- maybe github ate it :(
<zyga> +1
<zyga> I see it now
<zyga> thanks
<mvo> zyga: \o/
<mvo> zyga: thanks for your careful review
<Son_Goku> :(
<mup> PR snapd#5316 opened: store, et al: kill dead code that uses the bulk endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/5316>
<Chipaca> ^^^^ if anybody enjoys reviewing a +99 -1333 PR, now's your chance!
 * Chipaca -> lunch
<mborzecki> client.actionData.Name appears to be unused, anyone recalls what was the purpose of this field?
<Son_Goku> Chipaca, less Go code in the world makes me happier :)
<Chipaca> mborzecki: it was the name of the snap
<mborzecki> Chipaca: 'was' ?
<Chipaca> mborzecki: git show d01831fda7995cc0f2f207000adab192fb2fbf6d
<mvo> Chipaca, zyga we are still in a meeting, might overrun a litle bit
<zyga> ack
<Chipaca> mborzecki: was removed in 15edad32e3d572a2ddd53df3f5b7a9eab4b23333
<Chipaca> mborzecki: it's ignored server-side, is probably why
<Chipaca> mborzecki: KILL IT WITH FIRE
<zyga> mvo: should we wait?
<mborzecki> Chipaca: oh i won't do that ;) i plan to use it instead
<zyga> mvo: or shall we get started?
<mvo> zyga: go ahead I would say
<niemeyer> zyga: Meeting running late here.. we'll be there in a moment
<zyga> niemeyer: ack
<mborzecki> Chipaca: actually added Instance to SnapOptions, just to find that Name field a bit later
<Chipaca> mborzecki: Â¯\_(ã)_/Â¯
<Chipaca> mborzecki: removing it seems the saner thing to do i think
<Chipaca> mborzecki: sorry i didn't see your comment about using it instead
<Chipaca> mborzecki: that works also :-)
<Chipaca> mborzecki: but
<Chipaca> mborzecki: what would you use it for?
<mborzecki> Chipaca: snap install foo.snap --instance foo_bar
<Chipaca> mborzecki: the reason it's not used is because in doSnapAction, the name is already in the path
<Chipaca> mborzecki: that is, it's a POST to /v2/snaps/<name>
<Chipaca> mborzecki: so saying name in the body of the post is redundant
<Chipaca> redolent
<Chipaca> refulgent
<mborzecki> Chipaca: right, but if you try to install it as an instance than i can either use another form field or reuse this
<mborzecki> Chipaca: and it's also POST /v2/snaps, so the current name comes from the snap itself
<Chipaca> mborzecki: /v2/snaps is doMultiSnapAction
<mborzecki> Chipaca: i'm doing the variant which sideloads a snap file, hits the same endpoints but uploads a snap too
<Chipaca> mborzecki: ah! a'ight
 * zyga needs to feed the dog, brb
<zyga> re
<mborzecki> Chipaca: seems to work now https://paste.ubuntu.com/p/3WJZthdSyY/ :P
<zyga> jdstrand: hey
<zyga> jdstrand: do you have a sec?
<Chipaca> pedronis: in #5317 I have increased coverage of details.go while keeping to the spirit of the PR :-D
<pedronis> Chipaca: ah
<Chipaca> pedronis: perhaps not what you were hoping for :)
<pedronis> let's see what we get when the test have run
<Chipaca> pedronis: locally, coverage of store went from 88.3% (96.8% in details.go) to 87.9% (96.6% in details.go)
<Chipaca> the same two lines are not uncovered
<Chipaca> er, not covered*
<mup> PR snapd#5317 opened: overlord: introduce a gadget-connect task and use it at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/5317>
 * zyga iret's from real-life interrupt 
<pedronis> pstolowski: I will look at your disconnect hooks PR again in the morning
 * cachio lunch
<pstolowski> pedronis: ty
<mup> PR snapd#5318 opened: interfaces/builtin: add new cuda-support interface <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5318>
<diddledan> preview of what I'm working on https://usercontent.irccloud-cdn.com/file/h6uU1nG3/image.png
<zyga> @diddledan I'd love if gog would itself distribute snaps
<diddledan> yeah, they don't want to though
<zyga> did we ask?
<diddledan> last I saw they're "monitoring packaging systems"
<zyga> diddledan: I know some people there (or I used to, I need to check)
<zyga> pstolowski, mborzecki: can you guys give me a quick +1 on 5319
<zyga> it's a mv from package to package
<mup> PR snapd#5319 opened: cmd/snap-update-ns,strutil: move PathIterator to strutil, add Depth helper <Created by zyga> <https://github.com/snapcore/snapd/pull/5319>
<zyga> and a trivial one liner method
<zyga> I can split those if you'd feel better
<pstolowski> zyga: done
<zyga> mvo: hey, do you want to have the call about core?
<zyga> pstolowski: thank you!
<pstolowski> zyga: maybe you will know:
<zyga> yes?
<pstolowski> zyga: when we run spread tests, do we ever reuse the test user home dir between runs of entire suite?
<zyga> I think we never clean it
<zyga> yes, we reuse it
<zyga> I only recall seeing code that makes it
<zyga> but then that's that
<zyga> diddledan: gog has many similarities with steam
<zyga> diddledan: so you may look at the (now closed) steam-support interface
<zyga> as well as the surrounding discussions
<pstolowski> zyga: just to be sure: i'm not talking about not cleaning it between individual tests; i mean possibility of having leftovers between executions of entire suite
<zyga> pstolowski: I think it is the same
<zyga> pstolowski: it is only clean before first test :)
<zyga> after that, until the machine is recycled, we don't touch that
<zyga> thank you!
 * zyga just waits for green then proposes the next PR
<zyga> well, reopens the next PR
<mvo> zyga: lets do it tomorrow morning (unless you have sometihng urgent)
<zyga> mvo: no, nothing urgent
<mvo> zyga: cool, lets do it around 9ish tomorrow?
<zyga> sounds good
<mvo> cool
<om26er> popey: ping
<zyga> eh, blasted fedora 28 failure
<om26er> popey: regarding axel snap, do you think we can enable its auto builds now ?
<popey> om26er: heya. it alreay is hooked up. I did it when I closed the bug report.
<popey> om26er: but it fails to build https://build.snapcraft.io/user/snapcrafters/axel
<popey> Can't exec "aclocal": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 326.
<popey> https://launchpadlibrarian.net/373136884/buildlog_snap_ubuntu_xenial_amd64_1c7edf66b8a27bd4ca35886b0511f15e-xenial_BUILDING.txt.gz
<om26er> woa, it fails on all arches
<zyga> mborzecki: shall I change https://github.com/snapcore/snapd/pull/5315
<mup> PR #5315: cmd/snap-update-ns: introduce MimicRequiredError, make ReadOnlyFsErroâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5315>
<zyga> mborzecki: I think only you can test this https://github.com/snapcore/snapd/pull/5318
<mup> PR #5318: interfaces/builtin: add new cuda-support interface <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5318>
<cachio> mborzecki, hey
<cachio> mborzecki, I created a new image for arch and when I run the tests I get https://paste.ubuntu.com/p/gWm7dzkKFN/
<cachio> mborzecki, it is checking for updates
<cachio> but there are not new updates
<mup> PR snapd#5319 closed: cmd/snap-update-ns,strutil: move PathIterator to strutil, add Depth helper <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5319>
<mup> PR snapd#5081 opened: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<zyga> mborzecki, jdstrand, Chipaca: I updated https://github.com/snapcore/snapd/pull/5081 and it is ready for another review
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<mborzecki> cachio: let me take a quick look, don't know why it's not showing 'there is nothing to do' message
<cachio> mborzecki, we should remove the update from the snapd test suite
<mborzecki> cachio: pacman got updated recently, maybe it's showing different output when there are no updates now
<cachio> I mean, we don't need to update all the packages for arch
<cachio> mborzecki, I am updating the images every 3 weeks
<cachio> mborzecki, what do you think?
<mborzecki> cachio: well in theory we ought to be
<mborzecki> cachio: i'll take a quick look, it's probably something trivial
<mborzecki> cachio: can I use this image somehow, or have you replaced the one that we used before?
<cachio> mborzecki, I already remove the image
<cachio> I could create a new one
<mborzecki> cachio: can you built it and name it differntly than the one we have now? i'll update spread.yaml locally to use it
<cachio> mborzecki, sure
<cachio> mborzecki, in progress
<cachio> mborzecki, arch-linux-64-new-v20180613
<cachio> this is the image
<mborzecki> cachio: thx
<zyga> Iâm going for a bike run
<zyga> See you later
<mborzecki> cachio: right, so the logic in prepare_project for arch is wrong, i'll try to do a quick fix
<cachio> mborzecki, great, tx
<mborzecki> hmm my shellcheck got updated to 0.5.0 and it's rasing some issues in tests/lib/*.sh
<mup> PR snapd#5320 opened: tests/lib/prepare-restore: fix upgrade/reboot handling on arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5320>
<mborzecki> cachio: ^^
<cachio> mborzecki, tx
<mup> PR snapd#5030 closed: packaging/amzn2: initial packaging of 2.32.5 for Amazon Linux 2 <Reviewed> <Created by bboozzoo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5030>
<zyga> re
 * zyga is safely back from biking
<cachio> zyga, if you have 5 minutes #5320
<cachio> thanks
<mup> PR #5320: tests/lib/prepare-restore: fix upgrade/reboot handling on arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5320>
<mup> PR snapd#5320 closed: tests/lib/prepare-restore: fix upgrade/reboot handling on arch <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5320>
<zyga> cachio: pleasure :-)
<zyga> jdstrand: hey, around?
<jdstrand> meeting
<cachio> zyga, tx
<Luke> guys when I do a ruby build in a build-override, how do I move those files into the stage then?
<Chipaca> mbuahaha, got 'snap info' talking to v2/info \o/
<Chipaca> sergiusens: you around?
<sergiusens> Chipaca: yup
<Chipaca> sergiusens: two things
<sergiusens> Luke: make sure they end up in `$SNAPCRAFT_PART_INSTALL`
<sergiusens> Chipaca: one by one
<Chipaca> sergiusens: one, building a cross-platform snap-pack turned out to be a lot more work than I thought it would be, so it's on my plate as a Thing (as opposed to something I slot in between the cracks)
<Chipaca> sergiusens: two was Luke and you've done that :-)
<Chipaca> sergiusens: as i see it i should be getting to work on it early next week
<Chipaca> but I don't own my priorities :-)
<sergiusens> Chipaca: oh neat, does that include replacing mksquashfs too or just snap? I wonder, not require ð
<Chipaca> sergiusens: it does not include  replacing mksquashfs
<mup> PR snapd#5321 opened: tests: fix interfaces-contacts-service test retrying to remove share dir <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5321>
<Luke> sergiusens: thanks. is that var documented somwhere? I couldn't find it in the docs
<Chipaca> sergiusens: it's mostly a lot of careful separation of code into cross-platformy bits, but also a bunch of figuring out how to run a test suite on windows :-)
<Chipaca> sergiusens: I need to be in a special mindset for that last bit
<Chipaca> or hire somebody :-D
<Chipaca> (number of times I've gone for "hire somebody" in that situation: 3)
<sergiusens> Luke uses are describe on https://snapdocs.labix.org/scriptlets/4892 or https://docs.snapcraft.io/build-snaps/scriptlets
<sergiusens> Chipaca: use appveyor, that is what we use
<Luke> i saw the scriptlets docs before. there's no mention of $SNAPCRAFT_PART_INSTALL besides in passing in an example
<Luke> i guess I'm looking for an explanation of the best practices/intended use of $SNAPCRAFT_PART_INSTALL etc
<Luke> thanks btw
<Chipaca> sergiusens: nice, i'll look that up
<Chipaca> sergiusens: what happens every time I start is that I'm an hour into reading and I'm just adding to a stack of things to figure out :-) hence why i need to set aside time for it
<Chipaca> sergiusens: for example, appveyor seems to boil down to "run msbuild for you"
<Chipaca> so no i need to learn msbuild
<Chipaca> etc :)
<Chipaca> sergiusens: no worries, but not quick for me
<Chipaca> i'll get to it next week
<Chipaca> hopefully
<zyga> jdstrand: if you still have time today please look at chopTree again
<zyga> It now does what you asked for
<Chipaca> zyga: if you've got beans after the bike run, #5316 :-D
<mup> PR #5316: store, et al: kill dead code that uses the bulk endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/5316>
<Chipaca> zyga: also 'bike run' seems like you're doing something wrong :-)
<jdstrand> zyga: ok, it's on my list. it may be tomorrow
<zyga> Chipaca: that explains the odd stare ;-)
<zyga> Iâll read it first thing tomorrow
<jdstrand> niemeyer: hi! can you add this to your queue to give some thought: https://forum.snapcraft.io/t/camera-raw-usb-plugs-auto-connect-for-qtchildid/2917/4
#snappy 2018-06-14
<niemeyer> jdstrand: Replied, sorry for the delay there
<diddledan> is my system messed up somehow? https://www.irccloud.com/pastebin/zgh6Nf9E/
<mborzecki> morning
<zyga> Good morning
<zyga> I need to take the dog out and I will be back here shortly
 * zyga reviews 5316
<mup> PR snapd#5316 closed: store, et al: kill dead code that uses the bulk endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5316>
<zyga> whaa
<zyga> I was reading it :
<zyga> :-)
<zyga> but that's fine
<zyga> I guess I should make some coffee and meet with mvo then
<mvo> zyga: yeah, but rush
<zyga> rush or no rush? :D
<mvo> zyga: no rush
<mvo> zyga: sorry
<mvo> zyga: I guess that is a sign that I need more tea
<mborzecki> i think we're not picking up enough nvidia/cuda libraries
<mborzecki> CUDA 9.1 runtime ships libcudart.so* which is not included in our globs
<pstolowski> morning
<zyga> mborzecki: I would love a proof of concept nvidia snap
<mborzecki> zyga: this and the 'mesa' snap
<zyga> mesa is slightly different
<zyga> I don't know where it fits
<zyga> is it all a bunch of .so files
<zyga> or does it need to be in some weird specific spot
<mborzecki> cuda sdk - merge 1.2GB download :/
<mup> Bug #1639746 changed: Snap launching other snaps <snapd-interface> <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1639746>
<Saviq> hey all, where do I file bugs about emails from snapcraft.io? Thunderbird flags them as spoofing because of links pointing to a different place than they display. And then when viewing the online version, Firefox warns about it not being a fully safe connection (assets loaded via http)
<zyga> Saviq: good question, I don't know honestly, perhaps popey or JamieBennett knows?
<JamieBennett> https://github.com/canonical-websites/snapcraft.io
<davidcalle> Saviq: https://github.com/canonical-websites/snapcraft.io/ is a good place for it, make sure you tag @evandandrea and @lewciie
<zyga> Thank you
 * zyga thinks that it would be good to add a small piece of text to the page footer for this
<zyga> maybe worth a small PR
<Saviq> thanks!
<mborzecki> github is down or sth?
<mup> PR snapd#5322 opened: cmd/snap-confine: include CUDA runtime libraries <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5322>
<Chipaca> moin moin
<pstolowski> mvo, mborzecki, zyga : do you want to take another look at https://github.com/snapcore/snapd/pull/5288 ? i'd like to land it and see if it improves situation; i've added a little more debug and also added rm -rf cleanup step before the test starts, in case we're reusing the machine and previous cleanup didn't work for whatever reason (i suspect this could explain our issues as I think in such case our caching kicks in and
<pstolowski> we don't see retry on download, only on assertion fetch)
<mup> PR #5288: tests: econnreset/retry tweaks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5288>
<zyga> looking
<mborzecki> wanted to check cuda with snaps on arch, but the cuda package is installed under /opt/cuda, so our carefully crafter s-c globs basically went out the window
<Chipaca> mvo: you around?
<mvo> Chipaca: yes
<Chipaca> mvo: you have dev access to the hello-world snap, yes?
<mvo> Chipaca: let me check, yes
<mvo> Chipaca: you have as well
<Chipaca> I do?
<mvo> Chipaca: sure, check your mail
<Chipaca> ah
<Chipaca> I've been invited to perhaps :-)
<mvo> Chipaca: ;)
<mup> PR snapd#5323 opened: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5323>
<Chipaca> hrmph, the hello-world data in the store tests has been edited in undocumented ways :-(
<Chipaca> it's testing for content plugs that aren't there for ex
<pedronis> mborzecki: zyga had a suggestion for the InstanceName doc comment, you +1 it, are you applying it in the PR or when you actually implement the logic in a follow up?
<mborzecki> pedronis: must have missed it, let me push a quick patch
<pedronis> Chipaca: I think we have grown more features that is fair to stick on hello-world :/
<mborzecki> pedronis: pff yeah, didn't stage it :(
<Chipaca> pedronis: I know, and it's fine, but that's why there's a "download the json, and then <do this to it>" comment in the tests
<Chipaca> grmbl, grmbl, *AND* grmbl.
<pedronis> I don't think IÂ ever noticed that
<pedronis> it's probably/likely partly my fault, sorry
<zyga> pstolowski: yeah, let's merge 5288 .
<pstolowski> k, thanks
<mup> PR snapd#5288 closed: tests: econnreset/retry tweaks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5288>
<pedronis> mborzecki: np
<zyga> mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5315/files
<mup> PR #5315: cmd/snap-update-ns: introduce MimicRequiredError, make ReadOnlyFsErroâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5315>
<zyga> I applied your suggestion now
<popey> Saviq: yeah, a github issue about the mails is best, thanks.
<Saviq> popey: https://github.com/canonical-websites/snapcraft.io/issues/729 https://github.com/canonical-websites/snapcraft.io/issues/730
<popey> thanks Saviq
<mup> PR snapd#5324 opened: snap: run snap-confine from the re-exec location <Created by mvo5> <https://github.com/snapcore/snapd/pull/5324>
<pstolowski> life-changing: travis-ci.org##.ansi filter in ublock kills the cpu hungry log window and only leaves 'raw log' button
<zyga> mvo: I saw that, I'm making progress on the system interfaces now
<mvo> zyga: nice
<zyga> mvo: there's one more special case to handle
<Wimpress> Morning mvo zyga
<zyga> but we can do the smart thing as well (not touch it)
<zyga> base policy
<zyga> we should translate system back to core there
<Wimpress> I've been asked by an ISV if it is possible to run snapd in Docker.
<zyga> Wimpress: hello, how are you doing sir?
<Wimpress> My frst thought is no, but I "think" I saw someone show me snapd working in Docker.
<zyga> Wimpress: from what I know it is maybe possible but we don't test that today. It depends on how docker confines the container
<pedronis> and also what kind of distro is inside IÂ suppose
<zyga> yes, that's also a factor
<Wimpress> So technically possible but not an "out of box" experience?
<jamesh> zyga: I had a few more thoughts about the "old portals" issue, which I've added to the PR: https://github.com/snapcore/snapd/pull/5271#issuecomment-397235058
<mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
<jamesh> zyga: in short, I agree that it is a problem but think we might have been overestimating how prevalent it is
<zyga> jamesh: thank you for the write up and analysis, I think I tend to agree
<zyga> let me think about this today and try to catch jdstrand later to discuss, we will reply there
<pedronis> pstolowski: couple small comments on the disconnect hooks one
<mup> PR snapd#5325 opened: interfaces: add Repository.AllInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/5325>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/5325
<zyga> small helper for upcoming branch
<mup> PR #5325: interfaces: add Repository.AllInterfaces <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5325>
<Chipaca> jamesh: question out of the blue: do you know how to tell gnome what 'app' a window is from?
<Chipaca> jamesh: or how it does that for non-gnome apps?
<Chipaca> jamesh: snapped apps don't have an 'app' in looking glass, and they don't have an icon, and I suspect it's the same thing
<zyga> Chipaca: knowing gnome I'd not be surprised if it used google to search each time you open the activities screen
<Chipaca> zyga: :)
<jamesh> Chipaca: I'm not sure exactly how gnome-shell links the windows to apps off the top of my head (or if it differs for Wayland vs. X11 apps), sorry.
<zyga> The comment said /* Faster than scanning desktop files */
<Chipaca> jamesh: no problem
<Chipaca> jamesh: I'll continue to ask random people in the street then
<Chipaca> :)
<jamesh> I know the code in unity7 had some nasty hacks
 * zyga thinks http://blog.lenovo.com/en/blog/the-new-thinkpad-p52/ is crazy cool
<jamesh> some of which persists in snapd with  the BAMF_DESKTOP_FILE_HINT stuff
<Chipaca> jamesh: the BAMF_ thing was to tie it into bamfdaemon,  and some older apps also needed to set WMClass
<Chipaca> jamesh: but gnome shell indeed seems to ignore both these things :-)
<zyga> Chipaca: can we run gedit and see what it does
<Chipaca> (bamfdaemon, i'm not surprised)
<zyga> Chipaca: I suspect the best way to learn is just to observe a real app
<Chipaca> I'd be completely unsurprised if it were something like "the desktop file needs to be named exactly like the binary"
<Chipaca> also saddened
<popey> that is in fact the case AIUI
<jamesh> right.  IIRC, bamfdaemon would read the environment of the process via /proc to look for that variable to make the link
<zyga> Chipaca: all bugs are shallow ... eyes... sad... (pours more alcohol)
<Chipaca> popey: do you know if there's a way to override that?
<popey> i do not, I comply
<Chipaca> popey: how?
<popey> maybe the desktop: entry in snapcraft.yaml
<zyga> Chipaca: only 20 separate implementations to check :-(
<popey> i always put the .desktop file in snap/gui
<popey> e.g. https://github.com/snapcrafters/opentoonz/tree/master/snap/gui
<mup> PR snapd#5324 closed: snap: run snap-confine from the re-exec location <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5324>
<Chipaca> popey: let me test that then
<popey> ok, thanks
<popey> would be nice not to have to do it
<popey> (but we always do)
<Chipaca> huh
<Chipaca> well i'll be jiggered
<Chipaca> renaming the desktoop file to kiosceditor_kiosceditor did the trick
<mborzecki> zyga: can you take another look at #5306?
<mup> PR #5306: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5306>
<Chipaca> popey: https://forum.snapcraft.io/t/ubuntu-18-04-and-snap-issues/5832/8?u=chipaca
<popey> <3
<Chipaca> pedronis: in overlord/snapstate's fakeStore there's a bunch of code that uses a snap's channel to decide what to do
<Chipaca> pedronis: but I'm killing channel (and anychannel) as arguments to snapinfo -- they're not used anywhere in non-test code
<Chipaca> pedronis: do you think it'd be reasonable to give fakeStore an out-of-band way of knowing what's wanted of it?
<zyga> mborzecki: sure
<Chipaca> pedronis: (i think i might add channel back just for these tests, and kill it in a followup, as it'll get gnarly)
<mup> PR snapd#5326 opened: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
<zyga> mborzecki: is instance name and instance key the same thing, can they be used interchangeably?
<Chipaca> zyga: AIUI instance name == name + "_" + key
<mborzecki> zyga: foo_bar, foo_bar === instance name, foo === snap name, bar === instance key
<zyga> thanks
<mborzecki> pedronis: #5314 was updated, please take another look
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<zyga> mborzecki: done
<zyga> another instance of
<zyga> Jun 14 09:24:29 arch snapd[28173]: Jun 14 09:24:27 arch systemd[1]: var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount: Mount process finished, but there is no mount.
<zyga> Jun 14 09:24:29 arch snapd[28173]: Jun 14 09:24:27 arch systemd[1]: var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount: Failed with result 'protocol'.
<zyga> in mvo's branch
<mup> PR snapd#5324 opened: [RFC] snap: run snap-confine from the re-exec location <Created by mvo5> <https://github.com/snapcore/snapd/pull/5324>
<mvo> zyga: the snap-confine on core18 is a bit thorny, I wrote some options down in 5324 maybe we can chat after lunch about the pros/cons, nothing seems perfect but maybe the alternative plan in 5324 is worth persuing
<zyga> ok, I'm reading your PR now
<zyga> the system interfaces approach is clean so far
<zyga> not finished yet but very simple what's going on (for now)
<ondra> mvo ping
<mvo> ondra: pong (but almost at lunch)
<ondra> mvo sure, will try to be quick :)
<pedronis> mborzecki: thanks will look in a little bit
<ondra> mvo have I missed something about pi3 kernel and dtb?
<mvo> zyga: yeah, its not hard, just feels a bit "uneven" that we need to use different dirs for the profiles on classic and core and to reuse the snap profile dir
<mvo> ondra: missed in what sense? I haven't looked at this in a while
<ondra> mvo I'm getting a bit confused, so are we free to update kernel as much as we like and dtbs update correctly?
<mvo> ondra: well, we unblocked the kernel updates a while ago because the dtb diff was just a single line in a serial port uart freq
<ondra> mvo I thought we are not updating dtbs from kernel snap to system-boot at all
<mvo> ondra: but of course if this changes and the diff becomes bigger we need to halt things again
<mvo> ondra: we are not doing it in snapd, that is correct
<mvo> ondra: I mean, we don't copy stuff around into /boot at this point
<mvo> ondra: we have no code for this
<ondra> mvo so we are not updating dtbs, but rather relying that kernel does not really change there
<mvo> ondra: correct
<mvo> ondra: yeah, its just so that people get kernel updates but we still have not tackled the dtb update problem
<ondra> mvo can you please comment on that forum post? as Gustavo thinks there is no problem to solve, and I do not think this is correct assumption
<niemeyer> ondra: That's not what was written there
<mvo> ondra: do you have a link for me?
<niemeyer> mvo: https://forum.snapcraft.io/t/proposal-to-enable-pi2-3-major-kernel-updates/5842/8
<mvo> niemeyer: ta
<niemeyer> mvo: np
<ondra> niemeyer you are claiming that we have updates flowing and there is no problem, but clearly we do not have dtb updates flowing
<ondra> niemeyer so to me there seems to be mismatch in understanding what is actually updating
<niemeyer> ondra: I specifically said:
<niemeyer> a) The pi2 kernel had a major update just weeks ago, which disagrees with what was presented in the first few sentences
<niemeyer> b) We have a design for dtb updates in place
<niemeyer> c) If your needs are different, they need to be put into that design instead of besides it
<mup> PR snapd#5327 opened: store: switch store.SnapInfo to use the new v2/info endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/5327>
<Chipaca> pedronis: ^
<niemeyer> d) If you do critical updates like this in hooks it will likely destroy systems in the future
<niemeyer> e) We should have a meeting to discuss this
<pedronis> Chipaca: thx, will look
<niemeyer> ondra: Which of these points is incorrect or unreasonable?
<ondra> niemeyer I have been talking about this very problem with mvo in Berlin and he told we are still not updating dtbs when we update kernel,
<ondra> niemeyer so you are telling we are updating dtbs?
<zyga> mvo: is /etc/apparmor.d really read-only on core?
<niemeyer> ondra: I said the pi2 kernel had a major update. Is that true or not?
<mvo> zyga: yes
<zyga> mvo: I see, well, that's okay
<niemeyer> ondra: You're arguing with things I did not say
<zyga> I mean, it's harder but we can manage
<mvo> zyga: the trouble is that it has a bunch of subdirs
<mvo> zyga: otherwise I would say we just make it writable
<ondra> niemeyer was that update carefully crafted in a way it does not require dtb changes and can use old dtbs?
<zyga> mvo: if we can move s-c profiles in all the cases to a new place I'm okay with that
<mvo> ondra: we checked carefully that the new kernel would work fine with the old dtbs
<ondra> niemeyer proposal is targeting issue when dtbs are not updated with kernel updates, you claim there is no such a problem
<zyga> mvo: and we can consider deploying snapd.apparmor.service to core too, to be 100% sure that we have freedom here
<ondra> niemeyer I do not agree with that
<niemeyer> ondra: Which of the points above says that?
<niemeyer> ondra: In other words, you're saying that yourself.. not me
<mvo> zyga: interessting
<zyga> mvo: this would allow us to use a directory such as /var/lib/snapd/apparmor/internal or whatever we want
<zyga> mvo: and not clash in any wy
<zyga> *way
<ondra> niemeyer from forum "@ondra My understanding is that we have updates to pi2 boards flowing, and that the dtb problem in that specific case was a red-herring. "
<mvo> zyga: I like internal/
<zyga> mvo: or ...
<niemeyer> ondra: Exactly.. we had a pi2 kernel update just weeks ago
<zyga> system ;)
<ondra> niemeyer so you are saying there is problem
<mvo> zyga: heh
<zyga> mvo: but anyway, that's besides the point, let me read your branch carefully
<niemeyer> ondra: I said we *DID UPDATE IT*
<ondra> niemeyer and I can update kernel freely?
<mvo> zyga: I think that is great input, we can probably move it all
<niemeyer> ondra: THis is not theoretical
<zyga> mvo: the service is already in place, we should see if we can just enable it (it's harmless)
<ondra> niemeyer so you don't see problem that we cannot update dtbs?
<zyga> mvo: that is, ship it and enable via the snapd.run-from-snapd-snap service
<niemeyer> ondra: Why are you still making stuff up?
<mvo> zyga: we need to extend it to cover system/ as well, right?
<zyga> mvo: yes but it is our service
<zyga> it's simple to extend
<mvo> zyga: cool
<zyga> and we can ship it in snapd snap
<ondra> niemeyer because you are telling me there is no problem to solve
<niemeyer> ondra: So you hate the blue color?
<zyga> and it's a blessed shell script instead of one liner for the purpose of being shellchecked
<mvo> zyga: I need to run for lunch, lets catchup afterwards (and/or feel free to write your thoughts into the open PR)
<zyga> mvo: sure, go ahead
<ondra> niemeyer OK whatever, clearly impossible to talk to you
<niemeyer> ondra: Honestly, this is nuts.. I'm literally saying "let's please have a meeting to discuss your needs" and "if your needs are different let's integrate in the design"
<zyga> ondra, niemeyer: I'm sure we are perfectly capable of solving the problem if we talk together, I really recommend that we have a call later today/tomorrow
<niemeyer> zyga: That's literally the first thing I said :)
<zyga> perhaps ondra is not aware of the existing plans or there is a technical detail that we are missing
<niemeyer> Quoting:
<niemeyer> """
<niemeyer> Nevertheless, we already have a design for the proper representation of dtbs that can be updated. Letâs please not cook a different solution without looking at that design first. Even if itâs incomplete for your needs, we should improve on it instead of besides it. Happy to discuss this in our next meeting.
<niemeyer> """
 * zyga hugs niemeyer and ondra *together* 
<pstolowski> anyone looking at interfaces-calendar-service test flakiness? if not, i'll coz it's driving me crazy
<zyga> pstolowski: there's a PR from cachio but I don't quite understand how that helps or what the problem is
<zyga> pstolowski: I'd recommend diving into it , yeah
<zyga> and it seems to happen on all kinds of systems so a small loop with debug would be good
<pstolowski> oh ok, let me first check what did he do
<zyga> thank you!
<pstolowski> right.. it seems that retry didn't help, the PR failed on this test again
<pstolowski> interesting
<mborzecki> zyga: i think it's related to gvfs which does fuse internally
<zyga> mmm
<zyga> mborzecki: yeah, it feels like something is mounted there
<zyga> otherwise rm would not fail
<mborzecki> maybe worth trying is to kill gvfsd* in restore
<mborzecki> but that's a long shot anyway :P
<zyga> I think we need to reproduce and see what's there
<cachio> pstolowski, the retry didn't work?
<pstolowski> cachio: it seems to, your PR failed on travis
<pstolowski> *so
<cachio> but failed on a different test
<cachio> there are 2 tests failing for the same reason
<cachio> calendar and contacts
<cachio> pstolowski, I was trying to see what it is locking the files inside
<cachio> but when I debug it, it is already unlocked
<mborzecki> cachio: when it fails, can you check if there's anything in that directory (gvfs-metadata) and if there are any gvfs processes alive, if so, kill them
<cachio> mborzecki, running again to see
<mborzecki> ok, i'm off to the kindergarten, bbl
<mup> PR core18#26 closed: hooks: add path <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/26>
<pedronis> Chipaca: did a first pass,  main point is that I think the helpers merit unit tests (also because the current shape of responses doesn't exercize all corners of them)
<pedronis> looks good though otherwise
 * Chipaca ~> lunch
<jdstrand> zyga: what did you want to talk about? a snapd-apparmor.service for core?
<zyga> jdstrand: I'm not sure, yesterday or today/
<zyga> yesterday I only wanted to ask for a re-review of chopTree PR
<zyga> there are some interface PRs in flight but I think those are handled well on elsewhere already
<zyga> I'm sorry, I think the answer is "I'm not sure"
<jdstrand> zyga: it seems https://github.com/snapcore/snapd/pull/5271#issuecomment-397235058
<mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
<zyga> ah
<zyga> yes, that's that!
<zyga> so here I tend to agree with James, please think about it and let's discuss in the PR (since James is far away in terms of timezones)
<jdstrand> zyga: but I would caution you on moving snap-confine to internal/. I mean, the idea of that is not bad in and of itself, but understanding why the profiles aren't being loaded in /etc/apparmor.d is important before suggesting a solution
<jdstrand> zyga: do we understand the race/problem there?
<jdstrand> zyga: as in, are we just kicking the can and going to see it happen with internal/ too?
<zyga> jdstrand: this is a more subtle question, it is specific to core systems only
<zyga> where we cannot write to /etc/apparmor.d
<zyga> but need a place to store snap-confine profiles for snapd reexec
<zyga> and using /var/lib/snapd/apparmor/profiles was undesired as it would need a new prefix not to clash with snap profiles
<zyga> (but we could do that)
<jdstrand> why are we reexecing on core?
<zyga> this is the new work on a standalone snapd snap
<zyga> where core18 or core16 is used for booting
<zyga> but snapd is in a separate snap
<zyga> (snapd.snap)
<zyga> there's a new protocol for running that
<zyga> but it involves writing a profile for snap-confine for a given snapd snap revision
<zyga> mvo: I just realised there is a complication
<jdstrand> it still isn't clear. why are we reexecing on core?
<zyga> jdstrand: because core18 and core16 don't ship a snapd snap
<zyga> er
<zyga> snapd itseslf
<jdstrand> I mean, core16 and core18 won't have snapd, so there is nothing to reexec
<zyga> this isn't really reexecing, it needs a new name
<jdstrand> so?
<jdstrand> ok
<zyga> so we will exec snap-confine from /snap/snapd/123/usr/lib/snapd/snap-confine
<zyga> we need to generate a profile for that in snapd
<zyga> and we need to store it persistently
<jdstrand> but regardless of what it is called, snapd needs to put a snap-confine profile somewhere
<zyga> and load it on boot
<zyga> the question is where do we store it
<zyga> and /etc/apparmor.d is read only
<zyga> and has a host of other things inside that makes it harder for us to use as a sync directory
<jdstrand> this is getting into the territory of why I thought the snapd snap should not be a normal app snap
<zyga> it is not a normal app snap
<jdstrand> but a new 'type: snapd'
<jdstrand> ok, then that has evolved. last I heard it was
<zyga> (new type is an interesting idea but it's orthogonal, it has special handling already)
<zyga> it is not a normal app snap in the sense that it doesn't expose itself as a service
<zyga> or snap as an app
<zyga> it's all handled externally with snapd.run-from-snapd-snap.service
<Chipaca> popey: remember that xps? something was burnt out getting power to the ram; Â£65 later i've got an xps
<jdstrand> it is 'type: app' with special-casing. more and more as we go. that is orthogonal, but the more special casing, the more it shouldn't be 'type: app'. it isn't an app. it is a snap from managing and running apps
<jdstrand> s/from/for/
<jdstrand> anyway
<jdstrand> sure, put it in apparmor/internal, leave cache the same
<zyga> jdstrand: ack, thank you
<zyga> jdstrand: I agree about making it explicitly special and I think we will over time, this is just a way to hit core18 work on time
<jdstrand> you will then need snapd-apparmor.service
<zyga> jdstrand: yes, but as I said, it is just a proposal at this stage
<jdstrand> note, I still consider /etc/apparmor.d as read-only a good property on core
<zyga> mvo and I will talk about what the options are and then decide what to pursue
<jdstrand> because it makes it impossible to mess with system policy, tunables and abstractions
<zyga> jdstrand: yeah, I think that's fine too, it's just something we were not aware of a short while ago :)
<jdstrand> we actively chose to have /etc/apparmor.d/cache read/write but /etc/apparmor.d read-only
<mup> PR snapd#5328 opened: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5328>
<jdstrand> zyga: I was surprised to see that the 'profile not found' issue was not on your list. it seems I see at least once a day an issue where someone is hitting it
<zyga> hmm, indeed, I should look into it
<jdstrand> zyga: thanks
<zyga> I need to scan the forum for existing reports
<mvo> jdstrand: has apparmor upstream ever considered /var/lib/apparor.d in addition to /etc/apparmor.d ?
<mvo> jdstrand: having that as an official place would make some things on core18 easier for me, i.e. the snap-confine dynamic profile generation
<mvo> zyga: I was thinking about snapd.apparmor.service, the downside of using it is robustness, having something on core18 itself load profiles (like the current apparmor service) would mean things work even if snapd.run-from-snap does not work for whatever reason
<mvo> zyga: the snapd.* services are all generated only in /run/ at this point
<mvo> zyga: wdyt?
<mvo> zyga: I wonder if I should write a forum post about this, it has more edges than I expected it to have
<zyga> jdstrand: I see what you are saying but once run-from-snapd-snap stops working we are toast anyway
<zyga> no "snap", no "snap revert"
<zyga> nothing works at that time
<mvo> zyga: well, yes. however if in such an even at least the snaps themself keep running that would be preferable it seems
<mvo> zyga: different levels of de-generation :)
<jdstrand> mvo: apparmor upstream has not dictated how downstreams load policy
<jdstrand> mvo: apparmor upstream is interested in making a systemd unit that can be used across distros. this will allow adding additional directories, etc
<mvo> jdstrand: ok
<jdstrand> mvo: today, it is an Ubuntu-ism to load /var/lib/snapd/apparmor/profiles
<jdstrand> mvo: it would be possible for the apparmor init to add /var/lib/snapd/apparmor/internal
<jdstrand> mvo: it is also possible to ship /var/lib/snapd/apparmor/snap-confine....
<jdstrand> err
<jdstrand> /var/lib/snapd/apparmor/profiles/snap-confine....
<zyga> that is a directory
<zyga> ah
<zyga> yes
<jdstrand> then the init doesn't have to change anything
<jdstrand> we already have snap-update-ns. in there, it isn't impossible to think about snap-confine.something too
<jdstrand> ensure dir could ignore stuff that was prefixed with snap-confine.
<jdstrand> etc
<mvo> jdstrand: you mean to use the "snap-confine." prefix?
<mvo> jdstrand: just like we use the snap-update-ns. prefix?
<zyga> yes, that would work
<mvo> jdstrand: if we go with a unique prefix we could use "system." as this is already not availalbe as a snap
<mvo> zyga: (cc) -^
<mvo> and then we just write it in both core and classic into the same location - that will be nicer than the current mess^Wapproach
<zyga> mvo: system could even be a snap as snap profiles are snap.*
<jdstrand> mvo: yes, that is a possibility, then you are working within the current Ubuntu-ism
<zyga> (so snap.system.foo)
<zyga> vs system.whatever
<mvo> zyga: good point
<jdstrand> system. obviously works too
<mvo> jdstrand: yeah, I think I will go with this, thank you and zyga  for your input!
<jdstrand> np
<ogra_> niemeyer, seriously, i'm not attemprting to discuss anything with you, i was asking for a link to the design you referred to and you shut the topic down ... and you call *me* "passive aggressive" ?!?!
<niemeyer> ogra_: I won't discuss it here either. That's not passive aggressive, that's not having an argument at all. I'll talk to ondra in a place we can understand each other more easily.
<ogra_> niemeyer, pretty please do you have a link or dont you have a link, i do *not* want to discuss anything but you refer to a design that i'd like to be aware of
<ogra_> without any intend to discuss anything with you i just want to know about it since i will likely have to use it
 * zyga -> standup
<ondra> niemeyer random question, are we planning to support upgrade from UC16 to UC18?
<niemeyer> ondra: Yeah, definitely.. we need some good work there
<jdstrand> roadmr: hi! totally not urgent request for pulling r1091
<jdstrand> lool: that has what we talked about ^
<roadmr> jdstrand: sure thing, I'll put it in the queue and roll the ball from there
<jdstrand> roadmr: thanks
<lool> jdstrand: cool
<ondra> niemeyer then I'm gently pointing out, dtbs are not compatible between 4.4 and 4.15 kernels on pi
<niemeyer> ondra: Let's discuss the topic in our next call.
<ondra> niemeyer sure, more than happy to do so
<niemeyer> ondra: Thanks
<snappy_> Hi guys..   How can we delete/de-register the snap from the snap store?  Please someone guide me to de-register the snap in the store...
<popey> ^ sparkiegeek
<diddledan> something's wonky with the newly rolled-out buildd:
<diddledan> https://www.irccloud.com/pastebin/zDAQYaLN/
<diddledan> specifically it's failing to run my wget command in override-build
<sergiusens> diddledan: newly rolled out buildd?
<diddledan> sergiusens: https://forum.snapcraft.io/t/released-launchpad-buildd-163/5925
<sergiusens> diddledan: btw, had you tried corebird (the snap) with the communitheme ?
<diddledan> no, I haven't
<sergiusens> get transparent backgrounds
<sergiusens> might be a comunitheme issue (ah, that thing is so hard to spell)
<sergiusens> ooh, transparent proxy, that removes a lot of pain from some of the plugins
<diddledan> it might fix some plugins, but it's preventing wget from working in my build
<sergiusens> diddledan: so wget is not found or the network setup is getting in the way?
<diddledan> it's refusing to download the url - wget says no
<diddledan> see my paste above
<diddledan> the code that drives that is
<diddledan> https://www.irccloud.com/pastebin/vFsm4jzb/
<Chipaca> mvo: La Pampa, https://goo.gl/maps/ugAEKg51sjq, vs the Pampas, https://en.wikipedia.org/wiki/Pampas#/media/File:Pampas_Range.png
<Chipaca> mvo: not to confuse with the Pampa, an indigenous people
 * Chipaca really off now
<sparkiegeek> cjwatson: ^^
<pedronis> mvo: as I said, I think I'm going to pick up this, tomorrow tough likely:  https://github.com/snapcore/snapd/pull/5270
<mup> PR #5270: snap,client: show "publisher" in `snap list` and expose in client API <Created by mvo5> <https://github.com/snapcore/snapd/pull/5270>
<mvo> Chipaca: heh, thank you!
<mvo> pedronis: great, thank you
<mvo> pedronis: I will try to tame snap-confine on core18 now
<pedronis> mvo: we should probably block the --format one tough,  until that one is done, if that's ok
<mvo> pedronis: sure, just add "blocked" there
<pedronis> ok, thx
<mup> PR snapcraft#2155 closed: build_providers: support for communicating with a qemu VM <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2155>
<jdstrand> zyga: fyi, I added the small changes you requested in PR 5250
<mup> PR #5250:  interfaces/udev,misc: only trigger udev events on input subsystem as needed <Reviewed> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250>
<zyga> Ack, I will look shortly. Taking the dog out now
<jdstrand> mvo: fyi, that ^ is going to really help people like popey who are seeing desktop environment hangs and crashes upon interface connection
<jdstrand> mvo: I was hoping this would make 2.33, but it didn't. if you are respinning a 2.33, feel free to consider it (and to say 'no' if you want it to bake. if its in trunk, people like popey can use the edge snap)
<popey> I'm still using your shonky build of snapd
<popey> and not had any desktop explosions yet
<jdstrand> popey: I'm so glad it has helped you
 * diddledan hides the c4
<jdstrand> popey: keep an eye on that PR and you can start using the edge one
<popey> jdstrand: unrelated. firefox specifies removable media but doesn't autoconnect. Do *they* need to request that?
<mvo> jdstrand: it seems risky for 2.33.1
<popey> Because I wanted to upload a photo from a CD (yes, a CD) and had to connect it to get access
<mvo> jdstrand: but if you and $more people assure me it solves more problems than it creates I'm open to this
<jdstrand> popey: well, somebody does, yes
<popey> would it be okay if I requested it? :D
<popey> or do you need the upstream to do it
<jdstrand> mvo: at its heart, it is a simple change. run udevadm trigger with --subsystem-nomatch=input
<jdstrand> by default
<jdstrand> and add in other stuff as needed
<jdstrand> I will be on holiday tomorrow and next week
<mvo> jdstrand: oh, that evolved since I looked at last then I think. that sounds more innocent now
<jdstrand> mvo: I think it's safe (which is why I mentioned it at all), but I also won't be around if it gets pushed out. I'm also fine for 2.34
<mvo> jdstrand: I have a look, given that its (mostly aiui) nomatch that makes it much more appealing
<cjwatson> diddledan: Could I have the full build link, please?
<mvo> jdstrand: I will ask for it to get squash merged, I assume this is ok with you?
<mvo> jdstrand: to make the cherry-pick to 2.33 easier
<jdstrand> mvo: yeah, it needs a second review so if you did that it could double as a review for 2.33.1
<jdstrand> mvo: yes
<diddledan> cjwatson: this it? https://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/249050
<mvo> jdstrand: great, thank you. once I finished my current task I will look at it
<jdstrand> mvo: thanks for your review and consideration :)
<mup> PR snapd#5321 closed: tests: fix interfaces-contacts-service test retrying to remove share dir <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5321>
<jdstrand> popey: you can request it
<cjwatson> diddledan: mm, somebody's broken BSI's ability to show other users' builds, but I can work it out from that ...
<diddledan> cjwatson: that's the amd64 build, this is the i386 variant - both fail the same way: https://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/249053
<cjwatson> diddledan: Is it clear that this is a regression?  That snap has never had any successful builds
<diddledan> it's a brand new snap. it builds fine locally in cleanbuild
<cjwatson> Right, which says nothing about whether it's a regression in launchpad-buildd :)
<cjwatson> I can certainly look, it's just less of a panic if it's not obviously a regression.
<diddledan> @Wimpress can you trigger a build on tmnationsforever to test whether it's a regression as you're using a similar build?
<cjwatson> I'm setting it up locally
<cjwatson> It *could* be something wrong with the extra layer of proxying, although you can see the access log there reporting 200
<popey> diddledan: actually tmn wasn't hooked up to build yet. I have just done so. (which will trigger a build)
<cjwatson> And much more complicated things have worked
<cjwatson> So let's see if it reproduces in my local setup
<diddledan> thanks :-)
<popey> https://build.snapcraft.io/user/snapcrafters/tmnationsforever
<diddledan> looks like the `build-on:` isn't respected by the builders yet (but that's completely orthogonal. I'm just observing.. :-)
<cjwatson> diddledan: I know, I've been working on that for the last couple of weeks
<diddledan> I'm betting it's a pain to get working
<cjwatson> It is very definitely in progress
<cjwatson> Most of the pain has been in sorting out APIs for Bazaar-backed things
<diddledan> you need to download the project (into a builder?) before you have the required bits to tell you where to build.. glad I'm not working on that :-p
<cjwatson> The actual mechanics of build-on are relatively straightforward, just code that kyrofa supplied for me and plumbing
<cjwatson> Nah
<cjwatson> We have internal APIs to fetch files from Git repositories
<diddledan> aha
<cjwatson> And I've put the same thing together for Bazaar
<diddledan> sneaky backroom dealings!
<cjwatson> Although now that you mention it I'm going to have to work out how that works for stuff hosted on GH, argh
<cjwatson> sudden non-triviality realisation!
<diddledan> oops, sorry :-(
 * diddledan cuddles everyone who needs it
<cjwatson> might need to start doing internal imports or something
<zyga> re
<cpaelzer> hi, I assume I was lazy not paying attention to some mails - but it seems my small snap was sorted out in the snapstore
<cpaelzer> I still have it installed
<cpaelzer> virt-machine-type      0.0.2                   3     edge      paelzer       -
<cpaelzer> but can't find it on the store
<cpaelzer> maybe I violated some new check/rule
<cpaelzer> how would I debug that other than digging through the pile that is my mail inbox?
<sparkiegeek> cpaelzer: define "can't find it on the store" ?
<cpaelzer> like search on https://snapcraft.io/store
<cpaelzer> aren't all snaps there?
<sparkiegeek> cpaelzer: you haven't released it to stable, the search APIs don't (yet) return snaps that haven't been pushed to stable
<cpaelzer> oh, that explains why snap find doesn't find it either
<cpaelzer> thanks sparkiegeek
<cpaelzer> I thought it was shown on find in the (very) early days
<cpaelzer> but that is fine
<cpaelzer> yeah I can install from edge
<cpaelzer> thanks sparkiegeek
<zyga> jdstrand: will you have time to review https://github.com/snapcore/snapd/pull/5081 before your holidays?
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<popey> diddledan: huh, tmn fails too. https://launchpadlibrarian.net/374512942/buildlog_snap_ubuntu_xenial_amd64_7d2139885b31f8fd1187b9d3482243b9-xenial_BUILDING.txt.gz
<sparkiegeek> popey: looks different? is wget in the build-packages stanza?
<popey> No, it's in stage-packages.
<popey> works in cleanbuild though *shrug emoji*
<cjwatson> Yeah that looks like an obvious bug
<diddledan> yeah, I had to add wget to build-packages. that's a different issue :-)
<cjwatson> cleanbuild uses a slightly fatter base image
<sparkiegeek> popey: ð¤·
<popey> ok, thanks will fix that
<cjwatson> diddledan: speaking of which you need "build-packages: curl" in the gog-galaxy-version part
<popey> doing gods work sparkiegeek thanks
<cjwatson> I don't think that's the bug here, but noticed in passing
<diddledan> I do?
<sparkiegeek> popey: I had to leave people hanging :)
<diddledan> I'm not using curl anywhere
<cjwatson> Yeah you are
<cjwatson> Last line of your snapcraft.yaml
<diddledan> oh yeah, I see it, thanks
<diddledan> I should swap that for wget
<anarcat> grml... so more firefox problems! :) since 60.0.2 (or 60.0.1? not sure) u2f authentication is failing
<cjwatson> Eh, curl is more convenient for piping to stuff, so *shrug*
<anarcat> it works well in firefox-esr from the debian packages and used to work in earlier snap versions, so i'm not sure what's going on
<anarcat> the u2f token is a Yubikey NEO and it still works with chromium as well
<anarcat> i'm wondering how/if i can rollback to an earlier snap version
<cjwatson> diddledan: reproduced locally; trying under strace to get a better idea of what's failing
<popey> Chipaca: nice on the xps! The chromebook I got is all up to date (as far as it will go) and will probably live on a dusty shelf now :)
<pedronis> niemeyer: https://forum.snapcraft.io/t/possible-evolution-path-for-snap-store-endpoints-regarding-epoch/5871
<jdstrand> zyga: yes, see your inbox :)
<jdstrand> that's one for today
<anarcat> should i send my question on the forum instead?
<zyga> oh, thanks
<sparkiegeek> anarcat: snap help revert in general, 'snap revert firefox'  in particular?
<zyga> jdstrand: about readlinkat, I suspect it's an older conffile
<zyga> jdstrand: so one thing about todays discussion, I'd love to get snap-confine profile out of /etc
<zyga> and out of conf-file hell
<anarcat> sparkiegeek: thanks, i somewhat missed that
<jdstrand> I know you would and it makes some sense, especially with the core snap discussion from earlier
<jdstrand> I've said that elsewhere
<anarcat> sparkiegeek: what if i confirm the regression? should i file this as a bug somewhere?
<mvo> zyga: I updated 5324
<zyga> thanks
<anarcat> sigh... reverting to 60.0.1 doesn't fix the issue :/
<mvo> zyga: it uses most of the ideas you suggested, I think its nice now, no more special cases, profiles get loaded on boot etc
<mup> PR snapd#5306 closed: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5306>
<popey> jdstrand: we're getting a failure in the store where we're using build, so surprised it's failing... https://dashboard.snapcraft.io/snaps/tmnationsforever/revisions/6/
<popey> it says checksums don't match
<sparkiegeek> anarcat: I'm not familiar with the details of U2F, could it be https://forum.snapcraft.io/t/snapped-firefox-unable-to-use-smart-card/5719 ?
<anarcat> sparkiegeek: probably related, yes. it's strange because it used to work...
<anarcat> sparkiegeek: is there a way to revert further back?
<jdstrand> popey: it figures that as soon as I see my email that there was nothing reported, something was reported
<popey> You're welcome. :)
<jdstrand> popey: I really don't know anything about build. is it using a new enough snapcraft?
<zyga> jdstrand: ack, thank you for the mail
<jdstrand> popey: are you doing anything weird like an unsquash/fix something/mksquash?
<sparkiegeek> anarcat: look at the --revision flag
<cjwatson> jdstrand: hey the snapcraft version is right there in the build log
<cjwatson> (though may not be readily linked to from the store I suppose)
 * jdstrand doesn't have the build log url
<jdstrand> yeah, it isn't yet (that would be great! :)
<jdstrand> popey: is this electron-builder?
<cjwatson> jdstrand: you can start from https://launchpad.net/~build.snapcraft.io/+snap/7d2139885b31f8fd1187b9d3482243b9-xenial to find this one
<popey> jdstrand: no, we dont do anything shonky
<cjwatson> jdstrand: but in general, BSI uses whatever's latest in xenial-updates
<popey> jdstrand: it's just wine (dumped deb) and another couple of scripts dumped in
<anarcat> sparkiegeek: how do i find which revisions are available? info does not say much
<zyga> anarcat: you can only refresh to a revision you already have on your system (snap list --all will tell you)
<cjwatson> diddledan: so your problem is simply that the URL you're trying to fetch doesn't exist
<anarcat> zyga: thanks
<cjwatson> diddledan: Downloading https://dl.winehq.org/wine-builds/ubuntu/pool/main/wine-devel_3.9.0~xenial_.deb...
<cjwatson> (you get a 200 from the CONNECT and then a 404 from the underlying tunnelled protocol; that confused me for a while)
<diddledan> o_O
<mvo> cachio: can you point me to the snapcraft.yaml for the rsync snap please?
<mvo> cachio: nevermind, just found it
<diddledan> oooh. running locally sets $SNAP_ARCH, but for some reason that's not there in the buildd...
<cachio> mvo, ok
<cachio> it is in snapd repo
<sparkiegeek> cjwatson: nice spot
<anarcat> uh
<cjwatson> diddledan: probably because you're using snapcraft as a snap
<mvo> cachio: yeah, thanks, I will build a core18 version of this :)
<anarcat> so this never worked apparently
<cachio> mvo, great, thanks
<cjwatson> diddledan: it's the snap execution path that sets SNAP_ARCH, so that's really the wrong variable to use here
<cjwatson> (I'm not sure exactly what would be correct)
<sparkiegeek> anarcat: the other possibility is that changes in core could have affected it, so might be worth jumping back to latest firefox and walking back through core versions
<cjwatson> maybe just $(dpkg --print-architecture) ?
<anarcat> or at least it's not a firefox-induced regression: i can't make it work with any snap i have on disk (60.0, 60.0.1, 60.0.2)
<anarcat> i wonder if i had that working with 59
<anarcat> sparkiegeek: ah yes, i could try the revert trick with core?
<sparkiegeek> anarcat: yes
<anarcat> is there a way to see which updates took place when? "logs" and "changes" doesn't show anything useful
<diddledan> thanks for spotting that :-)
<anarcat> hahaha reverting core to 16-2.32.6 breaks all font display whee!
<anarcat> wow, blocky hell
<anarcat> well shit - i think i had that problem before, but i don't remember how i solved it
<anarcat> http://paste.anarc.at/snaps/snap-2018.06.14-10.59.05.png
<anarcat> boom ^
<sparkiegeek> anarcat: ... nice
<anarcat> yeah
<anarcat> so that was triggered by reverting core from 16-2.32.8 to 16-2.32.6
<anarcat> i tried reverting back to 16-2.32.5 as well, no dice, and then reverting *forward* to 16-2.32.8 does not fix the issue
<anarcat> and also, none of the core versions fix the u2f issue either
<cjwatson> diddledan: np
 * diddledan goes to sit in the corner with the cone-shaped hat with a big "D" written on it
<cjwatson> diddledan: FWIW it might help if you used wget --no-verbose rather than wget --quiet
<cjwatson> --quiet turns off all output, including errors
<diddledan> http://static.tvtropes.org/pmwiki/pub/images/dunce_hat.jpg
<cjwatson> so it's pretty unhelpful in this kind of situation
<cjwatson> --no-verbose means you get one line of output in the successful case, and something useful in the error case
<popey> jdstrand: oddly a later build worked fine!?
<anarcat> sparkiegeek: any other suggestions?
<sparkiegeek> anarcat: are you back to sensible fonts on latest core/firefox ?
<anarcat> sparkiegeek: nope
<anarcat> sparkiegeek: i'm trying to remove and reinstall FF now
<diddledan> I just got a checksums don't match, popey , jdstrand
<anarcat> i think it's what fixed it the last time
<diddledan> same, normal build on BSI
<anarcat> well that's one frustrating day
<jdstrand> diddledan: what is the snap?
<diddledan> https://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/
<diddledan> gog-galaxy-wine
<cjwatson> jdstrand: https://launchpad.net/~build.snapcraft.io/+snap/be52b943c0d4d977217aac0ad5a8ad1c-xenial/+build/249197 is an affected build
<cjwatson> snapcraft 2.42.1 says the build log
<cjwatson> I don't really know the toolchain here but let me know if it looks as though LP is doing something wrong here
<anarcat> aaand remove + install fixed the blocky font problem
<jdstrand> cjwatson: yes, thank you
<jdstrand> popey: that sounds like there is still a lurking timestamp issue
<jdstrand> as in, the resquash takes too long and the timestamps are different in the resquashed snap
<popey> Sounds plausible.
<anarcat> sparkiegeek: sigh... and core 16-2.32.5 still exhibits the same u2f problem
<jdstrand> it is weird that this has been enabled for 4 days and today is the first it is reported
<cjwatson> wait, you're relying on the unsquash/resquash all happening within the same second or something?
<cjwatson> have you considered using faketime?
<jdstrand> cjwatson: obviously we shouldn't be. I'm speculating there is a bug
<anarcat> testing this is excruciating: i need to revert, uninstall firefox, reinstall firefox, for every iteration
 * cjwatson nods
<jdstrand> cjwatson: squashfs-tools has not been super friendly for us. it would, for example, recreate symlinks during resquash with the current time rather than what was in the inode in the squash.
<cjwatson> helpful
<jdstrand> cjwatson: I'm suspecting something else in there. faketime is an interesting option I'll look into
<jdstrand> indeed
<jdstrand> roadmr: please disable resquashfs
<roadmr> jdstrand: on it
<roadmr> jdstrand: done
<pedronis> a 2nd review of #5328 would be nice, it's small and only test code
<mup> PR #5328: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5328>
<zyga> pedronis: done
<jdstrand> roadmr: thanks
<jdstrand> popey, diddledan: your next uploads should work
<pedronis> zyga: thx
<diddledan> thanks :-)
<popey> thanks jdstrand
<mborzecki> pedronis: thanks for the review, i'll try to push an update soon so that we could probably land the branch sometime tomorrow if there are no more issues
<jdstrand> diddledan: interesting:
<jdstrand> -drwxrwxrwt root/root                 3 2018-03-07 04:41 squashfs-root/var/spool/samba
<jdstrand> +drwxrwxrwx root/root                 3 2018-03-07 04:41 squashfs-root/var/spool/samba
<jdstrand> diddledan: your snap had a sticky dir and the resquash did not
<jdstrand> I'll look into that
<jdstrand> curious, same with tmnationsforever
<jdstrand> -drwxrwxrwt root/root                 3 2018-03-07 04:42 squashfs-root/var/spool/samba
<jdstrand> +drwxrwxrwx root/root                 3 2018-03-07 04:42 squashfs-root/var/spool/samba
<diddledan> tmnations is built using a very similar set of packages
<pedronis> mborzecki: ok, added another small comments about a TODO
<mborzecki> pedronis: thanks
<mborzecki> pstolowski: current master failed with econnreset :P
<pstolowski> noooo
<jdstrand> it is weird that a subsequent build would produce different results for tmnationsforever
<pstolowski> damn
<mborzecki> pstolowski: https://travis-ci.org/snapcore/snapd/builds/392288895?utm_source=email&utm_medium=notification
<jdstrand> well, it could be an overflow or something in squashfs-tools. anyway, I'll look into it
<cjwatson> sergiusens: not quite transparent proxy, just transparent handling of authentication
<cjwatson> sergiusens: I wouldn't rip out the proxy user/pass handling from snapcraft 'cause it is technically correct, but it should put less pressure on that to be absolutely correct
<mborzecki> pstolowski:what if we could simulate network issues by using a proxy instead?
<pstolowski> mborzecki: same story.. download request is happy after 1st attempt and we proceed with fetching assertions.. which fail and are retried as expected. but the test expects download to fail and be retried
<pstolowski> mborzecki: we could i guess, but there must be an explanation..
<mborzecki> pstolowski: is it using fakestore?
<pstolowski> mborzecki: no
<mborzecki> pstolowski: what if it used, and we add some error injection contraption to it?
<mup> PR snapd#5328 closed: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5328>
<mborzecki> pstolowski: https://github.com/tylertreat/comcast https://github.com/shopify/toxiproxy both are written in (surprise, surprise) Go
<pstolowski> mborzecki: we could, but current approach should work too :/
<pstolowski> i don't know.. maybe gcloud is actually so crazy fast sometimes that it manages to download entire huge test snap before we apply iptables rule and download simply succeeds? fwtw i saw this download completed in ~10s when i executed download manually on gcloud spread machine
<pstolowski> with ~10s it would be too slow and the test would do the right thing.. but maybe it's faster sometimes
<pstolowski> dunno
<sergiusens> cjwatson: no worries, we cannot remove it as we have known instances of people depending on them; but it does put us in a position where we need to solve specific use cases only
<mborzecki> is github slow for anyone else too?
<mborzecki> pedronis: https://github.com/snapcore/snapd/blob/master/asserts/device_asserts.go#L218 is this where we'd check for valid snap names in model assertion?
 * zyga takes a break for an hour, no biking this time, just coffee and a new book
<zyga> I need to vent my mind and rest for a while
<zyga> after that I'm back to system slots mvo :)
<zyga> jdstrand: thank you for the review on 5081
<zyga> I agree with everything but one remark about having enough data to pick * vs */
<zyga> perhaps I didn't understand you there
<zyga> if you don't have time to see my comment there before your holidays then don't worry, I will improve the comments and land and we can polish this more after you return
<zyga> I will now use this to construct apparmor permissions for mimics and this will fix one of the two remaining layout bugs :)
<pedronis> mborzecki: yes
<mborzecki> pedronis: ack, looks like a 3rd (or 4th?) copy of snap.ValidateName()
<mborzecki> pedronis: anyways, added a todo note and pushed everything to github
<pedronis> mborzecki: maybe, anyway, yes for now a todo is ok
<pedronis> mborzecki: also IÂ put some notes in the topic as well, don't know if you saw those
<mvo> zyga: ta
<mborzecki> pedronis: yup seen those, thanks for posting them
<niemeyer> pedronis, Chipaca: Here are some notes from today's call:
<niemeyer> https://forum.snapcraft.io/t/possible-evolution-path-for-snap-store-endpoints-regarding-epoch/5871/5
<cjwatson> kyrofa: https://code.launchpad.net/~cjwatson/launchpad/snap-parse-architectures/+merge/347998 FYI
<niemeyer> "On Tuesday, June 12, we incorrectly sent you an email stating that your billing account had been terminated for non-payment. No action is required on your part, and there has been no change to your active billing accounts. This email was sent in reference to billing accounts that had already been terminated."
<cjwatson> kyrofa: initial work, more to come, but this is what integrates your code most directly
<niemeyer> <3
<niemeyer> GCE
<kyrofa> Ah, cjwatson, awesome!
<kyrofa> Looks like I didn't quite get the python2 compatibility I was hoping for judging from the changes-- not too bad I hope?
<cachio> Chipaca, hey, there is a comment on #5242
<mup> PR #5242: tests: new test for joystick interface <Reviewed> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5242>
<Chipaca> cachio: hey
<Chipaca> cachio: me?
<cachio> it needs your opinion
<cachio> Chipaca, yes
<Chipaca> ah, seen it now
<Chipaca> cachio: replied
<Chipaca> cachio: we've not done that work yet, so it's still the only way to do it
<mvo> zyga: progress on 5324 - with that I managed to run a trivial core18 spread test on a real(ish) core18 image
 * mvo calls it a day with that success
<cachio> Chipaca, great, thanks!!
<cachio> mvo, congrats
<niemeyer> mvo: \o/
<cachio> mvo, is it possible to run the snapd suite?
<mup> PR snapcraft#2160 opened: many: refactor snapcraft.yaml loading out of load_config <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2160>
 * Chipaca EODs, for great justice
<mup> PR snapd#5329 opened: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329>
<cjwatson> kyrofa: very minor unicode_literals handling, but nothing serious
 * cachio afk
<cjwatson> kyrofa: the only really substantive change I made was to allow snaps to declare that they build on architectures that LP doesn't support, which seems wise to me
<kyrofa> Indeed, I suppose that makes sense
<bdx> having a bit of an issue with python deps showing up for packages that define #/usr/bin/env python3 as their header
<bdx> https://paste.ubuntu.com/p/XZnpjyzKbz/
<bdx> I cat the gunicorn exe and I think its just getting the wrong env
<bdx> https://paste.ubuntu.com/p/zBkpvyRXt7/
<bdx> due to the fact that python3.6 is actually what is being used ....
<bdx> I'm not really sure what exactly is going on .... last time I built this snap everything checked out but that was a few months ago, and on xenial
<bdx> but now, following a build/install of the snap it seems packages are borked because of the env possibly
<bdx> oh man ... I was so turned around ... pretty sure I've found my way
<binarycreations> Oh man, I do not know what I am doing wrong...
<binarycreations> This is my first attempt at creating a snap. I am trying to snap the anki desktop client.
<binarycreations> A gist of my snapcraft.yaml is available (https://gist.github.com/binarycreations/3991eba94a9dc78bb9ee1e3d66168e88)
<binarycreations> I am building my snap in a 16.04 Ubuntu VM using Vagrant so it is the server version of Ubuntu
<binarycreations> I then run the snap on my host which is Arch Linux
<binarycreations> They problem that I seem to have is, whilst the downloaded anki binary works fine on my host within the VM and snap I get a error from anki stating it can't find or load the libfontconfig.so
<ondra> niemeyer ping
<binarycreations> Is that an indication of a missing package? (i.e. I should find the package that includes that linked library in the stage-build)
<binarycreations> Is it due to the fact I am trying to build and run a snap on Ubuntu Server, where the app requires Ubuntu Desktop (as in an X server and other related dependencies that would be detected by ldd and added to the snap?)
<niemeyer> ondra: Hey
<ondra> niemeyer hey
<ondra> niemeyer  do we have interface, something like light weight content interface, which would allow one snap to change configuration of another snap?
<niemeyer> binarycreations: The forum is generally a better place for those discussions as it allows people to respond at the best time for them without you having to wait here and without the conversation scrolling off
<binarycreations> Okay, cool. I drop another question on there.
<niemeyer> ondra: Not anything built-in that would allow the equivalent of "snap set" across snaps.. we did discuss something like that a while ago, but only lightly
<niemeyer> ondra: I think it'd make sense to eventually have that as a proper mechanism
<ondra> niemeyer agree
<ondra> niemeyer I will kick off forum post about it to start gathering context
<niemeyer> ondra: Sounds good, thank you
<niemeyer> ondra: I think it can literally be some kind of interface that would enalbe "snapctl set" to take an extra argument with a snap name
<niemeyer> ondra: We'd condition that to only work if the interface is connected
<niemeyer> ondra: and we might allow auto-connection if both snaps are from same publisher, similar to how we do the content interface
<niemeyer> ondra: I mean, by default.. we'd also allow auto-connection after manual reviews as usual
<ondra> niemeyer but wouldn't you want to limit this between snaps A->B? Or you are thinking to have ability to configure all snaps?
<ondra> niemeyer yeah
<ondra> niemeyer sorry I misunderstood, so between defined snaps
<niemeyer> ondra: We need to think carefully.. but I think we have some good precedence in the content interface.. the issues are very similar, even if the actual "API" is different
<ondra> niemeyer yep
<ondra> niemeyer one can go crazy there and start defining per config keys, but I do not thing we need that fine control
<ondra> niemeyer I will kick of forum post and let's continue there
<niemeyer> ondra: We still want to have schemas for the configuration, as a general feature.. we might eventually hook the two things together and allow partial access to a configuration via the schema.. but agreed, that's future
<niemeyer> ondra: Thanks
<ondra> cool
<mup> PR snapcraft#2161 opened: many: automatically detect dependency changes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2161>
#snappy 2018-06-15
<mborzecki> morning
<mup> PR snapcraft#2161 closed: many: automatically detect dependency changes <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2161>
<zyga> hey everyone
<zyga> I will have an unusual Friday with some school stuff interfering today
<zyga> I will attempt to minimise it though
<mvo> zyga: good morning
<zyga> hey
<zyga> I'm sorry, I collapsed yesterday, I was sleeping since ~~19:00
<mvo> zyga: no worries
<zyga> I saw your ping about managing to run apps on top of your PR, that's fantastic
<zyga> I will share what I have on system slots
<zyga> though it's not fully working yet (tests)
<zyga> (tests are still choppy)
<mvo> zyga: thanks, its small steps on my part but it is nice to see (some) things coming together
<mvo> zyga: and thanks for working on the interfaces part!
<mborzecki> zyga: restarted the build in 5325
<zyga> I noticed someone did, thank you
<zyga> that branch is cursed :)
<mvo> hey mborzecki, good morning
<mborzecki> mvo: hey
<mborzecki> i'll restart the build in 5293 a couple of times, just to rule out the luck factor
<mborzecki> #5293
<mup> PR #5293: tests: fix interfaces-calendar-service test when gvfsd-metadata loks the xdg dirctory <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5293>
<mborzecki> if that's green, then we're down to just one notoriously flaky test - econnreset :P i'm sure pstolowski|afk  is super happy about that
<pstolowski> mornings
<pstolowski> mborzecki: i'm tempted to relax retry check in econnreset test to just for retry on either download or assertions, instead of expecting retries on download only
<pstolowski> *to just check*
<mup> PR snapd#5325 closed: interfaces: add Repository.AllInterfaces <Simple> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5325>
<zyga> mvo: I struggle with the number of places that need to know about "system",
<zyga> I need to take my dog out but after that let's chat
<mborzecki> hm that slack carshing xwayland is so weird
<mborzecki> there's a backtrace posted in the forums, given that slack is classic, it's probably doing some LD_* magic
<mborzecki> but none of the symbols seem to point back to /var/lib/snapd/snap/..
<mborzecki> unless the backtrace is wrong, or at least the library locations
<mvo> zyga: sounds good, just ping me when you are back and have time (I was in a different meeting just now)
<mup> PR snapd#5330 opened: snapstate: support restarting snapd from the snapd snap on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5330>
<zyga> mvo: re,
<zyga> mvo: so I'm pondering this
<zyga> the interface repository aspect itself is clean
<zyga> but overlord is more subtle,
<pedronis> mvo: hi, I remembered something about setup-profiles phase2 for core that we need to consider I think
<zyga> we can either teach all of interface manager to skip/ignore system snap
<zyga> and risk leaks to other managers perhaps
<zyga> or return virtual system snap from snap manager's APIs
<zyga> mvo: I was also considering actually installing a real snap that shows up in /snap but I think that is more complex actually (e.g. revert is messy now)
<mvo> pedronis: oh, what is that?
<pedronis> mvo: that it was also stopping going forward until we were restarted, that has relevance to autoconnect for example
<mup> PR core18#27 opened: run-snapd-from-snap: start snapd after seeding <Created by mvo5> <https://github.com/snapcore/core18/pull/27>
<pedronis> mvo: zyga:  we even the question of when we run autoconnect for things in system, either that needs to happen in the new snapd
<pedronis> *either way
<mvo> zyga: hm, would it help if snapstate would have a fake system snap?
<zyga> that's a good point
<zyga> pedronis: could it run.. twice?
<pedronis> it doens't need to run twice
<pedronis> is already in the right place
<zyga> mvo: yes, it would, I'm doing that now
<pedronis> is the waiting for restart that is missing now
<zyga> mvo: that part actually works now, I'm just moving things around to have only one instance of snap.Info in memory
<zyga> and to coordinate the implicit interfaces there
<pedronis> mvo: zyga: are we going to filter it out of snap list ?
<pedronis> or not
<mvo> pedronis: aha, ok. I remember (vaguely). should we do that in link-snap now?
<zyga> pedronis: currently it doesn't show up in snap list
<zyga> it's only virtually returned by Get
<pedronis> zyga: by hacking ?
<zyga> and ignored by Set
<pedronis> interesting
<zyga> that is, it is only a snap you can get the "state" of but it's not really anywhere else
<pedronis> bit unclear how that works with reloading profiles though
<zyga> reloading profiles?
<zyga> on startup with system key changes?
<pedronis> yes
<zyga> the interface manager has explicit code to load the virtual system snap
<zyga> so that works ok
<zyga> anyway, it's not fully baked yet
<pedronis> you can cheat in  snapsWithSecurityProfiles
<zyga> so we may abandon that totally
<zyga> oh, yes, that's a good idea
<zyga> I could remove the special code from interface manager then
<pedronis> zyga: it sounds messy though overall from afar
<pedronis> tbh
<zyga> pedronis: I agree
<zyga> pedronis: it's an experiment still, we may end up doing something totally different
<pedronis> mvo: where we put depends exactly when we run autoconnect logic for "system"Â interfaces
<pedronis> in theory it should happen in autoconnect for "core"Â or "snapd"
 * mvo nods
<pedronis> mvo: we can add waiting to link-snap (but is annoying if I remember) or auto-connect or yet something else (but then it's hard across upgrade)
<pedronis> mvo: I think we need in auto-connect itself because upgrades, if it's in link-snap is the old snapd that needs to wait there
<pedronis> and it will not
<pedronis> mmh, well, not it will still wait in setup-profiles
<pedronis> so maybe doing something different is ok
<pedronis> but we need to think
<mvo> pedronis: right. my gut feeling is that waiting in auto-connect - because that is close to why its needed. but I have not thought deeply about it yet
<pedronis> mvo: which brings back the annoying part of that story that is about detecting rollbacks or missing reboots
<pedronis> (IÂ hoped we could live without but seems not)
<pedronis> mvo: ah, but now we don't need to wait for a reboot, just a restart
<pedronis> bit easier
<mvo> pedronis: yeah, let me have a quick look
<pedronis> mvo: to notice the issue, you need to do something like install a snap that needs a new auto-connected system interface, notice that is not connect, refresh snapd to one that has it, if snapd doesn't do auto-connect with the right new version, the connection is still not there
<mvo> sil2100: hey, sorry that I didn't get to #24 for core18 earlier. I added some thoughts, hope they are helpful
<pedronis> mvo: admittedly all a bit of a corner case
<mup> PR #24: Renamed .bzrignore to .gitignore. Added .coverage. Removed the ./ in front of ignored paths <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapd/pull/24>
<pedronis> mvo: which also reminds that we need to teach about the "snapd" snap to snapstate.go byKind
<pedronis> it should sort first
<mvo> pedronis: I guess http://paste.ubuntu.com/p/YbV92FPgd8/ is too naive for the wait?
<mvo> pedronis: let me look at the sorting
<pedronis> mvo: it's not unreasonable,  the issue is more  the rollback checks,  we don't need them for snapd, but we need them for core
<pedronis> that one still fully reboots
<pedronis> IÂ mean  core as base
<mvo> pedronis: aha, so we need all of GuardCoreSetupProfilesPhase2 back it seems
<pedronis> some parts of it
<pedronis> yes, sorry
<mvo> pedronis: and teach it about bases
<mvo> pedronis: thank you
<pedronis> mvo: really only core
<pedronis> as a base
<pedronis> for now
<pedronis> undering the assumption that base themselves
<pedronis> don't have slots
<pedronis> (we might change that at some point, but don't think we want to go there now)
<mvo> pedronis: +1
<mup> PR snapd#5331 opened: snapstate: sort "snapd" first <Created by mvo5> <https://github.com/snapcore/snapd/pull/5331>
<zyga> mvo: ok, I have something that vaguely works
<zyga> I can share it now, let me commit
<zyga> it still doesn't pass unit tests
<mvo> zyga: ok
<mup> PR snapd#5332 opened: tests: relax check for download start, match either download or assertion retry attempt <Created by stolowski> <https://github.com/snapcore/snapd/pull/5332>
<mborzecki> pedronis: do you think #5314 is close to landing now?
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<zyga> mvo: ok let me get rid of junk from history and push it
<pedronis> mborzecki: probably, but IÂ need to look at it again
<pedronis> Chipaca: +1 to #5326 with some final nitpicks
<mborzecki> pedronis: ok, take your time, better catch all the places now
<mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
<pedronis> sorry
<pedronis> Chipaca: I meant #5327
<mup> PR #5327: store: switch store.SnapInfo to use the new v2/info endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/5327>
<pedronis> mborzecki: of course we have some pending PRs adding more Name() and RealName uses
<zyga> mvo: I have one idea I lijke
<zyga> "snap info system"
<zyga> could do what "snap version" says, e.g. synthesise nice description, summary,
<zyga> use os-release
<zyga> etc
<zyga> it sounds nice and would be ... cool :)
<mborzecki> pedronis: i guess i could nag people to add a todo note while they're at it, otoh wouldn't want to disrupt PRs too much, i can always merge this locally, since it's a rename the the code will fail to build (well maybe aside from RealName, this may easily fall under the radar)
<pedronis> mborzecki: any further tought btw whether we should put InstanceKey in Info/SnapState/SnapSetup or SideInfo ?
<zyga> mvo: command-not-found broke in bionic
<zyga> it's broken, but not as you know it https://www.irccloud.com/pastebin/Za3Og5z0/
<zyga> also, I wonder why it used "sudo snap install" twice
<mvo> zyga: hm, hm, what version of snapd do you have? edge?
<zyga> I'm running master
<zyga> + my magic changes
<mvo> zyga: this indicats some mismatch between snapd and snap
<mborzecki> pedronis: i'm leaning towards side-info, other option i looked at is keeping it in snapstate as a separate field, but i'm not convinced, feels like it's shifting the cost of tracking it to other places, besides we already repeat a bunch of data in side-info for every revision, instance keys are relatively short (at least for now) so there wouldn't be that much overhead
<zyga> mvo: ah, that's possible
<zyga> I only have ./snap
<mborzecki> heh formatting heredoc in task.yaml is awkward, especially if it's nested in some for loop/if block
<pedronis> mborzecki: it still feels a bit dirty, because everything so far in SideInfo is revision/store related
<Chipaca> error: e-book-client-error-quark[2] Conflicting UIDs found in added contacts
<Chipaca> wtf
<zyga> mvo: https://github.com/snapcore/snapd/compare/master...zyga:rfc/virtual-system-snap?expand=1
<zyga> mvo: pull this and have a look
<zyga> I will now look at what tests are unhappy
<zyga> towards making it unit test happy
<zyga> and then looking at spread happy
<mborzecki> pedronis: fair point, let's assume then that it's in SnapState (and thus in Info & SnapSetup), a bit more work but will probably pay off in the long run
<zyga> all suggestions welcome
<pedronis> mborzecki: given that we have Name() in at least a couple of those it should be well hidden, the question is how many fuctions take SideInfo directly, which is something I'm looking into
<pedronis> now
<mborzecki> #5293 is green for the 5th time now, killing gvfsd seems to work, needs a 2nd review and we could land it
<mup> PR #5293: tests: fix interfaces-calendar-service test when gvfsd-metadata loks the xdg dirctory <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5293>
<mvo_> zyga: thanks, I check after lunch
<pedronis> mborzecki: not a tone, some Mock functions but we have options tehre
<mborzecki> pedronis: heh, at least a couple of apis in snapstate will need adjustments, eg InstallPath which I touched recently
<pedronis> mborzecki: IÂ know,  I couple functions taking  *SideInfo,  will really need to take  *SideInfo, instanceKey string
<mborzecki> pedronis: those apis which take a name should be fine though
<mborzecki> name as in snap name
<pedronis> yep
<pedronis> mborzecki: the ReadInfo ones  are the mostly annoying, though usually we call them through other helpers
<pedronis> mborzecki: also not sure the one that opens  the file (vs deals with an installed snap) needs the instance key
<mborzecki> pedronis: iirc readinfo takes a name, it should be fine then
<pedronis> ah, yes
<pedronis> mborzecki: so maybe you could quickly check how many places doing  ReadInfoFromSnapFile  will need to stick a instanceKey in the result
<pedronis> that seems the biggest sticking point
<mborzecki> pedronis: yeah, i'm already setting it explicitly https://github.com/bboozzoo/snapd/blob/bboozzoo/parallel-snap-install-from-snap/snap/info.go#L933 so a simple adjustment
<pedronis> mborzecki: ?, I'm talking about *SnapFile
<pedronis> understood about just ReadInfo
<pedronis> it's used not a lot
<pedronis> we should be able to survice
<pedronis> survive
<mborzecki> yup, a handfull of places
<pedronis> same OpenSnapFile
<pedronis> with the latter we have a name or SnapSetup around
<pedronis> mborzecki: so, yes I would try  to add InstanceKey to Info SnapState and SnapSetup and see how it goes
<pedronis> seems cleaner long term
<zyga> pedronis: what's the revert plan for instances
<zyga> CE will test reverting core / snapd
<pedronis> zyga ?
<zyga> how do we plan that after installing instanced snaps revert won't cause issues on the system
<pedronis> it's kind of hard
<zyga> right but we need _a_ plan
<zyga> CE has a test that shows that revert must work
<pedronis> well on core devices nothing should do that
<zyga> we've been burned by that before
<mborzecki> with the former we seem to have the name in the caller (or don't care as in case of snap try)
<pedronis> unless is done explciitly
<zyga> pedronis: as long as they don't use instances (I doubt they do) it would work, right?
<pedronis> yes
<zyga> perfect
<zyga> we should coordinate with CE to let them know in case
<pedronis> it might also make sense
<pedronis> to have as experimental feature for a while
<pedronis> which means you really need to opt in
<zyga> I agree
<pedronis> to play with it
<mborzecki> experimental.parallel-installation
<mborzecki> or somesuch
<zyga> maybe use the word "instance" somehow
<zyga> people will get LL vs L wrong
<zyga> and instance is the word we use in various messages
<zyga> mvo_: so one thing I was worried about yesterday
<zyga> that I mentioned at the standup
<zyga> but then it slipped my mind
<zyga> was core transition with system in place
<pedronis> mborzecki: I will do another pass over InstanceName after lunch at this point
<zyga> we need to do something about it
<mborzecki> pedronis: great, thanks
<zyga> we also need to look at the core snap and the existing real core-support plug there
<zyga> I will park this branch and look after other work now, let's sync when you are back
<mborzecki> meanwhile, i'm updating wife's laptop to f28 to check that xwayland thing, can't believe is coming down like this
<mborzecki> that guy on arch, for whom the build failed had this in makepkg.conf LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,now", notice how it's missing -z before now
<mborzecki> zyga: that kill -9 gvfsd -> https://i.imgur.com/Iu0soAq.jpg
<pstolowski> pedronis: disconnect hooks conflict are more fun than autoconnect.. do you have a moment for HO?
<pedronis> pstolowski: nowish
<pstolowski> pedronis: ok
<pstolowski> pedronis: in the standup ho
 * Chipaca lunches
<popey> Chipaca: https://raymii.org/s/blog/snap_install_mosaic_the_first_graphical_webbrowser_on_Ubuntu.html
<popey> :)
<Chipaca> popey: :)
<Chipaca> ah drat i was going to have lunch
 * Chipaca is having one of those days
 * Chipaca goes
<niemeyer> mborzecki: Sent some notes on #5314.. have a morning full of meetings from now on, so won't be able to complete it before my afternoon
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<mborzecki> niemeyer: thanks, want to chat about this before/after the standup?
<niemeyer> mborzecki: Sure, but can't before my afternoon.. have 4 meetings in sequence now
<pedronis> mborzecki: niemeyer: IÂ should  probably be there too, otherwise we might start to push in different directions just because of misaligments/misunderstanding
<abeato> mvo_, niemeyer https://github.com/snapcore/snapd/pull/5309 is ready for another round
<mup> PR #5309: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5309>
<zyga> mvo_: do you want to sync before the standup?
<zyga> I will be absent later today for school stuff
<mvo_> zyga: sure we can sync
<mborzecki> pedronis: fwiw, we can go down the introduce StoreName() (and make it the same as InstanceName()) route, either having TODOs and introducing the change later, or adding it right now works for me
<mvo_> zyga: when you want
<zyga> ok, let's jump into the hangout
<mvo_> zyga: ok, I need one minute or so for tea
<pedronis> mborzecki: I'm fine with a do nothing StoreName personally
<pedronis> mborzecki: it seems also safer in the sense that new PRs might need to add places that need it actually
<mborzecki> pedronis: ok, let do this then, i'll put aside the spread and snapstate stuff now and will focus on this
<Nafallo> hi! what's the best way of using Ubuntu Core for an organisation. create a dummy user and add everyone's keys, or is there a way of registering an SSO account to a group with members? :-)
<Chipaca> pedronis: I've pushed a slightly more channel-y test
<Chipaca> pedronis: this'll all fall apart when we stop passing architecture to the store though :)
<Chipaca> Nafallo: create a user for the project, have it register the name of the snaps, and give devs developer access to the snap
<Chipaca> Nafallo: then as the team evolves it's easier to manage than if you  added the keys like you propose
<pedronis> Chipaca: thanks,  this and the old one still miss the HasLen check though
<Chipaca> pedronis: i'll just change the check to do a big deepequals
<Chipaca> bah
<Chipaca> better errors this way
<Chipaca> hmm
 * Chipaca fixes
<Chipaca> pedronis: done
<pedronis> Chipaca: thanks, just need to be green now
<Nafallo> Chipaca: I'm not sure we'll be doing snaps, rather than using Ubuntu Core for container hosts. last step in registration requires an Ubuntu SSO e-mail to grab the SSH keys etc... :-)
<Chipaca> Nafallo: ah! I'd misunderstood sorry
<mup> PR snapd#5332 closed: tests: econnreset - relax check for download start, match either download or assertion retry attempt <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5332>
<Chipaca> Nafallo: if i were in your place I'd check with mwhudson
<Chipaca> Nafallo: but it's something like 1am for him so probably not on irc
<Nafallo> alright. thanks for hilighting him :-)
<mup> PR snapd#5327 closed: store: switch store.SnapInfo to use the new v2/info endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5327>
<Chipaca> pedronis: ^
<pedronis> \o/
 * zyga goes to school
<mvo_> Chipaca: nice!
<mup> PR snapd#5333 opened: tests: show status of the partial test-snapd-huge snap in econnreset test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5333>
<mvo_> cachio: ^- not sure if this is helpful but it might
<mvo_> cachio: or did you had a chance to look at this already via some debug shell?
<cachio> mvo_, yes I did
<cachio> mvo_, I reproduced the error with this https://github.com/snapcore/snapd/pull/5329/files
<mup> PR #5329: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329>
<cachio> and the file was empty
<cachio> the partial
<cachio> zyga, do you think we can merge this one #5293 ?
<mup> PR #5293: tests: fix interfaces-calendar-service test when gvfsd-metadata loks the xdg dirctory <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5293>
<mvo_> cachio: oh, interessting, it was empty, hm, hm, I though we had code that errors if the file is empty
<mborzecki> pedronis: niemeyer: pushed StoreName to #5314
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<mvo_> cachio: aha, nice, I see your branch already has most of the info I also am keen to see. let me check the log
<mvo_> cachio: if you have a log captured from the run from 5329 I would love to have a look. if not I will just wait for it to fail in spread :)
<cachio> mvo_, let me check
<cachio> mvo_, https://paste.ubuntu.com/p/Bq8Z2H7X7G/
<cachio> this is hte last one which I could reproduce from my machine
<cachio> there is a reboot message at the end
<cachio> niemeyer, today morning I run spread -gc and deleted 465 machines
<niemeyer> Wow.. what was that about?
<cachio> all of them created this morning
<niemeyer> That sounds suspect
<cachio> most of them created at 4am my time
<cachio> niemeyer, I realized the number when I saw the log after all of them were deleted
<niemeyer> cachio: What's the cause?  Did you check what those machines were doing?
<cachio> niemeyer, no, when I realized the big number all the machines were already deleted
<niemeyer> cachio: Can you have a pass through Travis and see why that huge number was left behind?
<cachio> niemeyer, sure
<niemeyer> cachio: Thanks!
<niemeyer> cachio: We just need to make sure we're not missing anything.. that high number of machines going past 2h definitely means something
<cachio> niemeyer, yes, it could be caused with aprox 8 builds canceled
<cachio> niemeyer, I launch 54 machines on each build
<cachio> we launch
<mvo_> cachio: *cough* I think I found the reason for the econnect issue - the network ist just too fast. the debug log from my latest pr shows the test-snapd-huge.snap is there (no partial). so I think it got all downloaded in the time it took the script to do the iptable --block commmand
<cachio> mvo_, yes, that could be a reason, but I tested and it takes like 5/10 seconds to download
<mvo_> I wonder what we should do: a) make test-snapd-huge bigger b) retry the test if its too fast c) add artificial throttling into snapd via some config option (I like (c))
<mvo_> cachio: the log indicates its the case but let me double check, maybe we need to log slightly more (i.e. when a download finished)
<zyga> Throttle vÃ­a Linux
 * zyga sends regards from school
<mvo_> cachio: hm, you are right, someting is fishy
<mvo_> cachio: after 1s it had downloaded 33Mb which is fast but not fast enough unless it picks up speed very quickly afterwards
<cachio> mvo_, yesterday I tested the same because I had the same theory
<zyga> What is inside the snap?
<cachio> so I made many downloads and allways it was taking like 10 secdonds to complete the downlaod
<mvo_> cachio: yeah, then maybe the blocking is not working correctly
<zyga> as in, what takes up the space
<mvo_> cachio: because the debug output indicates that the file is fully there
<cachio> mvo_, mmmm
<cachio> mvo_, this explains why it is not retrying
<mvo_> cachio: exactly
<mvo_> cachio: so I think we should add code that checks if the file is fully there
<cachio> -rw-r--r--   1 test test     0 Jun 15 04:00 test-snapd-huge_1.snap.partial
<cachio> but after the test we see this
<Chipaca> mvo_: wouldn't chaning the sleep 1 to sleep .01 or sth be enough?
<mvo_> Chipaca: yeah, that might be worth a shoot
<Chipaca> also that task should have a debug entry that cats the error log
<Chipaca> I'm adding logging to store/Download fwiw
<Chipaca> as i was looking into this as well right now
<mvo_> Chipaca: cool, let me update my PR to shorten the sleep and to give better errors
<pstolowski> fwtw, I tried sleep = .1 in my PR (the one i talked about in the standup) and it didn't help
<Chipaca> I think checking quicker is the right approach; my worry is that throttling will bite us in nasty ways
<mvo_> pstolowski: it seems to be baby steps, maybe it just takes too long for the kernel to apply the rule
<mvo_> pstolowski: its definitely confusing though
<pstolowski> tell me ;)
<cachio> :)
<pstolowski> can we rule our caching out? I think that's the one thing i haven't investigated
<Chipaca> mvo_: another thing we can do is add a rate limiter to store/download, for use in tests
<cachio> mvo_, Chipaca something weird is that it is just happening in some systems
<cachio> not in all of them
<mvo_> Chipaca: yeah, I was thinking about this
<Chipaca> cachio: 'snap instal bofh' <- know the TRUE reasons for things
<Chipaca> for example, the errors you are seeing are because.... We had to turn off that service to comply with the CDA Bill.
<Chipaca> mvo_: first, logs :)
<Chipaca> otherwise it's all guesswork
<mvo_> Chipaca: I added some more bits in the tests but yeah, probably debug logs++
<cachio> Chipaca, hehe
<mvo_> Chipaca: I added some more debug and an explicit check if the download finished with dates, lets see what the outcome is
<pstolowski> pedronis: i think i need to bring installTask back into checkConnectConflicts, it seems to be the only way to be able to reason about and avoid self-conflicts
<pstolowski> pedronis: (for disconnect-interfaces)
<pedronis> pstolowski: why would you have self conflicts ?
<pedronis> I'm missing something
<pedronis> pstolowski: what are you conflicting on?
<pedronis> pstolowski: you probably need to add a flag like "auto"Â to the disconnects you create
<pedronis> though
<pedronis> maybe that's the missing bit
<pstolowski> pedronis: for auto-connect we don't have them because we consider auto-connect after we linked the snap; but as I examine all non ready tasks in disconnected-interfaces i encounter own tasks for unlink-snap for example, as they are pending
<pedronis> ah
<pedronis> mmh
<pedronis> no, don't understand
<pedronis> pstolowski: I see, the problem is that the old code was naive
<pstolowski> pedronis: we consider snap-removal, so we have disconnect-interfaces in the tasks and unlink-snap as well, we find conflict with ourselves
<pedronis> though it might work because of the other conflict logic
<pedronis> pstolowski: I see, you need to pass in your snapName  (no point passing in a task)
<pstolowski> yes, or that
<pedronis> pstolowski: yea, pleas pass just a name
<pstolowski> ok
<pedronis> and then just before the last if k == "unlink-snap" ....
<pedronis> you need to check   if snapName is that name and continue?
<pstolowski> yes that's the idea
<pedronis> pstolowski: call it disconnectingSnap ?
<pstolowski> sounds good
<pedronis> mborzecki: did the last pass over #5314
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<cachio> niemeyer, well
<cachio> for each build errored we leave 54 machines alive
<pedronis> mborzecki: mostly that we don't need some todos, a we could use StoreName even a bit less... otoh IÂ have  a question about app name shortcuts... also couple of places the todo is deeper than what to pick IÂ think
<cachio> and for each cancelled too
<cachio> niemeyer, in the last 4 hours we left 108 machines
<cachio> because build error
<mborzecki> pedronis: thanks, i'll take a look
<cachio> niemeyer, I don't have so much information about the executions on this morning because most of the builds were executed again and the logs are gone
<pedronis> mborzecki: also there's a conflict with John merge IÂ think
<Chipaca> *shocked*
 * cachio lunch
<niemeyer> cachio: Ack, thanks
<niemeyer> Lunch as well
<Chipaca> mvo_: cachio: pushed some more debug to #5333
<mup> PR #5333: tests: show status of the partial test-snapd-huge snap in econnreset test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5333>
<cachio> Chipaca, nice, thanks
<mvo_> Chipaca: *hug* thank you
<Chipaca> mvo_: :-)
<mvo_> a review for 5324 would be really nice
<Chipaca> mvo_: on it
<mvo_> Chipaca: thank you again!
 * Chipaca thinks popeycore is a genre of music, played by bands that dress up as pirates and out-nerd each other on performing authentic interpretations of sea shanties
<Chipaca> either that, or really small popes
 * Chipaca agrees
<mup> PR core18#28 opened: Fix the UID/GID mapping <Created by sil2100> <https://github.com/snapcore/core18/pull/28>
 * mvo_ hugs sil2100 
<zyga> re
 * zyga wonders how things are
<mborzecki> zyga: things are 30 minutes till the match starts :)
<zyga> mborzecki: I'm not a football fan rctually
 * sil2100 hugs mvo_ back
<sil2100> mvo_: I looked at your PR and I still need to test it, guess I'm too burned out today to not miss anything important
<sil2100> So I'll review it properly on Monday morning
<sil2100> o/
<mup> PR snapd#5293 closed: tests: fix interfaces-calendar-service test when gvfsd-metadata loks the xdg dirctory <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5293>
<Chipaca> mvo_: hm
<Chipaca> mvo_: [ "filename" -gt 1 ] does not seem like a good test for 'was the file downloaded'
 * Chipaca lets the test go ahead just in case he's missing something
 * Chipaca expects to see a 'integer expression expected' error
<cachio> Chipaca, I also added your debug info to the other branch
<Chipaca> cachio: heh, ok
<cachio> so if I can reproduce the error it will help
<Chipaca> cachio: including the debug: entry in task.yaml?
<cachio> Chipaca, yes
<Chipaca> yes part of the problem with this thing is that it wasn't printing anything useful on error
<Chipaca> so unless you were running with -debug you were SOL
<Chipaca> this should help
<cachio> yes agree
<cachio> the problem is that now it is not failing :)
<cachio> it works properly when you add debug info
<Chipaca> mbuahaha
<Chipaca> proper heisenbug
<Chipaca> it'll be doing crystal meth next
<mvo_> Chipaca: did I forgot a -count ?
<Chipaca> mvo_: what were you wanting that test to test
<Chipaca> mvo_: and what command takes -count
<mvo_> Chipaca: checking if test-snapd-huge is actually there
<mvo_> Chipaca: instead of .partial
<Chipaca> mvo_: I changed the test to [ -n "$(find ...)" ]
<mvo_> Chipaca: aha, nice
<Chipaca> mvo_: I suspected you were thinking [ "$(find ... | wc -l)" -gt 0 ]
<Chipaca> but that seemes contrived for the -gt 0 case :)
<Chipaca> and you'd written -gt 1 which made it worse :)
<mvo_> Chipaca: :(
<Chipaca> that si: it was [ "$(find test-snapd-hug_*.snap)" -gt 1 ]
<Chipaca> which has a bug because bash would expand that * sometimes
<mvo_> Chipaca: a clear sign I need to call it a week ;)
<Chipaca> i mean
<Chipaca> find -name <that>
<Chipaca> heh
<Chipaca> mvo_: yes :)
<mvo_> Chipaca: thanks for fixing it
<Chipaca> mvo_: worse thing was that it was working
<Chipaca> :)
<mvo_> Chipaca: it was?
<Chipaca> because the [ was returning 2, but it was in an if, so the if was never true
<Chipaca> 2 == WTF
<mvo_> uff
<Chipaca> :)
<Chipaca> mvo_: gotta love shell
<Chipaca> on fridays
<mvo_> Chipaca: I do - with passion
<Chipaca> post beer o'clock
<mvo_> (and fire)
<Chipaca> :-D
<mvo_> Chipaca: :) beer o'clock - can't wait to see results from the PR
<Chipaca> mvo_: same
<Chipaca> mvo_: it failed before with errors in unrelated tests, of course
<Chipaca> anyway, off to put pizzas in the oven
<Chipaca> full friday mode here
 * zyga hugs Chipacaâs rational Friday mode
<zyga> Well
<zyga> I meant to say I hug chipaca because of the pizza really
<mup> PR snapd#5334 opened: tests: show executed tests on current system when a test fails <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5334>
<mup> PR snapd#5333 closed: tests: show status of the partial test-snapd-huge snap in econnreset test <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5333>
#snappy 2018-06-16
<mup> Bug #1777243 opened: Support system daemons ran as user <Snappy:New> <https://launchpad.net/bugs/1777243>
<binarycreations> Hi, is there someway to get a shell into a snap to inspect the container environment? I am trying to troubleshoot a snap I have created for the anki-desktop client.
<binarycreations> There are more details in a forum post (https://forum.snapcraft.io/t/help-required-packaging-anki-desktop-client-as-a-snap/5950) if you are interested. Thank you in advance for any help or advice given.
#snappy 2018-06-17
<mup> Bug #1777243 changed: Support system daemons ran as user <Snappy:New> <https://launchpad.net/bugs/1777243>
<mup> PR snapd#5335 opened: tests: fix for the download of the big snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5335>
#snappy 2019-06-10
<mborzecki> morning
<pstolowski> hey
<mborzecki> pstolowski: hey
<Eighth_Doctor> mborzecki: https://pagure.io/flock/issue/163
<mborzecki> Eighth_Doctor: hey, thanks for submitting the talk
<mborzecki> super simple https://github.com/snapcore/snapd/pull/6974
<Chipaca> no mvo today?
<mborzecki> Chipaca: he's off, and iirc pedronis too
<zyga> good morning
<zyga> mborzecki: reviewed
<mborzecki> zyga: hey, how was the trip?
<zyga> mborzecki: good, except that I arrived one day early
<zyga> and had no place to say :)
<mborzecki> haha
<zyga> yeah, all sorted out :)
<zyga> mborzecki: I sent some simple updates
<zyga> I'd love to get those reviewed
<zyga> I will try to get the  MS_SHARED bug fixed this week
 * zyga breakfast
 * Chipaca approves of all unscientific benchmarks
<zyga> re
<zyga> hey Chipaca
<Chipaca> zyga: 'sup
<zyga> Chipaca: all good, prepping for day one
<mborzecki> cachio: standup?
<Chipaca> cachio: poing
<Chipaca> :)
<zyga> standup at  9 :)
<zyga> net
<cachio> Chipaca, https://paste.ubuntu.com/p/Y33RS4h2n5/
<Chipaca> cachio: can you make tmp _not_ be tmpfs? is it worth it?
<cachio> Chipaca, the image is created like this
<cachio> by ubuntu-image
<cachio> should I try the same with tmp non tmpfs?
<Chipaca> cachio: it depends; do we care?
<Chipaca> cachio: that is: do we need the tests to run with 1.5G?
<cachio> Chipaca, well, when I started I used to create images with 1GB
<cachio> then I had to go to 1.5
<cachio> now 2GB
<Chipaca> cachio: hmmm
<Chipaca> cachio: you could try unmounting /tmp and seeing how it goes
<cachio> perhaps is becase the tests are getting more exhaustive
<cachio> Chipaca, sure
<Chipaca> cachio: or you could run 'df -h /tmp' when things fail to see how full it is
<cachio> Chipaca, sure
<kyrofa> Hey cachio, you around? My gcloud creds don't seem to be working for spread anymore, is that something you guys did?
<kyrofa> Cannot allocate google:ubuntu-16.04-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: 400 Bad Request
<cachio> kyrofa, no
<cachio> I don't manage creds
<cachio> let me check if works for me
<kyrofa> Thanks cachio
<cachio> kyrofa, works well for me, please contact niemeyer, he will know
<cachio> kyrofa, np
<kyrofa> Huh, lost connection there for a sec. niemeyer, I seem to have lost the ability to access our spread workforce on google, can you help me with that?
<cachio> Chipaca, https://trello.com/c/boGCGgOI/249-invesigate-2392-test-failure-in-beta-validation
<cachio> I uploaded 2 scripts there
<cachio> I am gonna test again with tmp non tmpfs now
<Chipaca> cachio: ok
<cachio> Chipaca, there is something weird
<cachio> Chipaca, it is loosing memory on each iteration
<Chipaca> i know the feeling
<Chipaca> cachio: you mean df is showing less and less space available?
<Chipaca> cachio: or what?
<cachio> I am using free
<cachio> and yes
<cachio> show less and less
<Chipaca> cachio: and what does df /tmp show?
<cachio> untils the vm hangs
<cachio> let me add this to the script
<cachio> Chipaca, running
<cachio> I'll show the output in a minutes
<cachio> minute
<cachio> Chipaca, https://paste.ubuntu.com/p/ztQjvZZ55S/
<ogra> ppisati, hey ho ... would it be possible to also get an arm64 build of the pc-kernel snap (we're having a snapcraft community boardfaet this week and it would be cool to be able to use the official kernel so people dont need to maintain their own hacked up ones)
<cachio> Chipaca, 100% free is /tmp
<ogra> ppisati, (afaik things like pine64 and such should work with that kernel OORB)
<ogra> *boardfest
<cachio> Chipaca, this is happening with the beta imge
<cachio> I'll try now with the stable image
<Chipaca> cachio: maybe also log 'top -n1 -c -o %MEM' ?
<Chipaca> cachio: or 'top n1 c o %MEM' if you want to confuse people (in top the - are optional)
<Chipaca> (because why not)
<cachio> hehe
<cachio> sure
<cachio> I ran a bit un stable and seems to be working much better but then autoreboot
<Chipaca> yay :-/
<ppisati> ogra: yep, i can make that happen
<pstolowski> sergiusens: hey
<sergiusens> pstolowski: hey, what's up?
<pstolowski> sergiusens: we'll have a small feature request for snapcraft.. allowing type:snapd for snapd snap
<ogra> ppisati, awesome !
<Chipaca> pstolowski: meanwhile doesn't passthrough work?
<pstolowski> Chipaca: maybe (i haven't tried). but proper support is where we want to be anyway, store is ready afaik, snapd will soon be ready too
 * Chipaca â runch
<pstolowski|afk> sergiusens: is this something you can add to your queue?
<pstolowski|afk> i need to go, please leave me a message
<cachio> Chipaca, https://paste.ubuntu.com/p/4mM5dM2GRF/
<cachio> this is the output
<cachio> Chipaca, it starts with 1.5GB of free mem
<cachio> ends with 100 MB of free memory
<Chipaca> cachio: something fun is going on, because that memory's just disappearing
<cachio> Chipaca, yes
 * Chipaca EODs
<Chipaca> ð
<sergiusens> pstolowski: for the legacy or new codebase? Is `base: none` a thing already?
<sergiusens> !query  roadmr
<roadmr> hu?
<roadmr> ð¤
#snappy 2019-06-11
<mborzecki> morning
<mborzecki> mvo: is it equally hot at your location? it's ~8am and 26 degrees in the shade
<mvo> mborzecki: its overcast here today so not hot yet
<mvo> mborzecki: we had this last week :/
<pstolowski> mornings
<mvo> hey pstolowski
<jamesh> pstolowski: hi.  I ran into a transient unit test failure in the "snap snapshot" tests, and it looks like you've had most involvement in them.  I filed https://bugs.launchpad.net/snapd/+bug/1832161 with the details
<jamesh> seems like the regexp should be adjusted to account for different amounts of white space
<pstolowski> jamesh: hi! thanks for the report, will investigate
<mborzecki> pstolowski: hey
<pstolowski> jamesh: https://github.com/snapcore/snapd/pull/6982 should fix i
<pstolowski> *it
<lss8> is there now a way to disable automatic snap update checks? I'd like to not auto update my snaps as I want to have control over my system and don't need automated updates
<lss8> Chipaca ^updates could introduce security issues or there might be malicious updates which I don't want to automatically apply to my stable system
<Chipaca> lss8: it seems like a rather poor strawman to me, if you trust the thing enough to install it, you trust it to refresh -- for any case where an update has introduced new vulnerabilities, there have been many that removed them
<Chipaca> lss8: unless as I say you're vetting for a large fleet of devices in which case fair enough and there are tools for that
<pstolowski> mborzecki: one question to #6980
<Chipaca> lss8: for a single device, even for a small handful, you won't have a person full-time vetting things
<lss8> Chipaca those are my personal servers and I do have time to run `snap refresh lxd` every once in a while
<Chipaca> lss8: at which point you're arguing that existing, known security vulnerabilities are safer than unknown new ones
<lss8> I just don't want LXD to update itself when the current release is perfectly stable for me
<Chipaca> lss8: you can control when the refresh happens, and how often
<Chipaca> lss8: you cannot turn it off
<lss8> but.. there's no way to completely turn it off?
<Chipaca> lss8: there is no way to opt in to being part of a botnet, no
<Chipaca> I wish the forum would close topics after a couple of months of inactivity
<Chipaca> six months later "I'm getting the same error: <a completely different error that shares one word (probably "the") with the original>"
<jamesh> Chipaca: I think https://github.com/snapcore/snapd/pull/6954 is mostly ready.  It ballooned in size a bit adding the Ubuntu Core support though.  I could split that out into a separate PR pretty easily though by cutting off the final four commits
<Chipaca> jamesh: I need to circle back to some reviews, yes, sorry for my delay
<Chipaca> jamesh: I'll take a look and let you know, re splitting
<jamesh> the Ubuntu Core support mainly involved installing the new unit files on core18 systems
<pstolowski> Chipaca: hey, do you have a moment for https://github.com/snapcore/snapd/pull/6982 ?
<Chipaca> pstolowski: sure
<pstolowski> Chipaca: ty!
<mborzecki> Chipaca: by the looks of it manjaro forums does close the topics after 90 days of inactivity, so maybe it's a configuration option or a feature of some newer version of discourse?
<Chipaca> mborzecki: sadly I am only a moderator, not an admin
<mborzecki> Chipaca: mhm, i know
<mborzecki> Chipaca: looks like discourse https://forum.manjaro.org/t/snapd-is-not-working-since-downgrade-to-systemd-239-6-2-2-advised-in-the-security-update-on-2019-01-19/73774/37 doesn't it?
<mborzecki> ha found the exact version even among <meta> tags: Discourse 2.3.0.beta11 - https://github.com/discourse/discourse version ace6ce046273799c866e85942182db7d77bed4d2
<mborzecki> we use: Discourse 2.0.0.beta10 - https://github.com/discourse/discourse version 30fbf6fe8181426ff8cab81d10a26c61f635f4d6
<jamesh> the downside of closing old topics is that people end up needing to start new topics about the same thing that lose all context from the old discussion
<jamesh> it's not always a new user incorrectly diagnosing their bug
<Chipaca> jamesh: true, and I may just be noticing the bad ones
 * Chipaca brb
<zyga> Good morning
<pstolowski> hey zyga
<Chipaca> #6958 could use another review
<zyga> hey pawel  :)
<zyga> how are you guys doing?
<pstolowski> zyga: the weather is unbearable here, i envy you ;)
<zyga> pstolowski: 16C
<Chipaca> mvo: I just realied I should've reopened #6582 and targeted it to 2.40; done that now (pending rob's confirmation)
<mvo> Chipaca: ok
<zyga> pstolowski: and it rains
<mvo> zyga: hey, how are you? how is the summit
<zyga> pstolowski: I kind of wish it would be not raining so much because the hotel keeps us hostage
<zyga> mvo: hey, good morning!
<mborzecki> pstolowski: it's getting worse https://i.imgur.com/6MJHkqC.jpg
<pstolowski> omg
<Chipaca> pedronis, mvo: https://paste.ubuntu.com/p/BCXRzjcX5V/
<Chipaca> magic
<cachio> mborzecki, pstolowski you feel like me now
<pstolowski> cachio: :)
 * cachio afk
<diddledan> update on centos  : "Job for var-lib-snapd-snap-core-6964.mount failed." See $insert-log-message-checking-message-here - updating 2.38.1 to 2.39.1
<mvo> Chipaca: heh
<mborzecki> diddledan: that's when the rpm snippets ran right?
<mborzecki> diddledan: keep in mind you need to reboot after the update
<zyga> mborzecki: o m g
<zyga> 41C
<mvo> zyga: where?
<zyga> mvo: in pl
<diddledan> thanks mborzecki
 * Chipaca takes a break
 * Chipaca does not miss 41Â°C weather
<diddledan> is this a bug? devmode classic confinement snaps seemingly don't inherit environment variables from the calling shell while in stable they do
 * cachio afk
#snappy 2019-06-12
<mborzecki> morning
<pstolowski> hey
<mvo> hey pstolowski
<mborzecki> mvo: pstolowski: hey
<mvo> hey mborzecki and pstolowski
<pstolowski> o/
<pstolowski> mvo: https://github.com/snapcore/snapd/pull/6879 has conflicts
<mvo> pstolowski: thanks, looking
<pstolowski> mvo: #6981 can land?
<mvo> pstolowski: yes, thank you
<pedronis> mvo: hi, this is fixed now https://bugs.launchpad.net/snapd/+bug/1819318 ? (by installing snapd)
<mvo> pedronis: yes, this is in *-proposed now
<mvo> pedronis: once it lands in -updates we can mark it as fix released
 * mvo double checks
<zyga> Hello
<mborzecki> zyga: hey
<mvo> hey zyga !
<mvo> zyga: how are you?
<Chipaca> was there a yaml-querying tool we were already using in tests? (if so, what was it?)
<Chipaca> like jq but for yaml i mean
<mborzecki> yq?
<Chipaca> mborzecki: going with that one
 * pstolowski lunch
<Chipaca> mborzecki: i thought there was a gustavo one
<Chipaca> anyway, tets running, time for coffee
<Chipaca> tests also running
<Chipaca> everything is running
<mborzecki> did we have any fixes in master recently for a case when spread test node runs out of space?
<mborzecki> https://github.com/snapcore/snapd/pull/6980 consistently fails in google:ubuntu-16.04-64:tests/cross/go-build:ppc64el, / is 100% in use
<pedronis> mvo: Chipaca: I wrote this:  https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769
<mvo> pedronis: thank you!
<Chipaca> pedronis: nice
<Chipaca> pedronis: I flagged you for reviewing the leave-cohort, but it's got two +1's so if you don't feel you need to review it i'll go ahead and land it
<pedronis> Chipaca: I'm taking the afternoon off for some errands but I will try to skim it quickly later today
<pedronis> I don't expect suprises
<pedronis> though
 * pedronis off for errands
<Chipaca> ok
<mvo> 6691 needs a second review
<pedronis> it has a conflict though
<mvo> oh, let me fix this
<mvo> thanks!
<Chipaca> pedronis: you suck at being off for errands
<mvo> hm, deviceMgrSuite.TestUpdateGadgetOnClassicErrorsOut seems to fail sometimes in chg.IsReady(), Equals, true
<mvo> is that known?
 * mvo looks into it
<pedronis> mvo: sorry, I looked at 6691, I have a silly remark
<pedronis> anyway it's seems a more general problem
<mborzecki> mvo: maybe there's too few iterations there
<mvo> mborzecki: yeah, fix should be trivial
<mvo> mborzecki: and pushed
<mvo> pedronis: thanks for the remark in 6691
<mvo> ondra: I fixed the conflicts in 6691 now, hopefully good to go now
<ondra> mvo thank you
<ondra> mvo just saw it, good times
<zyga> Hey
<zyga> Iâm good thank you!
<pstolowski> a trivial that could land, just needs 2nd look: https://github.com/snapcore/snapd/pull/6967
<niemeyer> kyrofa: What happen re. GCE?
<Chipaca> mvo: snap info 0ad
<mvo> Chipaca: \o/ 950mb
<pstolowski> mvo: did you get state.json for the missing 'current' symlink error?
<mvo> pstolowski: no reply yet afaict
<mvo> pstolowski: also no private mail
<mvo> pstolowski: does it die for you if you remove current?
<pstolowski> mvo: no. the error comes from patch subsystem, this code only kicks in under certain conditions (namely, when range of core revisions was found)
<pstolowski> mvo: the 4961 revision from the bug report falls into the range
<mvo> pstolowski: interessting
<mvo> pstolowski: there are two newer revisions though, I wonder what is going on
<mvo> pstolowski: but a patch would explain why it happens
<mvo> pstolowski: I wonder if the patch is buggy in general
<mvo> pstolowski: 4961 is 2.33.1+git822...
<mvo> pstolowski: aha, nevermind 4916 is 2.33.1
<mvo> pstolowski: I wonder if going from 2.33.1->current is an issue, might be worth a test, I can make 2.33.1 availalbe
<mvo> pstolowski: unless you already have ideas what might be the issue(?)
<pstolowski> mvo: not really, the main issue is obviously the missing symlink; state.json could give us answer why it's missing
<pstolowski> mvo: if you can make 4916 available it's certainly worth trying out
<mvo> pstolowski: its an armhf one, should I grab you the coresponding amd64?
<pstolowski> mvo: what is the revisions number of the corresponding one for amd64?
<mvo> pstolowski: 4917
 * cachio lunch
<pstolowski> mvo: good. ok, yes, amd64 would be preferred
<mvo> pstolowski: sure
<kyrofa> niemeyer, re: GCE, whenever I try to run spread using my gcloud creds I get this: Cannot allocate google:ubuntu-16.04-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: 400 Bad Request
<niemeyer> kyrofa: That looks like an issue with the request indeed
<niemeyer> kyrofa: Doesn't feel like something that was rejected based on permissions or something
<kyrofa> niemeyer, true. Not sure what's going on there
<zyga> mvo: strace is a bit borked
<zyga> I've seen it fail in various environments
<zyga> on ubuntu I see
<zyga> zyga@fyke:~/locale-experiment$ snap run --strace locale-experiment.locale
<zyga> /snap/strace-static/current/bin/strace: Unexpected wait status 0x8b
<mvo> zyga: oh - I have not seen this. what distro release? and what do you try to trace?
#snappy 2019-06-13
<mborzecki> morning
<mvo> good morning
<mvo> mborzecki: hey, what did I miss so far :)
<mborzecki> mvo: nothing :) i'm the only one online
<mborzecki> mvo: unless you want to do a quick pass on https://github.com/snapcore/snapd/pull/6995 ?
<mborzecki> mvo: as for the PR title check, what if we dumped the API and used beautifulsoup instead?
<mvo> mborzecki: oh, nice idea
<mvo> mborzecki: heh :)
<mvo> mborzecki: its old school
<mvo> mborzecki: scraping the web like its 1994 :P I like this
<mborzecki> mvo: all we need is the title
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mvo> pstolowski: good morning!
<mvo> mborzecki: yeah
<mborzecki> mvo: maybe the stdlib html parser would be enough even
<mvo> mborzecki: did you look at the html already? does it look "easy" (sih)?
<mborzecki> mvo: https://paste.ubuntu.com/p/PhwG32HG6Q/
<mvo> mborzecki: sweeeeeeeet
<mvo> mborzecki: thank you so much
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6995 ?
<pstolowski> sure
<mborzecki> pstolowski: thanks!
<mborzecki> mvo: remember the weird gadget.yaml from yesterday https://github.com/rpdeo/build-pine64-image/blob/a550cb83ba319b58042599c77548101146059386/snappy/gadget/meta/gadget.yaml ?
<mborzecki> mvo: ubuntu-image calculates exactly the same positions as our code does
<mvo> mborzecki: good!
<mvo> mborzecki: so no risk of regression here
<mborzecki> mvo: added a command to dump the info of a positioned volume https://paste.ubuntu.com/p/DSwjDP8zP3/ probably useful for debugging
<mvo> mborzecki: nice
 * mvo looks
<mvo> mborzecki: I updated the pr title check pr
<mborzecki> mvo: thanks, looking
<mvo> mborzecki: I used the python stdlib to avoid having to worry about pulling in the right dependencies (but that is debatable I guess)
<mvo> mborzecki: actually I think I can improve my split, its a bit too silly (probably does not matter much though
<mvo> mborzecki: let me do it anyway :)
<mborzecki> mvo: and there's ImportError due to lxml
<mvo> mborzecki: yeah, just noticed this as well, silly me
<mborzecki> mvo: wondering if there's a command line tool for web scraping
<mborzecki> mvo: ideally like curl .. | scrape '.head.title' | grep '<match>
<mborzecki> mvo: check this out: https://paste.ubuntu.com/p/8R4Wkgdsxs/
<mborzecki> mvo: this is the tool: https://github.com/ericchiang/pup
<mvo> mborzecki: interessting
<mborzecki> mvo: and the PR is green :)
<mvo> mborzecki: yay
<mvo> now if only the apparmor-id test would not fail :/
<mborzecki> appstream-id? :)
<mvo> yeah, in my other PR that is ready to land it failed, I suspect the store is not happy but I did not look further yet
<mvo> mborzecki: https://paste.ubuntu.com/p/6f2rsHBgyg/
<mborzecki> mvo: let me try to add some debug info there
<mvo> mborzecki: +1
<mvo> mborzecki: its a bit annoying that we actually have no idea what data we got beside "computer says NO"
<mvo> mborzecki: we saw failures there a couple of times so definitely useful work to add debug there
<mvo> a second review for 6691 would be great
<mvo> to unblock ondra on this level
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/6996
<mvo> mborzecki: thank you!
<mvo> mborzecki: do you think you can reply to "support parallel installs on desktop" in the forum? we want to do it but I am not sure where we stand right now (except that we want to do it :)
<mborzecki> mvo: mhm, started writing a reply in the morning, but never sent it
<mborzecki> mvo: the catch is the classic snaps & paralle installs, the guy mentions build tools, those would be classic usually
<mvo> mborzecki: yeah, eactly
<mvo> mborzecki: iirc we talked about some minimal fs namspacing around classic to support it(?)
<mborzecki> mvo: yes, iirc zyga started looking into it at some point
<mvo> mborzecki: ok, I can reply as well in this case, I had hoped you had some more details :)
<mborzecki> thunderstorm coming this way, might loose power for a while (hopefully not)
<mborzecki> on the upside, it's raining now
<pstolowski> mvo: state.json provided for yesterday's bug with current symlink. investigating
<mvo> mborzecki: good luck
<mvo> pstolowski: sweet, thank you
<mvo> pstolowski: please keep me updated
<pstolowski> sure
<mborzecki> and it's gone, rained for 10 minutes :/
<Chipaca> mborzecki: just enough to keep the humidity up \o/
<Chipaca> mborzecki: for if you weren't feeling the heat properly
<mborzecki> Chipaca: a taste of the tropics for $0
<mborzecki> anyone up for a review of this trivial PR https://github.com/snapcore/snapd/pull/6996 ?
<Chipaca> why would anybody include a .zip in a snap :-\
<Chipaca> mborzecki: WRT that PR, do you have an example run that failed?
<mborzecki> Chipaca: i think mvo is the last one to see it fail
<Chipaca> mborzecki: I suspect the debug info you want is already in the log, but want to confirm
<mborzecki> Chipaca: https://paste.ubuntu.com/p/6f2rsHBgyg/
<Chipaca> mborzecki: no, in 'debug output for â¦
<Chipaca> mborzecki: you should have the snapd.service logs
<mborzecki> Chipaca: sry, that's all we have, idk which PR that was
<Chipaca> ah
<mvo> Chipaca: one sec, I find it for you
<Chipaca> ta
<mvo> Chipaca: https://travis-ci.org/snapcore/snapd/builds/545102574?utm_source=github_status&utm_medium=notification
<mvo> Chipaca: in the ubuntu section
<Chipaca> mvo: mborzecki: 'context canceled'
<mborzecki> Chipaca: timeout on nc side perhaps?
<mvo> Chipaca: oh, so it might be a real bug?
<Chipaca> mvo: mborzecki: probably
<Chipaca> why is it using nc for this :-(
<Chipaca> http would be a much better tool
<Chipaca> or curl
<mborzecki> Chipaca: the test does `nc -U -q 5 /run/snapd.socket`
<mborzecki> Chipaca: heh i should fix that probably
<Chipaca> mborzecki: 1.949731ms after getting the request, nc hangs up
<mvo> ta
<Chipaca> k
<mvo> Chipaca: this area of the code actually changed, yes? in this pr its about adding context to SnapInfo
<mvo> Chipaca: I wonder if there is a side-effect here ./
<mvo> Chipaca: it is using the request.Context
<Chipaca> mvo: the side effect should be that now we see the error :)
<sborovkov> Hi, is there a simple way to bypass this apparmor denial? Does not work in devmode snap as well, and the app I am debugging crashes right after/
<sborovkov> apparmor="DENIED" operation="ptrace" profile="snap.network-manager.networkmanager" pid=1387 comm="NetworkManager" requested_mask="trace
<Chipaca> before snapd would've carried on waiting for the store, and tried to write the reply, to find that nc had gone away
<Chipaca> now we see the error as soon as it happens so we get to see the log, probably
<Chipaca> mvo: that's my hypothesis anyway :)
<mvo> Chipaca: heh, ok
<mborzecki> Chipaca: let's try with curl maybe
<Chipaca> mborzecki: k
<Chipaca> you get the same denial in devmode?
<Chipaca> sborovkov: ^
<sborovkov> Chipaca, yes
<Chipaca> sborovkov: how do you do that?
<sborovkov> screenly-client      1.9.0.0         x6    candidate  -               devmode
<sborovkov> I am not sure what actually does that
<sborovkov> I updated Qt
<sborovkov> now qt webkit crashes
<sborovkov> on core
<sborovkov> not on raspbian
<Chipaca> sborovkov: but that denial is not from the screenly snap, it's from networkmanager
<sborovkov> yes, but it seems lijke it's communicating with it?
<sborovkov> should I try installing network manager in devmode?
<Chipaca> sborovkov: give it a try
<mvo> Chipaca: if I change the context that theStore.SnapInfo() gets to context.TODO() the issue goes away. it looks like the http.Request has an (aggressive) cancel context so probably not a good idea to reuse it(?)
<Chipaca> mvo: what happens if you use curl instead of nc?
<sborovkov> Chipaca, is there a syntax to force it to devmode with the same version of the snap?
<Chipaca> sborovkov: unfortunately there is no 'snap switch --devmode', no
<Chipaca> sborovkov: but you can 'snap refresh --devmode thesnap'
<Chipaca> dunno if it'll do what you need though
<mvo> Chipaca: heh, seems to be working
<Chipaca> anyway, i gotta go, will bbi1h
<sborovkov> that won't work since it has no updates
<sborovkov> I will just download the binary and sideload it
<mvo> Chipaca: so your theory is correct
<Chipaca> sborovkov: i'd suggest asking on forum.snapcraft.io, as zyga and/or jdstrand might be the best people to look into this
<Chipaca> sborovkov: (and they might not be around at the same time as you)
 * Chipaca really steps away now
 * pstolowski lunch
<mborzecki> Chipaca: updated https://github.com/snapcore/snapd/pull/6996 to use curl now
<pedronis> Chipaca: could you answer this: https://forum.snapcraft.io/t/install-snaps-backup-or-export-and-relocation-to-new-pc/11777
<pedronis> it's also probably in the wrong category
 * Chipaca writes <BLINK> for the first time in ages
 * Chipaca goes to have a quick shower before the standup because this smell will travel over hangout
<jdstrand> pedronis: hi! I'm at the snapcraft summit and we discussed this topic and was wondering if you can comment on it soonish: https://forum.snapcraft.io/t/new-base-snap-nix-base/11787/2
<jdstrand> pedronis: I'm heading into a meeting, but can discuss via the forum or here. zyga can also speak to it
<kenvandine> zyga: I have a snap that's failing to update
<kenvandine> https://www.irccloud.com/pastebin/fWXYWFf1/error%3A%20cannot%20perform%20the%20following%20tasks%3A%20-%20Setup%20snap%20%22snap-store%22%20(111)%20security%20profiles%20(cannot%20setup%20mount%20for%20snap%20%22snap-store%22%3A%20cannot%20update%20mount%20namespace%20of%20snap%20%22snap-store%22%3A%20cannot%20update%20preserved%20namespace%20of%20snap%20%22snap-store%22%3A%20cannot%20update%20snap%20namespace%3A%20no%20such%20file%20or%20direc
<kenvandine> tory)%20-%20Setup%20snap%20%22snap-store%22%20(111)%20security%20profiles%20(cannot%20update%20mount%20namespace%20of%20snap%20%22snap-store%22%3A%20cannot%20update%20preserved%20namespace%20of%20snap%20%22snap-store%22%3A%20cannot%20update%20snap%20namespace%3A%20no%20such%20file%20or%20directory)
<kenvandine> that was noisy :)
<zyga> kenvandine: hey
<zyga> kenvandine: wow, that's indeed noisy
<zyga> kenvandine: I'm at an event now and I cannot  focus on this; two small requests please: does it fail on edge core/snapd snaps and if so, can you please file a bug with the details
<kenvandine> i have revision 117 installed and trying to refresh to 136
<kenvandine> ok
<zyga> thank you
<pedronis> jdstrand: I'll see what I can do, I skimmed and to be honest I was a bit confused by it
<kenvandine> zyga: fails with edge too.  See bug 1832725
<mborzecki> mkfs wrapper https://github.com/snapcore/snapd/pull/6997
<cjp256> any know of a method to fetch a snap from the store for arch different from the running system?
<Chipaca> cjp256: yes
<Chipaca> cjp256: UBUNTU_STORE_ARCH=i386 snap download core16 --edge
<cjp256> thanks chipaca! :)
<Chipaca> cjp256: (from my bash history)
<Chipaca> we should add an --arch, but, eh
<Chipaca> priorities
<zyga> kenvandine: thank you,
<Chipaca> I've just been called to the boys' school, need to run off
 * Chipaca runs off
<Chipaca> of course it was just when my tea was _perfect_
<zyga> kenvandine: can you perhaps send the the two revisions
<zyga> mvo: hey
<mvo> hey zyga
<zyga> mvo: do you want to sync quickly or are you find with waiting for next week?
<kenvandine> marcustomlinson couldn't reproduce it
<kenvandine> so it's something with my system
<kenvandine> i even removed snap-store, installed stable and tried refreshing to candidate
<kenvandine> blew up
<mvo> zyga: if you have anything important we can chat otherwise friday/next week is fine
<zyga> mvo: ok,
<zyga> mvo: just good news :)
<zyga> mvo: I posted a small PR https://github.com/snapcore/snapd/pull/6998
<mvo> looking
<zyga> we're building an image with those patches for testing
<zyga> jamie also posted on the forum about nixos base snap
<zyga> and if there's any confusion about that I'd love to clear it up (interactively)
<zyga> so that nix can continue
<zyga> mvo: manjaro will seed snaps on the iso
<zyga> mvo: I'd like to spend a moment with someone to walk me through snap prepare-image --classic
<mvo> zyga: manjaro switches to /snap from /var/lib/snapd/snap ? do we need to do anything about this transition?
<mvo> zyga: on our side I mean, or is that just handlded in the packaging?
<mvo> zyga: I mean when users upgrade
<zyga> mvo: yes, we do
<zyga> mvo: it's in the patch
<zyga> mvo: that's more tricky, I think this kind of transition is tough in general
<zyga> mvo: I think you need to remove and reinstall snaps
<zyga> mvo: I'd like to change how we probe distributions
<zyga> but it's not something we need this week
<kenvandine> zyga: http://people.ubuntu.com/~ken-vandine/snap-store.tar.bz2
<zyga> mvo: we're discussing the migration path
<zyga> we don't have a good story for migration
<mvo> ok
<zyga> mvo: we are working on a migration script
<zyga> kenvandine: thank you
<mvo> zyga: ok
<pedronis> zyga: what's the question about prepare-image --classic ?
<zyga> pedronis: I'd like understand how to use it
<zyga> pedronis: so that manjaro can use it correctly to preseed the snap store stap
<pedronis> zyga: it's relatively straighforward, it might not do the right thin yet if you have only core18 snaps though, and you need to specify all bases and all content providers and a model
<zyga> pedronis: we only want to seed the snap-store snap
<zyga> so if you walk us through that that would be amazing
<Chipaca> mvo: d'oh, did /v2/download _just_ miss out on having context from day 1
<zyga> right now we (I learned) use a shell implementation of prepare-image that Wimpress shared
<zyga> and I'd be much more comfortable with the proper approach
<pedronis> zyga: something like this (ATM):  https://pastebin.ubuntu.com/p/9fm4p6Rvy9/
<zyga> looking
<pedronis> as I said atm is fetching core instead of snapd
<mvo> Chipaca: :/ I think so
<zyga> pedronis: does it fetch generic.model?
<Chipaca> mvo: (d'oh)Â³
<zyga> or do we need to get it somehow
<pedronis> zyga: no
<pedronis> that is like for core
<zyga> how can we get it?
<pedronis> zyga: snap known model on a ubuntu system for example
<pedronis> or they can make a model
<pedronis> but for that they need brand account and keys
<zyga> pedronis: do you recommend that  they make a model?
<zyga> we could do that
<pedronis> if they want and are comfortable managing the keys
<zyga> could you or someone else walk us through the process?
<pedronis> zyga: they need a brand account if they really want this, I would chat with your store person there
<zyga> that's what we will do
<zyga> once we have that, what else do we need
<noise][> +1 for them to have a distinct model
<pedronis> create a key,  register it, backup ~/.snap/gnupg
<zyga> pedronis: we'll work with daniel
<zyga> pedronis: and then we need to craft a model file?
<zyga> I'm not familiar with that process
<pedronis> there should be instructions around
<pedronis> given that is for classic it needs the bare minimum
<pedronis> like our generic one
<Chipaca> zyga: you there?
<zyga> Chipaca: yes
<Chipaca> zyga: https://forum.snapcraft.io/t/request-for-a-base-snap-for-godot/11808/5?u=chipaca
<Chipaca> zyga: i don't understand
<Chipaca> zyga: maybe i'm missing something
<Chipaca> zyga: you were there, maybe there's more context than is stated in the post, that i'm missing?
<Chipaca> or maybe there's something i'm ignorant of
<zyga> Chipaca: I can explain over a call?
<Chipaca> zyga: wfm
<zyga> pedronis: do we need a vault?
<zyga> pedronis: or can we keep authority-id as generic?
<pedronis> ah
<Chipaca> zyga: https://meet.google.com/fbb-gvae-mda?authuser=1
<pedronis> forgot about
<pedronis> that
<pedronis> so no
<pedronis> they should just use generic
<pedronis> they would need a vault otherwise
<zyga> oh
<zyga> hmmm
<pedronis> we cannot sign serial for them
<pedronis> by definition
<zyga> I understand
<Chipaca> zyga: i'll go make tea then
<zyga> Chipaca: stanndup
<zyga> or meet
<zyga> https://meet.google.com/wmp-dfwj-jdt?authuser=0
<cmatsuoka> mvo: I have a few unpushed recovery fixes (written in airport & plane), will test and push tonight after the event
<mvo> cmatsuoka: please do, I get errors that partition 4 cannot be created right now
<cmatsuoka> mvo: hmm, current HEAD was supposed to be functional (at least able to create everything and install), I'm running prepare on a new directory to see what's happening
<zyga> pedronis: quick question: can we today create a snap that can be content shared by anyone but is not published by canonical?
<zyga> pedronis: the use case is the godot runtime support snap for anyone publishing games via godot
<pedronis> zyga: yes, it's a matter of setting up the right snap-declaration
<pedronis> that's how we do it also for canonical snaps
<zyga> excellent, thank you
<zyga> CC Chipaca ^
<zyga> we were just discussing that and wanted to double check with you
<Chipaca> zyga: pedronis: ah! good, phew
<Chipaca> zyga: pedronis: for some reason i was still stuck in the 'publisher is the same, or is "canonical"' world
<Chipaca> glad that's moved on :)
<mvo> cmatsuoka: thanks! its a bit cryptic, the error just says "Could not create partition 4 from 23606048 to 3920448" no reason why is given :/
 * cachio afk
<pedronis> Chipaca: for content, canonical is not special I think, it's really same publisher or overriden by the declaration
<cmatsuoka> mvo: will check that and report back as soon as I have everything downloaded and built
 * Chipaca goes for a walk
<mvo> cmatsuoka: thank you, I will have dinner and check back
<mvo> cmatsuoka: looks like my core-build checkout was not in the writable-ramdisk PR
<mvo> cmatsuoka: eh, branch, let me try to figure out why
<cmatsuoka> mvo: oh ok that explains the problem
<mvo> cmatsuoka: yeah, sorry for the noise
<cmatsuoka> mvo: still building here, slow network and slow cpu
<cmatsuoka> mvo: the recent fixes are related to extracting the kernel and initrd from the snap
<mvo> cmatsuoka: thanks
<cmatsuoka> mvo: so recovering using a different kernel version was still booting with the original kernel (I didn't notice because in my tests I used the same kernel in both recoveries)
<cmatsuoka> mvo: to go through the entire recovery cycle selecting a different recovery version you'll also need the pc gadget on writable-ramdisk to recognize a new "recovery_reboot" snap mode
<mvo> cmatsuoka: I merged/uploaded your pc-gadget changes to 20/edge
<cmatsuoka> this can be handled in a different way but that was the least intrusive one (but still required some changes in the grub configuration)
<cmatsuoka> mvo: ah nice, thanks
<mvo> cmatsuoka: I'm cleaning my dir now to ensure I have all the right checkouts now
<pedronis> have the re-reg managers_test test passing, need some cleanups though (and a likely a couple follow ups)
<jdstrand> pedronis: do you have a moment to talk about nix-base?
<pedronis> jdstrand: I read the description more carefully, it seems ok if a bit of a degenerate (as used in math terminology) case
<zyga> mvo: do we use snapd snap by default nonw?
<jdstrand> pedronis: nix is quite unique in that nix packages ship only the libs they need and everything is mounted under /nix
<jdstrand> pedronis: so there is nothing needed in there. hence the analogy to static binaries and the bare base snap
<jdstrand> pedronis: anyhoo. can you comment in the forum that you are ok with it?
<cmatsuoka> mvo: the re-prepared version worked here to install, didn't try recover yet
<pedronis> jdstrand: do you know why it needs the /nix directory in it, we don't let layout create directories at that level?
<jdstrand> pedronis: the ayouts feature does not allow creating toplevel directories under /
<pedronis> ok
<jdstrand> pedronis: it is a limitation of the implementation
<pedronis> jdstrand: it would be good if the topic mentioned this for clarity
<jdstrand> I can add that detail
<jdstrand> pedronis: done
<jdstrand> pedronis: it isn't clear if you approve this (I haven't approved the snap due to this discussion)
<pedronis> jdstrand: sorry, it took a bit to understand where the comment was added, I added a comment myself
<jdstrand> pedronis: thanks!
 * Chipaca EODs
<mvo> zyga: we don't auto-transition people yet but if you only have core18 we install it
<mvo> cmatsuoka: yeah looks good
<albertosottile> jdstrand: hi, any chance you could review our answer in the Syncplay classic confinement request topic?
<jdstrand> albertosottile: I commented in the topic. It is now moving forward and there is one more step (publisher vetting; cc popey_ and Wimpress)
<jdstrand> https://forum.snapcraft.io/t/classic-confinement-request-syncplay/11189/12
<albertosottile> jdstrand: understood, thanks. Please let me and Et0h know if we can assist in any way during the vetting
<popey_> albertosottile: done
<albertosottile> popey_: thanks!
<popey_> no problemo
<jdstrand> albertosottile: granted. please see the forum comment
<albertosottile> jdstrand: thank you :) We will submit another revision asap
<jdstrand> albertosottile: cool. sorry it took so long. it was a bit of a different use case for classic and we wanted to make sure we considered everything
<jdstrand> albertosottile: thank you for your patience :)
<albertosottile> jdstrand: I totally understand
<albertosottile> We also wanted to ask for an alias for a syncplay-server command, is now the right time to do so?
<jdstrand> albertosottile: yes. that will go quickly. please make a request in the forum
<albertosottile> Sure
<albertosottile> jdstrand: https://forum.snapcraft.io/t/alias-request-syncplay-server/11821
#snappy 2019-06-14
<sincere_fox> Hello
<sincere_fox> I just installed an electron app via snap and I get this error https://pastebin.com/63MfH8NH
<mborzecki> morning
<mborzecki> Chipaca: mvo: morning guys
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski and mborzecki
<mborzecki> have you seen https://forum.snapcraft.io/t/new-base-snap-nix-base/11787 ?
<mvo> yeah, its very cool
<mborzecki> on the same note, wodner if any help is needed here: https://forum.snapcraft.io/t/base-runtime-freedesktop-sdk-runtime-19-08/11153/
<mborzecki> would that enable a flatpak to be repacked as snap and vice versa?
<mvo> mborzecki: I think so
<mvo> mborzecki: or at least flat->snap it seems, not sure about the reverse but having a common base seems to be sensible
<Chipaca> mborzecki: morning
<mvo> pstolowski: mup is still down :( I pushed a tiny PR to not error if "current" is missing in "patch"
<mvo> pstolowski: please have a look, maybe its too naive
<mvo> hey Chipaca, gooood morning :)
<Chipaca> :)
<mborzecki> anyone up for some mkfs magic? https://github.com/snapcore/snapd/pull/6997
<mborzecki> or i shoudl say mkfs/mtools
<pstolowski> mvo: thanks. i've been thinking about what to do about that.. looking
<mvo> pstolowski: again, maybe too naive but I think we don't want to fail
<mvo> mborzecki: I like your idea about the symlink /snap to avoid the full cost of switching in the majaro case
<mborzecki> mvo: i'm bit afraid this would break when poeple grab snapd from AUR
<mborzecki> mvo: which they have done in the past :/
<mvo> yeah
<pstolowski> mvo: okay, i think it's fine, let me comment in the PR
<mvo> pstolowski: \o/
<mvo> pstolowski: thank you
<pstolowski> mvo: added comments
<mvo> pstolowski: thanks, makes perfect sense
<mvo> mborzecki: looking at your mkfs stuff now
<mborzecki> mvo: ta
<mvo> mborzecki: its actually short, I like that
<pstolowski> mvo: thanks for the change, one more remark for the test change you made
<mvo> pstolowski: thanks, looking!
<mvo> pstolowski: indeed, very good point
<mvo> pstolowski: thank you!
<pstolowski> ty!
<mborzecki> usual issues https://www.reddit.com/r/linux/comments/c07mp1/ubuntu_devs_testing_chromium_browser_transition/ snaps are slow, themes, auto refresh etc
<mvo> mborzecki: some ideas for your PR  looks great overall
<mvo> gentle ping about 6691, it needs a second review
<pstolowski> mvo: #7000, what a milestone! :)
<mvo> pstolowski: indeed, 7k PRs its slightly crazy
<Chipaca> mvo: does brave work for you?
<mvo> Chipaca: it used to work
<mvo> Chipaca: I can try again, shall I use the script from my gist?
<mvo> Chipaca: or just deb/snap?
<mvo> Chipaca: what release of ubuntu?
<Chipaca> mvo: nah, just tell me if the snap's app runs
<Chipaca> here it dies
<Chipaca> but i'm on xenial
<Chipaca> wondering if it's universally broken or what
<Chipaca> (it complains about the sandbox)
<Chipaca> wait, drat
<Chipaca> it does work
<Chipaca> hmm hmm
<mvo> Chipaca: aha, ok. its still installing here :)
<Chipaca> mvo: maybe i just needed to install it with assertions once for it to pick up the connections
<Chipaca> :)
<mvo> ok
<pstolowski> grr @go-flags
<Chipaca> pstolowski: no why?
<Chipaca> now*
<Chipaca> mvo: grr @ snaps that do a bunch of copying stuff around on first run :-/
<Chipaca> on an HDD, that's nearly a whole minute waiting for the window
<Chipaca> impressive
<Chipaca> s/nearly/more than/
<Chipaca> brave:none:596299776:69398:3087:2707
<mvo> Chipaca: ohhhh, so thats the reaon?
<mvo> Chipaca: reason?
<mvo> Chipaca: its the copying of stuff not actually anything else?
<Chipaca> that's SNAP:MODE:SIZE:START:START2:WALK
<mvo> Chipaca: I'm very happy I asked you to look at this :)
<Chipaca> is 69 seconds for first run, 3 seconds for 2nd (from an empty cache)
<mvo> Chipaca: is that perf output?
<Chipaca> that's my script output
<Chipaca> one line of it
<mvo> Chipaca: *nod*
<Chipaca> an evolution of yours :)
<mvo> Chipaca: nice find, out of curisoity, what is it copying around?
<Chipaca> running it on my laptop with its blazing fast ssd, this wasn't noticeable
<Chipaca> bah, a little: 6s to 4s or something like tht
<Chipaca> on the gaming computer that has HDD homes, the above
<Chipaca> anyway, will push the script and the results in a bit
<Chipaca> i don't have zstd though so somebody else needs to run those to get that
<Chipaca> (where is zstd supported?)
<mvo> Chipaca: I can build you a sqaushfs-tools with zstd
<mvo> Chipaca: its only available in git ./
<Chipaca> mvo: will my kernel know how to mount it?
<mvo> Chipaca: how do things compare to "on squashfs vs on ext4"? that is the most interessting one to me :)
<mvo> Chipaca: thats a xenial kernel? I can check, iirc zstd in kernel was done way before squashfs-tools supported it (which is kinda-ironic)
<mvo> Chipaca: 4.1.4
<Chipaca> xenial here, bionic on the hdd
<mvo> Chipaca: so should be in xenial, let me double check
<Chipaca> CONFIG_SQUASHFS_ZSTD=y â bionic
<Chipaca> nothing like that in xenial
<mvo> meh, ok
<Chipaca> gnome-calculator:try:16560272:4577:3320:391
<Chipaca> gnome-calculator:xz:4218880:4120:2904:328
<Chipaca> mvo: ^ ext4 vs xz-compressed squashfs
<Chipaca> about the same
<Chipaca> (granted g-c is small)
<mvo> Chipaca: silly me, misread - its 4.14 so no luck for you
<mvo> Chipaca: niiiiiiiiiiiiiiice
<mvo> Chipaca: I think that is a really good find
<mvo> Chipaca: well, second run is with hot cache?
<Chipaca> mvo: https://paste.ubuntu.com/p/82p3BFzwD9/
<Chipaca> mvo: no, both drop caches
<Chipaca> mvo: second run is without whatever the snap does on first run
<mvo> Chipaca: \o/
<mvo> Chipaca: you rock
<mvo> Chipaca: this data looks very encouraging
<Chipaca> mvo: https://gist.github.com/chipaca/2efec6e9d89cadada6478d8a010c5c2e
<pedronis> Chipaca: what are you actually trying?  me is a bit confused here
<Chipaca> pedronis: the effect of different compression options of squashfs on the speed of apps in a snap
<mvo> pedronis: we talked yesterday that one of the open questions is how much overhead squashfs/xz is compared to ext4. I had some concerns about this from measurements on brave (and from feedback from the advocy team)
<pedronis> mvo: talked when?
<Chipaca> day before yesterday i think
<Chipaca> pedronis: you were off
<mvo> pedronis: do you have concerns about this ?
<pedronis> mvo: multiple, mostly process ones
<mvo> pedronis: as in "not the right time"?
<pedronis> yes, also is untracked
<pedronis> also it's hard for me to help if I don't have context
<pedronis> mvo: if I look at trello I wouldn't know John is working on this
<mvo> pedronis: meh, sorry then. I updated the trello to have some info on it. also its hopefully not a long task, ~1d or so. but happy to talk some more during the standup and address concerns
<pedronis> or that it was started at all
<mvo> pedronis: yeah, my bad, let me fix this
<mborzecki> Chipaca: https://paste.ubuntu.com/p/wd3YjtbWbW/
<pedronis> mvo: is John also working on https://trello.com/c/mwEvN8Hk/237-squashfs-install-performance-fuse-sucks ?
<pedronis> or just the one you moved to WIP
<Chipaca> pedronis: i am not working on that one
<pedronis> ok, I thought you were
<pedronis> that's why I was also confused
<Chipaca> pedronis: we did talk about that i was working on this yesterday in the standup
<pedronis> I understood as the other one
<pedronis> funnily enough
<pedronis> we did talk about lxd, no?
<Chipaca> pedronis: i mentioned that tangentially i suggested the unpack-on-install approach as a global flag and that might be a solution to the fuse thing
<pedronis> that's the other thing though
<pedronis> so my confusion
<mvo> pedronis: indeed, now it all makes sense. sorry for the confusion
<Chipaca> heh
<Chipaca> pedronis: this was one of the things that distracted me a bit from working on the benchmarking script itself (which is now done for now)
<Chipaca> that, and people being wrong on the internet
<mvo> Chipaca: heh :) I think we should write a forum post and maybe igor from advocacy can make it into a blog post). also would be nice to figure out what brave is doing, ideally we could suggest a fix to them (but timeboxed, lets not get dragged into a rathole :)
<mvo> Chipaca: anyway, very happy with these numbers
<Chipaca> mvo: http://paste.ubuntu.com/p/PVS5shj2QZ/
<Chipaca> mvo: that's 'find ~/snap/brave' after first run, starting from it being empty
<Chipaca> mvo: it's 37MB big
<Chipaca> (so not big enough to justify how long it takes to do it)
<mvo> Chipaca: thanks! its probably also doing some sort of generation for this data. oh well
<Chipaca> mvo: desktop-launch
<mvo> Chipaca: oh? snap run --trace-exec brave should give us some clues about this
<Chipaca> ok let me do that on the slow box :)
<mvo> Chipaca: i need to get lunch now, will read backlog
<mvo> Chipaca: thank you!
<Chipaca> pedronis: you ok with landing #6978 then? i'm not sure, from your comments
<Chipaca> mvo: https://paste.ubuntu.com/p/sw3wGxgWzk/ (spoiler: it's update-mime-database)
<mborzecki> off to pick up the kids
<pedronis> Chipaca: ?
<pedronis> Chipaca: no, need to have a pass, mostly about those switch summary messages
<Chipaca> ok
<pedronis> Chipaca: made my main comments
<pedronis> Chipaca: I understand they from no channel came before, but given we are touching all of them it's a chance to improve that
<Chipaca> yep
<Chipaca> pedronis: but
<Chipaca> pedronis: can i address it in a followup?
<pedronis> Chipaca: worried about conflicts ?
<Chipaca> pedronis: wanting to get the pr that exposes all these things (with spread test) up
<Chipaca> and it's stacked on this one
<pedronis> ah, ok
<pedronis> Chipaca: ack that in the PR
<pedronis> *acked
<mborzecki> re
<pedronis> mvo: pstolowski: made a comment on #7000
<pstolowski> pedronis: thanks, thinking about it right now
<pedronis> pstolowski: also we have a bigger problem, what if snapd comes from snapd
<pedronis> but you have core installed
<mvo> pedronis: thank you, in a meeting right now but will look at it once that is over
<pstolowski> pedronis: right.. this logic predates snapd snap.. the reset only happens for level 6 under these conditions, and patches should be idempotent though
<pstolowski> pedronis: nb, we have 2 other issues i found that led to all this, we can discuss before/after standup
<pedronis> pstolowski: yes, the problem is that we wouldn't run them though
<pedronis> because snapd will be updated before core maybe
<pedronis> but we look at core
<pedronis> (not sure it depends on ordering issues)
<pstolowski> pedronis: hmm i see
<zyga> hey everyone
<zyga> last day
<pstolowski> hey zyga! how is it going? tired?
<zyga> it's been a fantastic week
<zyga> lots of really amazing results
<zyga> I strongly recommend reading the forum summary
<pstolowski> zyga: yep i saw the tweets etc
<zyga> https://forum.snapcraft.io/t/snapcraft-summit-montreal-2019-day-1-2-3/11763/5 <- for anyone interested
<zyga> pstolowski: building firefox out of nixos packages in ~10 lines == mind blown
<zyga> a little tired :)
<zyga> but it's 14C here so I cannot complain
<zyga> how was the week back home?
<pstolowski> zyga: insanely hot.. with thunders yesterday afternoon, so a little relief
<zyga> I'm off for breakfast, ttyl
<vladoski> I'm trying to install Heroku via snap, but everytime gets stuck on this and fails: error: cannot perform the following tasks:
<vladoski> - Run configure hook of "heroku" snap if present (run hook "configure": execv failed: Permission denied)
<Chipaca> vladoski: strange
<Chipaca> vladoski: what snap is it?
<Chipaca> d'oh, "heroku"
<vladoski> Chipaca: yep it's heroku
<Chipaca> vladoski: looks like a buggy snap
<Chipaca> vladoski: do you have /snap/bin ?
<vladoski> ahm, so what should I do?
<vladoski> Chipaca: yes
<vladoski> I have 4 snaps in it
<Chipaca> vladoski: what's the output of 'snap version'?
<vladoski> snap    2.39.1-1.fc30
<vladoski> snapd   2.39.1-1.fc30
<vladoski> series  16
<vladoski> fedora  30
<vladoski> kernel  5.1.8-300.fc30.x86_64
<vladoski> Chipaca: that's the output
<Chipaca> mborzecki: ^ ?
<vladoski> I'm using Fedora 30 if it helps
<vladoski> oh nvm it was in the log ahah
<Chipaca> vladoski: yeah, mborzecki has been looking at issues on fc30 which is why i'm asking him to take a look
<Chipaca> just in case it's a known issue / known workaround
<mborzecki> vladoski: it's aknown problem, we have a fix for it and it's in fedora src repo already, we just need to update the package
<Chipaca> huzzah
<vladoski> Yes I know that snap is a little buggy now with fedora, one week ago I had to remove it because it was giving problems with battery status, function keys and system errors
<mborzecki> wondering if zyga or Eighth_Doctor could fedpkg build a new package maybe?
<Eighth_Doctor> for what?
<mborzecki> vladoski: you can temporarily switch selinux to permissive, setenforce 0, install the snap, and then setenforce 1
<mborzecki> Eighth_Doctor: snapd
<Eighth_Doctor> oh the fixes you sent in yesterday, right?
<mborzecki> Eighth_Doctor: yup :)
<Eighth_Doctor> I'll fedpkg build them now
<Eighth_Doctor> only reason I didn't was that I thought mvo was going to release 2.39.3 with that fix integrated
<Chipaca> Eighth_Doctor: hmm, yesterday mvo in the standup decided not to do a .3, and have it be distro-patched, so we could move on to .40
<mborzecki> Eighth_Doctor: i think we'll do 2.40, let me double check with mvo
<Chipaca> Eighth_Doctor: we dropped the ball on letting you know
<Eighth_Doctor> welp
<mborzecki> ah, missed that
<Chipaca> mborzecki: was that a "mvo should have told you to communicate that"?
<mvo> meh, sorry, did I fail at doing this?
<zyga> mborzecki: next week at earliest
<mborzecki> Chipaca: nope, i should have picked that up myself :P
<Eighth_Doctor> I guess I'll update to 2.39.2 and push it
<mborzecki> so basically, /me dropping the ball :)
<Chipaca> mborzecki: yes but mvo should've double-checked :)
<Chipaca> <--> etc
 * Chipaca lazy
<mborzecki> Eighth_Doctor: that last 2 patches are not in .2, so please apply those separately
<Eighth_Doctor> will do
<mborzecki> Eighth_Doctor: great, thank you!
<Eighth_Doctor> they're building now
<Eighth_Doctor> zyga, mborzecki: I've been thinking that for Fedora snaps, we should look to plug into the modularity toolchain
<Eighth_Doctor> instead of trying to beat snapcraft into working
<Eighth_Doctor> I'm tired of trying to figure out how to make snapcraft do what I want, and getting the modularity toolchain to do it would make it possible for Fedora contributors to officially build and submit snaps
<mborzecki> ha
<mborzecki> Eighth_Doctor: sounds like what the nix guys did
<zyga> Eighth_Doctor: I have the exact same feeling this week
<Eighth_Doctor> and like the flatpaks/ namespace we have in Dist-Git, we could have a snaps/ one for people to make snap modules
<zyga> Eighth_Doctor: it is the most direct way to get the right things to happen
<zyga> Eighth_Doctor: oh, btw, I asked the godot deveoper to go to flock
<Eighth_Doctor> yeah
<zyga> his work on using fedora in snaps is amazing
<Eighth_Doctor> which one?
<zyga> and it  is really an eye-opening experience as to why this is done this way
<zyga> Eighth_Doctor: godot stack, including games, are all built from fedora bits
<zyga> Eighth_Doctor: but the story there is much deeper
<Eighth_Doctor> nice!
<Eighth_Doctor> I knew that at least one godot dev liked the fedora stack :)
<Eighth_Doctor> and that would be an awesome surprise to put into our presentation at flock: https://pagure.io/flock/issue/163
<Eighth_Doctor> zyga, mborzecki: https://src.fedoraproject.org/projects/flatpaks/*
<Eighth_Doctor> I want exactly the same thing for snaps
<mborzecki> cachio: https://github.com/snapcore/snapd/pull/7004 this should work (works locally in xenial vm), i'll try to run one of nested core tests
<Eighth_Doctor> zyga: I'm pretty close to having a new simple tool for producing a base snap
<Eighth_Doctor> there's a few things I'm changing up so that it works in a decently portable way across rpm distros without baking too much logic into it for that
<Eighth_Doctor> but also the part I don't know is uploading snaps properly without requiring snapcraft
<Chipaca> siiiiigh
<Chipaca> home isn't auto-connected on core, right?
<Chipaca> siÂ³Â³gh
 * Chipaca fixes the spread test
<cachio> mborzecki, nice
<cachio> i'll try it
<mborzecki> cachio: i'm trying google-nested:ubuntu-16.04-64:tests/nested/core/hotplug
<zyga> Chipaca: correct
<cachio> mborzecki, nice, I integrated that to the PR #6892 and I am running on 18.04 and 16.04
<cachio> I'll tell you how it works
<Eighth_Doctor> zyga, mborzecki: bodhi updates proposed
<Eighth_Doctor> F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-17c0fb9ce6
<Eighth_Doctor> F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-91c0be0cc5
<Eighth_Doctor> EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-502ed76053
<Eighth_Doctor> I need testing and karma
<mborzecki> Eighth_Doctor: great, thank you!
 * Chipaca reckons Eighth_Doctor should have enough karma to launch a spaceship, at this point
 * Eighth_Doctor snorts
<mborzecki> vladoski: you should be able to get a working version from updates-testing repo once it's there ^^
<vladoski> mborzecki: okay thanks!
 * cachio afk
 * zyga is extremely sleepy and tired
<zyga> sorry everyone
<zyga> Eighth_Doctor: some more attention on the update, thank you for working on this !
<abeato> jdstrand, hey, I have a couple of minor updates to interfaces waiting for review: https://github.com/snapcore/snapd/pull/6962 and https://github.com/snapcore/snapd/pull/6975
<juliank> I recently realized that snapped browsers break integration with KeePassXC, because it uses some native messaging thingy
<juliank> but I'm not sure what could be done about that
<pedronis> pstolowski: I reviewed #6960
<juliank> Apparently this is super nasty stuff, where the browser invokes a binary on the host
<juliank> e.g. https://developer.chrome.com/extensions/nativeMessaging
<pstolowski> pedronis: ty
<cachio> pstolowski, when you have some time could you please take a look to #6892
<pstolowski> cachio: oh yes, looking now
<cachio> pstolowski, thanks
<pstolowski> cachio: so the problem with assertion disk & snapshot remains unresolved, right? no problem with the workaround, just curious, did Maciej have any other ideas?
<cachio> pstolowski, no new ideas so fat
<cachio> far
<cachio> I juest tested the change on how assertions disk is created
<cachio> and works very well
<cachio> I'll wait Maciej reply before merging this PR
<pstolowski> cachio: ok, +1 from me
<cachio> pstolowski, nice, thanks
 * cachio lunch
 * cachio afk
#snappy 2019-06-15
<David99> Hello, I have a question: I'm currently running clear linux (I know it's not oficially supported, sorry if it is a problem) and I want to install snapd. I can install from the repos the dnf package manager, but it has no repos enabled. Is there some fedora/RHEL style repo which I could enable that has snapd in it?
<zyga> sergiusens: https://bugs.launchpad.net/bugs/1832858
#snappy 2020-06-08
<mborzecki> morning
<mborzecki> mvo: hi, there's a typo in https://github.com/snapcore/snapd/pull/8822 that static checks choke on
<mup> PR #8822: release: 2.45.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8822>
<mvo> mborzecki: meh, ok
<mvo> mborzecki: thank you, will fix
<zyga> hey guys
<mborzecki> zyga: hey
<zyga> hey
<mborzecki> zyga: how is your back?
<zyga> thinking about how to say it
<zyga> f*** uP?
<zyga> not good for sure
<mborzecki> zyga: sad to hear that
<mvo> hey zyga - good morning
<zyga> hey mvo
<pstolowski> morning
<mvo> hey pstolowski - good morning
<mup> PR snapd#8804 closed: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8804>
<mup> PR snapd#8815 closed: tests: port snap-handle-link test to tests.session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8815>
<zyga> thanks mvo!
<mvo> zyga: thank *you*
<zyga> mvo: MRI on Wednesday at 15:00
<zyga> so before then I'm working from bed
<mvo> zyga: ok
<mup> PR snapd#8825 opened: tests: move a few more tests to snapstate_install_test <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8825>
<zyga> https://github.com/snapcore/snapd/pull/8826
<mup> PR #8826: tests: assorted small patches <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8826>
<zyga> pstolowski: +1
<zyga> heh
<mup> PR snapd#8826 opened: tests: assorted small patches <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8826>
<zyga> I've seen so many tasks that never get a ping back from travis
<zyga> mvo: perhaps it is time to drop travis from the "required" list?
<zyga> the only thing left is the CLA check
<pstolowski> zyga: ty!
<mvo> zyga: I guess we could remove it totally, yes?
<zyga> mvo: I would keep it for a while because IIRC mborzecki wanted to do some changes to the CLA checker
<mborzecki> anyone remember whether time-control only works if you use timedatectl?
<zyga> and having a 2nd guess would be better
<zyga> mborzecki: as in the interface?
<zyga> mborzecki: let me look
<zyga> mborzecki: it's literally defined as such but perhaps that's a bit too tight
<zyga> mborzecki: what kind of extra permissions do you think it should grant?
<mborzecki> zyga: there's https://forum.snapcraft.io/t/access-to-bin-date-in-strict-confinement/18041 but the reporter gets EPERM (so likely not caused by AA)
<zyga> mmm
<zyga> how does date set time
<zyga> clock_settime or something like that?
<mborzecki> zyga: strace tells met it's clock_settime
<zyga> so a seccomp filter is probably what needs changing
<zyga> IMO it's sensible
<mborzecki> yup
<mborzecki> ok, let me open a PR and mark it for security review
<zyga> thanks
<zyga> maybe tweak the spread test in the PR as well
<zyga> I think we have one
<zyga> mvo: there was a question about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1881350 and release to groovy
<mup> Bug #1881350: snap seeding fails with libc6-lse <snapd:Fix Committed by zyga> <glibc (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1881350>
<zyga> do you think it's better to do 2.45.1 or just a distro patch?
<pedronis> pstolowski: mborzecki: hi, when you have time, could you re-review #8702 (it follows my suggestions, I think, now)
<mup> PR #8702: overlord/configstate: add system.kernel.printk.console-loglevel option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8702>
<mborzecki> pedronis: sure, will do
<pstolowski> pedronis: sure
<pedronis> thx
<mvo> zyga: I uploaded to groovy already
<zyga> ah, fantastic
<mvo> zyga: and it's there already (i.e. autopkgtest passed)
<zyga> mvo: my daughter doesn't recognize me :)
<zyga> mvo: she's scared when she sees me now
<mvo> zyga: haha - oh boy
<mvo> zyga: but you *do look different'
<mborzecki> zyga: shaved your beard?
<zyga> yep
<mborzecki> so we no longer poke jamie, but rather set 'needs security review' tag?
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8827
<mup> PR #8827:  interfaces/builtin/time-control: allow POSIX clock API <Needs security review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8827>
<zyga> mborzecki: yes
<zyga> done
<zyga> mborzecki: any weird things happen when you change the time?
<zyga> perhaps that test should be invoked via a time namespace?
<zyga> just to make sure it affects the system less
<mup> PR snapd#8827 opened:  interfaces/builtin/time-control: allow POSIX clock API <Needs security review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8827>
<mborzecki> zyga: it gets restored in the test, the ntp should slowly update the clock
<mborzecki> zyga: btw. do any of the systems have a kernel that supports time ns already?
<zyga> mborzecki: yeah, I think 20.04+ should be fine
<mborzecki> iirc it's in 5.6
<zyga> it was a added a while ago
<zyga> or maybe I read the patch a while ago :D
<mborzecki> it's automatically a part of new uts ns right?
<pedronis> mborzecki: mmh, that PR is not using the file I thought it should use
<zyga> mborzecki: no, I donât think it is
<mborzecki> pedronis: 99-snapd.conf?
<zyga> Uts is a separate ns
<pedronis> mborzecki: yes, actually the code is confusing
<pedronis> why is it mentioning 10-console-messages.conf
<pedronis> I see it has both
<pedronis> I asked a question there now
<mborzecki> zyga: https://kernelnewbies.org/Linux_5.6#Time_Namespaces hmm my version if unshare is unaware of CLONE_NEWTIME
<pedronis> mborzecki: I'm not sure why it bothers with 10-console-messages.conf at al
<pedronis> it should just write an empty 99-snapd.conf, no?
<pedronis> or remove it
<mborzecki> pedronis: aiui it reloads the old/default setting
<mborzecki> so it's applied now, rather than on the next reboot
<pedronis> I see, feels fragile
<pedronis> maybe we should just sysctl --system all the time
<pedronis> if there's a change
<pedronis> mborzecki: I commented about that
<mborzecki> pedronis: hm yes, that's an option, i think one could argue if you tweak something at runtime, it could get overwritten
<pedronis> mvo: what's the state of this: https://bugs.launchpad.net/snapd/+bug/1867415 ?
<mup> Bug #1867415: Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs <rls-ff-incoming> <snapd:New for mvo> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1867415>
<mvo> pedronis: this is fixed, let me update the bug
<mvo> pedronis: oh, let me see, someone claims it's not
<pedronis> mvo: yes, exactly, that's why I'm asking
<mvo> pedronis: I will try to reproduce now
 * mvo is downloading
<mup> PR snapd#8828 opened: tests: clean up up the use of configcoreSuite in the configcore tests <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8828>
<abeato> tianon, hey, are all interfaces used by the docker snap actually needed? I was looking into a way to restrict what the snap can do
<zyga> is the store under load?
<zyga> error: cannot get snap sections: cannot sections: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/sections"
<zyga> pedronis, mborzecki: tracking broken out as a separate PR https://github.com/snapcore/snapd/pull/8829
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<zyga> I chose to bundle ConfirmSystemdServiceTracking in the same PR as that function itself is tiny and completes the picture as to how this is meant to be used
<zyga> this is half of the large PR now and contains really just the logic to create a transient scope, along with unit tests
<zyga> I didn't add the spread tests as those would pull in virtually everything from the original
<mup> PR snapd#8829 opened: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<zyga> the design was reviewed by jamie and he gave a +1 on the original PR
<pedronis> zyga: mvo: this has a lot of back and forth by you but no priority or status != new: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1873004
<mup> Bug #1873004: lxd interaction blocked until snapd was restarted <lxd (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1873004>
<zyga> pedronis: yes, I think this is a duplicate of an existing issue that was investigated but not fixed earlier
<zyga> pedronis: I will look at launchpad to find the other report
<zyga> pedronis: it _looks_ like snapd starts before we mount snaps, and if core is mounted after snapd, this will happen
<zyga> (no interfaces)
<zyga> ah wait
<zyga> wrong bug
<mvo> oh, is that a dupe of the one andy had on friday ?
<zyga> I looked at the other tap
<zyga> *tab
<zyga> no no, sorry let me read the correct link
<zyga> hmm
<zyga> hmm
<zyga> mvo: I don't have any more ideas for that bug
<zyga> the frequency seems to suggest it is related to core reloading
<zyga> er, refreshing
<pedronis> mborzecki: bit confused by the rename to UpdateBootScript, not sure how it helps with confusion with InstallBootConfig
 * zyga prepares the next segment 
 * zyga takes a break from writing and reads https://github.com/snapcore/snapd/pull/8675/files
<mup> PR #8675: osutil: add disks pkg for associating mountpoints with disks/partitions <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8675>
<mborzecki> pedronis: i'm thinking about https://github.com/snapcore/snapd/pull/8775#discussion_r434505499 bot end up named grub.cfg, so maybe grub.cfg and recovery/grub.cfg?
<mup> PR #8775: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>
<pedronis> mborzecki: should we have a chat before the standup about the grub scripts?
<mborzecki> pedronis: now or later?
<pedronis> mborzecki: can do in 5 min?
<mborzecki> pedronis: sounds fine
<pedronis> mborzecki: going to the standup
 * mvo hugs pstolowski for 8828
<pstolowski> mvo: thanks for the review & suggestions!
 * zyga needs a break
<zyga> man, you have kids and they are at home
<zyga> but when *everyone* just comes to the same room
<zyga> and the dog too
<zyga> and then everyone starts moving
<zyga> it's a bit too much
<pedronis> zyga: I commented/asked some question in #8573
<mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
<mup> PR snapd#8830 opened: bootloader: introduce bootloarder assets, import grub.cfg with an edition marker <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8830>
<zyga> Thank you!
<mup> PR snapd#8831 opened: tests: use configcoreSuite in journalSuite and remove some duplicated code <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8831>
<pedronis> pstolowski: I did a pass on #8812
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pstolowski> pedronis: great, thank you!
<pedronis> some high-level questions/comments
<mup> PR snapd#8722 closed: tests: check that host settings like hostname are settable on core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8722>
<pedronis> zyga: does #8829 need a security review?
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<zyga> pedronis: I think jamie could indicate if he needs to review it again but my understanding it he gave this a +1 already
<zyga> if he has the time for a quick look to decide if a deeper look is necessary
<zyga> that would be okay
<zyga> jdstrand: ^
<mup> PR snapd#8832 opened: travis.yml: removed, all our checks run in GH actions now <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8832>
<clmsy> is it possible to try core20 out without updating kernel or its a no go
<clmsy> i set the gadget to use 20 and left the kernel snap 4.4.x (core16 kernel) i guess its normal that i cant use to build an image this way
<pedronis> clmsy: core20 needs a new model assertion syntax and new initramfs, because of  the latter an old kernel will not work as is
<clmsy> thx pedronis!
<ogra> popey, gitea just exploded in my face ... seems it sets a versioned SNAP_USER_DATA everywhere in its app.ini instead of using the /current link so after an update it cant access its data anymore ...
<ogra> (fixing app.ini manually to use the symlink everywhere foxes the app and it starts again)
<ogra> *fixes
<zyga> uh
<pedronis> zyga: dbusutil/dbustest/stug.bo needs a blankline before package  atm the copyright is the doc comment of the package
<zyga> ah, thanks
<zyga> I didn't check that
<pedronis> I have a check, but it's a bit hacky, maybe we should add to run-checks anyway
<pedronis> mborzecki: I did a pass on #8830, mostly naming
<mup> PR #8830: bootloader: introduce bootloarder assets, import grub.cfg with an edition marker <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8830>
<mborzecki> pedronis: thanks!
<popey> ogra i am on vacation, do feel free to provide feedback upstream (which publishes the snap)
<mup> PR snapd#8833 opened: sandbox/cgroup: remove redundant pathOfProcPidCgroup <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8833>
<ogra> popey, will do, thanks ... enjoy your vac.
<mup> PR snapd#8834 opened: dbusutil/dbustest: add separate license from package <Simple ð> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8834>
<cachio> mvo, I created a PR for skip
<cachio> #8835
<mup> PR #8835: POC:  skip binary to stip tests in an easy way <Proof of concept> <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8835>
<mvo> cachio: thank you! looking now
<cachio> mvo, this is to address this https://github.com/snapcore/spread/pull/72
<mup> PR spread#72: Run condition <Blocked> <Reviewed> <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/72>
<mborzecki> pedronis: cmatsuoka: i can take a look at making some of the exported gadget code private tomorrow morning
<mborzecki> the updaters, device lookup, filesystem image cuold all be private
<mup> PR snapd#8835 opened: POC:  skip binary to stip tests in an easy way <Proof of concept> <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8835>
<mborzecki> we did not agree on what to do with the code what was introduced for the tool that could build images, or did we?
<cmatsuoka> mborzecki: ack, thanks!
<mup> PR snapcraft#3164 closed: cli: remove enable-ci command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3164>
<mup> PR snapd#8836 opened: sandbox/cgroup: add tests for ParsePids <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8836>
<zyga> hmmm
<zyga> not that many spread tests are in flight
<zyga> mvo: I wonder if it would help if we also ran unit tests in self-hosted runners
<zyga> after all, the worker is really mostly idle apart from waiting for network IO from spread
<mvo> zyga: works for me
<zyga> mvo: I somewhat worry about RAM usage though, not sure how much our test suite takes
 * zyga checks
<zyga> mvo: I'll experiment with some PRs later
<zyga> mvo: I think now we're waiting for unit tests to pass to run spread and have more spread capacity than unit test capacity
<mvo> zyga: yeah, makes sense
<zyga> hmm, actually, my view was stale 32 spread jobs in flight
<zyga> so perhaps that would not win much
<zyga> exactly at capacity
 * zyga breaks for lunch
<pedronis> mborzecki: I commented on the name of the assets get function again
<mborzecki> nice, i like assets.Internal
<mup> PR snapd#8398 closed: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8398>
<mup> PR snapd#8800 closed: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open - 2.45 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8800>
<zyga> mborzecki: what is the word "edition" used for, is it like "version"?
<mborzecki> zyga: yeah, in the same feel as edition in gadget.yaml
<zyga> ah
<zyga> I forgot we have that
<ijohnson> zyga: what versions of opensuse would you say are supported by snapd?
<zyga> 15.1 and tumbleweed
<zyga> but .45 is not out there yet as I had issues with auth
<zyga> (the package is ready for a while, I just need to return to it)
<jdstrand> zyga: with PR 8829, is that broken out from PR 7825 unmodified? if so and you didn't change anything (significant, ie, algorithm or implementation-wise) in this part of the code, then I don't need to re-review
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> jdstrand: there are way more tests
<jdstrand> tests are great :)
<jdstrand> others can review those
<jdstrand> variable renames, equivalent/simple refactoring, also not needed in this go code
<zyga> jdstrand: and there's a new helper that checks for the cgroup of a service (using an existing helper but technically the function is new) - it is on line https://github.com/snapcore/snapd/pull/8829/files#diff-4706d268ffa8aa3999d09cac05b3ced2R110
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<jdstrand> s/not needed/don't need a security review/
<zyga> you may want to eye that if you want, I included it here because in all cases we call either the new CreateTransientScope or the new ConfirmSystemdServiceTracking
<jdstrand> that function is fine and using a reviewed-already api
<jdstrand> zyga: well, if you feel that my cursory glance missed something and you want me to review, please add the needs security review tag
<zyga> jdstrand: I think this is okay, I really don't think there's anything security related here
<zyga> and there's no new design
<zyga> just broken out code
<zyga> tests
<zyga> and some moving around to different packages to fit the structure better
<jdstrand> yeah, that is what it looked like
<jdstrand> I mean, yes, we need to have the design and code for this feature reviewed, but we did that extensively in PR 7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> yes, this is my understanding as well
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8830#pullrequestreview-426362895
<mup> PR #8830: bootloader: introduce bootloarder assets, import grub.cfg with an edition marker <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8830>
<zyga> man I was up for like 30 seconds
<zyga> and it hurts for a few minutes now
<roadmr> ouch zyga  :(
<zyga> yeah, this is not a good time
<mup> PR snapcraft#3162 closed: tests: remove scenario usage from lifecycle order <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3162>
<mup> PR snapcraft#3163 closed: cli: remove the hidden inspect command <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3163>
 * cachio lunch
<pedronis> zyga: I wrote a quick mail about /usr/lib/snapd
<zyga> pedronis: checking
<zyga> pedronis: I like this a lot
<zyga> let me think a little about it and draft something for tomorrow
 * zyga goes to rest for a while, putting the laptop away
<mup> PR snapd#8827 closed:  interfaces/builtin/time-control: allow POSIX clock API <Needs security review> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8827>
<Saviq> anyone else seeing snaps unstable on travis today? I'm getting a lot of failed lxd snap installsâ¦
<tianon> abeato: I guess that depends on what you want to "lock down" -- "privileged", "home", and "removable-media" are definitely optional, but the others are all related to core functionality of Docker you'd have to go out of your way to not use IIRC
<zyga> Saviq: we actually moved away from travis *today*
<abeato> tianon, I actually tried removing "privileged", but get into some problems when starting dockerd
<abeato> it was some permission for sysfs
<Saviq> zyga: lucky
<zyga> Saviq: maybe store load?
<Saviq> could be, there's very little info on what went wrong, suggesting to look at the journalâ¦
<tianon> abeato: ahh, I can reproduce -- that's definitely related to the mitigations in 19.03.11 for CVE-2020-13401 (open /proc/sys/net/ipv6/conf/docker0/accept_ra: permission denied)
<abeato> tianon, yeah, it was that
<tianon> abeato: that one's technically something that has to be updated in the snapd "docker-support" profiles, IIRC (not something we can fix in the Docker snap directly, AFAIK)
<abeato> tianon, I see, is it something that will be fixed eventually?
<ijohnson> tianon: o/
<ijohnson> tianon: I am just now running into the same issue for `/proc/sys/net/ipv6/conf/docker0/accept_ra`
<tianon> abeato: I *think* it'll require a PR to https://github.com/snapcore/snapd/blob/269ced7c4f31bbd912f73cba822f522244da16d5/interfaces/builtin/docker_support.go, since the denial is likely apparmor
<ijohnson> tianon: is the right fix to just allow that in the policy?
<tianon> :D
<tianon> yeah
<ijohnson> ok, let me see maybe the docker snap should just be using network-control instead?
<tianon> it has that already, doesn't it?
<ijohnson> I don't remember if network-control provides for that access or not
<tianon> ah, it has network and network-bind but not network-control
<ijohnson> tianon: yeah I think network-control should give access to that sysfs thing
<tianon> https://github.com/snapcore/snapd/blob/269ced7c4f31bbd912f73cba822f522244da16d5/interfaces/builtin/network_control.go#L84-L93 it does appear so :)
<ijohnson> tianon: you will need to add network-control to the plugs for dockerd, then we will probably need to get the assertion for the docker snap updated to allow auto-connection of network-control
<ijohnson> tianon: can you start a new forum topic on forum.snapcraft.io about granting network-control to the docker snap and ping jdstrand ?
<tianon> sure thing :)
<ijohnson> thanks tianon
<abeato> tianon, ijohnson thanks
<mup> PR snapd#8834 closed: dbusutil/dbustest: separate license from package <Simple ð> <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8834>
<ijohnson> tianon: fyi I just finished testing adding the network-control interface to the docker snap locally and it fixed that issue so that should be all that's needed, we shouldn't need interface changes to docker-support I think
<ijohnson> tianon: but let's see how the forum topic goes
<tianon> nice :D
<tianon> https://forum.snapcraft.io/t/auto-connect-docker-to-network-control/18054?u=tianon :)
<ijohnson> tianon: great, and just to be clear the docker snap does allow capability net_raw in the apparmor policy, so I think it is theoretically possible for that CVE to affect the snap
<ijohnson> tianon: though I'm not sure how well the docker snap supports specifying different capability sets for the container
 * ijohnson has never tried it
<tianon> ijohnson: yeah, the snap is absolutely affected by that CVE -- not sure if it goes all the way to the host level, but certainly cross-container (and likely *is* able to send RAs to the host)
<ijohnson> tianon: ok, yeah so we should try to get this fixed asap then, also how does the mitigation work, as I tried to reproduce the issue where the docker snap couldn't write to that sysfs file in a VM but it worked fine, presumably because the networking in the VM was different?
<ijohnson> err the networking setup in a VM is different from a real machine is what I meant
<jdstrand> roadmr: hey, can you pull 20200608-1642UTC ?
<ijohnson> because I see it on a real machine but not on VM's
<tianon> ijohnson: the mitigation disables accepting IPv6 RA (by writing to that sysfs value) on brdige devices Docker creates (which wouldn't be changed in a VM vs on a physical host); your VM might have had IPv6 completely disabled, in which case the mitigation wouldn't be necessary (that sysfs file wouldn't exist at all)
<tianon> ijohnson: https://github.com/moby/moby/compare/v19.03.10...v19.03.11 is pretty small (just the mitigation patch)
<tianon> ijohnson: reading that patch, your VM might have something like "failed to read ipv6 net.ipv6.conf.<bridge>.accept_ra" as a warning in the dockerd logs
<ijohnson> hmm it seems that my VM has ipv6 enabled, but still the docker snap is able to run
<ijohnson> perhaps that accept_ra was already disabled in the VM
<tianon> hmm
<tianon> maybe
<tianon> but it writes it whether it's disabled or not
<ijohnson> yes, I wonder if there's not a default bridge set somehow?
<ijohnson> hmm so on a fresh focal VM, I have /proc/sys/net/ipv6/conf/default/accept_ra set as "1"
<tianon> ijohnson: given the current positive direction of that thread, I should upload an update with network-control to edge right? :)
<ijohnson> tianon: yes please
<ijohnson> tianon: I assume when jdstrand or some other store admin gets a chance they will process the auto-connection
<ijohnson> tianon: but also iirc you should be able to just push a new version with network-control to edge, and that will be installable, but folks won't have it magically work without running manually `snap connect docker:network-control` but after the auto-connection is issued then that will magically work
<tianon> ijohnson: right :)
<ijohnson> tianon: while not really relevant anymore since you got auto-connect, I debugged a bit more in the VM and I think the bug is only when docker snap is upgraded and the old version of that bridge didn't have the ipv6 disabled, I think that when this version of the docker snap is installed fresh it just creates the bridge with that disabled
<ijohnson> but maybe I'm missing something else
<ijohnson> s/ipv6 disabled/ipv6 RA packet things/
<tianon> interesting
<tianon> well, FWIW, the commit is pushed; as soon as launchpad gets around to it, it should be in edge :)
<ijohnson> great thanks!
<jdstrand> tianon: we have the votes now but normally we wait 7 days for reviewers to comment. is this an emergency?
<tianon> jdstrand: I'd defer that to ijohnson -- I don't think it's an emergency, but it is preventing folks from using the "docker" snap without privileged enabled
<jdstrand> tianon: the current docker snap or one in edge/etc?
<jdstrand> and by current, I mean 'stable'
<ijohnson> jdstrand: tianon: I don't know that I'd call it an emergency, but I do think it is urgent since the current docker snap on stable is somewhat broken for existing installations and I don't think it's reasonable to revert to the previous one, as the previous docker snap suffers from that critical CVE
<tianon> stable
<ijohnson> jdstrand: but folks can "un-break" their installs by refreshing to edge and then manually connecting network-control
<jdstrand> ijohnson: so, stable already has network-control?
<ijohnson> jdstrand: the critical CVE being https://nvd.nist.gov/vuln/detail/CVE-2020-13401
<ijohnson> jdstrand: no, only edge has network-control
<ijohnson> as per tianon's commit today
<jdstrand> ijohnson: but stable and edge have the fix, and you want to promate something with network-control to stable?
<ijohnson> well actually edge may not have it yet, I have not looked at the lp builders status to see if they built it or not
<jdstrand> promote*
<jdstrand> and by fix, I mean the cve fix
<ijohnson> ah
<ijohnson> so that CVE is currently fixed on all channels of the docker snap
<jdstrand> ok, but it regressed in certain ituations
<ijohnson> yes
<jdstrand> gotcha. ok, I'll fast track it
<ijohnson> thanks jdstrand
<jdstrand> ijohnson, tianon: done
<ijohnson> nice thank you
<tianon> thank you!
<tianon> now if I could just figure out why the snap has intermittent build failures on launchpad that I can't reproduce locally...  /o\
<roadmr> jdstrand: hi! certainly - will put it in the queue.
<mup> PR snapd#8826 closed: tests: assorted small patches <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8826>
<zyga> jdstrand: not urgent but small: mvo requested a 3rd review of a test you wrote that I modify: https://github.com/snapcore/snapd/pull/8803
<mup> PR #8803: tests: port interfaces-many-core-provided to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8803>
<roadmr> jdstrand: fun, looks like those 2.45 base declaration changes broke a few store tests :)
<jdstrand> roadmr: oh? was network-status one of the special ones that was used in the testsuite?
<roadmr> jdstrand: yep, looks like it
<roadmr> jdstrand: f.ex I had it in an EXPECTED_DENIED_CONNECTION_INTERFACES list but it's not in that category anymore
<roadmr> (because its deny-connection: true got removed)
<jdstrand> roadmr: it looks like you could use mir instead
<roadmr> jdstrand: thanks! I'll for sure replace with that if needed
<jdstrand> roadmr: yes, network-status is no longer denied, for sure
<roadmr> jdstrand: some of the tests just check the interface categories generically so should cope with me moving network-status out of the EXPECTED_DENIED list
 * jdstrand nods
<roadmr> jdstrand: it's also no longer in EXPECTED_APP_PROVIDED_SLOT_INTERFACES as it's now provided by core
<roadmr> jdstrand: so all the changes seem to make sense; I'll probably tag you in the MP for a sanity check
<roadmr> none of this looks controversial in any case
<jdstrand> happy to look at it, but your assessment is correct
<jdstrand> afaics
<jdstrand> (from way over here :)
<roadmr> jdstrand: osram-dp2i-avahi is indeed in a brand store O_o they should file a support case
<jdstrand> roadmr: ok, I responded to say to file a support case
<roadmr> makes sense
<roadmr> thanks!
<mup> PR snapd#8825 closed: tests: move a few more tests to snapstate_install_test <Test Robustness> <Created by stolowski> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8825>
<roadmr> jdstrand: https://code.launchpad.net/~roadmr/software-center-agent/+git/software-center-agent/+merge/385315 for when you have a min - no rush, I'm out of runway today but will check back tomorrow :)
<mup> PR snapd#8831 closed: tests: use configcoreSuite in journalSuite and remove some duplicated code <Test Robustness> <Created by stolowski> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8831>
<mup> PR snapcraft#3165 opened: Update cmake plugin to use more modern flags <Created by GamePad64> <https://github.com/snapcore/snapcraft/pull/3165>
#snappy 2020-06-09
<mup> PR snapd#8837 opened: Add an activates-on property to apps to support D-Bus activation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8837>
<mup> PR snapd#8838 opened: tests: fix the basic20 test for uc20 on external backend <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8838>
<mborzecki> morning
<mup> PR snapd#8833 closed: sandbox/cgroup: remove redundant pathOfProcPidCgroup <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8833>
<mup> PR snapd#8836 closed: sandbox/cgroup: add tests for ParsePids <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8836>
<mup> PR snapd#8838 closed: tests: fix the basic20 test for uc20 on external backend <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8838>
<mborzecki> mvo: hey
<mup> PR snapd#8828 closed: tests: clean up up the use of configcoreSuite in the configcore tests <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8828>
<mvo> good morning mborzecki
<mborzecki> mvo: can you cherry pick https://github.com/snapcore/snapd/pull/8827 to 2.45?
<mup> PR #8827:  interfaces/builtin/time-control: allow POSIX clock API <Needs security review> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8827>
<mvo> mborzecki: sure thing
<mborzecki> mvo: and we can probably land https://github.com/snapcore/snapd/pull/8822 the tests failed with `error: cannot get snap sections: cannot sections: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/sections"`
<mup> PR #8822: release: 2.45.1 <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8822>
<mvo> mborzecki: cherry-picked, thank you
<mborzecki> mvo: thanks!
<mvo> zyga: re the "too early for operation" error, I seem to only see this in the uc20 prepare, did you see tihs on other suites as well?
<zyga> Yes, i saw it in Ubuntu 20.04 as well
<zyga> Good morning
<mup> PR snapd#8822 closed: release: 2.45.1 <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8822>
<mborzecki> zyga: hey
<zyga> Hey, sorry to be up so late. A bit sleepy still. I could not sleep well
<mborzecki> heh, funny, spread discards the node that failed suite level prepare?
<zyga> it's day two but my little daughter is still very reluctant to approach me
<zyga> I guess I need to find a xmas beard and glue it first :)
<mborzecki> oh, and it's not possible to restart old gh action jobs
<mborzecki> there's no restart workflow button for the cla check job in https://github.com/snapcore/snapd/pull/8620
<mvo> zyga: anything other than 20.04? core20 is also 20.04 based, I wonder if it's only a 20.04 issue for some strnage reason
<mup> PR #8620: spdx: add GPL-3.0-or-later license <â Blocked> <Created by prabhu> <https://github.com/snapcore/snapd/pull/8620>
<mborzecki> (it las ran more than a month ago tho)
<zyga> mvo: no, nothing apart from 20.04 or core20
<zyga> mvo: it is weird, because we *wait* for seeding
<zyga> so what could it be?
<zyga> perhaps seeding "succeeds" with an error
<zyga> and then we carry on and hit this
<zyga> could we fail seeding due to incorrect time somehow? (but I strongly doubt this)
<zyga> mvo: since it always fails on that line
<zyga> mvo: perhaps we should add a patch that shows snap changes and other stuff
<zyga> mvo: I will send a patch for that shortly
<zyga> jamesh: thanks for splitting out https://github.com/snapcore/snapd/pull/8837
<mup> PR #8837: snap: add an activates-on property to apps for D-Bus activation <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8837>
<jamesh> zyga: no problem.  I think there's more that can be split out on top of that.
<mborzecki> zyga: mvo: what if there's a problem talking to the store, does this require poking the store to get some serial number?
<zyga> yes, I think this is a good approach to landing large branches, as there's realistically much more review for small branches than there is for large ones
<zyga> mborzecki: I don't know what would happen, my expectation is that when wait seed returns you are good to go
<zyga> mborzecki: and we don't block installing snaps when you are not registered
<jamesh> detecting existing ActivatesOn conflicts with existing snaps could probably be done on top of this PR
<zyga> jamesh: small comment https://github.com/snapcore/snapd/pull/8837/files#r437174750
<mup> PR #8837: snap: add an activates-on property to apps for D-Bus activation <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8837>
<mvo> zyga: I like the idea of showing snap changes and snap tasks --last=seeding
<mvo> zyga: I'm looking at the code right now, trying to understand this
<mvo> zyga: I will try to write a small reproducer
<zyga> mvo: do you want me to send patches or will you?
<mvo> zyga: if you have it ready please do, otherwise I can do it. but I try to write a reproducer first I think
<zyga> not ready yet, I'll defer to you then
<mvo> zyga: ta
 * zyga tries to drink coffee then
<pedronis> mvo: hi, the strange failures logs in #8832 doesn't seem to tell much,  it doesn't seem to trigger debug logs?  we need to add more logging, I started at the code some more yesterday and still unsure what is happening, it seems 20.04 only
<mup> PR #8832: travis.yml: removed, all our checks run in GH actions now <Precious Logs> <Simple ð> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8832>
<pedronis> s/started/stared/
<pedronis> mvo: also afaict this started appearing only last week? I wonder what changed
<mvo> pedronis: yeah, it's pretty new
<pstolowski> morning
<zyga> good morning pedronis, pstolowski
<zyga> pedronis: I think it started more than a week ago
<zyga> pedronis: at least ~ 2 weeks to be safe
<zyga> maybe it increased in frequency, maybe just bad luck
<mvo> or !luck :P
<zyga> I think we all agree we need more data
<zyga> back in 15 min
<mvo> hrm, hrm, I wrote a script that does what prepare.sh is doing in a loop and of course it is not failing. depressing
<zyga> mvo: are you testing locally?
<mvo> zyga: in qemu
<mvo> zyga: but yeah, "locally"
<mvo> zyga: from my desktop machine
<mup> PR snapd#8839 opened: tests: add debug for 20.04 prepare failure <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8839>
<mvo> zyga: do you happen to have an example failure on a 20.04 sytem (not core20)? if not, no problem, I will go over the existing failure
<zyga> let me look quickly...
<mvo> pedronis: are you happy with 8808 in principle (i.e. making the settle timeout a function etc)? if so I can help dimitri to land it (unless it requires design changes)
<pedronis> mvo: let me make a precise suggestion
<mvo> pedronis: \o/
<mvo> pedronis: thank you
<pedronis> mvo: https://github.com/snapcore/snapd/pull/8808#issuecomment-641090791
<mup> PR #8808: riscv64: bump timeouts <Created by xnox> <https://github.com/snapcore/snapd/pull/8808>
<mvo> ta
<pedronis> mvo: and https://github.com/snapcore/snapd/pull/8808#issuecomment-641092197
<mup> PR #8808: riscv64: bump timeouts <Created by xnox> <https://github.com/snapcore/snapd/pull/8808>
<pedronis> mborzecki: hi, +1 to #8830 with some final suggestions
<mup> PR #8830: bootloader: introduce bootloarder assets, import grub.cfg with an edition marker <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8830>
<mborzecki> pedronis: thanks
<mup> PR snapd#8832 closed: travis.yml: removed, all our checks run in GH actions now <Precious Logs> <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8832>
<mborzecki> quick errand, back in 30
<mup> PR snapd#8840 opened: tests: move try-related tests to snapstate_try_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8840>
<mup> PR snapd#8839 closed: tests: add debug for 20.04 prepare failure <Test Robustness> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8839>
<mborzecki> re
<pstolowski> pedronis: i'm working on addressing comments to #8812; moving all this to servicestate means no backend abstraction layer for services and calling wrappers directly, makes sense?
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pedronis> pstolowski: yes correct, then in the tests in snapstate if needed you do the same thing we do for ifacestate stuff
<pedronis> or at least something similar as needed
<pedronis> but not sure this will be used immediately in snapstate?
<pstolowski> pedronis: i think the tests i've in this PR need to be moved entirely to servicestate
<pedronis> yea, I think my comment is relevant only for when we'll move start/stop-snap-services but that's not an immediate issue
<pstolowski> pedronis: and changed, because i cannot use fakebackend anymore
<pedronis> pstolowski: I really don't have a strong opinion, you an use whatever work best for the tests
<pstolowski> pedronis: ok, thanks
 * pstolowski lunch
<ackk> hi, any idea why snap is reporting error: cannot install "q": invalid instance name: invalid snap name: "q" if I "snap install q" ?
<ogra> does anyon know if /dev/shm/snap.$SNAP_NAME/foo can be the endpoint of a content interface (for sharing a crypto function between two snaps)
<ackk> (also "snap info q" doesn't find anything)
<pedronis> ackk: we don't support single letter snap names
<ackk> pedronis, yet the store has them?
<ackk> pedronis, (and command-not-found tells you to "snap install q")
<ackk> https://snapcraft.io/q
<pedronis> you'll need to talk to the store afaik they shouldn't be supported in the store either
<pedronis> snapd will never install them
<ackk> pedronis, I see, thanks
<zyga> ogra: can you explain in more detail please
<ogra> zyga, a customer has a snap with a crypto tool that creates /dev/shm/atpkcs11 and puts a mutex inside ... they want to be able to use this from a second snap
<zyga> I see
<zyga> let me think
<ogra> (with snapcraft-prleoad they can indeed re-locate to /dev/shm/snap.$SNAP_NAME ... but i dont know if sharing that location would work)
<mup> PR snapd#8840 closed: tests: move try-related tests to snapstate_try_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8840>
 * zyga break to rest
<mup> PR snapd#8841 opened: gadget: drop dead code, hide exports that are not used externally <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8841>
<mborzecki> pedronis: ^^
<mborzecki> was able to hide/remove a bit more
<mborzecki> heh 17 files changed, 147 insertions(+), 1414 deletions(-)
<mborzecki> heh, hit that too early for operation thing again
<zyga> mborzecki: oh
<zyga> do you have more logs?
<zyga> mvo added debug bits
<mborzecki> nope
<zyga> you had older masteR?
<mborzecki> yeah
<mborzecki> but i have another new PR running, let me check whetherh it has the right changes
<mborzecki> ehh nope
<mvo> xnox: I pushed a small tweak to 8808, should be ok to re-review
<mvo> pedronis: hm, I'm testing the uc20 beta right now and there are a bunch of updates since. I get a reboot in the middle of console-conf. I guess we need to think about the user experience for this :/
<pedronis> mvo: yes, but it would be the same with uc18 I suppose
<mvo> pedronis: yeah, new kernel and snapd while I was in console-conf tryint go set this up
<mvo> pedronis: yeah, not a regression
<mvo> pedronis: mostly idle wondering
<pedronis> mvo: it's ok, it probably relates to trying to control our reboots more
<ijohnson> morning folks
<ijohnson> mvo: pedronis: also I filed https://bugs.launchpad.net/subiquity/+bug/1880156 about precisely the problem you are mentioning
<mup> Bug #1880156: console-conf when run with auto-refresh of core20 will crash and become non-responsive <core20> <uc20> <snapd:Incomplete> <subiquity:Incomplete> <https://launchpad.net/bugs/1880156>
<mvo> hey ijohnson
<ijohnson> apparently I should respond there
<mvo> ijohnson: ha! one step ahead :)
<mvo> ijohnson: thank you!
 * ijohnson -> afk 
<mup> PR snapd#8842 opened: tests: fix bug waiting for snap command to be ready <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8842>
<zyga> mvo: lmao
<zyga> was that the bug?!
<mvo> zyga: yes, well one bug :)
<zyga> mvo: do you mean there are more?
<mborzecki> https://forum.snapcraft.io/t/snaps-show-squares-instead-of-fonts/18073 hmm does pop os have a different fontconfig version too?
<mborzecki> mvo: hmm funny, shellcheck could warn about that
<cachio> mvo, hey
<zyga> mborzecki: it's based on ubuntu so... unlikely
<zyga> but ... dunno, install and check :)
<cachio> snapd-vendor-sync running
<mborzecki> if i had a penny for every linux distro i ever installed... :)
<ogra> stgraber, are there any lxd images anywhere that do not waste the first 5min running cloud-init (read: do we have any minimal images that do not come with it)
<stgraber> ogra: all official Ubuntu images have it, but we have unofficial images that don't.
<stgraber> ogra: images:ubuntu/20.04
<ogra> (i'm running stuff immediately when the container comes up ... and cloud-init just changes the whole config underneah me)
<ogra> stgraber, thanks !
<pedronis> zyga: I reviewed #8829
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<pedronis> zyga: I also commented yesterday in #8573 as you asked
<mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
<zyga> thanks!
<zyga> pedronis: the "fail" thing is a bit mysterious, thank you for pointing that out
<zyga> IIRC nothing in systemd itself uses the other value
<zyga> but it can be traced to the source and I think got documented
<zyga> I'll go over the rest and adjust it today
<zyga> pedronis: I can move the random uuid to randutil in the same branch as I need to make changes anyway
<pedronis> as you prefer
<zyga> pedronis: I made some progress on the snap tooling fix, I will send a RFC today
<ijohnson> zyga: there's now a random uuid function in randutil, see RandomKernelUUID
<ijohnson> perhaps that was pedronis' comment
<zyga> ah, I didn't know
<zyga> perhaps that's all we need
<zyga> thanks!
<ijohnson> zyga: you might need to adjust it slightly and it's user in cmd_initramfs_mounts I think
<ijohnson> but that should be fine
<pedronis> ah, I forgot, it's probably there because I made the same comment at the time
<mup> PR snapcraft#3166 opened: plugin handler: load legacy plugins prefixed with 'x-' <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3166>
 * zyga break from computer
<mborzecki> mvo: gdbserver could use some reviews, maybe zyga, ijohnson or pstolowski can take a look there?
<zyga> I will look
<zyga> It tomorrow morning fine?
<zyga> Iâm a bit tired by holding my laptop
<ogra> zyga, before you go, did you have any idea regarding the /dev/shm ssue above ?
<ogra> *issue
<zyga> ogra: yes, sorry,
<zyga> ogra: /dev/ is shared from host
<zyga> ogra: os if one snap puts stuf there and the other consumes they can see the same thing
<ogra> right ... but /dev/shm isnt writable
<zyga> you need an interface more than content
<ogra> (from a snap)
<zyga> the interface that will model the relationship
<zyga> ogra: content sharing won't work as you cannot share stuff that is not "yours"
<zyga> ogra: layouts cannot work either as they are private to a view of a given snap
<ogra> well /dev/shm/snap.$SNAP_NAME is mine
<zyga> ogra: yours as in $SNAP, $SNAP_DATA
<ogra> and they want to share content from /dev/shm/snap.$SNAP_NAME to another snap
<zyga> content cannot share anything else
<zyga> sure I get that
<ogra> ok
<ogra> you saying /dev got me confides
<ogra> *confused
 * ogra glares at his fingers 
<zyga> content is not the way to share it IMO, please discuss this as a new interface
<ogra> i know jdstrand ws looking at the possibility to have a pcscd (smartcard daemon) interface eventually ... i think that would allow such sharing ... but i dont think any work has happened in that area
<zyga> ogra: if this is specific to a given daemon then I sugges pursuing that
<ogra> zyga, not the way == impossible ? or just ugly ?
 * zyga took the painkiller and tries to rest
<zyga> ogra: hmm?
<zyga> impossible
<zyga> content cannot do that
<ogra> ok
<ogra> thanks !
<jdstrand> not yet, no. if someone else wants to pick it up, that's fine
<roadmr> zyga: ouch I hope you get better soon
<jdstrand> (re pcsd)
<zyga> roadmr: I hope so too
<pstolowski> mborzecki: i can take a look
<pstolowski> ijohnson: re hotplug & greedy plugs, i think we discussed something a few weeks ago and i replied to a question you had there but i don't remember where.. was there a bug report?
<ijohnson> pstolowski: do you remember what it was about
<ijohnson> pstolowski: oh if it's about greedy plugs jdstrand fixed it
<ijohnson> hotplug + greedy plugs works with the right declaration
<pstolowski> ijohnson: right, i think i hinted at declaration being na issue
<jdstrand> there was a bug report
 * jdstrand tries to find
<zyga> mvo: snapd tools via export system https://www.irccloud.com/pastebin/ExcgIlg7/
<jdstrand> but yes, it was a bug in the snap decl
<jdstrand> https://bugs.launchpad.net/snapd/+bug/1876356
<mup> Bug #1876356: greedy auto-connect doesn't work with hotplug <snapd:Fix Released by stolowski> <https://launchpad.net/bugs/1876356>
<pstolowski> jdstrand: right, that's the bug, thanks
<jdstrand> pstolowski: did you see that I asked you about experimental? if you did and responded, I'll read email (just came online)
<pstolowski> jdstrand: sorry i didn't reply to your question there, missed it
<pstolowski> jdstrand: on the forum? yes, i replied
<jdstrand> yes, thanks
<jdstrand> pstolowski: ok, I asked Field to give you some feedback
<pstolowski> jdstrand: great, thank you!
<zyga> pedronis: I have end-to-end implementation of RFC for exporting snapd tools
<zyga> pedronis: I'll send the RFC branch in a moment
<zyga> pedronis: the changes are surprisingly short
<pedronis> zyga: this is without the snap-confine changes?
<zyga> pedronis: with a tiny snap-confine change, snap-confine currently mounts the tools so I changed the path to use the exported tools instead
<mborzecki> and back
<mborzecki> refresh delta test failing?
<mborzecki> 2020-06-09T13:24:50.3724981Z Jun 09 13:24:39 jun091254-105239 snapd[76428]: storehelpers.go:438: cannot refresh snap "test-snapd-delta-refresh": snap has no updates available
<zyga> mborzecki: maybe store load?
<zyga> mborzecki: I have something cool
<mborzecki> zyga: what is that?
<zyga> just running one more run of spread to see if I got a tweak right
<zyga> mborzecki: exports
<zyga> mborzecki: exporting stuff from snaps to host
<zyga> mborzecki: use cases are numerous :)
<zyga> mborzecki: but 1st use case is to fix this: https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139/5
<mborzecki> zyga: hm just a sec, bikeshedding on #8823, trying to make iteration smarter
<mup> PR #8823: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8823>
<zyga> mborzecki: heh sure :)
<zyga> I was supposed to EOD anyway but I will be around for 15 more minutes
<zyga> mborzecki: btw, do you remember this soundtrack? https://www.youtube.com/watch?v=Kf8j3FYxekk
<mborzecki> zyga: staying a bit longer today, got some errands to run during the day tomorrow
<zyga> yeah
<zyga> my errand was to walk to the loo today :P
<mborzecki> zyga: and ofc i remember this, it's even on spotify
<zyga> mborzecki: I played some on x240
<zyga> wish I could go down to the office to play on a real computer
<zyga> but the sound is great (on headphones, not on x240)
<mborzecki> hm did some changes and it works, wonder if the test cases are enough
<zyga> I have a "macro" ggg
<pedronis> mborzecki: what are you trying to do?
<mborzecki> pedronis: checking whether i can further limit the number of iterations with bitset having counted leading & trailing zeros
<pedronis> mborzecki: are you using math/bits ?
<mborzecki> pedronis: yeah
<mborzecki> pedronis: does that pull in some crazy dep?
<pedronis> no, it's mostly table based
<pedronis> I'm not sure it would make me change my mind
<pedronis> about keeping the two impls tough
<pedronis> the other thing we care about is also Serialize size
<mborzecki> pedronis: i was curious to try that out ;)
<pedronis> it's ok, I mean abour serialisation again we could be clever but at some point it all gets even more complicated to track
<pedronis> than two very distinct paths
<pedronis> mborzecki: the leading zero change should be relatively straighforward no?
<mborzecki> pedronis: let me show you the diff
<mborzecki> pedronis: https://paste.ubuntu.com/p/vxtcGMMRB5/
<pedronis> I see
<mborzecki> pedronis: trims the loop range a bit
<mborzecki> pedronis: i'll post it in a comment
<pedronis> mborzecki: I didn't think of this, but we probably don't need to use both functions, instead of shifting bit, we could shift w until its 0
<mborzecki> pedronis: ha, yeah, nice idea
<mborzecki> mvo: pstolowski left some comments under #8784, i'll address them
<mup> PR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
<zyga> ok, did the change I wanted
<zyga> it should now work on fedora as well
<zyga> (and arch :)
<mborzecki> doesn't look like we'll land anything today
<zyga> mborzecki: ?
<mborzecki> the delta test is failing
<zyga> ah
<zyga> did you ask store devs?
<mborzecki> actually wanted to run the test myself, but the logs say there's no update for the snap (which is weird i guess?)
<zyga> hmm
<mborzecki>   latest/beta:      1.0+fake1 2017-05-17 (5) 2MB -
<mborzecki>   latest/edge:      1.0+fake1 2017-05-17 (3) 2MB -
<mborzecki> edge and beta have different revisions, so the test should work
<zyga> mmmm
<zyga> maybe store bug?
<zyga> if you refresh the snap by name
<zyga> does it work?
<zyga> sergiusens had this issue with multipass in #snapcraft now
<Saviq> So classic -> strict may be a red herring?
<zyga> btw
<zyga> progress bars are gone
<zyga> what happened?
<mvo> zyga: what/where?
<zyga> mvo: snap install foo
<zyga> shows no progress bar
<mvo> zyga: I see a lot of failures that progress is missing
<mvo> zyga: if it's very fast (the install) you don't see one
<zyga> it's gone :)
<zyga> it doesn't print
<mvo> zyga: iirc that's normal
<zyga> why?
<zyga> it used to
<mvo> zyga: really? I think I noticed this a while ago that it is sometimes missing and iirc it was just too quick
<zyga> hmmm
<zyga> I installed snapd
<zyga> and it took a while
<zyga> and there was no progress at all
<mvo> zyga: oh, then it might be a bug
<zyga> mvo: I implemented the "C" approach today
<mvo> zyga: \o/
<zyga> and did some manual testing to play around and see how things wokr
<zyga> *work
<mup> PR snapd#8843 opened: [RFC] many: export tools from core/snapd to mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/8843>
<zyga> I meant for this to be a draft
<zyga> but oh well
<zyga> mborzecki: ^ check it out
 * zyga EODs and closes IRC
<zyga> mvo: tomorrow I will be partially of for the MRI
<mvo> zyga: good luck
<zyga> thanks
<mup> PR snapd#7900 closed: tests: do reset of tests during restore and add checks to validate the fs <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7900>
<mborzecki> looking
<mborzecki> hmm Jun 09 20:52:21 galeon snapd[28574]: taskrunner.go:439: DEBUG: Running task 4103 on Do: Download snap "test-snapd-delta-refresh" (5) from channel "latest/beta"
<mborzecki> Jun 09 20:52:21 galeon snapd[28574]: store_download.go:137: DEBUG: Available deltas returned by store: []
<mborzecki> that's why it's failing
<mborzecki> cachio__: ijohnson: ^^
<cachio> mborzecki, where did you see that?
<mborzecki> cachio: all the recent ci runs
<cachio> mborzecki, do the store team know about that??
<mborzecki> cachio: no, haven't reached out yet, was about to EOD
<cachio> mborzecki, ok, np, I can take it
<mborzecki> cachio: great, thank you
<cachio> enjoy your EOD
<cachio> mborzecki,
<mborzecki> cachio: https://github.com/snapcore/snapd/runs/754908664
<Intruder777> hello, how can I list and install older versions of a particular snap?
<Intruder777> snap info <package> seem to show only latest
<oerheks> some snaps give stable / candidate /  beta / edge versions.
<Intruder777> oerheks: how do I list and install older versions from stable channel?
<oerheks> snaps with bugs are likely to be removed
<Intruder777> stupid thing did auto update...
<Intruder777> oerheks: snap info shows me only latest version for "stable". how do I see and install some older versions?
<oerheks> not?
<Intruder777> not?
<Intruder777> what do you mean?
<oerheks> sudo snap revert <package> # but this requires an older available version that you could see with snap info too
<oerheks> like; snap list --all vlc
<oerheks> https://snapcraft.io/docs/getting-started#heading--revert
<Intruder777> revert says "no revision to revert to"
<Intruder777> I've tried to do `snap refresh <pckg> --revision=..." by guessing older revision number, but it says "Access by specifying a revision is not allowed for this
<Intruder777>  Snap"
<Intruder777> how is this situation possible at all??? with the package manager?
<oerheks> that happens, when it is prop software..
<oerheks> what snap are you talking about?
<Intruder777> opensource one
<Intruder777> telegram-desktop
<Intruder777> I mean how it can be in 2020 that package manager silently upgrades packages without permission?
<Intruder777> and then there is no way to revert it back...
<Intruder777> that's freaking nonsense
<oerheks> no, not if there is a fix for a leak or vulnarability.
<oerheks> contact the snap maintainer?
<Intruder777> the snap itself have to at least backup previous version before upgrading without permission
<Intruder777> so I don't have to contact package maintainer
<oerheks> oh, 'edge' got an update today
<oerheks> https://snapcraft.io/telegram-desktop
<Intruder777> I need previous versions.
<oerheks> You can save installed packages using following code; snap save ; And then all the installed packeges will be zipped with data to /var/lib/snapd/snapshots/
<Intruder777> oerheks: is there a way to configure snap to always make backup when refreshing to newer version?
<oerheks> so, for edge you would do this manually ( from now on) . i see  not way to get older versions back
<Intruder777> maybe you know how to fix this: "telegram-desktop: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory"
<Intruder777> I've tried to uninstall and reinstall the snap and it doesn't help
<Intruder777> oerheks: it was working fine before and now shows this error
<oerheks> i find some older posts about this, "snap refresh" fixed the problem.
<oerheks> but if you run the latest edge, you might want to file a bugreport to the maintainer.
<Intruder777> I run latest stable
<Intruder777> 2.1.11
<oerheks> removing a snap would also mean removing the settings in ~/snap/<snapname>
<Intruder777> so?
<Intruder777> what's your point?
<oerheks> just saying
<Intruder777> I already did it twice
<Intruder777> it was not working before I did it. and it still doesn't work now
<Intruder777> oerheks: is there a way to remount snap filesystem for read/write?
<oerheks> yes, see answer popey https://forum.snapcraft.io/t/mount-snap-with-rw-for-troubleshooting-propose/12264
<Intruder777> all my experience with a snap is a story of failures. I use to install rocket-chat from a snap and one day it stopped working because stupid snap is configured to auto update packages by default and the newer version of rocket-chat had a glitch which breaks the mongo-db migration, so it bricked all my local settings. craziness. now I installed telegram-desktop. and again, the auto-update screwed things up
<Intruder777> what crazy people set auto updating packages by default??
<Intruder777> that link says "You can unsquashfs the snap to a folder then snap try foldername/ which will âinstallâ the snap directly from that folder." - very helpful. an how do I do those steps? can I somehow make changes directly in /var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/?
<oerheks> just contact the maintainer, i am not going to write that bugreport for you
<Intruder777> oerheks: I don't need to contact maintainer and wait for it to fix it. I wanted to fix it by trying to change Qt lib version directly inside snap
<Intruder777> oerheks: ok, I've just downloaded the linux binary from Telegram site and it works. and the snap goes to trash bin
#snappy 2020-06-10
<zyga> Good morning
<zyga> I will start around 9
<mup> PR snapd#8842 closed: tests: fix bug waiting for snap command to be ready <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8842>
<pstolowski> morning
<mup> PR snapd#8816 closed: tests: port 2 uc20 part1 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8816>
<pedronis> mvo_: hi
<zyga> Hey everyone
<zyga> Iâm around, going to address PR feedback now
<zyga> I will be off later for the mri
<mvo> pedronis: hi, not sure my earlier "hi" made it to you, for some reason I was put into "quiet" mode by freenode
<mvo> pstolowski: good morning
<mvo> zyga: good luck for later today
<pedronis> mvo: if your nick is not the registered one (like mvo_) you can't talk here
<alazred> Hi there! I've asked that question on #snapcraft but I think it fit best here. I have a snap that break after each reboot. it show me this error https://pastebin.com/X3VCfyua. If I reinstall the snap it work again. I'm running snapd on manjaro-arm on the pinebook pro.  Any pointers of what might be going on ? thanks in advance!
<zyga> alazred: this means that nothing is loading apparmor profiles
<zyga> alazred: what is the status of snapd.apparmor.service?
<zyga> alazred: it is responsible for loading snapd apparmor profiles on system startup
<alazred> zyga: https://pastebin.com/i1eMy3Md
<alazred> zyga: sorry not the good one
<zyga> hmm, too bad there are no logs
<zyga> do you have persistent journal enabled?
<zyga> it would be good to make sure you do (mkdir /var/log/journal)
<zyga> and reboot
<zyga> and then check the status of that service
<alazred> zyga: It's dead  https://pastebin.com/eX3ccSgz
<zyga> the service is not enabled
<zyga> systemctl enable --now snapd.apparmor.service
<alazred> Ive enabled it and it's now working !
<alazred> zyga: thanks  !
<zyga> alazred: maybe file a bug in manjaro
<zyga> alazred: do you remember if it was disabled out of the box?
<alazred> zyga: Yeah i will go there also !  The error was not super clear  and since the other apparmor.service was enalble i tought I was ok on that side.
<zyga> yeah, until apparmor 3 ships we need a custom service
<alazred> zyga: I'm pretty sure it was
<zyga> apparmor 3 won't need this
<zyga> ok
<alazred> but since it's arch base I don't know if it enable those things on install.
<alazred> I'll try to know more on that. Thanks again for your time!
<zyga> alazred: thanks for reaching out :)
<alazred> zyga: They dosen't do mention of snapd.apparmor.service in the manjaro wiki. Only to enable snapd.socket.
<zyga> alazred: I see, I think it needs fixing
<zyga> I reached out to some manjaro friends and let them know
<mborzecki> morning
<alazred> zyga: Ok thanks !
<mup> PR snapd#8841 closed: gadget: drop dead code, hide exports that are not used externally <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8841>
<mup> PR snapd#8844 opened: asserts/internal: add some iteration benchmarks, potential opt  <Created by pedronis> <https://github.com/snapcore/snapd/pull/8844>
<pedronis> pstolowski: I tried to answer your comment in #8823, also made some small changes based on mborzecki feedback
<mup> PR #8823: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8823>
<pstolowski> thanks
<zyga> mvo: I'm seeing this error, not sure if related to my PR or just random
<zyga> https://www.irccloud.com/pastebin/Xh7y61FS/
<mvo> zyga: oh, fun. looks like the earlier incorrect loop masked some other problem :(
<mvo> zyga: how often/where do you see it?
<zyga> just noticed a few systems failed this way on my RFC PR
<zyga> https://github.com/snapcore/snapd/pull/8843/checks?check_run_id=756927988
<mup> PR #8843: [RFC] many: export tools from core/snapd to mount namespaces <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8843>
<zyga> look at the colors on the left
<zyga> lots of green, a few reds
<mvo> zyga: quire a few reds :/
<zyga> yeah
<zyga> I wonder what was going on before
<mvo> zyga: ok, I have a look. odd that it did not appear in the original PR
<zyga> it doesn't seem like a new bug
<zyga> just surfaced
<mvo> zyga: yeah, I'm sure the superlong timeout just masked the issue
<zyga> it *might* be something my PR does
<zyga> but I'm not sure
<zyga> one sec
<zyga> Wed, 10 Jun 2020 08:30:40 GMT
<zyga> retry: next attempt in 1.0 second(s) (attempt 6 of 120)
<zyga> 730
<zyga> Wed, 10 Jun 2020 08:30:40 GMT
<zyga> + snap wait system seed.loaded
<zyga> 731
<zyga> Wed, 10 Jun 2020 08:30:40 GMT
<zyga> error: cannot communicate with server: timeout exceeded while waiting for response
<zyga> 732
<zyga> with time stamps
<zyga> this is not after a long wait
<zyga> but this is surprising
<zyga> so retry *succeeded*
<zyga> after 6 seconds
<mvo> zyga: yeah, I suspect snapd is restarting or something
<zyga> but the "snap wait" immediately after that fails
<zyga> yeah
<zyga> maybe snap wait should be more robust
<zyga> I think this may be what was randomly failing earlier as well
<zyga> btw, those timestamps *rock*
<mvo> zyga: yeah, snap should actually retry :/
<zyga> heh
<zyga> retry snap wait
<zyga> ;)
<pedronis> we have the wait.go logic but is meant for things that give back a Change
<pedronis> but we need some bits of it
<pedronis> for wait
<pedronis> itself
<pedronis> this kind of code: https://github.com/snapcore/snapd/blob/master/cmd/snap/wait.go#L96
<mvo> pedronis: thank you
<mup> PR snapd#8845 opened: [RFC] many: add "system.service.snapd-autoimport.disable" setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/8845>
<mvo> zyga: I can look at the wait issue now
<zyga> mvo: thank you
<mup> PR snapd#8808 closed: riscv64: bump timeouts <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8808>
<zyga> afk
<mborzecki> zyga: are you still using fish?
<mvo> zyga: it's all broken
<zyga> mvo: what?
<zyga> mborzecki: yes
<zyga> mvo: what's going on?
<zyga> sorry, not having most productive day
<zyga> I feel the best in a position where typing is not possible
<mborzecki> zyga: can you try `snap <TAB>`, does it show the commands and their help?
<mvo> zyga: the wait thing you pointed me to is broken in 3 different ways on 16/18/20 :(
<mvo> zyga: anyway, I'm looking
<zyga> mvo: woah
<zyga> mborzecki: trying
<zyga> yes
<zyga> it super nice way :)
<zyga> how do we screenshot on linux?
<zyga> hmm
<mup> PR snapd#8846 opened: tests: move update-related tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8846>
<zyga> mborzecki: check this out https://usercontent.irccloud-cdn.com/file/K78qpiep/fish-tab-completion.png
<mborzecki> yeah, it's in the upstream https://github.com/fish-shell/fish-shell/blob/master/share/completions/snap.fish
<zyga> super pretty
<zyga> not using bash helpers but I guess for some reasons
<mborzecki> zyga: there was some problems reported in the forum though https://forum.snapcraft.io/t/tab-completion-for-snap-connect-in-fish-spams-errors/18083
<mborzecki> it wfm though
<zyga> yeah
<zyga> that is broken
<mborzecki> mhm
<mborzecki> yeah, it's the connect/disconnect thing
<mborzecki> that warning should probably go to stderr
<zyga> mborzecki: snap connect <tab> SNAFU https://usercontent.irccloud-cdn.com/file/KdWyk66Z/snap-connect-broken-completion.png
<zyga> mvo: can you tell some more
<zyga> mvo: it's really interesting
<mvo> zyga: the first (16) stops with a connection timeout exceeded
<mvo> zyga: the second (18) hangs forever
<zyga> whaat?
<mvo> zyga: and 20 fails with dpkg --purge dir not empty
<zyga> and it was just this broken/
<zyga> how did we miss it?
<mvo> zyga: I start with 20 now that looks most simple
<mvo> zyga: no idea, 20 could be just coincidence
<mborzecki> zyga: heh it calls `snap interfaces $snap | string replace -r '[- ]*([^ ]*)[ ]+([^ ]+)' '$2$1' | string match -v "*Slot*"`
<mborzecki> hm i'll to fix it upstream
<zyga> one thing I love in fish
<zyga> is that $foo is not unsafe
<zyga> as fish does not expand strings this way
<zyga> it's weird coming from bash
<zyga> but nice
<zyga> mvo: sorry for dragging you into this
<mvo> zyga: my own fault for doing the original PR
<pstolowski> mvo, mborzecki : is #8784 still a draft?
<mup> PR #8784: snap: add new `snap run --experimental-gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
<mborzecki> pstolowski: switched it to 'ready'
<mvo> pstolowski: I think we can switch it
<pstolowski> indeed, thanks
<mborzecki> it's probably missing some tests tho, we can add those once we get some reviews
<mborzecki> zyga: this should fix it https://github.com/fish-shell/fish-shell/pull/7104
<mup> PR fish-shell/fish-shell#7104: completions/snap: workaround snap interfaces deprecation notice <Created by bboozzoo> <https://github.com/fish-shell/fish-shell/pull/7104>
<zyga> nice
<mborzecki> hm zomething we could distro patch for instance in ubuntu?
<zyga> I'm sure we can
<zyga> mvo:  cna you dput to ubuntu?
<mborzecki> (once it lands upstream first)
<mvo> zyga: dput what?
<zyga> mvo: fish
<mvo> zyga: I can/could to groovy, focal will need a SRU
<zyga> grovy would be good
<mborzecki> i'll file a bug first
<pedronis> mborzecki: looks like #8830 can be merged?
<mup> PR #8830: bootloader: introduce bootloarder assets, import grub.cfg with an edition marker <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8830>
<mborzecki> it's green yay! at last
<mvo> zyga: and none of the wait issues you saw in the PR is reproducible so far :(
<zyga> hmmm
<zyga> maybe my PR is at fault
<zyga> are you trying on master or on that branch?
<mvo> zyga: master
<mvo> zyga: let me try your PR
<pedronis> is the export PR?
<zyga> if it's just that PR it's not worth spending time on it
<zyga> I thought you found some deeper issues on master
<mvo> zyga: ok, I park it for now (if the current run is also not failing)
<mup> PR snapd#8830 closed: bootloader: introduce bootloarder assets, import grub.cfg with an edition marker <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8830>
<mvo> pedronis, zyga a log of the 20.04 "device not ready" we talked about yesterday with the debug log https://github.com/snapcore/snapd/pull/8845/checks?check_run_id=757318867 - I'm now trying to make sense of it
<mup> PR #8845: [RFC] many: add "system.service.snapd-autoimport.disable" setting <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8845>
<zyga> Jun 10 10:09:33 jun100957-926530 snapd[35371]: snapmgr.go:298: cannot read snap info of snap "snapd" at revision 7777: cannot find installed snap "snapd" at revision 7777: missing file /snap/snapd/7777/meta/snap.yaml
<zyga> that's super clear IMO
<zyga> mvo: this is the bug that we talked earlier about
<zyga> mvo: about someone showing a system where booting lost interfaces
<zyga> because core was not mounted on time
<zyga> but
<zyga> how can this be happening!?
<zyga> this is what is so myserious about it
<zyga> are we racing with mounting that we do ourselves?
<pedronis> here there is no core snap at all
<pedronis> to be clear
<pedronis> there is no snapd snap either
<zyga> this is also weird: Jun 10 10:00:06 jun100957-926530 systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
<mvo> zyga: oh, the mount units could be too slow to start?
<zyga> and this killing was after we did this
<zyga> Jun 10 10:00:06 jun100957-926530 systemd[1]: snapd.service: State 'stop-sigterm' timed out. Killing.
<zyga> and this kicks off the snapd.failure unit Jun 10 10:00:06 jun100957-926530 systemd[1]: snapd.service: Triggering OnFailure= dependencies.
<zyga> hmmmm
<zyga> mvo: is it possible that snapd failing unmounts snap units?
<zyga> like undoing some dependency chain or something
<mvo> zyga: possibly seems unlikely but I guess we need to explore whatever we can find
<pedronis> mvo: but remember there should be no snapd at all at that point here
<mvo> zyga: hm, two interessting things - the image has snaps seeded already, I think that's the only image we have with that property
<pedronis> we just reinstalled the snapd deb
<mvo> zyga: there is also a error auto-refresh change
<pedronis> it seems like there's state from something else around
<mvo> pedronis: it looks like the image already has snapd in the image (and lxd/core18)
<pedronis> yea
<pedronis> and removing snapd doesn't do the right thing
<zyga> oh interesting!
<pedronis> this is prepare.sh
<pedronis> it was written for systems which just the snapd deb
<pedronis> but possibly with 20.04 there's a ton of stuff there
<pedronis> we just install the new deb?
<mvo> pedronis: yes
<mvo> pedronis: it sounds like we need to purge snapd first
<pedronis> that probably doesn't work well
<mvo> maybe that's enough
<pedronis> if snapd is in the middle
<pedronis> of seeding
<pedronis> there's a real bug here I suppose
<pedronis> what should happen if you upgrade the deb while snapd is seeding
<mvo> right
<pedronis> not saying that we need to fix that to fix prepare.sh
<pedronis> but we defintely need to check what happens, what we want to happen
<pedronis> in that scenario
<mvo> yeah
<pedronis> it seems you can get a fairly weird state
<mvo> pedronis: looking at the looks it seems like the seeding is already done, it happend 43 days ago (probably when the image was booted first and preapared for our needs)
<mvo> pedronis: I suspect the issue happens when a auto-refresh is in progress while we update the deb
<mvo> pedronis: but it's a similar issue I guess(?)
<pedronis> yes
<pedronis> I don't think we have thought through this
<pedronis> maybe it's only relevant if the deb has a newer snapd?
<mvo> yeah - and it seems real given that andy had this bug on a ubuntu 20.04 system some days ago
<mvo> pedronis: oh, that's interessting
<pedronis> naively the main issue in prepare.sh is that we have a state.json with seeded
<pedronis> but it doesn't relate to the installing snapd
<pedronis> but I don't know if there's other interference possible
<pedronis> especially if the deb version is newer
<pedronis> it's a bit confusing because when it works we end up with no snaps except core20
<mvo> pedronis: what is most interessting to me is that we see the mount units vanishing, this looks like the bug we had the other day. I would like to understand this :/ the fix in prepare.sh is easy (like you said) we can purge and things should work. anyway, I have lunch first but this looks interessting and like there is something real lurking here
 * mvo lunch
<pedronis> mmh, we have also our strange hack that removes the seed
<pedronis> though I suppose only if it's invalid
 * zyga preps for the MRI
<zyga> see you laster
<zyga> *later
<ogra> good luck
<zyga> mvo: purge unmounts
<zyga> mvo: so snapd may be doing stuff while we purge and purge and purge
<zyga> (just a guess)
 * pstolowski going to the vet, bbl
<clmsy> hi everyone
<clmsy> i have a question about building a custom image with ubuntu core 20
<clmsy> im specially interested in trying to build with grade:secure option
<clmsy> i modified my model json file and trying to sign it
<clmsy> i get this error: error: cannot assemble assertion model: cannot specify a grade for model without the extended snaps header
<clmsy> now it kinda makes sense because on this page, every snap is put with its identifier: https://docs.ubuntu.com/core/en/releases/uc20
<clmsy> but the sign function from snapcraft expects a json
<clmsy> do i have to somehow insert this information to required-snaps list
<clmsy> i guess maybe i have to remove "require-snaps" andd replace it in json with "snaps" as a map not just a list of strs
<mvo> clmsy: hey, check https://github.com/snapcore/models/blob/master/ubuntu-core-20-amd64.json for an example
<mvo> clmsy: there are some more in https://github.com/snapcore/models
<clmsy> aaah its already in here thanks a lot!
<clmsy> hmm
<clmsy> did anyone get pc-kernel snap not found while trying to build a core20 image ?
<ijohnson> clmsy: what branch are you using for your kernel snap you need to be using the 20/ channel
<clmsy> 20/beta
<clmsy> i mean surely its there since snap info shows: 20/beta:          5.4.0-34.38.1  2020-06-08 (524) 271MB -
<clmsy> haha
<ijohnson> clmsy: hmm then I don't know what the cause of that issue is then
<pstolowski> re
 * mvo hands pstolowski the "biggest-PR-of-the-year" award
<pstolowski>  /o\
<mvo> pstolowski: heh - not your fault that snapstate_test grew to such monstrous size :) thanks for cleaning it up !
 * mvo hands pstolowski the "Augean Stables" award instead
<pstolowski> LOL
<mborzecki> haha
<zyga> Back home
<zyga> Need rest
<zyga> Darn pain
 * mvo hugs zyga (gently)
<zyga> I wonât be doing those 12 hour flights anytime soon
<mup> Bug #1882957 opened: Snapd `internal error: connection "[slot] [plug]" not found in state` <Snappy:New> <https://launchpad.net/bugs/1882957>
<cachio> pedronis, this is what I updated in spread: https://github.com/snapcore/spread/pull/72
<mup> PR spread#72: Skip tests <Blocked> <Reviewed> <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/72>
<cachio> pedronis, today I'll push another implementation using SKIP command
<cachio> I need to make that work better
<cachio> before pushing
<clmsy> im almost able to build a custom image w core20, one last road bump im having
<clmsy> error: cannot add snap "network-manager" without also adding its base "core" explicitly
<clmsy> now i have type:base core20
<clmsy> do i need to add say core16 without type:base or somehow add core16 base information to snap header of network-manager
<ogra> either add "core" to your required-snaps in the model assertion or find a different track for network-manager
<ogra> (i'm sure at least a core18 track exists for it)
<clmsy> ok thank you, ill try figure that out
<pedronis> clmsy: you need to use type: core for core
<clmsy> ok i guess as long as type:base is core20 i am allowed to add more type:core
<ogra> well, the NM he installs has seemingly "base: core"
<ogra> so "core" needs to be in the image as well ... or an NM with core18 or core20 base
<pedronis> yes, he can do that by having an entry in snaps with type: core  name: core id: of core
<clmsy> thanks for the fast feedback!
<ogra> ah, in the model assertion ? (thats new !)
<pedronis> ogra: in core20 models requires-snaps is called snaps and has much more syntax
<pedronis> it's a list of maps
<ogra> neat
<ogra> !
<ogra> (i have admittedly not looked a lot at 20 yet)
<pedronis> ogra: https://github.com/snapcore/models/blob/master/ubuntu-core-20-amd64.model for an example
<ogra> (some docs, howtos and tutorials would be really helpful)
<mup> Bug #1882957 changed: Snapd `internal error: connection "[slot] [plug]" not found in state` <Snappy:New> <https://launchpad.net/bugs/1882957>
<ogra> oh, this is really cool !
<ogra> can you omit the id filed for using local snaps though ?
<clmsy> yeah i like the syntax and the reason i jumped into trying to utilize is that, one of our main images that we use, i needed to implement full disk encryption and secureboot
<clmsy> than i saw that with core20 i can utilise grade:secured for that feature
<ogra> (local snaps are pretty essential during development)
<pedronis> ogra: yes, but only in grade: dangerous
<ogra> good
<ogra> thats good enough
<pedronis> yes, it's supported exactly for development
<ogra> yeah ð
<mup> Bug #1882957 opened: Snapd `internal error: connection "[slot] [plug]" not found in state` <Snappy:New> <https://launchpad.net/bugs/1882957>
<mvo> cachio: silly question - I have one spread run for ubuntu-core-20-64 (https://github.com/snapcore/snapd/pull/8845/checks?check_run_id=757318867) that uses an image that has snaps installed. when I run the same test here with my local spread against google I get a ubuntu 20.04 base image without snaps. any idea how this can happen? why would we get different images for 20.04?
<mup> PR #8845: [RFC] many: add "system.service.snapd-autoimport.disable" setting <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8845>
<cachio> mvo, let me check the pr
<cachio> one sec
<zyga> mvo: interesting failure in repartition magic
<zyga> https://github.com/snapcore/snapd/pull/8829/checks?check_run_id=757631787
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<mup> PR snapd#8847 opened: tests: fail in setup_reflash_magic() if there are snaps already <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8847>
<zyga> I would add retry test -e /dev/loop1p2 before that settle call
<zyga> I suspect we just call settle in a racy way
<zyga> since the partition may not exist yet
<zyga> (on line 547 in the log)
<cachio> mvo, agree with zyga, it has to be a race
<zyga> I can send patches later but I really need to rest in a neutral position now
<zyga> so away from screen and kbd
<cachio> mvo, I'll try to reproduce it here to see how to fix it
<clmsy> well guys i think you might wanna add multiple core support on the model because the image tool is not allowing this
<clmsy> error: core snap has unexpected type: base
<clmsy> here ill show you how the model assertion looks like
<clmsy> https://pastebin.com/BhXhNqM7
<clmsy> i tried removing type information from core18 and core as well
<clmsy> still complains
<ijohnson> clmsy: core18 should not have `type: core`
<ijohnson> clmsy: core18 should have `type: base`
<ijohnson> I think
<clmsy> hmm
<clmsy> i can try that sure
<clmsy> gut feeling was that i thought having 3 snaps set as type: base might cause an issue
<ijohnson> which snap is used as the actual base for the image is decided by the base header in the root of the model, not by the type: base in the snaps header iirc
<pedronis> ijohnson: correct
<pedronis> that's the reason it exists, we don't support many gadgets or kernels, but there can be many bases, but only one is the boot/root base
<clmsy> yes thank you :)
<mup> PR snapcraft#3166 closed: plugin handler: load legacy plugins prefixed with 'x-' <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3166>
<mvo> cachio: is there any way to figure out what base image https://github.com/snapcore/snapd/pull/8845/checks?check_run_id=757318867 was using? i.e. is there a way for me to login into that image? I tried spread -debug google:ubuntu-core-20-64 but the image I get from that is different, it has no snaps but the log there shows that there are snaps in the image that failed in the test
<mup> PR #8845: [RFC] many: add "system.service.snapd-autoimport.disable" setting <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8845>
<cachio> mvo, yes
<cachio> but in case of core is difficult because the base image is focal and we update it during the prepare
<cachio> mvo, so, to login to core-20 image then only way is to add an exit 1 in some place and use -debug
<cachio> if you want to log into the focal image used as base you can do the following in spread-images project
<cachio> spread -shell google:ubuntu-20.04-64:tasks/google/start-instance
<cachio> you need to comment the service account line in the spread.yaml to make that work
<mup> PR snapcraft#3167 opened: unit tests: move to pytest <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3167>
<mvo> cachio: right, I got to this point but even with exit in setup_reflash_magic I get an image that looks different, i.e. something without snaps at this point
<mvo> cachio: but in the log of 8845 I see there is core18/lxd installed in the image
<mvo> cachio: and I wonder how this is possible :/
<cachio> mvo, lxd?
<cachio> mvo, you see that in snap changes output right?
<mvo> cachio: yeah, if you look at https://github.com/snapcore/snapd/pull/8845/checks?check_run_id=757318867 and look at line 365
<mup> PR #8845: [RFC] many: add "system.service.snapd-autoimport.disable" setting <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8845>
<mvo> cachio: aha, I can even link to it https://github.com/snapcore/snapd/pull/8845/checks?check_run_id=757318867#step:5:365
<cachio> mvo, yes, let me check the base image
<mvo> cachio: thanks, please check if we have any base image with that, if so I would love to login into one to debug this further :)
<cachio> mvo, for ubuntu core 20 we are using the image ubuntu-2004-64-virt-enabled as base
<cachio> not sure why we are not using the regular one
<cachio> can't remember
<mvo> cachio: can you check on this base image if it has snaps?
<cachio> mvo, starting the image
<cachio> almost started
<mvo> cachio: thank you
<cachio> but takes few minutes
<cachio> mvo, core18 and lxd installed
<cachio> mvo, let me check why
<mvo> cachio: oh, nice. let's keep it this way for now, I want to do some debugging
<mvo> cachio: so here is something crazy - if I setup an "exit 1" in setup_reflash_magic and run spread google:ubuntu-core-20-64:tests/main/smoke I get a shell that does not contain snaps. am I just confused?
<cachio> mvo, hehe, the snaps should not be there for sure, and are not installed during images are updated
<zyga> ijohnson, mborzecki: can you please look at https://github.com/snapcore/snapd/pull/8848 and think if we have a similar problem anywhere in non-test code?
<mup> PR #8848: tests: wait after creating partitions with sfdisk <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8848>
<cachio> mvo, I think those are comming from the base image
<mup> PR snapd#8848 opened: tests: wait after creating partitions with sfdisk <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8848>
<zyga> mvo: could you be getting a different region
<zyga> and a different image in that region?
<mvo> zyga: ohhh, yes
<zyga> (somehow)
<mvo> cachio: is that possible? what zyga said, that we get diffrent images for different regions that might be slightly different? so when I run from my local machine I get a different result than github actions?
<mvo> cachio: fwiw, I really want to run with the snaps because I would love to debug why this fails
<cachio> mvo, ah, ok, makes sense
<cachio> mvo, in parallel I need to check why are those snaps installed
<cachio> google:ubuntu-20.04-64-base .../tasks/google/start-instance# snap list
<cachio> Name              Version   Rev    Tracking         Publisher          Notes
<cachio> core18            20200427  1754   latest/stable    canonicalâ         base
<cachio> google-cloud-sdk  296.0.0   135    latest/stable/â¦  google-cloud-sdkâ  classic
<cachio> lxd               4.2       15457  latest/stable/â¦  canonicalâ         -
<mvo> cachio: can you find out somehow ? i.e. is there a setting somewhere in the website for gce etc?
<cachio> snapd             2.45      7777   latest/stable    canonicalâ         snapd
<mvo> cachio: nice! yeah, that's what I see in the logs
<cachio> mvo, I just started an image which is not ours
<cachio> it is from cloud team
<mvo> cachio: anyway, in a meeting let's talk a bit more later
<cachio> mvo, sure, I am having lunch now
<kyrofa> jdstrand, can you help explain this denial? Log: apparmor="DENIED" operation="bind" profile="snap.nextcloud.occ" pid=19769 comm="loolwsd" family="unix" sock_type="stream" protocol=0 requested_mask="bind" denied_mask="bind" addr="@6C6F6F6C7773642D74634C4838366E3700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
<mvo> cachio: can I modify spread.yaml somehow to get that image? after lunch is fine :)
<jdstrand> kyrofa: aa-decode 6C6F6F6C7773642D74634C4838366E3700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
<jdstrand> Decoded: loolwsd-tcLH86n7
<jdstrand> kyrofa: that abstract socket is not snap-specific
<cachio> mvo, yes
<zyga> kyrofa: aa-decode is your friend
<cachio> mvo, just use -> image: ubuntu-os-cloud/ubuntu-2004-lts
<kyrofa> Huh, I've never used aa-decode before
<zyga> kyrofa: first time for everything
<jdstrand> kyrofa: it should match: @snap.@{SNAP_INSTANCE_NAME}.**
<jdstrand> it isn't a tool that you normally need, but when you do, it is handy :)
<kyrofa> jdstrand, what is SNAP_INSTANCE_NAME in this context?
<jdstrand> kyrofa: 'nextcloud'
<kyrofa> Ah okay
<jdstrand> ie, they should use @snap.nextcloud.anything-they-want
<jdstrand> if they want to support parallel installs, they should look at $SNAP_INSTANCE_NAME from the environment to obtain 'nextcloud'
<jdstrand> the snap probably isn't parallel-installable now for a bunch of reasons though
<jdstrand> (eg, port binding)
<kyrofa> jdstrand, no it's not, for reasons like this: https://forum.snapcraft.io/t/run-configure-hook-of-nextcloud-1-snap-run-hook-configure-error-error-running-snapctl-unknown-service-nextcloud-apache/11422
 * cachio lucnh
<kyrofa> But yeah, ports would be problematic as well
<cachio> mvo, I need to edit out scripts to clean preinstalled snaps
<mvo> cachio: let's talk after lunch/meeting
 * zyga looks at a conflict and sighs
<alazred> zyga: The manjaro-arm team has already updated their snapd package to add the systemd.apparmor.service. Should be alright now! Thanks again for your help!!
<zyga> alazred: wooot :)
<zyga> alazred: how is the arm laptop?
<alazred> zyga: Feel good still some quirks to go around since it's new hardware. But it is still a good piece of hardware! I've been playing around with it for a week and so far I'm really pleased with it !
<alazred> zyga: The only really negative thing so far are the speakers... They are useless. you need to be in an almost silent room to hear anything. Other then that pretty good.
<zyga> yeah, speakers are often neglected in laptops
<alazred> those are probably the worst ;)  but really for the price it's hard to complain
<ogra> who uses them anyway
<zyga> speakers?
<mvo> cachio: I changed the image for ubuntu-core-20-64 to ubuntu-os-cloud/ubuntu-2004-lts and still no snaps installed. so it looks like I still get a different image under some cistumstances :/
<zyga> mvo: echo the root password and IP address and run a PR
<zyga> mvo: then get int
<zyga> and check cloud init data
<zyga> and maybe the image
<zyga> you may get cloud region info there too
<zyga> mvo: or jokes adise
<zyga> *aside
<zyga> spread tests are invoked from a machine we can ssh to
<zyga> so ...
<zyga> just saying
<zyga> if you need I can help
<mvo> zyga: could init data is a good idea, let me try this now
<zyga> mvo: if you want I can just give you shell access
<zyga> and you can spawn spread by hand
<zyga> just like tests do
<zyga> and debug away
<mvo> zyga: are you in an image with snaps pre-installed?
<zyga> mvo: I didn't try but if the theory is that location matters
<zyga> well, I can give you location
<kyrofa> jdstrand, regarding that abstract socket denial, I wanted to make sure you knew that snappy-debug didn't give me any advice
<kyrofa> It just gave me the log
<mvo> zyga: let me first try from my location and check the cloud init data, in any case, we should not get totally differfent images so I really want to understand this
<kyrofa> In case that's something you wanted to support
<zyga> ok
<zyga> yeah, I'm +10 on getting to the bottom of it
<jdstrand> kyrofa: there is a bug on that
<jdstrand> err, a checklist item in a card
<jdstrand> but thanks
<jdstrand> oh, actually, I fixed that in edge already
<jdstrand> kyrofa: ^
<jdstrand> I need to do some 2.45 policy updates for snappy-debug, when I do, the fix will be in stable
<kyrofa> jdstrand, nice!
<jdstrand> kyrofa: actully, I think it needs a small tweak for the encoded path
<jdstrand> kyrofa: but that fix will be in stable
<jdstrand> when I push it
<mvo> zyga: meh, no information in /run/cloud-init about the image booted it seems
<zyga> hmmm
<zyga> nothing? when I was looking at the /home/ubuntu mystery I did see some data (more than I could understand)
<zyga> maybe something in journald?
 * zyga limps out of bed to get some tea
<mvo> cachio, zyga things starting to make slightly more sense now - so the ubuntu-20.04-64 image has lxd/core18 installed. we have code in prepare-restore.sh to purge snapd. However as evident in 8845 this code is not always run or does not always work. so I think that is the issue, I'm on it, no need to change anything on the image - I strongly suspect the purge fails under some circumstances
<ijohnson> mvo if the image you booted was in GCE it should definitely have /run/cloud-init ?
<zyga> re
<mvo> ijohnson: sorry, I was not clear. it does have /run/cloud-init just no information what the image name is
<ijohnson> ah ok
<zyga> mvo: could it be that the sequence matters
<zyga> and depending on which suite runs first
<zyga> mvo: try looking at the log you saw from the failure
<zyga> what was the first suite on that machine?
<mvo> zyga: we purge as part of --prepare-project so that should be ok
<zyga> I see
<zyga> hmmmmmmm
<zyga> that is weird then
<mvo> zyga: if it's an incomplete purge that explains also why the mount units are not there anymore
 * zyga returns to resolving conflicts
<pedronis> pstolowski: should I re-review #8812 ?
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<mup> PR snapd#8847 closed: tests: fail in setup_reflash_magic() if there are snaps already <Test Robustness> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8847>
<cachio> mvo, ah, ok
<cachio> well, just let me know if we need to clean up the image before publish it
<mvo> cachio: please keep it for now
<cachio> mvo, sure, np
<mvo> cachio: I pushed a new PR that hopefully helps figuring out what is going on
<mvo> cachio: pushed 8849 that hopefully catches this in the future
<zyga> mvo: do you know if the wait in 8848 needs to be reproduced in any production code?
<mup> PR snapd#8848 closed: tests: wait after creating partitions with sfdisk <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8848>
<mup> PR snapd#8849 opened: tests: fail in setup_reflash_magic() if there is snapd state left <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8849>
<mvo> zyga: I don't think we need this wait
<zyga> mvo: which one?
<mvo> zyga: the snap wait seed.loaded in setup_reflash_magic
<zyga> mmm
<mvo> zyga: I think that's not needed, snapd is purged earlier so it will never seed
<mvo> zyga: in this code we also don't need to install core, we can just download it :)
<zyga> heh, thanks for looking at this with fresh eyes
<mvo> zyga: but let's only change it after we found the root cause of the other issue
 * mvo really needs dinner now
<zyga> I did knee-jerk reactions it seems
<zyga> jdstrand: hey
<zyga> I'm going to EOW soon
<zyga> I'd love a +1/-1 on this test tweak
<zyga> https://github.com/snapcore/snapd/pull/8803
<mup> PR #8803: tests: port interfaces-many-core-provided to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8803>
<zyga> so that I can end the week with no dbus-daemon leaking :)
<zyga> it's a +2 PR but you need to look before it lands or doesn't land
<pstolowski> pedronis: yes
 * cachio app with kinesiologist
<jdstrand> zyga: I commented such that you should be unblocked. I did not approve since I didn't pore over it
<zyga> jdstrand: thank you :)
<zyga> it's +2 so that's good
<mup> PR snapd#8803 closed: tests: port interfaces-many-core-provided to tests.session <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8803>
<hellsworth> hey folks is there a uc20 image that is not signed that will work in kvm?
<roadmr> why unsigned?
<hellsworth> well maybe i just need the signature :)
<roadmr> ð
<hellsworth> which of these *.gpg files would have been used to sign the image?
<hellsworth> md5sums, sha1sums, or sha256sums
<roadmr> none :)
<roadmr> hellsworth: image signatures are contained in an assertion if I'm not mistaken, those are signed with a key that lives in the assertion service
<hellsworth> hmm ok i just wanna boot uc20 in kvm..
<hellsworth> i have a lovely qemu command that worked just fine for uc18 and not for uc20
<roadmr> ohh I see
<hellsworth> any advice would be helpful
<roadmr> but you do have an uc20 image which you didn't build yourself?
<hellsworth> correct
<roadmr> that likely contains the correct signature
<roadmr> why isn't it working? what do you see?
<hellsworth> ok here is what i see: https://drive.google.com/file/d/1LLXq8kBPaNAqPc26ldAheBL-SH938936/view?usp=sharing
<hellsworth> and my command to launch it is: https://paste.ubuntu.com/p/PD6pwtsZm8/
<hellsworth> although i'm happy to use any method to boot a uc20 vm in qemu
<hellsworth> maybe the answer is to just not use core20 in kvm and rely on the rpi..
<roadmr> hellsworth: ohh I see, that doesn't look like a *snap* signature problem :/
<roadmr> hellsworth: is it possible the uc20 image is somehow broken? is it a daily? ty using an older one?
<hellsworth> i have
<hellsworth> i've actually tried several images from the last month
<hellsworth> all had the same problem
<hellsworth> so i figured it was something *I* was doing
<ijohnson> hey hellsworth
<ijohnson> so you want to boot uc20 with qemu without tpm yeah ?
<hellsworth> correct
<ijohnson> hellsworth: the issue I see with your qemu cmd you posted is that you need to specify -bios to use uefi
<roadmr> at last someone who knows what they're doing unlike me :)
<hellsworth> roadmr: thanks so much for helping and learning with me though :)
<hellsworth> okey dokey ijohnson i can toss that option in there..
<roadmr> let me know if it works :)
<ijohnson> install the ovmf pkg, then use OVMF_VARS.ms.fd from there
<hellsworth> sorry but what's OVMF_VARS.ms.fd?
<hellsworth> (ovmf is already installed)
<ijohnson> hellsworth: that's the uefi vars you need to specify on the cmdline
<ijohnson> sorry let me just show you the full cmdline
<hellsworth> thanks :)
<ijohnson> https://www.irccloud.com/pastebin/ximYskET/
<ijohnson> so since you don't have tpm drop the
<ijohnson>     -chardev socket,id=chrtpm,path=/var/snap/swtpm-mvo/current/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 \
<ijohnson> line
<ijohnson> oh sorry also you will want to copy the OVMF_VARS.ms.fd from the /usr/share/OVMF to somewhere you can write to it
<ijohnson> I just copy it to the current dir and use $(pwd)/...
<ijohnson> does that all make snse?
<hellsworth> oh yeah it does
<hellsworth> thanks!
<ijohnson> great let me know how it goes for you
<ijohnson> hellsworth: also see https://docs.ubuntu.com/core/en/releases/uc20?_ga=2.193753581.1178879775.1591618991-2086332007.1562287587
<hellsworth> /usr/share/OVMF/OVMF_VARS.ms.fd is a binary file so writing to it doesn't seem to be a thing
<ijohnson> hellsworth: no you don't write to it
<ijohnson> Qemu writes to it
<cmatsuoka> I think I have a somewhat simpler qemu command line somewhere, let me see...
<ijohnson> To store uefi vars
<hellsworth> ijohnson: ah ok re qemu needing write perms
<ijohnson> Right that's why you copy it
 * ijohnson -> errands biab 
<cmatsuoka> hellsworth: if you don't need encryption, this one also should work: https://pastebin.ubuntu.com/p/PZXjnvNDJ3/
<hellsworth> ok neat thanks cmatsuoka ! i'm actaully trying the command that is in the docs under Testing UC20 https://docs.ubuntu.com/core/en/releases/uc20
<hellsworth> good that the documented command is working :)
<hellsworth> roadmr: the answers to my questions seemed to be here https://docs.ubuntu.com/core/en/releases/uc20
<roadmr> \o/
<cmatsuoka> hellsworth: nice, I think the line from the uc20 page is the same command with parameters in a different order
<hellsworth> well it uses qemu-system-x86_64 instead of kvm directly
<cmatsuoka> ah ok, yes, that part is different
<hellsworth> so uc20 doesn't have dpkg or apt.. how do i install stuff?
<cmatsuoka> aha
<cmatsuoka> snap install
<hellsworth> mm
<hellsworth> right
<hellsworth> of course
<roadmr> that's the whole point, hellsworth !!!!! ð
<hellsworth> haha yes yes :)
<hellsworth> it's jsut my brain's defaults :)
<roadmr> whatever you do don't install crapsnap
<roadmr> (I don't think I even have anything published on that one)
<hellsworth> i'm just looking to install my locally built network-manager snap to test.. so this should be fine
<roadmr> \o/
 * cmatsuoka tries crapsnap
<hellsworth> there is a crapsnap in stable and edge..
<cmatsuoka> stable is good enough for this particular snap, I guess
<cmatsuoka> oh no docker
<hellsworth> it's interesting to me that the uc20 vm has networking because i'm obviously able to ssh into it. but it doesn't have the network-manager snap installed... if i install a new network-manager snap, then how do i know that *it* is being used/tested
<roadmr> hellsworth: did you ask cwayne_'s team? they do just that kind of thing :)
<hellsworth> hmm no.. what room is best to find that team in?
<cmatsuoka> cachio: have you seen this error before? https://github.com/snapcore/snapd/pull/8824/checks?check_run_id=759081039
<mup> PR #8824: many: move encryption and installer from snap-boostrap to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824>
<cachio> cmatsuoka, checking
<cachio> cmatsuoka, no
<roadmr> hellsworth: try #ce-certification-qa on canonical irc
<cachio> I'll try to reprpoduce it
<hellsworth> thanks roadmr
<cmatsuoka> cachio: thanks! I'm not sure if it's deterministic or not
<kyrofa> roadmr, I'm installing microk8s and I see that it's installing from a track that is not latest. Does that mean I can point latest at whatever I want now as a snap publisher? Any chance you know where the docs are for that?
<roadmr> kyrofa: probably using "default" tracks
<roadmr> kyrofa: yep, 1.18 has been marked as the default track, so trackless installs will install from (and follow) that track
<roadmr> kyrofa: https://forum.snapcraft.io/t/behaviour-change-sticky-and-default-tracks/14970 for now I don't know if there's any more documentation
<kyrofa> roadmr, how do you mark a track as default?
<kyrofa> roadmr, ah, thank you
<roadmr> kyrofa: it's a newish feature so if you do use it and have any comments/bugs please do let us know ;)
<kyrofa> Will do :)
<cachio> cmatsuoka, I couldn't reproduce the error
<cachio> cmatsuoka, I'll try again
<cmatsuoka> cachio: I suspected it was random, I'll re-run the test
#snappy 2020-06-11
<alazred> zyga: Hi there ! I made the install of snapd from scratch this morning.  There are a few things that seems off When you have a few min look at the step i took to install it. Thanks! https://pastebin.com/Mu53z5km
<zyga> alazred: can you show me the packaging file, it seems some things are wrong
<zyga> fontconfig bits are something mborzecki should look at next week
<zyga> he's off today and tomorrow, can you show up on Monday and chat with him please?
<alazred> zyga: the font config thig is an error related to telegram tho
<alazred> zyga: Yeah1 I'll try to to seek him on Monday.
<zyga> it's a more complex issue
<zyga> fontconfig broke compatibility
<zyga> and writes cache in different format without saying the version is different
<zyga> there was some more differences that were a factor that got partially resolved recently and should be released soon
<alazred> zyga: here is the PKGBUILD file https://gitlab.manjaro.org/manjaro-arm/packages/community/snapd/-/blob/master/PKGBUILD
<alazred> zyga: Those are the change that has been made yesterday. https://gitlab.manjaro.org/manjaro-arm/packages/community/snapd/-/blob/master/snapd.install
<alazred> reguarding starting the snapd.apparmor.service
<zyga> ah
<zyga> the post install feels wrong
<zyga> the socket should be started, not the service
<zyga> snapd.socket
<alazred> that was my next question
<zyga> and the other service should be *enabled*, not started
<zyga> and it should not be restarted on upgrade
<zyga> and is it snapd-apparmor.service or snapd.apparmor.service?
<zyga> the snapd apparmor service only matters on boot
<zyga> does not need to be restarted or anything
<zyga> on upgrade snapd.service should be restarted
<zyga> on install snapd.socket should be enabled and started
<zyga> and snapd apparmor service should be enabled but not started (no need to)
<zyga> compare with our first-party arch version: https://github.com/snapcore/snapd/blob/master/packaging/arch/snapd.install
<alazred> Ok and snapd.service will get started when snapd.socket will be enabled. right ?
<zyga> and even that is buggy as it doesn't mention snapd.apparmor.service
<zyga> snapd.service is socket activated by snapd.socket
<zyga> so it will start when needed
<zyga> yeah, I need to talk to maciek
<zyga> those are all low hanging fruit
<alazred> Same for snapd.apparmor.service is handled by snapd.socket
<zyga> oh?
<zyga> what do you mean?
<zyga> https://github.com/snapcore/snapd/blob/master/data/systemd/snapd.apparmor.service.in
<alazred> I mean when .socket get enabled and started it handle snapd.service and snapd.apparmor.service  when it needs it
<zyga> alazred: snapd.apparmor.service is different
<zyga> it's not socket activated
<zyga> it just needs to be enabled to run once on each boot
<zyga> it's not needed after booting
<alazred> ok all clear ! =)
<alazred> So the change needed to be done to have a proper install are: enabling and starting snapd.socket and enabling snapd.apparmor.service.
<zyga> yes
<zyga> in addition there are some things done in the arch version that should be ported over
<zyga> like handling reloading snapd
<alazred> Perfect
<zyga> I would sync with Maciek on Monday to discuss details as he knows this part better than I do
<alazred> ok I'll refer that
<alazred> Perfect thanks again for the help!
<zyga> sure, it's a pleasure :)
<alazred> zyga: One last thing. someting need to be done with the apparmor.service at all ?
<zyga> I don't quite know what's the state of apparmor in manjaro but it has the same purpose as snapd.apparmor.service - it loads profiles on boot
<zyga> apparmor profiles are text files
<zyga> that are compiled and cached into a binary form
<zyga> that is then loaded into the kernel to become effective
<zyga> that service performs that step
<alazred> ok so the snapd-apparmor.service should be sufficient
<alazred> ?
<zyga> it's not a replacement, it's just handling the part that snapd generated
<zyga> both are needed, one loads system wide profiles from packages
<zyga> and the other loads system wide profiles generated by snapd
<alazred> OK.
<mup> PR snapcraft#3168 opened: plugins: fix loading of catkin-tools <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3168>
<cachio> ijohnson, when you have 10 minutes, could you please take a look to #8755?
<mup> PR #8755: tests: fix classic ubuntu core transition auth <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8755>
<cachio> ijohnson, jello
<ijohnson> hallo
<ijohnson> cachio: yes I will take a look at that test
<cachio> ijohnson, thanks
<pedronis> ijohnson: cachio: standup?
<ijohnson> 2fa sry
<mup> PR snapcraft#3168 closed: plugins: fix loading of catkin-tools <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3168>
<roadmr> jdstrand: hey sorry didn't tell you yesterday - review-tools from 2020-06-08 (the one with the 2.45 snapdecl changes) is now in prod
<jdstrand> roadmr: nice, thanks! (cc emitorino)
 * cachio lunch
<emitorino> nice roadmr, thanks!
<abeato> ijohnson, hey, if a kernel/core snap had a failed update, will snapd try to refresh again to the same revision that failed?
<ogra> hopefully not ... you'd end up in an install loop
<ogra> (because it is likely it will keep failing if it didnt change)
<abeato> right... but I would like confirmation ;)
<ijohnson> abeato: iirc it depends on how it failed, if it was something like a network error trying to download we should retry but if the device fails to boot from it and it got rolled back no it shouldn't try again, but let me double check the code for you
<abeato> ijohnson, thanks - I'm talking here about the roll back case especifically
<pedronis> ijohnson: afair we will retry, we need a different way to remember blocked to avoid that
<ijohnson> pedronis: hmm maybe I was thinking of `snbap revert` ?
<ijohnson> but also you're right I don't see that code anywhere right now :-/
<ijohnson> actually I don't even know that a snap revert will prevent automatic refresh again
<ijohnson> I seem to recall John telling me/explaining to me how snap revert marked snaps we reverted _from_ somehow so that they were garbage collected at some point but I can't find that code at all anymore
<ijohnson> it's probably still there I just can't find it
<pedronis> ijohnson: yes, snap revert does
<ijohnson> pedronis: is that by manipulating the Sequence[] and then something else cleans up the Sequence ?
<ijohnson> that's the only logic I can find in snapstate that seems like it would clean things up
<pedronis> ijohnson: snapst.Blocked
<pedronis> sorry
<pedronis> ijohnson: I mean look at SnapState.Block
<pedronis> but yes it relates to having Current not match the top of the Sequence
<pedronis> but it doesn't help for a kernel that failed completely because that doesn't go into Sequence
<ijohnson> hmmm
<ijohnson> I must say how this garbage collection works is quite unintuitive and non-obvious :-/
<ijohnson> yeah I see how it works now for snap revert and why it won't work for kernel/base snaps
<ijohnson> abeato: so I was wrong we will retry even if the kernel failed to boot and was rolled back unfortunately
<ijohnson> abeato: if there's not already a LP bug about this could you file one? unclear when we will be able to get around to it however
<abeato> ijohnson, hm, I see...
<abeato> ijohnson, yeah, I will do that, thanks for taking a look - it certainly feels like a bug
<pedronis> it's definitely something we want to fix, but therer are some open questions around it
<abeato> ijohnson, so when will it try again? which is the time between snap refreshes?
<pedronis> 6 hours unless configured otherwise
<ijohnson> abeato: what pedronis said
<abeato> ijohnson, pedronis : https://bugs.launchpad.net/snapd/+bug/1883147 - thanks
<mup> Bug #1883147: snapd does not blacklists rolled back kernel snaps <snapd:New> <https://launchpad.net/bugs/1883147>
<ijohnson> thanks
<pedronis> thx
<ijohnson> degville: hey I just noticed that the uc20 release page doesn't have an html title for the specific page ?
<ijohnson> i.e. https://docs.ubuntu.com/core/en/releases/uc20 shows up as just "| Ubuntu for IoT Developers documentation"
<degville> ijohnson: ah, good spot - thanks - I'll fix it. Most of the pages do place their titles ahead of that IoT stanza. It's probably because I'd quite like to drop it entirely but haven't been brave enough.
<ijohnson> :-)
<mup> PR snapd#8850 opened: dirs: delete unused Cloud var, fix typo <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8850>
#snappy 2020-06-12
<mup> PR snapd#8851 opened: interface/fwupd: add more policies for making fwupd upstream strict <Created by woodrow-shen> <https://github.com/snapcore/snapd/pull/8851>
<mup> PR snapd#8852 opened: asserts: introduce new assertion validation-set <Created by pedronis> <https://github.com/snapcore/snapd/pull/8852>
<mup> PR snapd#8853 opened: asserts: introduce the concept of sequence-forming assertion types <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8853>
<mup> PR snapd#8849 closed: tests: fail in setup_reflash_magic() if there is snapd state left <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8849>
<mup> PR snapd#8755 closed: tests: fix classic ubuntu core transition auth <Simple ð> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8755>
<mup> PR snapd#8854 opened: sysconfig/cloudinit: make callers of DisableCloudInit use WritableDefaultsDir <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8854>
<ogra> mwhudson, do you still care for console-conf ? ... https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1881588
<mup> Bug #1881588: pre-seeding lxd on Core appliances breaks console-conf user creation <snapd:Invalid> <subiquity (Ubuntu):New> <subiquity (Ubuntu Xenial):New> <subiquity (Ubuntu Bionic):New> <https://launchpad.net/bugs/1881588>
<ijohnson> ogra: that's probably one for xnox these days
<ogra> ah, i didnt know he took over console-conf
<ogra> (specifically for xenian/bionic where it isnt a snap yet)
<ogra> *xenial
<pedronis> ijohnson: standup ?
<xnox> ijohnson:  huh. mwhudson is still subiquity lead
<xnox> ogra:  it is related to the previous stuff on forums etc. "there is no way to create system users/groups for a snap to use"? and/or now it is possible, but breaks other pieces of snapd?
<ogra> xnox, no it is related to a combination of "pre-seeding lxd in an appliance creates a user" .... and ... "console-conf refuses to create a user if /var/lib/extrausers/passwd containe any entry (instead of just checking the "managed" state of the system)"
<ogra> *contains
<ogra> there is some hardcoded hackery in snapd or the lxd snap that allows it to create the lxd user on install ... console-conf notes that the extrausers db has a user (even though not the system user) and falls flat on its face
<ogra> as ian described in the bug, console-conf should not check the passwd db with blind assumptions but simply check the "managed" state of the system ... that indicates a prope core system-user has been created
<ogra> *proper
<xnox> ogra:  # TODO: use proper snap APIs.
<ogra> xnox, TODO for whom ?
<xnox> ogra:  is the proper snap API to query "managed" state?
<ogra> i cant release a bunch of appliance i'm working on because of this
<xnox> ogra:  that's a code comment right next to parsing of the /var/lib/extrausers/passwd, in console_conf
<ogra> oh, yeah
<ogra> there is an API
<ogra> hah !
<ogra> xnox, https://github.com/snapcore/snapd/wiki/REST-API#get-v2system-info
<ogra> ""managed": false,"
<xnox> ogra:  but there is also https://docs.ubuntu.com/core/en/guides/manage-devices/#checking-if-a-system-user-assertion-was-created
<xnox> snap known system-user
<xnox> ogra:  what is that?
<ogra> yeah, that too
<ogra> the above is the API to query snapd
<xnox> ogra:  cause console-conf not only needs to know "if there is a system management user already" but also "what it is called"
<ogra> right
<ogra> the API isndeed only returns the state ... not the usersname
<ogra> *username
<ogra> https://github.com/snapcore/snapd/wiki/REST-API#get-v2users migth help with that
<xnox> right
<ogra> but if the system is managed i can simply refrain from running the user module (if it is a module, i havent looked at subiwuity)
<ogra> *subiquity ...
<ogra> (why does my typing suck so badly today ð )
<ijohnson> xnox: mmm actually maybe you need to be even smarter than snapd, as there could be users created on the system via cloud-init, probs if a user was created by cloud-init console-conf should not run?
<ogra> yeah ... along with the fact that cloud-init created users are typically broken for core ... i.e. will not "snap login" the user and thus the system never becomes "managed"
<ijohnson> ogra: well with cloud-init you don't have to provide SSO, so there's not an obvious way to have any user created by cloud-init a "snap user"
 * pedronis break
<ogra> right ... c-init is simply not designed for core ... (which is why i have been opposing its inclusion since day one)
<ijohnson> xnox: anyways probably the best way to fix that bug for now is just to check if snap managed is false, then run cloud-init, if there is a system user, then `snap managed` should return true
<ogra> it allows you all kinds of awful hacks and people simply never (have to) learn the proper ways
<ijohnson> xnox: (or use the API instead of the cli cmd, etc.)
<ogra> alternatively just ignoring the lxd user might be an appropriate quick fix/hack
<ogra> (and probably a potential docker one too ... though i think that one is even worse hardcoded in the readonly /etc/passwd for some obscure reason))
<ogra> yay consistency !
<ijohnson> ogra: was a bug ever filed about the docker user / group being in the base snap's /etc/{passwd,group} ?
<ogra> no, i only just remembered it again right now ... and it is indeed there
<ijohnson> ogra: that should probably be assigned to sil2100 or xnox at this point
<ogra> (no idea if it exists in core20 though)
<ijohnson> ogra: it exists in core20
<ijohnson> same as core and core18
<ogra> aha
<ijohnson> actually since core20 hasn't been released yet, perhaps we could just drop it from the base snap now and move it to extrausers ð¤
<ogra> well, it might also help to find out how exactly the lxd user gets there in the first place
<ogra> i dont really know if it comes from the lxd snap or snapd
<ijohnson> ogra: that's known it's the lxd snap doing hacks because it can
<ogra> ah
<ogra> so docker would have to be alloed the same hack
<ogra> *allowed
<ijohnson> well
<ijohnson> no, not necessarily, just because lxd gets to be hackish doesn't mean that docker should get to be hackish too
<ogra> heh
<ijohnson> anyways this is not the right channel to discuss this
<ogra> oh, note that removing a user from passwd is extremely dangerous ... the UID/GID might change underneath you but writable will have dirs using the old numbers
<ogra> (this is why the core build scripts have a bunch of pre/post-build md5 sum checks for /etc/passwd and fail hard if anything has changed)
<ijohnson> ogra: hence why I say we should fix it for core20 before it is released :-D
<ogra> right, but only there ... else you need to do awful filesystem transitions
<ijohnson> yeah I don't know how to handle other releases, but that's not my problem to fix
<xnox> ogra: i agree it's a bug. i'm not sure if fixes in consoleconf alone are enough, or if anything will be needed in snapd too.
<xnox> ogra:  pasted comments on the bug report, and hope for some advice from snapd team as to which APIs / command-line calls console-conf should use to determine if system is managed or not, and by whom.
<ogra> i'm pretty sure fixing console-conf is enough, snapd provides all info it needs
<ogra> but yeah, i'll leave it to the snapd team to answer
<kenvandine> ijohnson: hey, fontconfig is biting us again... in really fun ways
<kenvandine> bug 1858636
<mup> Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1858636>
<kenvandine> ijohnson: a snap refresh will break the cache on the host for debs
<ijohnson> kenvandine: do you mean a refresh to any snap version or a specific snap version ?
<kenvandine> any snap
<ijohnson> oh that seems ... bad ...
<kenvandine> seb128 just reproduced this with a refresh of core
 * ijohnson reads the bug
<seb128> ijohnson, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1858636/comments/37
<mup> Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1858636>
<seb128> has steps
<seb128> it screws the cache
<ijohnson> seb128: that's reproducible in a fresh focal VM for example ?
<seb128> which means fonts are missing from snap and debs
<seb128> ijohnson, yes, those steps I just tried on an autopkgtest cloud instance
<seb128> (I had it created to test something else just poked there)
<ijohnson> thanks folks I will have a look here
<seb128> ijohnson, thanks!
<kenvandine> ijohnson: thanks!
<ijohnson> hmm it seems that the focal releases zsync file doesn't work
<seb128> ijohnson, I don't think it's specific to focal and you trying on your normal system should work fine
<abeato> ijohnson, hey, how would you define the difference between plugs and slots? Because from an implementation pov, they are in the end quite symmetrical - would you say that the difference is mostly conceptual?
<ijohnson> man it is busy today in here
<abeato> lol
<abeato> nw, was just a random question
<ijohnson> abeato: uh I guess what's the answer you're looking for ? something to give to a customer or your own philosophical musinsgs?
<abeato> ijohnson, more the second
<ijohnson> abeato: yes it is mostly conceptual, but the idea reallly is that a slot is "providing" something that the plug consumes, for example with the docker interface, the slot is providing access to the docker socket
<ijohnson> seb128: when I run your final command fc-cat I see a bunch of "Unable to load the cache" messages, I presume that is your bug?
<ijohnson> kenvandine: ^
<seb128> ijohnson, no
<ijohnson> seb128: I ran the commands how do I tell if my fontconfig was broken
<seb128> that's just the cat command not being targetted
<seb128> as I wrote
<ijohnson> https://www.irccloud.com/pastebin/8FEZ1pvX/
<seb128> you should have an entry
<seb128> "NotoColorEmoji.ttf" 0 "Noto Color Emoji:familylang=en:style=Regular:stylelang=en:fullname=Noto Color ...
<ijohnson> seb128: that's what I see
<seb128> right
<seb128> it's buggy
<seb128> try now to do dpkg-reconfigure fontconfig
<seb128> and try again see if it lists a result
<ijohnson> ah yes I see now
<seb128> that's the difference
<ijohnson> after the dpkg-reconfigure I see NotoColorEmoji in the grep output
<ijohnson> ok
<seb128> somehow snap does the cache refresh in a way that misses out that installed font
<ijohnson> hmm
<ijohnson> I need to think on this, but I'm wondering if this is reproducible with any core snap refresh or if it specifically is something new
<abeato> ijohnson, ok, that what my intuition too - I was curious because in the end you can provide same permissions to either plug or socket.  And I noticed that you can even connect the same plug to two different "slot providers"
<seb128> ijohnson, the report is from january so it's not "new" as in recent
<ijohnson> seb128: kenvandine: because we did land some changes recently to the fontconfig handling but AIUI that was supposed to be for just non-ubuntu distros like arch that were broken
<ijohnson> abeato: yes plugs can be connected to many slots, i.e. see gpio pins. what ends up being unique is the _connection_ not itself
<ijohnson> *connection itself
<abeato> right
<abeato> ijohnson, thanks for the insight
<seb128> ijohnson, does snap log somewhere the output of the fontconfig cache refresh?
<ijohnson> seb128: right so I can see this with an empty /var/cache/fontconfig and edge core snap, refreshing to stable core snap will regenerate the cache, but not in a way that picks up that NotoColorEmoji font, so it is not something that is introducted between 2.45 and master right now
<seb128> it doesn't create a /var/log/fontconfig.log
<seb128> ijohnson, I will let you poke at it since you are able to trigger the issue, otherwise my comments are probably just going to slow you down/interrupt, but let me know if I can help in some way
<ijohnson> seb128: no we don't save the log anywhere
<seb128> would be useful to do :)
<mup> PR snapcraft#3169 opened: package-repositories: allow empty component list <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3169>
<mup> PR snapcraft#3170 opened: pluginhandler: no update cache for the build step <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3170>
<mup> PR snapcraft#3167 closed: unit tests: move to pytest <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3167>
<ogra> wh owns the expect snap ? i cant remember if it was chipaca, zyga or mvo who initially created it ... https://forum.snapcraft.io/t/expect-snap-not-living-up-to-expectations/18142
<ogra> *who
<ijohnson> ogra: seems to be ~snappy-dev https://launchpad.net/~snappy-dev/+snap/expect
<ogra> oh my ... snappy-hub !
<ogra> i thought that was dead since 2017 !
<ijohnson> haha apparently not
<ogra> and it was done by federico ! who is long gone
<mup> PR snapd#8855 opened: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Created by pedronis> <https://github.com/snapcore/snapd/pull/8855>
<pedronis> that was fun (#8855), not entirely
<mup> PR #8855: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8855>
<ijohnson> pedronis: seems a unit test failure on that PR
<pedronis> no, something about mkversion.sh
<pedronis> let's see if it works better now
<ijohnson> pedronis: the unit test says it can't create a dir
<ijohnson> anyways I'm sure you can debug it
<pedronis> heh
<ijohnson> why are fonts so hard
<ijohnson> the spread test we have has a working font package that shows up in the cache but we now have some font packages which do not show up in the cache we generate
<pedronis> ijohnson|lunch: I fixed it, there's some weirdness on centos now though that seems unrelated
<ijohnson> pedronis: yeah I've seen that on centos
<ijohnson> seems a package probelm
<ijohnson> *missing package
<mup> PR snapd#8856 opened: tests/main/install-fontconfig-cache-gen: for bionic, focal use broken font <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8856>
<mup> PR snapd#8857 opened: tests/lib/prepare: increase the size of the uc16/uc18 partitions <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8857>
<ijohnson> tianon: o/ do you have a minute to chat about the docker snap on UC?
<mup> Issue core20#72 opened: move docker user/group to extrausers <Created by anonymouse64> <https://github.com/snapcore/core20/issues/72>
<jdstrand> kenvandine: hey, fyi, https://github.com/snapcore/snapd/pull/8699#pullrequestreview-429340871
<mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs Samuele review> <Needs security review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
<jdstrand> kenvandine: I'm not sure alan signed up for a spread test, but it is needed. not sure if you want to reach out for someone from your team to do it in a followup
<kenvandine> jdstrand: yeah, that is probably something jamesh could help with
<jdstrand> kenvandine: I mean, he hasn't said 'no' yet, just thought I'd mention it so two weeks from now it isn't blocked on that
<kenvandine> indeed
<kenvandine> jdstrand: thanks
<jdstrand> kenvandine: thanks! :)
<roadmr> hi jdstrand ! I got a system-files request to access /proc/sys/fs/file-nr, I get the feeling tht might be best covered by another interface, got any ideas?
<roadmr> if not, is it ok to grant system-files read-only?
<jdstrand> roadmr: it doesn't exist in an interface, but file-max is in the default template. we should add it to there
<jdstrand> roadmr: feel free to issue it read only. I've taken a todo to update the default template
<roadmr> thanks jdstrand
<jdstrand> np
<roadmr> I'll allow it then! cheers!
<jdstrand> emitorino: fyi ^
