#snappy 2015-08-17
<dholbach> good morning
<longsleep> moin folks, first question of the wekk, can i somehow make a /var/log location available for a service in a snap?
<ogra_> not under confinement i think
<ogra_> stdout is logged to syslog though
<ogra_> (or to joornald if you prefer that)
<ogra_> *journald
<longsleep> ogra_: well i have a daemon which opens /var/log/blah.log and logs there until it reads its config to change the location .. kind of sucks and i was wondering if i can get around to recompile it
<ogra_> well, i assume somethin similar to /tmp might be possible here
<longsleep> ogra_: yeah - thats what i was thinking
<ogra_> kickinz1, whats up woth owncloud ? seems it doesnt work at all anymore since the docker update
<kickinz1> ogra_, I started looking at it seems like it doesn't get SNAP_APP_DATA_PATH env. I need to recontruct it.
<ogra_> well, as long as it is known :)
<kickinz1> ogra_, I plan to upload it soon to the store (ran out of time last week to work on it)
<ogra_> yeah, i didnt mean to be pushy or anything ... just noticed it on the weekend
<longsleep> ogra_: just checked the code for ubuntu-core-launcher, there is no way to setup additional bind mounts for snaps. So seems like i have to recompile the service :/
<ogra_> longsleep, well, there is code that handles /tmp somewhere ... the same code could be used for log handling
<ogra_> (not by you ... )
<ogra_> (transparently provided to you rather ... like /tmp is)
<longsleep> ogra_: yes but this would need a change in ubuntu-core-launcher - too complicated i guess
<longsleep> ogra_: code for tmp is here http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/main.c
<ogra_> Chipaca, ^^^ ?
<Chipaca> longsleep: "additional bind mounts for snaps"?
<Chipaca> i'm probably missing context here
<Chipaca> also i probably caught you in your lunch break :)
<Chipaca> ah
<Chipaca> longsleep: yeah, no, no way. either recompile, or wrap it with a preloader that changes open of things in /var/log to somewhere else
<Chipaca> there's no way to tell it to use something else?
<ogra_> Chipaca, well, on the phone we have per-app upstart los from ubuntu-app-launch ... i'm wondering if the same wouoldnt make sense on snappy
<ogra_> *logs
<Chipaca> ogra_: the per-app upstart logs are just logging stdout/err to a predetermined file, amirite?
<Chipaca> ogra_: it's not that it allows you to write to /var/log/blah.log
<ogra_> yeah
<Chipaca> i think we might be able to tell journald to write the per-app journal to a file
<Chipaca> but i'm not sure we want to
<Chipaca> of anything, we might want to expose that to app devs
<Chipaca> ie not make it the default
<ogra_> hmm, yeah
<Chipaca> s/of/if/ fwiw
<Chipaca> still no new snappy :'(
<lool> longsleep: I tried to pass the things you mentioned around RPi2 and other issues to Paolo, but it's not great on IRC; would you mind opening a bug describing the rpi2 smc issue? it seemed like something we could address in the kernel once and for all
<lool> longsleep: the other things... these seemed like workload specific and we just need a facility to set them
<ogra_> lool, not sure what makes you think longsleep had the smsc issue :) we dont have a pckage for the RPi kernel or any way to track the bugs for it ... but paolo is aware of the issue and will work on it
<lool> ogra_: I know the smc affects everyone, it's just that longsleep brought it up; I wasn't aware of it before that and wanted to pass it cleanly to paolo
<ogra_> the smsc issue only affects people that have it
<ogra_> and it was me who brought it up
<lool> ogra_: how do you mean only affects people that have it?
<lool> ogra_: so it's for an additional ethernet adapter, not the main one?
<ogra_> and as i told you on friday there is no "suits all" solution
<ogra_> smsc is a USB NIC
<ogra_> only devices that use it will be affected by the turobo mode bug
<lool> ogra_: I see
<lool> ogra_: so what's the compromise here?
<ogra_> and you have two ways to work around it ... either by switching off turbo mode or by bumping the vm_min size up
<ogra_> for the RPi kernel we can easily do the latter so people dont see decreased performance ...
<ogra_> if you would want to do this in -generic i wouldnt just bump the min addr
<ogra_> since it might have other effects and the NIC is only used in sepcific boards
<ogra_> (not in the BBB for example, which has a real NIC, nothing USB attached)
<longsleep> lool: yeah rpi2 is more for ogra_
<longsleep> lool: my issue was more a general one to inject kernel parameters (sysctl, proc stuff, ...) as early as possible without having to change initrd or other hacks
<lool> longsleep: ack
<longsleep> lool: if you want me to add a whishlist issue for that i can certainly do that
<lool> longsleep: yeah, I don't think we have anything tracking this ATM
<lool> it's all on our minds, but amongst a gazillion other issues
<lool> ogra_: I don't feel I understand why it can't be fixed properly upstream; if it can't I guess we want to document how folks would do this on top of snappy and move on
<lool> ogra_: is there an upstream pointer somewhere about this? you might have provided this on friday, but I can't find it right now
<ogra_> GRMBL ...
<longsleep> Chipaca: just saw you replies - yeah its compiled with a static path to /var/log and stuff is logged there until the config file is loaded - i guess i could hack some preloader
<longsleep> Chipaca: but a general approach to add more bind mounts within snaps would be nice to have
<lool> ogra_: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=5898&hilit=ethernet%2bhot&start=50 seems to have the most complete report of the smsc issue
<ogra_> lool, we have like 6 bugs open for that in LP since 2009 :)
<lool> ogra_: with this linaro bug describing a workaround in linaro ubuntu images https://bugs.launchpad.net/linux-linaro/+bug/664477
<ubottu> Launchpad bug 664477 in Linaro Linux "System hangs due to cascade of smsc95xx errors " [Medium,Fix released]
<lool> from 2011
<ogra_> yeah, there are older ones too :)
 * ogra_ researched all that last week before bringing it up here 
<ogra_> (and discussiong it with ppisati)
<ogra_> for the Pi kernel we will just bump the value
<ogra_> but there is no generic way of fixing it
<longsleep> ogra_: the fix is to disable turbo mode?
<lool> you can bump the vm.min_size too
<ogra_> longsleep, well, that costs yoiu performance
<longsleep> ogra_: yeah thats why i asked
<longsleep> ogra_: what parameters are you actually adding now?
<ogra_> right, we will bump the default of vm.min_size of the RPi kernel
<lool> if I understand correctly, the speed at which frames come in overflows the memory the kernel can allocate from driver context
<ogra_> which is 8192 or some such currently
<longsleep> ah
<lool> it would seem to me the kernel config at least, or the runtime should detect this combination of options and bump the vm.min_size
<lool> but in any case, we should tune our config system to set it everywhere
<ogra_> well, on devices where we have that HW and have a dedicated kernel it is easy to just change the kernel default
<lool> ogra_: it's USB though, so you could plug it into anything
<ogra_> yeah
<ogra_> i wonder if it makes sense toi generally set the vm.min_size to 16k or 32 ...
<ogra_> i'm not sure what impact that has
<ogra_> (on devices that wouldnt necessarily need it)
<lool> ogra_: I believe Kconfig can set a value as a recommended default; we could probably upstream a patch to do this
<ogra_> i know in the past we fixed it in userspace by shipping a sysctl.d snippet by default for all arm builds
<lool> yup
<ogra_> grrr ... why dont we have parted on snappy :P
<lool> ogra_: cause you haven't snap-ed it  :-)
 * ogra_ wrangles with partition resizing for /writable ... 
<ogra_> would be helpful if i could test on the actual install :)
<ogra_> lool, i havent snap'ed it because nobody did rebuild the archive for static.archive.ubuntu.com yet :P
<ogra_> (would be awesome if we could just do that :) )
<lool> it's not clear whether we want static binaries of everything
<lool> consider the case where you have like 50 binaries in your snap using the same libs
<ogra_> no, indeed, but it makes "quickly snappin somethin" so much easier :)
<lool> ogra_: you tried snapcraft?
<lool> it's pretty good at this too
<ogra_> (and my kbd still needs a new g key ...)
<lool> snappin'
<ogra_> yeah :)
<lool> somethin'
<ogra_> i should add some autocorrection to xchat to replace g with '
<ogra_> it works if i hit it very hard ... just not while typing it in a normal way
 * ogra_ knew it was a mistake to buy a logitech kbd when he bought it 
<ogra_> shiny technology ... krappy mechanics
<kyrofa_> ogra_, it was made for angry people
<ogra_> haha
<kyrofa_> ogra_, you're just too laid back
<longsleep> one of my services seems to get killed by systemd - main process exited, code=killed, status=31/SYS - any ideas?
<ogra_> well, there is surely more :)
<ogra_> (in some log)
<longsleep> no
<longsleep> i cannot find any more information
<longsleep> the service does log on stderr
<longsleep> it has networking and netowrk-service caps
<longsleep> Main PID: 1329 (code=killed, signal=SYS)
<longsleep> mhm
<longsleep> mhm
<longsleep> mkdir("/tmp/body", 0700)                = 0
<longsleep> stat64("/tmp/body", {st_mode=S_IFDIR|0700, st_size=40, ...}) = 0
<longsleep> +++ killed by SIGSYS +++
<longsleep> Chipaca: ^^^ any idea?
<ogra_> where is that mkdir ?
<ogra_> inside your daemon ?
<longsleep> in my confined service
<longsleep> yes
<Chipaca> longsleep: um, ouch?
<Chipaca> longsleep: anything in syslog?
<longsleep> Chipaca: nope :/
<longsleep> rate limiting is off
 * longsleep is trying to confine nginx
<longsleep> well, it fails for /tmp too
<longsleep> mkdir("/tmp", 0700)                     = -1 EEXIST (File exists)
<longsleep> stat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=40, ...}) = 0
<longsleep> +++ killed by SIGSYS +++
<longsleep> so i think it is the stat64?
<Chipaca> longsleep: what does it do after the stat64?
<Chipaca> jdstrand: tyhicks: you around?
<longsleep> i did not look into the code - hold on
<ogra_> hmpf ... i thinnk i shouldnt pull parted into the initrd ...
<ogra_> not sure we want libreadline in there
<ogra_> (and ncurses through that )
<longsleep> ogra_: sfdisk should be good enougth?
<ogra_> well, we used to use that in the past for the same purpose ... i'd prefer parted since thats what we use everywhere else though
<ogra_> (installer etc)
<ogra_> but yeah, iirc that was actually the reason why we picked sfdisk back then too
<jdstrand> Chipaca: I am, Tyler is not
<Chipaca> longsleep: is the SIGSYS in a service, or in commandline?
<longsleep> Chipaca: no idea what comes next :/ body folder is created fine and then bam
<longsleep> Chipaca: service
<Chipaca> jdstrand: these lackeys always slacking off, huh
<jdstrand> heh
<jdstrand> he is on holiday today, back tomorrow :)
<Chipaca> jdstrand: would a SIGSYS be seccomp doing something?
<Chipaca> or is it unrelated to that?
<jdstrand> seccomp should send SIGKILL
<jdstrand> and you would see a log entry
<Chipaca> yah
<Chipaca> longsleep: SIGSYS usually means "bad system call"
<ogra_> longsleep, are you sure its not an amd64 binary ?
<ogra_> :)
<longsleep> ogra_: yes it runs fine when unconfined or run directly
<Chipaca> ooh
<Chipaca> longsleep: strace that :)
<longsleep> Chipaca: output is from strace :)
<Chipaca> longsleep: strace -f -s 999 -o /tmp/trace yoursvchere
<Chipaca> longsleep: i mean unconfined
<longsleep> ah
<longsleep> ok
<longsleep> good idea
<Chipaca> longsleep: then we see what comes next \o/
<longsleep> is there a quick way to unconfine a installed snap?
<Chipaca> longsleep: edit the call to ubuntu-core-launcher and plug unconfined instead of the second parameter? never tried it though :)
<Chipaca> longsleep: that'd mean editing /etc/systemd/system/something.service
<Chipaca> longsleep: or you could just remove the call to the launcher entirely :)
<longsleep> ok next comes chown32("/tmp/body", 65534, -1)   = 0
<longsleep> guess that is the problem
<longsleep> so .. no change owner?
<longsleep> at least not to nobody i guess
<Chipaca> longsleep: that's interesting
<Chipaca> jdstrand: would you expect that?
<Chipaca> jdstrand: it's clearly something in our confining apparatus doing it, but i don't understand what/how
<jdstrand> we don't allow chown because there is no reliable uid to chown to
<jdstrand> but, this is unconfied, no? nothing should be blocking it
<longsleep> i want to run it confined
<longsleep> (this is a web server, so it really should be)
<Chipaca> jdstrand: we found out it was chown running it unconfined
<jdstrand> also, we are using SCMP_ACT_KILL in the launcher so a sigsys won't be sent
<Chipaca> jdstrand: running it confined we get sigsys, and nothing in the logs
<Chipaca> hence a puzzled chipaca
<Chipaca> i say we, but it's all longsleep all the time :)
<longsleep> yeah but what you say is how it is
<jdstrand> seccomp can send sigsys, but only if seccomp_init is given SCMP_ACT_TRAP
<Chipaca> which makes me think maybe i should do a test case and see if i can reproduce it
<longsleep> Chipaca: well, this is nginx startup
<jdstrand> systemd can also send sigsys if a syscall filter is setup through systemd
<Chipaca> ooooh
<Chipaca> jdstrand: that might be it then?
<jdstrand> are we setting that up now? it has to be something specific in the service file
<Chipaca> jdstrand: not unless we're doing it unawares
<Chipaca> or it's the default or something
<jdstrand> it should not be the default
<jdstrand> everything would break
<jdstrand> http://www.freedesktop.org/software/systemd/man/systemd.exec.html
<jdstrand> SystemCallFilter=
<longsleep> i do not see anything in the service file
<longsleep> http://paste.ubuntu.com/12108429/
<jdstrand> plus it would be redundant with the launcher syscll filtering
<Chipaca> ok, meeting now
<Chipaca> after meeting will reproduce with small case
<Chipaca> then pester you again jdstrand ;)
<longsleep> well what i see is that chown seems to trigger sigsys
<longsleep> all right - thanks guys!
<jdstrand> chown should trigger sigkill
<jdstrand> and there should be a log entry
<jdstrand> but I didn't think you got all the way to chown before
<jdstrand> I thought the sigsys came before that and you only saw chown when you went unconfined
<longsleep> jdstrand: well strace says +++ killed by SIGSYS +++
<longsleep> yes
<longsleep> jdstrand: here are the two strace parts http://paste.ubuntu.com/12108465/
<longsleep> so i concluded the chown is the reason for the kill
<jdstrand> longsleep: according to man 7 signal, SIGSYS is sent when a bad argument is used. are you specifying a uid to chown that doesn't exist?
<longsleep> jdstrand: that could be it
<longsleep> jdstrand: what uid should i actually use?
<jdstrand> well, as mentioned, you shouldn't use chown at all
<longsleep> jdstrand: but the uid 65534 is nobody and it does exist
<jdstrand> if you picked one that existed, then seccomp would kill you
<longsleep> jdstrand: well it is done by Nginx - i do not have much a say in the matter
<longsleep> jdstrand: so you say when i chown to an existing uid then seccomp will kill the process?
<jdstrand> yes
<longsleep> thats it then
<jdstrand> except I don't think it is
<jdstrand> because you are seeing the wrong signal
<jdstrand> but really, it doesn't matter, cause if you fixed whatever this problem is, seccomp would block you
<longsleep> ok - but it is calling chown with a uid which does exist
<jdstrand> the reason why we don't allow it at the moment is because the launcher doesn't support syscall argument filtering and because there is no reliable uid to chown to (in general)
<jdstrand> so, patch out the chown or otherwise tell nginx to run as root
<longsleep> jdstrand: nginx will not run as root, if you run it as root it will setuid to nobody
<longsleep> and i was trying to avoid patches :/
<jdstrand> it sounds like that behavior needs to be modified
<jdstrand> fyi, syscall arg filtering is being tracked in bug #1446748
<nothal> Bug #1446748: implement seccomp filtering by argument <ubuntu-core-launcher (Ubuntu):Triaged> <ubuntu-core-security (Ubuntu):Triaged> <http://launchpad.net/bugs/1446748>
<ubottu> bug 1446748 in ubuntu-core-security (Ubuntu) "implement seccomp filtering by argument" [Wishlist,Triaged] https://launchpad.net/bugs/1446748
<jdstrand> but that wouldn't be enough for your case-- you also need a non-root uid to start as
<jdstrand> which is another unimplemented feature in snappy
<jdstrand> from the seccomp security policy:
<jdstrand> # snappy doesn't currently support per-app UID/GIDs so don't allow chown. To
<jdstrand> # properly support chown, we need to have syscall arg filtering (LP: #1446748)
<jdstrand> # and per-app UID/GIDs.
<ubottu> Launchpad bug 1446748 in ubuntu-core-security (Ubuntu) "implement seccomp filtering by argument" [Wishlist,Triaged] https://launchpad.net/bugs/1446748
<longsleep> jdstrand: all right, so if understand this correctly, i would need both to run nginx unconfined
<longsleep> err confined
<longsleep> because nginx does fail with chown, and then will try to change the uid as it is run as root
<longsleep> jdstrand: so the much bigger problem is that there is no way to start a snap service with a uid other than root right?
<jdstrand> it is a missing feature
<longsleep> jdstrand: ah the trick was simple after i understood this: user root root;
<longsleep> then it will not chown and not setuid/gid
<longsleep> jdstrand: thans for explaining!
<longsleep> +k
<jdstrand> ok, glad that worked. still puzzled why you were sent a sigsys
<longsleep> jdstrand: well yeah - no i get the next sigsys .. seems like the worker processes get killed of
<longsleep> f
<Chipaca> jdstrand: confirmed that i get SIGSYS not SIGKILL when running something that does chown
<Chipaca> jdstrand: but, i do get something in the log
<Chipaca> [Mon Aug 17 15:36:52 2015] audit: type=1326 audit(1439825813.354:13): auid=1000 uid=1000 gid=1000 ses=1 pid=994 comm="q" exe="/apps/hello-world.canonical/1.0.18/bin/q" sig=31 arch=c000003e syscall=92 compat=0 ip=0x7f65d470c4d7 code=0x0
<longsleep> Chipaca: can the audit log crash, the last audit stuff i see is from ths morning :/
<Chipaca> longsleep: what do you get if you say "sudo sc-logresolve"?
<longsleep> Chipaca: nothing - no output
<Chipaca> ah well
<Chipaca> longsleep: i haven't known it to, but i tend to fire a kvm up, test stuff, and shut it down again
<Chipaca> my bbb hasn't ever crashed in that way that i know of though
<Chipaca> also i don't think it's "a thing" that can crash
<longsleep> Chipaca: let me try to reboot, i have the next sigsys kill - means i can only run nginx without a master process which is not suitable for production
<Chipaca> you'd lose all logs, not just the audit ones
<longsleep> right
<longsleep> rebooting now
<longsleep> Chipaca: no audit logs for me but plenty of worker process 6715 exited on signal 31
<longsleep> :(
<Chipaca> it might because i'm not doing this as a service
<Chipaca> that's next
<Chipaca> man, i need tab completion on 'snappy install'
<davmor2> Chipaca: alias si
<Chipaca> longsleep: so, as a service, SIGSYS, with log entry
<Chipaca> e.g. Aug 17 15:51:10 localhost kernel: [  945.918847] audit: type=1326 audit(1439826670.799:20): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1120 comm="q" exe="/apps/xkcd-webserver.canonical/0.5/bin/q" sig=31 arch=c000003e syscall=92(chown) compat=0 ip=0x7f8da417a4d7 code=0x0
<Chipaca> (as output from sc-logresolve)
<longsleep> Chipaca: mhm ok then - so any ideas why it could not log that for me?
<Chipaca> longsleep: well, two ideas
<Chipaca> longsleep: my environ is not your environ -- i'm trying on a kvm with wily rolling and you're on 15.04
<longsleep> Chipaca: yes and on armhf
<Chipaca> longsleep: and, your thing is doing a whole lot more than mine is
<Chipaca> longsleep: want to try running my thing on your thing?
<Chipaca> longsleep: otherwise i could try running my thing in your thing :)
<longsleep> Chipaca: sure - do you have an armhf snap?
<Chipaca> longsleep: no, i just compiled it and copied it over
<Chipaca> longsleep: but i'll make one for you
<Chipaca> give me a bit though :)
<longsleep> Chipaca: you can try my snap if you have an armhf environment
<Chipaca> longsleep: i've got a bbb, but i'd have to reflash it to know where it stands (i usually break them! because, um, i just compile stuff and copy them over ;) )
<longsleep> Chipaca: btw, i see the audit logs when i install or remove snaps
<longsleep> Chipaca: i meanm the profile status lines
<Chipaca> longsleep: curiouser and curiouser
<longsleep> Chipaca: just sent you the URL as pm, that triggers signal 31 kills constantly
<Chipaca> longsleep: http://people.canonical.com/~john/min_0_armhf.snap
<longsleep> Chipaca: (as the worker process is killed)
<jdstrand> so, after looking at the kernel documentation (as opposed to the man page), it does look like the exit status of the task will be SIGSYS in we are setup for kill
<Chipaca> jdstrand: \o/
<Chipaca> jdstrand: so the only question remaining is why longsleep isn't seeing it in the logs
<Chipaca> longsleep: that snap is untested ;) but it should give you a binary and a service
<jdstrand> perhaps kernel rate limiting is in effect?
<Chipaca> longsleep: that run the same thing
<Chipaca> jdstrand: longsleep mentioned he'd disabled it i think
<longsleep> jdstrand: sysctl -w kernel.printk_ratelimit=0
<longsleep> i have that in effect
<jdstrand> this is on armhf? I have a sneaking suspicion that there is something wrong with logging on armhf cause I have felt that sometimes messages were getting dropped when they should've been logged, but I've never been able to reproduce when I want to
<longsleep> yes
<longsleep> armhf yes
<jdstrand> but it is just a feeling
<jdstrand> perhaps if you reboot you'll see it
<longsleep> i rebooted and no change
<longsleep> but i see this: audit_printk_skb: 12 callbacks suppressed
<jdstrand> hmm, yeah, I don't know then
<longsleep> should that happen when i have the ratelimit disabled?
<jdstrand> right so the sysctl value will of course be dropped on reboot
<longsleep> i applied it again
<longsleep> Chipaca: your service failed to start but no audit except http://paste.ubuntu.com/12109082/
<longsleep> Chipaca: and no audit when running min.q
<Chipaca> longsleep: :(
<longsleep> so either its my system, my kernel or a general issue on armhf
<jdstrand> maybe you should apply kernel.printk_ratelimit=0 to something in /etc/sysctl.d
<longsleep> let me try
<jdstrand> eg, /etc/sysctl.d/99-debug-ratelimit.conf or something
<jdstrand> then reboot
 * longsleep reboots
<longsleep> jdstrand: well i might have an idea
<longsleep> systemd-journald[360]: Failed to join audit multicast group. The kernel is probably too old or multicast reading is not supported. Ignoring: Operation not permitted
<jdstrand> interesting
<longsleep> i am on kernel 3.10
<longsleep> otherwise no difference after reboot
<jdstrand> is anything in dmesg?
<longsleep> well
<longsleep> sysctl -a|grep printk
<longsleep> kernel.printk = 4	4	1	7
<longsleep> kernel.printk_delay = 0
<longsleep> kernel.printk_ratelimit = 5
<longsleep> kernel.printk_ratelimit_burst = 10
<longsleep> it did not apply what i set
<longsleep> but i added the file
<longsleep> mhm
<longsleep> well the procps service does not seem to apply settings from /etc/sysctl.d
<jdstrand> according to http://www.freedesktop.org/software/systemd/man/sysctl.d.html, systemd is supposed to do that
<jdstrand> systemd-sysctl.service
<jdstrand> I don't know if snappy let alone Ubuntu uses that
<longsleep> yes if i do systemctl restart systemd-sysctl.service it gets applied
<longsleep> not on boot though
<jdstrand> interesting
<jdstrand> /etc/init/procps.conf is the upstart job
<jdstrand> so that won't be run
<longsleep> right, still my old habits
<longsleep> let me boot again
<jdstrand> maybe pitti or ogra_ has insight as to how /etc/sysctl.d should be applied on boot and why systemd-sysctl.service is seemingly not being run
<jdstrand> "systemd-sysctl.service is an early-boot service that configures sysctl(8) kernel parameters"
<jdstrand> not sure why if you created /etc/sysctl.d/99-your-thing.conf why it wouldn't by applied
<longsleep> (ODROIDC)root@odroid:~# sysctl -a|grep "kernel.printk_ratelimit "
<longsleep> kernel.printk_ratelimit = 5
<jdstrand> unless there is a bug
<longsleep> that is after boot
<jdstrand> and what is the name of the file you created?
<longsleep> systemctl restart systemd-sysctl.service
<longsleep> (ODROIDC)root@odroid:~# sysctl -a|grep "kernel.printk_ratelimit "
<longsleep> kernel.printk_ratelimit = 0
<longsleep> how you suggested
<longsleep> cat /etc/sysctl.d/99-debug-ratelimit.conf
<longsleep> kernel.printk_ratelimit = 0
<jdstrand> seems there is a bug that those aren't being applied
<longsleep> let me try to add it to an existing file then
<jdstrand> I would be surprised if that work-- I imagine the service itself isn't being started
<longsleep> ah i think that is a mount order issue
<longsleep> i cannot change the other files - those are readonly
<longsleep> ah not all of them
<longsleep> now added it to 10-zeropage.conf
<jdstrand> that would make sense
<longsleep> did not work either
<longsleep> so there is a bug for sure
<jdstrand> can you file it against https://bugs.launchpad.net/snappy/+filebug?
<longsleep> my most likely guess is that /dev/mmcblk0p4 on /etc/sysctl.d type ext4 (rw,relatime,data=ordered) is not mounted when the systemd service is run
<longsleep> jdstrand: sure
<jdstrand> yeah, when you suspected mount ordering, I was thinking you were probably onto something
<ogra_> jdstrand, uh, i didnt even know it isnt run
<ogra_> thats clearly a bu
<ogra_> g
<longsleep> jdstrand: bug #1485683
<nothal> Bug #1485683: /etc/sysctl.d is not applied on boot <Snappy:New> <http://launchpad.net/bugs/1485683>
<ubottu> bug 1485683 in Snappy "/etc/sysctl.d is not applied on boot" [Undecided,New] https://launchpad.net/bugs/1485683
<jdstrand> cool, thanks
<longsleep> Chipaca: so i can now run Nginx confined but as a single process, whatever happens when the child is started, it fails with sigsys and i have no log :(
<ogra_> Chipaca, mvo, seems the last snappy build now fails in manpage generation
<Chipaca> huzzah!
<mvo> we are moving forward
<ogra_> no idea why we run it :)
<Chipaca> that one is probably my fault :)
<ogra_> (is there actually a manpage ?)
<Chipaca> ogra_: sergiusens asked for it
<mvo> yes!
<mvo> we don't have man but â¦
 * Chipaca symlinks man to less and makes everybody have a fit
<ogra_> dont make cjwatson cry !
<seshu> Hello, I'd like to install mir and my application. How do I make snappy autologin?
#snappy 2015-08-18
<clobrano> Hi all
<ogra_> hey clobrano
<clobrano> hi ogra_, a little question, I looked around but I haven't found anything so far: I would need to change something in a driver (e.g. option), like adding a vid/pid pair
<clobrano> usually, I would recompile the kernel with this change, is that possible on ubuntu core? Is there another way to do so?
<ogra_> clobrano, you mean via a udev rule or dircetly in the driver ?
<clobrano> ogra_: directly in the driver
<ogra_> for that i fear you have to recompile the kernel,. yes
<clobrano> is that still possible for ubuntu core?
<ogra_> (thouht often enough a udev rule is enough to tell the kernel to load a specific driver)
<clobrano> ogra_: unfortunately this is necessary for our project
<ogra_> what device is that ? for armhf we have semi-good documentation for building the device tarball ... i'm not sure we have anything for x86 (where the tarball gets auto-generated by the image build system)
<ogra_> you would actually build your own device tarball for what you want to do and use that with ubuntu-device-flash to generate an image
<zyga> ogra_: hmm, no lspci/lsusb on snappy?
<clobrano> ogra_: well, the documentation for armhf could be a good starting point
<ogra_> clobrano, https://developer.ubuntu.com/en/snappy/guides/porting/ see the section about the devcie tarball, hardware.yaml etc
<clobrano> ogra_: thanks ;)
<ogra_> zyga, real men use /sys directly :P
<zyga> ogra_: and remember all the enums ;)
<ogra_> indeed, from the top of their head :)
<asac> anyone around who knows snapcraft?
<asac> ted: ogra_: ?
<asac> i need to run a command for building qt5 from source after the checkout
<asac> is there a hook feature post-pull or something?
<lool> asac: I've been requesting hooks for a while
<lool> asac: but instead, just create a make part and use the bits from the qt parts
<asac> lool: not sure i understand
<asac> i should derive a new plugin?
<asac> e.g. on autotools
<asac> and then extend the pull code to run a command in srcdir ?
<asac> hmm. shouldn the make plugin allow to allow specific mark targets that are not make; make install?
<asac> lool: is it possible to have a local part in a snapcraft tree that doesnt pull anything?
<asac> e.g. can i make my parts/qt5/ directory and put a makefile in there that then does all it needs ?
<asac> guess i am on wrong track
<lool> asac: so your goal is what again?
<lool> asac: most of the time, you don't need a new plugin
<lool> plugins are for recurring cases
<lool> asac: we don't have any config in the make plugin; it indeed defaults to make and make install DESTDIR=...
<lool> asac: if you don't want to pull anything, just say source: .
<asac> lool: qt5 from git... you git clone topath; cd topath; perl init-repository
<asac> i dont know how to best run init-repository
<asac> lool: its like repo sync that gets all the real source
<lool> asac: while you could hack this around with a makefile, if you want the "pull" semantics of snapcraft to map to this different way of pulling, you indeed need a plugin
<asac> lool: right. wondered if there could be a post-pull mangling hook
<asac> maybe all stages should have pre and post hooks?
<asac> guess not very clean
<asac> lool: can i write local plugins yet?
<asac> or do i best work inside the snapcraft tree to add new plugins?
<lool> asac: I personally would like the pre- / post- hooks as I feel it would be useful, however it's not in the spirit
<lool> snapcraft documents parts, not actions/tasks
<lool> so hooks already feel wrong there
<asac> right
<lool> and then hooks would potentially make it harder to port snapcraft to non-linux platforms
<asac> well i kind of agree on spirit
<asac> but i hate the non-reuse feature of deriving from a specialized class
<lool> if people start having a bunch of shell scripts running sudo apt-get install foo etc.
<asac> so maybe having a plugin system that allows to add reusable things pre-post would be good
<asac> so write a post-pull plugin that you can add through an option in parts to any plugin
<asac> maybe call it extension :)
<asac> for instance
<asac> copy
<asac> many want that i guess
<asac> maybe could go in Base
<asac> but if not, its not good for reuse
<asac> as it is
<asac> assuming there are many useful helper thingies that not all want ...
<ogra_> mvo, is there a bzr tree for initramfs-tools-ubuntu-core ?
 * ogra_ cant seem to find one
<mvo> ogra_: just https://code.launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core
<mvo> ogra_: but freel free to setup one
<ogra_> ah
<biezpal> Hey everyone. We're trying to run lxc-start command and getting the following apparmor message in syslog
<biezpal> apparmor="DENIED" operation="file_inherit" profile="/usr/bin/ubuntu-core-launcher" name="/dev/null" pid=17552 comm="ubuntu-core-lau" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<biezpal> It seems like apparmor profile for ubuntu-core-launcher is blocking lxc-start command. Our profile for lxc-start is ignored, what we are doing wrong?
<biezpal> ogra_, I believe you can help us :)
<ogra_> biezpal, i guess jdstrand is better in that ...
<ogra_> one thing to keep in mind if you sideload a snap is that the profile is only re-generated if you have a new version number
<ogra_> so bump that before installing your snap locally
<biezpal> ogra_, ok, thanks
<biezpal> jdstrand, could you advise something?
<jdstrand> hey, reading
<jdstrand> biezpal: I'd need to look at the snap. is it in the store? how are you invoking it?
<jdstrand> biezpal: actually, looking at the denial, it is in the launcher. can you adjust '/etc/apparmor.d/usr.bin.ubuntu-core-launcher' to have this before the trailing '}': /dev/null rw,
<jdstrand> biezpal: then do: sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher
<jdstrand> biezpal: then try again
<cwayne> heya, whats the easiest way to resize my snappy kvm image so that i can install larger snaps?
<ogra_> cwayne, well, add zeros to the end of it, resize the writable partition, resize the filesystem on the writable partition
<ogra_> http://paste.ubuntu.com/12117162/
<ogra_> :D
 * ogra_ is just working on a prototype to do exactly that on first boot
<Chipaca> ogra_: https://code.launchpad.net/~chipaca/snappy/manpage-ftbfs/+merge/268330 if you've got a sec?
<Chipaca> (not many people with review-ability right now ;) )
<ogra_> Chipaca, sorry, was dragged away for a moment ... as far as i can judge that code it looks fine :)
<Chipaca> ogra_: evil draginses awayes
<ogra_> Chipaca, in line 25 ... are you sure /usr is in $BUILDDIR ?
<ogra_> or was /usr/bin/snappy the whole wrong path anyway ?
<Chipaca> ogra_: snappy is just under obj-yadda/bin/
<Chipaca> ogra_: http://pastebin.ubuntu.com/12118266/ is what i got when running find in debian/rules
<ogra_> Chipaca, ack ... approving then
<ogra_> done
 * Chipaca gefingercrossen
<ogra_> haha
<ogra_> Chipaca, hmm, same error it seems
<ogra_> can't load package: package launchpad.net/snappy/i18n/xgettext-go
<Chipaca> ogra_: i see a successful build on amd64
<ogra_> ah, then that was i386 only
<ogra_> https://launchpadlibrarian.net/214836852/buildlog_ubuntu-wily-i386.ubuntu-snappy_1.5ubuntu1-1%2B632~ubuntu15.10.1_BUILDING.txt.gz
<Chipaca> armhf worked too
<Chipaca> i say we drop i386 from supported architectures and move on
<ogra_> haha
<ogra_> tell that to the edison people :P
<jdstrand> stgraber: fyi in case you missed it, I commented on the lxd snap in the store. please see the review comments
<longsleep> ogra_: did you see my script for the resize: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh - any reason you do not use 'growpart' ?
<ogra_> longsleep, what are the deps and does it support any kind of filesystems ?
<ogra_> i wanted to use parted since thats our standard tool and gets the most maintainer attention ... but parted has to big deps to ship it inside the initrd
<longsleep> ogra_: growpart is on snappy already
<DarwinF> I sideloaded an app onto my RPi and whenever I try to start the service I get an error with "... name org.freedesktop.PolicyKit1 not provided..." Is there a way to fix that?
<longsleep> ogra_: (its coming with cloud init i think)
<ogra_> longsleep, ah, i need it in the initrd ... i'll have to take a look
<stgraber> jdstrand: thanks. At a conference this week, will check next week.
<longsleep> ogra_: all that cut tr sed stuff from your script looks scary - so maybe growfs can help to avoid that
<ogra_> longsleep, whats scary about it ?
 * ogra_ fids it crystal clear ;)
<ogra_> *finds
<longsleep> ogra_: :D
<longsleep> well i guess i thind multiple sed tr cut pipes scary in general
<ogra_> well, yeah, its a prototype ... normally i'D merge the tr/cut stuff into one sed line :)
<ogra_> and it is likely throw away work anyway
<longsleep> ogra_: yeah, it is totally valid to use
<ogra_> just to get the feature fast ... later it will get re-implemented
<longsleep> ogra_: also i took a different approach to find the partition - i was not using findfs instead i use blkid and go through /sys to find all the stuff
<ogra_> yeah, findfs is used all across the initrd ...
<ogra_> which made me pick it ...
<longsleep> right
<longsleep> ogra_: though i wonder why do you need the sanitizing code, should it not return good values already?
<ogra_> longsleep, it returns the device node for the partition
<ogra_> if i use a USB key that will be /dev/sdn1
<ogra_> for mmc you have /dev/mmcblknp1
<ogra_> so you always get the XpX in mmc nodes ...
<longsleep> ogra_: ok, so then i would recommend to use /sys to find whatever else you need, instead to use that case block
<longsleep> (starting from /sys/class/block/..)
<ogra_> hos does that help me getting rid of the p ?
<ogra_> *how
<ogra_> i need to get from the return value from findfs to the device name ...
<jdstrand> stgraber: sure, np. just wanted to make sure you saw them
<jdstrand> stgraber: enjoy :)
<longsleep> ogra_: well i dont know but i think whatever findfs returns should have its entry in /sys/class/block/
<ogra_> and non mmc'S return the right thing while mmcs do return something with a XpX at the end
<longsleep> ogra_: that folder should contain anything else
<longsleep> ogra_: the name should not matter when you traverse through sys
<ogra_> hmm
<longsleep> ogra_: you can find the device name by following the symlink of /sys/class/block/whatever
<longsleep> ogra_: then go one level up and read the dev
<longsleep> file
<longsleep> that will work whatever names the block partitions have
<longsleep> eg /sys/class/block/sda1 -> ../../devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
<longsleep> follow the symlink, then ../dev is the name of the device
<ogra_> not in case of mmc :)
<longsleep> no?
<ogra_> no, the content of dev just pÃ¼oints back to the partition
<longsleep> go one level up
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /sys/class/block/mmcblk0p2/dev
<ogra_> 179:2
<longsleep> yes and then follow that symlink again below /dev/block/179:2
<ogra_> /sys/dev/block/179:2/dev is just the same thing
<longsleep> right, one more level of links to follow
<ogra_> going one level up wont get me mmcblk0
<longsleep> when you have 179:2 open the link of /dev/block/179:2
<longsleep> will be ../sda or similar
<longsleep> then you have it
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ readlink /sys/dev/block/179:2
<ogra_> ../../devices/platform/mmc-bcm2835.0/mmc_host/mmc0/mmc0:0007/block/mmcblk0/mmcblk0p2
<ogra_> ah, i get what you mean
<longsleep> you are still one level too deep
<ogra_> yes, but that actually allows to go up
<ogra_> i doubt it will be much less code than the case statement (which is way to big anyway, the *) stuff is superfluous )
<longsleep> it will not be less code, but it will support anything the kernel can come up to. I do not know how many possible partition naming schemes there are
<ogra_> yeah, indeed
<longsleep> thats why i wanted to use the kernel provided information to find stuff
<ogra_> well, i guess i'll re-use some of your resize-snappy lines :)
<ogra_> looks indeed a bit saner :)
<ogra_> though i still dont think i'll use growpart, that would introduce a hard dep of initramfs-tools-ubuntu-core on cloud-guest-utils
<longsleep> ogra_: yeah - if you can get the sfdisk stuff working that should be totally fine
<ogra_> (and i need the size checks ahed of running anything ... we only want to grow if it it actually useful)
<ogra_> *if it is
<longsleep> grofpart just gives you all the gear already and checks if there is something to resize
<longsleep> grow*
<ogra_> i dont see you running fsck ...
<longsleep> yeah growpart has this --fudge parameter which does that check
<longsleep> yeah i am not running fsck
<longsleep> probably bad :(
<ogra_> how do you make resizefs work without it ? by default it should refuse any operation if there isnt a fresh fsck
<longsleep> mhm maybe growpart does that
<ogra_> yeah
<Chipaca> ogra_: you poked at an image build?
<ogra_> Chipaca, eeek, sorry !!
 * Chipaca scribbles in a little black book, tutting disparagingly
<ogra_> Chipaca, running
<ogra_> no little star sticker for me today i guess :/
<Chipaca> ogra_: well, we can't go handing out golden stars just like that now, can we?
<longsleep> I am going to FrOSCon on the weekend, someone of you folks going too?
<longsleep> there is a snappy and an ubuntu phone talk on saturday
<ogra_> longsleep, i think thats svij's talk :)
<svij> ogra_: longsleep: yep
 * davmor2 notices ogra_ is now listed on Santa Naughty list, Man that Chipaca has friends in high places
<davmor2> hmmmmm wait a minute, you never see Chipaca and Santa in the same room........he writes in a book and.......wait a minute
<Mikaela> I thought only sudo without being sudoer resulted to that list
<Chipaca> davmor2: Mikaela: i was *wondering* why i got everybody's sudo alert mail
<Chipaca> it all makes sense now
#snappy 2015-08-19
<biezpal> jdstrand, hey, sorry high latency :)
<biezpal> jdstrand, again about ubuntu-core-launcher apparmor profile - remounted / to rw, added "/dev/null rw" and everything worked
<biezpal> jdstrand, how we can do the same without remounting ro volume?
<biezpal> jdstrand, Isn't a read access to /dev/null a normal behavior for app?
<biezpal> *write
<jjohansen> biezpal: PoLP, its not used by many apps
<jjohansen> if ubuntu-core-launcher is using it then we need to make sure it gets added to the profile so that it is there as part of the ro image
<biezpal> jjohansen, ok, then how could I run my app?
<biezpal> without changing ubuntu-core-launcher profile
<jjohansen> I would assume, that there is an abstraction that allows it, if not there should be
<jjohansen> or you could go the route of additional rules
<jjohansen> I think that would trigger a rule
<jjohansen> s/rule/review/
<jjohansen> eg. the permy app has additional read paths set, and additional write paths
<jjohansen> oh hrmm, just check not additional write, but additional read
<jjohansen> I'd have to lookup how to specify that in the manifest
<biezpal> but the problem is that ubuntu-core-launcher cannot write to /dev/null, even before my app starts
<biezpal> apparmor="DENIED" operation="file_inherit" profile="/usr/bin/ubuntu-core-launcher" name="/dev/null" pid=17552 comm="ubuntu-core-lau" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<jjohansen> biezpal: then the ubuntu-core-launcher app is missing a rule it needs, its profile will have to be updated
<jjohansen> you can remount and run your app locally but until that change rolls out ...
<biezpal> jjohansen, I've added /den/null rw to the launcher profile as jdstrand advised and everything became ok
<biezpal> so, we should wait until next Snappy update?
<jjohansen> right, it needs to be updated in the base image, other wise other people won't be able to run it without doing the remount, and adding of the permission
<biezpal> jjohansen, ok, thank you. Waiting for update :)
<dholbach> good morning
<biezpal> good morning
<ogra_> off to the dentist ...
<Chipaca> ogra_: you have all the fun
<Chipaca> whee! in wily rolling we now can do "sudo snappy service xkcd-webserver stop" \o/
<Chipaca> also "snappy man|less"
<Chipaca> which is only useful if you can read troff
<Chipaca> :)
<biezpal> wow, nice
 * ogra_ sees the recent systemd discussion on ubuntu-devel-discuss and wonders if "snappy service" was such a clever idea :P
<ogra_> (oh, and re ... :))
<Chipaca> woo, random-versioned sideloaded packages works
<Chipaca> the tests are all grumpy tho
<jdstrand> biezpal: re /dev/null and remounting> for now, you can't do anything else. it is a bug in the launcher. we should get it fixed
<Chipaca> jdstrand: what's the bug?
<jdstrand> Chipaca: lack of /dev/null rw in the profile
<jdstrand> Chipaca: I am preparing an upload for wily as we speak
<Chipaca> ahh
<Chipaca> ok :)
<Chipaca> jdstrand: i read "bug in the launcher" as something wrong in the c code
<jdstrand> Chipaca: are you guys planning an upload for the launcher for vivid?
<jdstrand> if not, I'll upload to the ppa too
<Chipaca> jdstrand: i know of no such plans
<Chipaca> jdstrand: which says more about how much attention i'm paying to that kind of plans than of the plans themselves
<jdstrand> haha
<jdstrand> well, the launcher has been pretty stable for a while. I'll just do the upload :)
<Chipaca> which reminds me
<Chipaca> elopio: with yesterday's image, amd64 and armhf images should now have a network interface on first boot
<Chipaca> let me confirm that just in case
<Chipaca> yep! just booted kvm, got an iface right away
<Chipaca> \o/
<jdstrand> biezpal: ok, uploaded fix to wily and the image ppa. the fix should be in edge in the next image or two
<longsleep> Chipaca: will the random sideload version stuff available in 15.04 eventually?
<beowulf> hi, can anyone tell me why the store gives me these errors with a snap that doesn't define any apparmor profiles? http://pastebin.ubuntu.com/12124699/
<beowulf> it's just a test snap for working in the store, the package.yaml is http://bazaar.launchpad.net/~stephen-stewart/+junk/test-snap/view/head:/meta/package.yaml
<jdstrand> beowulf: what version of snappy are you using to create those packages?
<jdstrand> beowulf: it seems you are using a very old version...
<Chipaca> longsleep: sergiusens said yes
<Chipaca> longsleep: i am not so sure :) but hope so
<Chipaca> elopio: i'm still getting âadt-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds...â from the integration tests
<Chipaca> elopio: which is a bummer, because i'm pretty sure i'm breaking them with this branch
<beowulf> jdstrand: oops, yes i am, thanks!
<Chipaca> longsleep: btw, i & we have been calling it "random version", but that didn't really work, so it's a monotonically increasing version instead
<Chipaca> longsleep: that if you look really carefully just happens to be the current time in nanoseconds, in base36
<Chipaca> which is fairly arbitrary, but (1) is reasonably monotonically increasing for our purpose, and (2) is a one-liner to implement :)
<elopio> Chipaca: checking...
<elopio> Chipaca: it's working for me.
<elopio> Chipaca: can you paste the log somewhere to see the adt messages?
<elopio> Chipaca: All good, what could possibly go wrong
<elopio> \o/
<Chipaca> elopio: http://pastebin.ubuntu.com/12125512/
<elopio> Chipaca: http://paste.ubuntu.com/12125594/
<elopio> plars: do you want to jump into a hangout to set up the manifest details?
<longsleep> Chipaca: sounds good and will not give dups when developing
<Chipaca> elopio: https://code.launchpad.net/~chipaca/snappy/schmideload/+merge/268498
<Chipaca> longsleep: yep
<plars> elopio: sure
<plars> elopio: I'm not sure the manifest bits work right now, ask ev about that
<plars> elopio: I have no idea how they are used either... but we can talk about a spec
<elopio> plars: https://plus.google.com/hangouts/_/canonical.com/qa?authuser=0
<clobrano> hi all :) is there a way to have a second terminal on snappy (virtual consoles do not seem to work)?
<ogra_> well, whatever the systemd way of enabling more is ...
<ogra_> sudo systemctl enable getty@tty2.service
<ogra_> sudo systemctl start getty@tty2.service
<ogra_> that seems to work
<elopio> Chipaca: All good, what could possibly go wrong
<elopio> that was running with the snappy binary from your branch, faking the updates and rollbacks.
<elopio> do you want me to run something else, like real updates from a specific image #?
<elopio> Chipaca: ah, I think your branch only modifies the sideloaded snaps. We don't have integration tests for that, so of course they all pass.
<Chipaca> elopio: \o/
<elopio> I'm not sure how to test sideloads. We would have to receive arguments with the snaps that you want to install, and write tests for those snaps, that maybe will install from the store only if they are not already installed.
<elopio> I'll add a card to trello.
<elopio> Chipaca: https://trello.com/c/02SDJD9x/198-tests-for-sideloaded-snaps in case you want to add requirements.
<Chipaca> elopio: 198 tests for sideloaded snaps is probably a bit much :)
<elopio> Chipaca: that's what you say now, but let's talk again when the missing test #199 breaks a stable release.
<Chipaca> elopio: dealopio
<elopio> plars: I triggered a test.
<plars> elopio: yeah, I just heard the relays firing :)
<elopio> plars: that's fast :D
<plars> elopio: right, at this point it's just booting back to a stable image it can flash the sd card from
<plars> elopio: so it'll be booting the emmc right now, creating/flashing your image will take a bit longer obviously
<plars> elopio: sounds like it just booted the test image
#snappy 2015-08-20
<w2vy> just learning here... anyone using Ubuntu Core/snappy on freescale i.mx6 or i.mx7?
<biezpal> jdstrand, thanks!
<imuguruza> LanderU: Hey!
<LanderU> imuguruza: Hi!!!
<ravirdv> hi
<ravirdv> I've got ubuntu core running on imx6 based board, how do I install snappy package manager?
<ravirdv> I'm using this ppa sudo add-apt-repository ppa:snappy-dev/tools
<ravirdv> but when I install snappy-tools, it throws unmet dependencies error for package "ubuntu-device-flash"
<biezpal> Hi all, need help again :)
<biezpal> Wanted to configure apparmor profile for openvswitch and faced the following problem:
<biezpal> apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="openvswitch_ovs-init-switch_0.0.1" name="apps/openvswitch/0.0.1/var/run/openvswitch/db.sock" pid=6190 comm="ovs-vswitchd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<biezpal> But in apparmor profile we have "/apps/openvswitch/** rwklmpix,"
<biezpal> If we start switchd service from the console without ubuntu-core-launcher everything is ok.
<ogra_> biezpal, iirc there is a bug open about this, create your socket in $SNAP_APP_DATA_DIR, then it should work
<ogra_> (i.e. /var/lib/apps/<packagename>/<version>)
<biezpal> ogra_, let me check, thanks
<biezpal> ogra_, the same for new paths(
<biezpal> apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="openvswitch_ovs-init-switch_0.0.1" name="var/lib/apps/openvswitch/0.0.1/db.sock" pid=2766 comm="ovs-vswitchd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
<ogra_> hmm
<biezpal> is it ok that we don't have / in the beginning of "name"
 * ogra_ wonders if it is normal that the first / is missing 
<ogra_> heh
<ogra_> *snap*
<ogra_> i think it is not normal ... i definitely see it in other denial messages
 * Chipaca thinks âdude, where's my /â
<biezpal> Service starts with the following string
<biezpal> "/apps/openvswitch/current/bin/ovs-switchd --db=unix:/var/lib/apps/openvswitch/0.0.1/db.sock --pidfile"
<biezpal> and if we run this command from the console - everything is working
<ogra_> you need a triple slash for the unix socket ;)
<biezpal> *adding second "/" didn't helped
<biezpal> and third
<ogra_> add a third one
<Chipaca> ogra_: where's the triple slash requirement coming from?
<Chipaca> can't see that in http://manpages.ubuntu.com/manpages/natty/man8/ovs-vswitchd.8.html
<ogra_> unix:///var/run/foo.sock
<Chipaca> is it pretending it's a url?
<ogra_> its a unix socket ... they always have a :// ... plus the path
<ogra_> no idea where that comes from to be honest
<ogra_> well, not true
 * ogra_ tries to find out :P
<Chipaca> biezpal: are you using ovs-switchd from ubuntu? because there's no --db mentioned in the manpage either
<Chipaca> biezpal: i know nothing about ovs-switchd though :)
<biezpal> /usr/bin/ubuntu-core-launcher openvswitch openvswitch_ovs-init-switch_0.0.1 /apps/openvswitch/current/bin/ovs-vswitchd --pidfile unix:///var/lib/apps/openvswitch/0.0.1/db.sock
<biezpal> Chipaca, sorry, --db argument was from ovs-vsctl
<biezpal> Chipaca, yes, we are using ovs from ubuntu
<Chipaca> biezpal: and that triple-slashed one doesn't work either?
<biezpal> Chipaca, yep
<Chipaca> ogra_: âThe  default is unix:/var/run/openvswitch/db.sockâ
<ogra_> ok
<biezpal> without /usr/bin/ubuntu-core-launcher everything is perfect
<Chipaca> ogra_: no triple slash shenanigans
<ogra_> yeah
<Chipaca> biezpal: well, yeah :) except you're not contained
<Chipaca> biezpal: what arch are you running this on, and what version of snappy core?
<ogra_> did longsleep not recently have a similar prob ?
<Chipaca> longsleep had *all* the problems, but I don't remember this one
<ogra_> (creating a socket in /var/run ... which then worked when using $SNAPP_APP_DATA_PATH in the call)
<Chipaca> ah, that yes
<biezpal> Chipaca, release: ubuntu-core/15.04/stable, architecture: amd64
<ogra_> biezpal, try using the variable instead of the path name in your call
<biezpal> ogra_, $SNAPP_APP_DATA_PATH - this variable?
<ogra_> yes
<biezpal> ogra_, checking
<Chipaca> biezpal: can you scp strace from your machine, and run it (contained) with strace -f -o /tmp/ovs.trace -s 999 your_binary_here ?
<Chipaca> biezpal: alternatively, you could share your snap :)
<biezpal> ogra_, the same with env var in path
<biezpal> Chipaca, how can I send strace output to you?
<Chipaca> biezpal: pastebin? scp it somewhere? john.lenton@canonical.com?
<biezpal> Chipaca, http://pastebin.com/fPXGw7Jv
<Chipaca> hm
<Chipaca> there's a lot of WAT in that
<Chipaca> like, why is it trying to modify things in /etc/ ?
<Chipaca> biezpal: but also, it's trying to write to /apps/openvswitch/current/var/run/openswitch/
<Chipaca> openvswitch*
<biezpal> Chipaca, yes, this strace was made for old paths
<biezpal> Chipaca, for /var/lib/apps it's the same
<Chipaca> sigh
<Chipaca> biezpal: ok, so, to help me help you debug
<biezpal> Chipaca, sorry, uno moment :)
<Chipaca> biezpal: first, different question, is this a binary or a service?
<Chipaca> the order of things to do varies a little depending on that :)
<Chipaca> biezpal: no worries, before doing it again let's start with as clean a slate as possible
<biezpal> Chipaca, it's a service
<Chipaca> biezpal: and how are you running the service under strace?
<biezpal> Chipaca, I'm running the command from ExecStart line in service unit
<Chipaca> biezpal: good :)
<Chipaca> biezpal: now, do dmesg -T | tail, note the timestamp, start the service, and pastebin everything after that timestamp in a followup dmesg -T; also, pastebin the strace with the "right" paths please
<Chipaca> biezpal: importantly, don't do anything else between the two dmesg's :)
<beowulf> Chipaca: hey, what's the lastest version of snappy-tools on vivid?
<Chipaca> oaiduno
 * Chipaca checks
<biezpal> Chipaca, strace - http://pastebin.com/CQRhrh0J
<biezpal> Chipaca, dmesg - http://pastebin.com/kN6KZPFf
<Chipaca> beowulf: 9, i guess?
<Chipaca> beowulf: there's a 10 in wily though
<ogra_> shouldnt you use the tools PPA anyway ?
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/tools
<beowulf> Chipaca: ogra_: i am, i'm just trying to figure out if i've fubar'd something with my install before i do any more compaining about package review failing in the store :)
<beowulf> Chipaca: thanks, i'm on 10 in vivid
<Chipaca> beowulf: where's that coming from? (apt-cache policy snappy-tools)
<beowulf> Chipaca: apt-cache policy and dpkg -s snappy-tools both say 10 for me
<ogra_> then you are likely using the PPA
<beowulf> http://ppa.launchpad.net/snappy-dev/tools/ubuntu/ vivid/main amd64 Packages
<ogra_> yeah
<ogra_> you shoudl be good
 * guest42315 ð ðððð ððððð!
<beowulf> i'm trying to build a mimimun viable snap to use for examining user flows in the store, to try and make that a more pleasant experience, but my snap keeps failing review with apparmor errors, can anyone help me? http://pastebin.ubuntu.com/12134346/
<beowulf> the snap is here http://bazaar.launchpad.net/~stephen-stewart/+junk/test-snap/view/head:/meta/package.yaml
<Chipaca> drk|aw: ð½ðððððððð ðððððððððððððð ððð ðððððð
<Chipaca> beowulf: bzr branch lp:snappy-examples ?
<Chipaca> wait, no, wrong lp:
<Chipaca> beowulf: lp:~snappy-dev/snappy-hub/snappy-examples
<beowulf> Chipaca: no, the problem is staging :(
<beowulf> Chipaca: it's review tools must be out of date, gah
<beowulf> i just tried on prod and it's fine
<Chipaca> beowulf: good thing you've got root on staging, amirite
<beowulf> no comment
<Chipaca> biezpal: i am still looking at your thing
<Chipaca> just in case you're wondering
<biezpal> Chipaca, waiting :)
<biezpal> thx
<Chipaca> biezpal: it's a framework, yes?
<biezpal> Chipaca, right
<Chipaca> longsleep: you around?
<Chipaca> biezpal: so. I don't know quite what's going on with your snap
<Chipaca> biezpal: i've confirmed in 15.04 you can write to $SNAP_APP_DATA_PATH, and AFAIK longsleep i susing that to create a socket
<ogra_> yeah
<Chipaca> biezpal: your service is doing a bunch of things which are failing
<ogra_> i know we even have a bug open for that but i cant find it
<Chipaca> biezpal: for example, it's looking for a control socket in the wrong place
<Chipaca> biezpal: and you're getting an apparmor denied from a service, which i thought couldn't happen
<Chipaca> biezpal: so
<ogra_> Chipaca, well, the interesting bit is still that the DENIED messages miss a leading / in the name= bit ... i have never seen that
<Chipaca> ooooooh
<Chipaca> biezpal: your service
<Chipaca> biezpal: is calling binaries you ship
<Chipaca> biezpal: through their wrapper
<Chipaca> biezpal: this won't work
<Chipaca> biezpal: just call the binaries directly
<Chipaca> ogra_: maybe that's a side effect of double-wrapping?
<ogra_> hmm, snappy list -v didnt show me a new docker ... snappy update now downloads a docker update ... there seems to be no way for me to see tho what i'm actually upgrading
<Chipaca> biezpal: did what i just said make sense to you?
<ogra_> oh, i'm blind :P
<Chipaca> ogra_: snappy list --updates
<ogra_> yeah, that was more about tehupdate command
<ogra_> i totally missed that it printed the version in the first output line
<ogra_> sadly the running docker service doesnt want to stop, so now it hangs
<ogra_> (i started a container manually, seems the systemd unit doesnt get along with that ?
<ogra_> )
<ogra_> Waiting for docker_docker-daemon_1.6.2.002.service to stop.
<ogra_> ...
<Chipaca> docker is slow to stop
<Chipaca> was the first service to necessitate the "waiting" work
<ogra_> ok, i'll give it more time then
<ogra_> aha
<ogra_> it moved to ...
<ogra_> Waiting for owncloud_owncloud_8.0.2.004.service to stop.
<Chipaca> it does eventually get tired of waiting and goes to play with its marbles
<ogra_> (which isnt running ... lets see how it deals with that)
<Chipaca> but shouldn't happen
<Chipaca> that should be quick then :)
<ogra_> yeah, just moved on
<ogra_> downloading a new owncloud too
 * Chipaca is on the edge of his seat
<ogra_> i wonder how we ever want to make this work in webdm
<ogra_> your browser will surely time out :)
<Chipaca> ogra_: heheh
<Chipaca> ogra_: i dunno if you've looked, but there are these "interacter" things everywhere
<ogra_> at the webdm code ? no, not yet :)
<Chipaca> ogra_: those abstract away the idea that interaction is asynchronous sometimes
<Chipaca> ogra_: no, in snappy itself
<ogra_> ah
<Chipaca> ogra_: webdm provides its own "progress bar" kinda thing, interacter, whatever you call it
<Chipaca> ogra_: whereas we just provide a terminal one (and a null one)
<ogra_> yeah, that didnt work so well even for installing docker and owncloud :)
<Chipaca> ogra_: you can't do it with webdm?
<Chipaca> that's good to know, see :)
<ogra_> i usually end up with an error message in webdm
<ogra_> it works and all ...
<ogra_> but prints an error at the end of the install (which takes a felt century)
<kickinz1> ogra_ one way for owncloud would have be to include the image itself to the snap, so the progress bar could be seen.
<ogra_> (RPi2 here btw, everything is slow ;) )
<kickinz1> ogra_, but at upgrade time we have useless data download unless we have binary diffs.
<ogra_> kickinz1, yeah, i was wondering why you dont include it ... does it get so big ?
<ogra_> ah
<biezpal> Chipaca, yes, it make sense for me, but we don't calling binaries through the wrapper
<ogra_> saving bits :)
<Chipaca> biezpal: yes you do
<biezpal> Chipaca, actually, we don't have binaries defined in package.yaml
<biezpal> Chipaca, http://pastebin.com/hapxpjjc
<ogra_> yay
<ogra_> it finished
<Chipaca> oh
<Chipaca> execve("/apps/openvswitch/current/bin/ovs-vswitchd"
<Chipaca> biezpal: not through the wrapper
<kickinz1> then also, on a rpi2 loading the image is quite long, so you see the progress bar, but you are still waiting 5 mns for the image to be loaded :(
<Chipaca> biezpal: i lied to you
<Chipaca> biezpal: and that's probably the launcher itself :-/
<Chipaca> man i suck at debugging :)
<biezpal> Chipaca, we are using our own wrappers only when we need to export LD_LIBRARY_PATH for our binaries
<Chipaca> biezpal: what do you get from
<Chipaca> biezpal: sudo journalctl -u openvswitch_ovs-init-switch_0.1.service
<biezpal> Chipaca, http://pastebin.com/w5aw605v
<Chipaca> biezpal: fwiw, i am able to create a socket and listen on it just fine, with no additional privileges nor anything, in 15.04 amd64
<Chipaca> biezpal: are you using a custom policy or something?
<biezpal> Chipaca, we are able to create and listen on socket too, but we cannot connect to it
<biezpal> Chipaca, our ugly debug policy prfile: http://pastebin.com/JyjSNW38
<ogra_> kickinz1, seems to be working really well now ...
<Chipaca> wow
<biezpal> Chipaca, in unconfined mode everything is ok
<biezpal> yes, it's ugly :)
<Chipaca> biezpal: silly question, what permissions does the socket file have?
<Chipaca> biezpal: also, what creates the socket, and what tries to connect to the socket?
<biezpal> (amd64)ubuntu@rh1440073371:~$ ls -l /var/lib/apps/openvswitch/0.1/db.sock    srwx------ 1 root root 0 Aug 20 16:09 /var/lib/apps/openvswitch/0.1/db.sock
<biezpal> "/apps/openvswitch/current/bin/ovsdb-server --remote=punix:$SNAP_APP_DATA_PATH/db.sockââ--remote=db:Open_vSwitch,Open_vSwitch,manager_optionsââ--pidfile"
<biezpal> this command creates socket
<biezpal> and it works under the same profile
<Chipaca> biezpal: and both these things are services
<biezpal> "/apps/openvswitch/current/bin/ovs-vswitchd --pidfile unix:$SNAP_APP_DATA_PATH/db.sock"
<biezpal> last command - connects to the socket
<ogra_> with the --pidfile option ?
<biezpal> yes, both services
<biezpal> ogra_, yes, it creates pidfile for daemon
 * ogra_ woould expect a pidfile as argument for this 
<Chipaca> biezpal: and both run with the debug profile you pasted? or is that profile the one you use when you say unconfined it works?
<biezpal> ogra_, daemon uses default path for pidfile
<ogra_> ok
<biezpal> Chipaca, ovsdb-server able to create socket under this profile, but ovs-vswitchd can connect only in unconfined mode
<Chipaca> biezpal: ogra_: it creates a pidfile at /apps/openvswitch/0.1/var/run/openvswitch/ovs-vswitchd.pid.tmp which will be a problem when you try to tigthen the profile, but works for now
<ogra_> yeah
<ogra_> you can define it via --pidfile= ...
<biezpal> Chipaca, yes, we are keep it in mind
<ogra_> according to the manpage
<biezpal> we'll change it when solve the main problem :)
<Chipaca> biezpal: i'm out of ideas
<kickinz1> ogra_, but it still need systemd's socket support, and an upgrade to 8.1.1, both are in the pipe, but I'm lacking time.
<Chipaca> biezpal: let's wait on jdstrand or tyhicks, they're smart :)
<ogra_> kickinz1, well, i dont get nagged about upgrades anymore
<ogra_> so thats a win
<kickinz1> ogra_, I've already did some snappy code, so it supports sockets, so we may get rid of sleeps. I started an owncloud 8.1.1, but upgrade from 8.0.2 is stuck
<ogra_> cool !
<kickinz1> ogra_, owncloud gets broke, good for fresh install, but definitively need to understand where it hangs.
<biezpal> Chipaca, thanks for the help anyway, we are also working on it
<biezpal> waiting for these guys
<Chipaca> ok. i've got to run to the shops. will be back for the standup. o/
<ogra_> kickinz1, i wonder if we shouldnt have some mechanism that an app can use its own upgrade mechanism if wanted ...
<ogra_> so it would do the upgrade inside the container ...
<kickinz1> ogra_ yes I think we need that, but for owncloud, owncloud already has db migration, and an upgrade path. Data and files are kept outside the container via volumes. But the migration get stucks in the middle.
<ogra_> hmm
<kickinz1> ogra_ the new owncloud starts, but say it is in maintenance mode, and I had to left it like that.
<kickinz1> ogra_ (it say it will work out the migration, then is seems to do something then maintenance mode is on)
<ogra_> :(
<kickinz1> s/is on/is blocked on/
<w2vy> new here... looking at running snappy on freescale i.mx6 or i.mx7 and have some general questions...
<w2vy> they have their own kernel and build with yocto, just wonder how much of their support i would lose by switching..
<w2vy> i was thinking yocto could deal with snappy, assuming there were recipies for it...
<ravirdv> @w2vy I'm also looking for some help with imx6
<nothal> ravirdv: No such command!
<w2vy> ok. just curious, why not use the freescale release?
<ravirdv> Snappy looks good, mainly for OTA
<ravirdv> I was able to  run Ubuntu Core with own kernel
<ravirdv> trying to build snappy with with a/b partition scheme
<ravirdv> image*
<w2vy> i am looking for options because they can't tell me who is responsible for security patches, etc
<w2vy> from talking to them it sound like the Buck Stops Here... I don't WANT that buck!
<ravirdv> true, that control has be with us
<w2vy> us?
<ravirdv> as in product manufacturers
<w2vy> you want to have to deal with every patch that is released and apply each one yourself?
<ravirdv> just the control of which packages goes onto customer's device
<w2vy> of course... but not each patch to each package!
<ravirdv> ofcouse not :)
<w2vy> of course i will have to pay for the ability to sleep at night...
<ogra_> w2vy, you can use whatever kernel you want as long as you can make all options work and have the latest apparmor patches
<ogra_> https://developer.ubuntu.com/en/snappy/guides/porting/
<ogra_> the u-boot bits there need updating, we changed that setup, but the stuff there is definitely enough to make it work
<w2vy> well here I go again... is there a ubuntu core channel?
<w2vy> i am trying to drill down to pick a kernel first...
<ogra_> not surew what you mean by ubuntu core channel
<w2vy> me either...
<ogra_> ubuntu-core (the non snappy variant) has no channel (though it has nothing to do with snappy)
<w2vy> lol
<w2vy> sigh
<ogra_> snappy ubuntu-core has this channel
<w2vy> let me back up and you can tell me where to go...
<w2vy> i am planning a product that will run linux inside - for various reasons. looking for a kernel that I can use (free or not - but not go broke) that has patches tested so I not not need to be the open source patch guru
<w2vy> talking to freescale i felt like i was getting dumb looks, like I had no idea what I was talking about (could be)
<ogra_> well, with snappy you can use any kernel you want as long as you can enable the right options and can apply the apparmor patches that are required to run apps under confinement ...
<ogra_> so you will likely not get around touching some kernel bits, even if your board is supported by the latest upstream kernel you will want to apply the right build configuration as the very least
<ogra_> the porting websie above has that documented in the last paragraph i thinnk
<ogra_> *website
<ogra_> well, not last but one of the last :)
<w2vy> yes well "upstream kernel" does not imply any reliability... not like a canonical kernel does...
<w2vy> i guess i just need to wait for someone from canonical to contact me...
<ogra_> well, the canonical kernel uses the upstream one :)
<w2vy> yes, but it may have been tested and the patches selected by someone who knows a hellva lot more than me!
<w2vy> s/someone/a whole team/
<ogra_> did you contact anyone already ?
<w2vy> yesterday, so i figured i'd try to learn a bit more before they call
<ogra_> so ... the ubuntu kernel is plain mainline with a specific config and a few extra patches. if your board can already be suported by that then it should be trivial ...
<ogra_> if it cant or if you need to use a BSP kernel then you either need to make the necessary changes yourself or you need to pay someone for this :)
<w2vy> yeah, the "few extra patches" is where I would  mess up and ship a holey product
<ogra_> totally depends :)
<w2vy> yeah, i an trying to find where i will be sending my support money...
<w2vy> (inbox fills up)
<ogra_> the most important bits are apparmor and some config options for systemd ...
<ogra_> applying the apparmor patches essentially means "delete the whole apparmor dir in the kernel source and replace by canonicals"
<ogra_> and the rest is just confi stuff
<w2vy> lol
<ogra_> *gonfig
<ogra_> bah !
<w2vy> config
<ogra_> thanks :)
<w2vy> ok, let me raise the SNR here and go read you link...
<ogra_> the same thing goes for uboot ... there are some minimal config patches and a specific setup, nothing fancy
<ogra_> once you have both you can build an oem snap package for the bootloader and a device tarball for the kernel ...
<ogra_> then you hand both of them to the ubuntu-device-flash tool which assembles an image for you using the snappy rootfs and the two bits you created
<ogra_> if you look for a commercial contact at canonical try maarten.ectors@canonical.com ... he does that stuff for snappy specifically
<w2vy> thanks
<ogra_> hmm
<ogra_> why is my test initrd only 2.6M big
<Chipaca> ogra_: because you're testing klibc-snappy?
<ogra_> Chipaca, well, not sure why, i havent looked yet ... it boots fine even with the small one that i built in a chroot
 * ogra_ will check for differences once he landed the resize code 
 * ogra_ sighs ... resizing takes aeons
<ogra_> i should have re-partitioned instead of relying on gparted to shrink the partition for testing
<ogra_> took 20min already just to resize from 16G to 5
<ogra_> crap ... and indeed the resizing didnt work
<ogra_> grrr
<ogra_> http://paste.ubuntu.com/12135391/
<ogra_> it did work but didnt re-read the new partition table
<ogra_> f*ckk
<longsleep> ogra_: why does it take so long to resize?
<ogra_> longsleep, ask gparted :P
<ogra_> i resorted to not cut the partition in half but only make it 2G smaller ... that works a tad faster
<ogra_> but still, i cant convince the initrd to reread the new partition table without reboot
<longsleep> ogra_: did you try to run my script, that works just fine without reboot required if i remember correctly
<longsleep> maybe the cloud init script does some extra magic
<ogra_> also, your code uses a lot non-std tools, i had to copy quite a few bits into the initrd (realpath etc)
<longsleep> yeah well, realpath is kind of standard but not part of a shell builtin
<ogra_> right, nor is dirname
<longsleep> busybox does not have it?
<longsleep> narf :)
 * ogra_ reboots and prays 
<ogra_> (not that i'm religious :P )
<longsleep> busybox has dirname and realpath
<longsleep> so i suggest to just add busybox :P
<ogra_> ah, not linked or not the initrd build we use then
<longsleep> mhm i checked the busybox on my 14.04 workstation, i did assume the one in initrd might be the same
<longsleep> maybe the links are missing
<ogra_> GRRR !"!!!
<ogra_> http://paste.ubuntu.com/12135511/
<ogra_> funny that the manpage explicitly lists -R
<ogra_> even more interesting that the resizefs complains about missing fsck while i see that running above in the log
<ogra_> hmm
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo sfdisk -s /dev/sda1
<ogra_> 15666176
<ogra_> and pobviously the kernel actually knows the new partition size ... so somewhere along the way it actually *did* re-read it
<ogra_> myths all over the place :P
<longsleep> oh boy
<longsleep> ogra_: i remember something about that and reading something that the error is no error and can be ignored in this case
<ogra_> well
<ogra_> if resize2fs would actually use the new size i wouldnt care about the error :)
<longsleep> right
<ogra_> oh
<ogra_> i might have to re-read *before* running fsck
 * ogra_ tries that 
<longsleep> ogra_: my script does the job just fine http://paste.ubuntu.com/12135559/
<longsleep> ogra_: so it must be some magic of cloud init
<ogra_> longsleep, yeah, i cant pull cloud-init into the initrd
<ogra_> (and i really dont want to use it
<ogra_> )
<longsleep> ogra_: yeah, but maybe take a look what it is doing
<ogra_> also it operates in a saner environment than initrd ... you have a fully running system up
<longsleep> well, if it just works you could avoid run it from initrd and do it later as a regular service
<ogra_> ok, next try ...
 * ogra_ crosses fingers
<longsleep> btw, growpart is just a bash script too, so you should be able to add this into initrd without too much issue
<ogra_> longsleep, i really dont want to tinker with a filesystem underneath a ton of bindmounts
<ogra_> resizing from a systemd unit really calls for trouble, even if it might work right now
<longsleep> ogra_: yeah - i prefer to have it in initrd as well, take a look at the growpart script, it is quite long but works just fine
<longsleep> it uses partx to update the partition
<longsleep> and sfdisk
<longsleep> so you should be good
<ogra_> yeah, i really dont want partx in the initrd
<ogra_> that will pull in a ton of deps
<ogra_> GEEZ !
<ogra_> e2fsck 1.42.12 (29-Aug-2014)
<ogra_> ...
<ogra_> writable: 135627/840480 files (0.0% non-contiguous), 577059/3368192 blocks
<ogra_> resize2fs 1.42.12 (29-Aug-2014)
<ogra_> Please run 'e2fsck -f /dev/sda1' first.
<longsleep> well, i just found this update the the kernel partition table info after growing this requires kernel support and 'partx --update'
 * ogra_ cant belive that 
<longsleep> ogra_: same disk?
<ogra_> the fsck obviously runs directly before the resizefs
<ogra_> yes
<longsleep> hum
<longsleep> no idea
<ogra_> so it checks, gives me the summary and then resize complains
<ogra_> i wonder if e2fsck behaves differently if you use -fy vs oinly using -f
<ogra_> thats the onl idea i have
<ogra_> oh
<ogra_> resize2fs has a -f option too ... lets try that one :)
<ogra_> heh
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo cp chroot/boot/initrd.img-foo /boot/uboot/a/initrd.img
<ogra_> ^^^ this takes nearly 5min
<ogra_> goota love the RPi IO
<ogra_> hmm, it definitely does something this time
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ df -h |grep oem
<ogra_> /dev/sda1                     15G  1.9G   12G  14% /oem
<ogra_> yippie !!
<ogra_> http://paste.ubuntu.com/12135660/
<ogra_> and now the same with running from SD ...
<ogra_> lets see what it does if the first partition is already mounted :P
<jdstrand> beowulf: make sue the review tools are up to date and you are using an up to date snappy binary to build the snap
<beowulf> jdstrand: it was a problem with myapps.developer.staging.u.c, the core framework had different policy versions on staging and prod
<Chipaca> ogra_: have not read all the backlog, but "sfdisk -R" used to work, but at least in wily it says you should do "blockdev --rereadpt" instead
<ogra_> Chipaca, yeah, thats what i use now
<Chipaca> ah, k
<jdstrand> beowulf: ok, cool, glad it is resolved
<Chipaca> ogra_: and it didn't?
<ogra_> (and what i tried to use forst ... but i was running it to late ... inbetween i tried sfdisk -R ... )
<ogra_> *first
<ogra_> it works now with writable on USB disk ... i'm just re-flashing from scratch to see what it does with /root is already mounted from the same disk now
<asac> kyrofa: what do i need to do to get your piglowtop app working? readme doesnt say anything :)
<ogra_> i have a slight suspicion it will not work
<ogra_> asac, hw-assign
<ogra_> for the i2c device i think+
<asac> ogra_: dev/i2c...?
<asac> kk
<asac> let me try
<kyrofa> ogra_, check the meta/readme
<kyrofa> err, asac ^^
<ogra_> me ?
<ogra_> heh
<kyrofa> ogra_, sorry :)
<asac> kyrofa: it wasnt in the README.md... :)
<asac> let me see
<kyrofa> ogra_, I'm so used to typing out your nick really fast
<asac> gotcha
<asac> wonder if this persists across reboots :)
<ogra_> kyrofa, yeah, asac and me are easy to mix up ... i'm the fat toothless longhaired guy ... and he is not :P
<kyrofa> asac, yeah, I kept that pretty high level since it wasn't specifically for snappy. The snappy-specific stuff is in the "snappy" readme (i.e. meta/readme)
<kyrofa> asac, the hw-assign? Works for me
<asac> kyrofa: so after reboot the process is still running
<asac> but nothing is blinking
<kyrofa> asac, although it's a little wonky. When you uninstall piglowtop it also removes the hw-assignment, except when it doesn't
<kyrofa> asac, hmm. systemctl status -l piglowtop_piglowtop_0.1.0.service ?
<asac> still complains about not being able to access it
<kyrofa> asac, also verifying i2c is setup: you have /dev/i2c-1?
<ogra_> asac, try  reboot ?
<asac> yeah did that
<asac> i have ls -la /dev/i2c-1
<asac> crw------- 1 root root 89, 1 Aug  7 17:01 /dev/i2c-1
<asac> have that too
<asac> maybe i didnt connect it proper?
<asac> i connected it to the last pins... not the side of the gpiop
<ogra_> damn ... that didnt look like it resized
 * ogra_ guesses it doesnt like having a partition mounted
<kyrofa> asac, mine is on the side closest to the power LEDs
<asac> oh ... so thats different then
 * asac tries
<asac> guess i cant connect the gpio pins anyway when having the orange box closed, so ... :)
<kyrofa> :P
<ogra_> This disk is currently in use - repartitioning is probably a bad idea.
<ogra_> Umount all file systems, and swapoff all swap partitions on this disk.
<ogra_> Use the --no-reread flag to suppress this check.
 * asac shuts down, opens case and reconnects glow
<ogra_> grmbl
<ogra_> now the question is how dangerous is it to ignore that check
<longsleep> ogra_: well - i am pretty sure there are ways that this breaks the system
<asac>  ok greawt... let me not do the mistake again and clsoe the case :)
<ogra_> longsleep, well, i dont touch any of the partitions that are mounted ... i only change the table
<ogra_> and only for a partition that isnt mounted currently
<longsleep> ogra_: the partition you change is also always at the end - so you should be good in all normal cases
<asac> and yes, it just started glowing.... i miracle ::
<asac> thx kyrofa
<ogra_> longsleep, right
<asac> guess device tree could be used to map those pins somwhere else?
<ogra_> i think it is fine as an interim solution
<kyrofa> asac, no problem! Thanks for trying it :)
<ogra_> that code wont stay anyway i think
<asac> kyrofa: you could add a config for it
<asac> so i could change the values you refer to in README.md
<asac> right now ping does not glow :)
<asac> snappy config
<asac> hook
<asac> eat yaml, remember values for service etc.
<asac> but great!!
<kyrofa> asac, you mean so snappy config can change the brightness, etc?
<asac> yeah the parameters you mention in README.md
<vmayoral> ogra_: hi! thanks for the kernel pointers. I'm struggling with udf to recreate the image
<vmayoral> ogra_: mind looking at https://gist.github.com/vmayoral/c7f9ab2b6160cdcfabca?
<asac> would be cool to have snappy config so i can change those values from the defaults
<kyrofa> asac, good idea! I've not messed with snappy config yet
<asac> for the service
<asac> its easy kinda
<kyrofa> :P
<asac> kyrofa: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/config-example/
<asac> just check the meta/hooks dir
<asac> kyrofa: or http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/config-example-bash/
<asac> if you want hacky yaml/bash :)
<asac> ok guess time to close the case :P
<kyrofa> asac, thanks for the reference!
<ogra_> GRRRRRR !!!!
<ogra_> didnt work even with the option forced
<vmayoral> ogra_: i see it's been addressed at https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472516, let me try to update my tools and retry
<ubottu> Launchpad bug 1472516 in goget-ubuntu-touch (Ubuntu) "udf cannot double map partitions error" [Undecided,Fix released]
<ogra_> Syncing disks.
<ogra_> blockdev: ioctl error on BLKRRPART: Device or resource busy
 * ogra_ cries 
 * asac wonders what my wife will say once this thing replaces our old, super powerwasteful mini 10 laptop that does mail/ftp/irc server in the living room :)... hope she will be impressed by the ultimate beauty odf this thing
<ogra_> sigh ... i guess i have to start from scratch and use a premount script :/
 * ogra_ wanted to have that code ready by wed. :(((
<asac> resizing premount sounds reasonable
<asac> you can still finish it today
<ogra_> asac, yeah, i should have done that from the start, but its so convenient to do it later since i dont need to duplicate half the code to fill the right vars
<ogra_> vmayoral, well, your output looks slightly different, but yeah, try it
<ogra_> damned
<ogra_> why the heck does the ubuntu-core initrd script forcefully mount /run/initramfs
<ogra_> init does that already and this makes us use all former logs
<ogra_> eeek
<ogra_> and we even mount /run afresh
<ogra_> so mucxh code duplication !!!
<ogra_> (and so harmful)
<Chipaca> ogra_: if only we knew those ubuntu-core people we could make them fix it!
<ogra_> haha
<ogra_> well, i have a mild guess the person that wrote most of this script isnt here anymore
<Chipaca> ogra_: :)
<Chipaca> elopio: so my mp from yesterday should be getting two more auto-comments at some point?
<elopio> Chipaca: yes, if I manage to get the polling right today.
<vmayoral> ogra_: nah, didn't work https://gist.github.com/vmayoral/33e80be0b06b7a48a74c. Went ahead and created a new chroot with vivid downloading the latest packages https://gist.github.com/vmayoral/33e80be0b06b7a48a74c
<elopio> Chipaca: your MP looks good to me, but you are touching many funcs that I haven't seen before. I think it would be better to wait for mvo's or sergio's review.
<Chipaca> elopio: yes, i wasn't expecting a proper code review on this one any time soon
<vmayoral> ogra_: don't think it's that but let me map dev, proc and sys in the chroot and retry
<vmayoral> ogra_: nop, got read of the resolving issue but still getting the "exit status 2"
<vmayoral> s/read/rid
<Chipaca> vmayoral: have you verified your snap?
<ogra_> yay
<ogra_> http://paste.ubuntu.com/12136132/
<vmayoral> Chipaca: i also tried the same with the one provided by you guys http://people.canonical.com/~platform/snappy/raspberrypi2/
<ogra_> Chipaca, well, i bet the erle snap usually works :)
<Chipaca> vmayoral: what version of ubuntu-device-flash is that?
<Chipaca> vmayoral: (do you always sudo when you're already root? :-p)
<Chipaca> ah, it's in the gist
 * Chipaca reads
<Chipaca> vmayoral: it seems to work here on wily
<Chipaca> vmayoral: which isn't particularly helpful i know
<Chipaca> vmayoral: let me see if the other computer is still legacy :)
<vmayoral> Chipaca: mmmm i just created a new vivid chroot to make sure that it could be reproducible
<vmayoral> Chipaca: do you think you could try that?
<Chipaca> vmayoral: i've got a vivid host, let me try there first
<vmayoral> Chipaca: great, thanks
<ogra_> i did build the rpi image on trusty FWIW
<ogra_> but using ubuntu-device-flash from the tools PPA so we should be using the same thing
<Chipaca> john@fridge:/tmp/pi2$ sudo ubuntu-device-flash core 15.04 --oem=pi2_0.15_all.snap --device-part=device-pi2-0.15.tar.xz -o pi2.img --developer-mode
<Chipaca> Determining oem configuration
<Chipaca> Using a custom OS or Kernel part will prevent updates for these components
<Chipaca> Fetching information from server...
<Chipaca> Downloading and setting up...
<Chipaca> vmayoral: New image complete
<ogra_> looks fine to me
<ogra_> vmayoral, are you using ubuntu-device-flash from https://launchpad.net/~snappy-dev/+archive/ubuntu/tools ?
<ogra_> 0.27-0ubuntu1  ....
<Chipaca> ogra_: that's what his apt-cache policy says
<ogra_> weird
<vmayoral> ogra_: yeap
<Chipaca> vmayoral: is the filesystem you are doing this on in any way special?
<ogra_> Chipaca, how good is your shell foo ? i dont want to upload without a second pair of eyes  http://paste.ubuntu.com/12136199/
<Chipaca> ogra_: i aspire to upgrade it to your level someday somehow, but i can read what you write
<ogra_> i guess thats enough for a yay or nay :)
<vmayoral> Chipaca: mmm i'm running a trusty virtual machine and i chrooted the a new vivid image since it was giving me trouble on trusty
<ogra_> hmm, i should expand the first changelog line a bit i guess
<vmayoral> not sure if that's special :(
<ogra_> vmayoral, well, it works for me onb trusty too
<ogra_> that is how i created the image in the first place
<Chipaca> ogra_: i see no problems in the shell in the patch
<ogra_> cool
<Chipaca> ogra_: if i were feeling nitpicky i'd ask whether it was intentional to lose precision on the size check
<Chipaca> ogra_: but i'm not :-P
<ogra_> well, i dont really want it to resize just because there are 10k free or some such
<ogra_> which is why i picked these artificial 10%
<ogra_> [    9.596964]  sda: sda1
<ogra_> e2fsck 1.42.12 (29-Aug-2014)
<ogra_> [    9.951713] random: nonblocking pool is initialized
<ogra_> resize2fs 1.42.12 (29-Aug-2014)
<ogra_> done.
<ogra_> yay
<ogra_> so even with USB disk writable partition it works fine
<Chipaca> ogra_: i meant, you're checking (device_size-used_size) against the floor of device_size/10
<Chipaca> so it sometimes won't resize even when you have 10% waste
<ogra_> what would you propose ?
<Chipaca> ogra_: to commit it :)
<ogra_> hahaha
<ogra_> ok
<Chipaca> you can tell people to use tune2fs to get back their precious bytes if the need 'em :-p
<ogra_> well, we can always improve
<ogra_> and i'm not sure at all we'll even keep that code
<ogra_> so yeah, let me upload so we have it in tomorrows rolling/edge image
<ogra_> so if bug 1485306 could be fixed now ... we could actually make u-d-f create a 1byte partition ...
<ubottu> bug 1485306 in Snappy "ubuntu-device-flash should not create data in writable partition" [Undecided,New] https://launchpad.net/bugs/1485306
<ogra_> that would make the images massively smaller :)
<ogra_> utlemming, ^^^ automatic resizing of the writable partition should show up in the next rolling/edge image build tonight
 * ogra_ adds a checkmark on the trello card next to "ping back ben howard" about resizing :)
<ogra_> elopio, so this trello card has a "add automated tests under self tests" ... do we have any tests at all for initrd scripts anywhere ?
<ogra_> i mean ... its a great approach ... but i cant even imagine remotely how such a test would work
<elopio> ogra_: the self tests are functional from the point of view of the user, so there you would have to check that the partition was resized.
<elopio> I'm not sure how to generate an image and a kvm that causes a resize, but that sounds doable.
<ogra_> elopio, so we would actually need an image where writable doesnt occupy the full space
<ogra_> i guess thats a task for sergiusens then to change u-d-f
<ogra_> which we should do in general now
<ogra_> to generate smaller images
<elopio> testing the script itself as it runs in memory, I have no idea how to do that.
<ogra_> right
<sergiusens> ogra_: you already have that working?
<ogra_> that was what made me curious :)
<ogra_> sergiusens, well, i just uploaded http://paste.ubuntu.com/12136293/
<ogra_> should work in the next image
<sergiusens> ogra_: I'll work on an MP then
<ogra_> (still room for improvement, but i understood it is urgent to have it )
<sergiusens> ogra_: really?
<ogra_> sergiusens, yeah, see the other channel :)
<elopio> ogra_: I guess you can also run the resize script. Change all the initramfs specifics for parameters so it's easily testable.
<elopio> so the problem would be the hooks. Maybe sergiusens has ideas, or somebody from the kernel team.
<elopio> a fake initramfs?
<ogra_> well, you need to check it at runtime somehow
<ogra_> so i guess a boot test of an image is needed
<ogra_> and i assume we dont have anything for that at all yet anyway ... sounds like a bier task
<ogra_> *bigger
<elopio> ogra_: yes, please make new cards for these things. If you have any clues about where to start, please add them as comments to so we can start the research.
<elopio> s/to/too
<ogra_> will do
<ogra_> hah, what i really love is that i re-flashed my SD about ten times today ... just removing the label from the last partition and plugging in my USB key with the formerly used writable partition and i'm back with all my installed apps (docker, owncloud etc) just working like before
<ogra_> :)
<sergiusens> ogra_: should we growfs by default and make writable 1MiB?
<sergiusens> ogra_: also, should we take a shot at making system-a and system-b smaller?
#snappy 2015-08-21
<sergiusens> elopio: do you know if the launchpad api can now check git repos?
<sergiusens> elopio: I guess we aren't using tarmac anymore for MPs, are we?
<guest> "Thank you developers"
<guest> Owncloud works again
<guest> But an old question:
<guest> How can I change the storage location from "/var/www/data" to a folder in a usb drive?
<guest> Bad time for question, I guess you all are asleep :)
<dnlplm> Hello
<dnlplm> I have a question related to a snap package
<dnlplm> is there a way to unpack a snap package?
<vsuojanen> curious how do you update the snaps and distribute the updates to 100 devices? what component is it listens and startups update if there are changes in the service/cluster? is there a local connection config in each Snappy system ?
<ogra_> vsuojanen, afaik the component is snappy itself
<Chipaca> vsuojanen: snappy is not at this point cluster-aware, if I understand your question correctly.
<ogra_> well, you can easily have a central server that pushes snaps via snappy-remote
<Chipaca> ogra_: yes, but that's like saying ubuntu is cluster-aware because it ships with ssh
<ogra_> :D
<ogra_> its all a matter of the shell scripts you add ;)
<tbr> didn't someone replace docker with a shell script?
<ogra_> heh, yeah
<Chipaca> it would be nice to be able to say "uppdate the cluster in phases, have no more than one rack in each dc updating at the same time, switch over after first N upgraded" or something
<Chipaca> tbr: nah, docker would need at *least* five lines in that script
<Chipaca> too much work
<Chipaca> what we replaced with a shell script was the idea of snappy-remote
<ogra_> well, there is always ; to make it a single (very long) line :)
<Chipaca> ogra_: not beyond 2090962 characters (on my system)
<ogra_> lol
<Chipaca> xargs --show-limits ftw
<vsuojanen> i didn't get now all, but you say snappy-remote ?
<vsuojanen> yes i just have the idea of delivering updates to devices without interrupting client device use
<Chipaca> vsuojanen: by default snappy checks the store periodically and updates things that are updatable
<vsuojanen> I don't have a clue what is available from you and what are the best practices. I'm just interested aboth delivering updates this way
<vsuojanen> *u
<vsuojanen> thank you. it's here https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
<ogra_> Chipaca, did you see the mail on snappy-app-devel ?
<ogra_> looks a bit like the binary isnt found by ubuntu-core-launcher to me
<Chipaca> ogra_: subject of said mail?
<ogra_> "execv failed when running my self-built customized minicom"
<ogra_> the strace in there is a bit sparese
<Chipaca> ogra_: i haven't got anything from snappy-app-devel since aug 6
<ogra_> *sparse
<Chipaca> and there it seems to be via snappy-devel
<Chipaca> ogra_: can you ask them to pop on here?
<ogra_> sure
<Chipaca> ogra_: that strace is needing a -f so we can see the second execv
<Chipaca> ogra_: so it's either not finding the binary, or the binary is needing libraries that it isn't finding
<Chipaca> ogra_: given that they've gotten as far as they have, money is slightly more on the latter
<ogra_> i answered
<Chipaca> ogra_: my hero
<Chipaca> :-p
<ogra_> lol
<longsleep> love is everywhere!
<Chipaca> and especially in this hummous!
 * Chipaca is having a slightly late lunch on a very lovely sunny afternoon here outside london
<davmor2> Chipaca: man you so funny
<ogra_> same here ... *munch* *munch*
<Chipaca> davmor2: hummous is serious stuff
<davmor2> Chipaca: ask jibel if it is sunny in London it breaks the weather apps tests that looks for rain and london
<Chipaca> davmor2: https://goo.gl/photos/aEffhN6NM3Ca88T47
<ogra_> pisa near london !
<davmor2> Chipaca: you could be anywhere you don't blag me with your holiday snaps of Italy ;)  No Queen genuine or pearly and you are not in London :D
<Chipaca> davmor2: https://goo.gl/photos/yVWnTzftxoufYLjo6
<Chipaca> davmor2: of course, i could've carried it with me to wherever
<Chipaca> davmor2: but i'm not going out to hunt for better proof at this time, sorry
<dnlplm> hello
<Chipaca> dnlplm: hello hello
<dnlplm> I wrote the mail in snappy-devel
<Chipaca> dnlplm: were you able to re-run strace with -f?
<dnlplm> yes, I have it
<Chipaca> dnlplm: pastebin?
<dnlplm> ok, just a minute and I will put it
<dnlplm> thanks for your support
<dnlplm> http://pastebin.com/nKW8478x
<ogra_> dnlplm, hmm, does /apps/minicom.sideload/2.7/minicom actually exist ?
<ogra_> (and hi !)
<dnlplm> actually not
<dnlplm> so this is the problem
<ogra_> yeah
<dnlplm> I installed the package with snappy-remote
<dnlplm> so does this mean that there is a problem in my .yaml file?
<ogra_> oh, i see whats wrong .... your package.yaml has no exec: entry for the binary
<ogra_> https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
<ogra_> binaries:
<ogra_>  - name: binary
<ogra_>    exec: path/to/binary
<ogra_> the path is reltive to the install path (i.e. /apps/minicom.sideload/2.7/)
<ogra_> *relative
<ogra_> (and indeed your binary needs to exist in the place you point to :) )
<dnlplm> ok, I thought that the binary was copied in the correct dir
<dnlplm> by the installer
<dnlplm> I will change the exec entry
<dnlplm> thank you very much
<ogra_> have you been using snapcraft to create the snap ?
<ogra_> (sounds like a but if so ... )
<ogra_> *bug
<dnlplm> snappy build
<ogra_> ah
<ogra_> snappy build just rolls whatever you have in the dir you call it in (or give as argument) into a snap ... it doesnt modify the content in any way
<dnlplm> ok
<ogra_> so your binary indeed needs to be there already
<dnlplm> so a possible solution is to create the dir  tree
<dnlplm> same of the target?
<dnlplm> or maybe I should use snapcraft
<ogra_> well, i usually create a bin/ dir where i put the binary in
<ogra_> and point the exec line to bin/mybinary
<dnlplm> ok
<dnlplm> sounds easier
<dnlplm> thanks, I will try the suggested change
<ogra_> let us know how it goes :)
<dnlplm> sure
<Chipaca> ogra_: you don't need an "exec" line, IIRC, in which case it looks for "./name"
<ogra_> ah
<Chipaca> ogra_: s/, IIRC,//
<ogra_> the doc above only says:
<ogra_> Binaries have to be declared. As above, you can provide a list of the binary names you want to export to users when they install your app.
<ogra_> and has the exec: in the example
<Chipaca> ogra_: mhmm
 * ogra_ files bug 1487505 as a reminder
<ubottu> bug 1487505 in Snappy "packaging documentation should mention that "exec:" is not mandatory" [Undecided,New] https://launchpad.net/bugs/1487505
<Chipaca> ogra_: exec might be mandatory for the review tools tho
<ogra_> ah
<Chipaca> i haven't checked
<Chipaca> and the sooner we fold the review tools into snappy itself the better
<Chipaca> but, there it is
<Chipaca> snappy tries to be generous with what it receives
<Chipaca> whereas the store doesn't have that luxury
<ogra_> yeah
<ogra_> well, we can always close the bug
<Chipaca> exec itself shouldn't matter one way or another, but it's the mindset
<ogra_> yup
<Chipaca> anyway! hope that unblocked dnlplm. Wondering where the binary was, such that he thought we'd find it by magic :)
<ogra_> the binary alone might not help though, might still need libs
<dnlplm> solved :-)
<ogra_> cool !
<dnlplm> I simply added the entry
<dnlplm> exec: meta/bin/minicom
<dnlplm> and now it is working without any issue
<Chipaca> um
<ogra_> oh, dont put it into meta :)
<Chipaca> dnlplm: don't put it into meta/ please
<Chipaca> dnlplm: we pretend "meta/" is ours :)
<ogra_> meta should only have packaging info
<dnlplm> ok
<dnlplm> simply bin/minicom
<ogra_> yeah
<Chipaca> dnlplm: nothing would've broken _today_ (i think?) with it being in meta/, but if tomorrow we decided to use meta/bin for something we wouldn't go around checking if you were ok with it
<Chipaca> dnlplm: in that sense it's "ours"
<dnlplm> that's fine
<dnlplm> I understand your concern
<ted> Testing my snapcraft demo and it seems the docker framework is broken.
<ted> It uses a 'pwd' where that'll be the directory of the app, not the framework.
<ted> Seems that /app/docker/current/ works as a good replacement :-)
<sergiusens> Chipaca: do you know if launchpad's api export git already?
<sergiusens> git branches, MPs and such
#snappy 2015-08-22
<pindonga> hi all, anyone can tell me where the source is available for the webcam-demo package?
<pindonga> I'd like to learn how it was built
#snappy 2015-08-23
<ogra_> pindonga, see https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/
#snappy 2016-08-22
<frodowiz1> new here.. gotta sleep at midnight.. anyone understand how to set a tcl library path inside a snap?  if it is by using export, i am working on that. probably need to launch a script to export  the path then run tclsh. am i anywhere  near right?
<pitti> sabdfl: there's plenty of interfaces; journald logs syslog, dmesg, services's stdout/err, so any of those; a direct interface is logger --journald (if you need to fine-tune the property fields), or the C library API; http://0pointer.de/blog/projects/journal-submit.html describes those
<mup> PR snapd#1713 closed: tests: start teaching the fakestore about assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1713>
<zyga> good morning
<zyga> mhall119: hello
<zyga> mhall119: I heard you ran into an issue with the content interface on Firday
<zyga> mhall119: could you please report the issue if you didn't already
<zyga> mhall119: I talked to mvo and I believe I know what this issue is about, I will fix it no
<zyga> now*
<JamieBennett> zyga, there is a bug already I believe
<morphis_> ogra: could you put the firmware for pi3 wifi already into the kernel snap?
<zyga> JamieBennett: do you have a link for that
<JamieBennett> https://bugs.launchpad.net/bugs/1615113
<mup> Bug #1615113: snap-confine prevented from mounting base directory through the "content" interface <Snappy Launcher:New> <https://launchpad.net/bugs/1615113>
<JamieBennett> zyga, ^
<mup> PR snapcraft#747 opened: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <https://github.com/snapcore/snapcraft/pull/747>
<zyga> JamieBennett: thanks, the bug is fixed now
<ogra> mvo, mind merging my classic-snap PR ? (then i can move the snap to the beta channel)
<zyga> hey ogra, how are you :)
<JamieBennett> zyga, great, and great investigation work from mhall119
<ogra> zyga, a bit worn out (busy weekend) but fine beyond that :)
<morphis_> <morphis_> ogra: could you put the firmware for pi3 wifi already into the kernel snap?
<mup> Bug #1615566 opened: snapcraft SDK <Snappy:New> <https://launchpad.net/bugs/1615566>
<ogra> Chipaca, so when my system does a secret auto update over night then "snap list" shows the newly installed ubuntu-core despite me not having rebooted yet (so that version isnt in use at all yet) ... isnt that a bug ?
<ogra> morphis_, well, we need it to go to the archive
<morphis_> ogra: sure, but what is the state of that work?
<ogra> i'll try o get it added to the package via the PPA, but it needs to go in ASAP
<morphis_> aye
<ogra> morphis_, no idea, ppisati_ are you working on getting the Pi3 FW into xenial  ?
<ogra> mvo, can you approve https://myapps.developer.ubuntu.com/dev/click-apps/5573/rev/6/ ? that should amke morphis_ happy
<morphis_> ogra: yeah!!
<ogra> *make
<ogra> (i hope at least )
<mup> PR snapd#1709 closed: many: teach prepare-image to copy the model assertion (and prereqs) into the seed area of the image <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1709>
<mvo> ogra: done
<ogra> thx !
<mvo> ogra: you need to publish it still though
<ogra> morphis_, tell me if it works for you, then i'll push it to the beta channel too
<ogra> mvo, yeah
<morphis_> ogra: will do
<morphis_> matteo: ^^
<matteo> ok
<matteo> by publish you mean in the snap store?
<ogra> mvo, FYI, i dropped the "raspi2" from the pi2-kernel version string ... (was inconsistent vs the other kernels)
<ogra> matteo, yes, it is n the edge channel now
<morphis_> matteo: yes, in the edge channel
<ogra> matteo, if you have a running image on the pi3, just "sudo snap refesh pi2-kernel --edge" and reboot ... then check /proc/net/dev if you have a wlan interface
<matteo> ok
<ogra> (i'll have to do another rebuild though, forgot to ship the license file for the FW)
<matteo> is the firmware like the DHD one?
<ogra> it is from ppisati_'s package
<ogra> raspberrypi-wireless-firmware  from https://launchpad.net/~p-pisati/+archive/ubuntu/embedded
<matteo> ok
<zyga> matteo: o/
<matteo> hi
<ogra> ubuntu@pi2:~$ ifconfig | grep "^[a-z].*Ethernet"
<ogra> enxb827eb04db1c Link encap:Ethernet  HWaddr b8:27:eb:04:db:1c
<ogra> gotta love the new NIC naming ...
<morphis_> ogra: doesn't work here
<ogra> hmm, any errors in dmesg/syslog/journald ?
<morphis_> pi2-kernel 4.4.0-1019-2 is what I have
<ogra> yeah, thats the right oone
<morphis_> I am seeing brcmfmac loaded
<ogra> did it load before ?
<morphis_> ogra: https://paste.ubuntu.com/23078108/
<morphis_> no
<morphis_> [   18.743469] brcmfmac_sdio mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2
<ogra> brcmfmac_sdio mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2
<ogra> heh
<ogra> *snap*
<morphis_> hm
<morphis_>  /lib/firmware/brcm80211/brcm/brcmfmac43430-sdio.bin is present
<ogra> yes, i guess wrong dir
<ogra> shoudl go to /lib/firmware/brcm i guess
<morphis_> ogra: yeah, looks so
<ogra> bah, that needs some hackery :(
<jgdx> when snapping a .deb, what's the best strategy when it comes to hard coded cmake variables passed as -D to a target?
<jgdx> ogra, maybe you know? ^
<jgdx> looks like you can do it at runtime using getenv, or somehow at build time. Or maybe via some magic in snapcraft.yml
<ogra> jgdx, well, i usuallly snap binaries when snapping debs :)
<ogra> jgdx, that said ... i have one package that uses the make plugin https://github.com/ogra1/packageproxy
<ogra> (thats approx, built from latest git)
<jgdx> ogra, please excuse my lack of proper terminology :p
<ogra> but usually i just download the deb and run dpkg -x . and then use the copy (now dump) plugin to copy the binaries around
<ogra> https://github.com/ogra1/laidout is one where i re-use upstreams .deb
<jgdx> ogra, actually, the binary I snapped works fine, but the binary tries to read from a absolute path based on CMAKE_BINARY_DIR, which doesn't exist.
<ogra> ah, thats bad
<ogra> if it douesnt provide a way to overrdie that at runtime i fear you have to patch ...
 * ogra would make it use getenv() and add an env var from a wrapper script 
<jgdx> ogra, right, and then the best way would be a configflags: -DSNAPPY=1?
<ogra> hmm, no idea
<ogra> thats a kyrofa or sergiusens question ... (or one for the snappy-playpen on gittter)
<jgdx> ogra, okay, thanks
<sergiusens> ogra jgdx I think that is an upstream call ;-) RUNTIME_RELOCATION?
<sergiusens> or even just check for the existence of env vars and use those if defined
<jgdx> sergiusens, I forgot to mention we're the upstream /cc ogra  :)
<ogra> hah
<ogra> well, just get the path from an env var then
<ogra> (as override option)
<jgdx> okay then :) Thanks sergiusens, og
<morphis_> ogra: are you pushing a fixed kernel snap to the store?
 * zyga released snap-confine 1.0.40 just now
<tvoss> zyga, o/
<ogra> morphis_, already there but mvo needs to approve it again (https://myapps.developer.ubuntu.com/dev/click-apps/5573/rev/7/)
<morphis_> ogra: aye!
<mvo> ogra: done
<ogra> mvo, whom do i have to poke to get approval righty myself ... i really dont want to drag you away from your work all the time
<ogra> *rights
<jgdx> sergiusens, any way to quickly do a make build, then have those newly built files into prime?
<morphis_> ogra, mvo: hm, a snap refresh --edge pi2-kernel does give me any updates
<morphis_> ah!
<ogra> it does here
<morphis_> that took a bit to go through
<ogra> yeah, thats my fault ... forgot to press the publish button immediately
<morphis_> :-)
<morphis_> ogra: ah, there we go, a wlan0 is present now
<ogra> yay
<morphis_> matteo: ^^
<bull> hi everyone :)
<bull> why our snap cant read files inside it :D
<ogra> where is "it" in that question ? :)
<bull> ogra, why my snap cant read $SNAP/etc/xdg/Trolltech.conf
<bull> ogra,  am writing gui for snapcraft plz join and guide me where am wrong :P
<ogra> bull, what makes you think it cant read the file, do you have any DENIED messages in syslog ?
<bull> yes
<ogra> can you put them into paste.ubuntu.com ?
<bull> ogra,  that is the same issue i faced yesterday . i was packaging supercalc and it says DENIED
<bull> it should able to read $SNAP/etc/xdg/Trolltech.conf , i checked the xdg vars not set or hardcoded in my qt app
<ogra> wasnt that trying to read another file ?
<ogra> (i.e. without $SNAP)
<bull> i copied that file to other location inside $SNAP and it saying denied again
<bull> you mean outside $SNAP ?
<ogra> and you fixed your binaty to actually read the file or accept the XDG location ?
<ogra> *binary
<ogra> this isnt really a snap problem ...
<bull> bro why developer will mess with xdg path to pack their apps with snap
<ogra> if your app does not respect the XDG_CONFIG_DIRS variable then there is a bug in your app (or in whatever loads the file)
<bull> i mean they will excepting everything okay , cause this is unusual no packaging systems messs with what app looking for ?
<ogra> these variables have been designed in the freedesktop standard to exactly allow re-location of binaries
<ogra> so that you can run two versions of the same app alongside from different paths for example
<ogra> if the app doesnt follow that standard you might need to fix it
<bull> ogra, my app works fine on ubuntu 12.04 to 16.04
 * ogra wonders why there are so many QT apps that do not have such probs
<bull> with debian packaging
<ogra> (we obviously have a good bunch in the store)
<bull> qt4?
<ogra> yes, debian packaging has full root access to the whole system ...
<ogra> (and the according security issues too)
<bull> ogra it is clear that my app want read $SNAP/etc/xdg/Trolltech.conf
<jdstrand> sabdfl: hi! re 1615262> yes, I'll take care of it
<bull> so my question -  why snap cant read its ownstructure
<ogra> bull, i dont understand
<ogra> can you show the exact DENIED messages please
<bull>  why snap cant read its own structure  ( $SNAP/etc/xdg/Trolltech.conf )
<bull> wait
<ogra> (since you start giving contradicting info)
<bull> http://paste.ubuntu.com/23078316/
<bull> its not snappy-debug
<bull> it comes out directly when i run app
<ogra> thats not a DENIED message
<ogra> and doesnt talk about Trolltech.conf at all !
<bull> okay wait
<bull> let me debug
<bull> ogra, /snap/supercalc/x2/usr/bin/wrapper: /snap/supercalc/x2/trollconf: Permission denied
<mup> PR snapcraft#747 closed: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/747>
<ysionneau> Hi, webdm does not work anymore on my target, some xmlhttprequest answers a 500 error code when querying /api/v2/packages/?installed_only=true
<ysionneau> any idea?
<ysionneau> I only see a rotating Ubuntu logo
<ogra> bull, please giv the DENIED messages from syslog ...
<bull> it not logging anything
<ogra> bull, when you try to run the app after you installed the snap
<bull> sudo /snap/bin/snappy-debug.security scanlog | grep supercalc
<ysionneau> no error in the journalctl -u snap.webdm.snappyd.service
<ogra> ysionneau, there is a bug in the systemd unit, it doesnt wait for networking
<jdstrand> bull: fyi, you probably simply want: sudo /snap/bin/snappy-debug.security scanlog supercalc
<ysionneau> ogra: hmmm but I can browse the page though :o
<ogra> ysionneau, oh, and it isnt called webdm anymore ;) it is snapweb now
<bull> ysionneau, okay
<ysionneau> ogra: well, when I do "snap find webdm" it finds it
<ogra> oh, we need to unpublish it i guess
<ysionneau> (and snap find snapweb does not find anything :o am I outdated somehow ?)
<bull> ogra, i got it
<ysionneau> I have ubuntu-core 16.04+20160531.12-01
<bull> ogra, http://paste.ubuntu.com/23078334/
<mup> PR snapcraft#748 opened: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <https://github.com/snapcore/snapcraft/pull/748>
<ogra> ubuntu@pi2:~$ snap list snapweb
<ogra> Name     Version  Rev  Developer  Notes
<ogra> snapweb  0.20     4    canonical  -
<ogra> ubuntu@pi2:~$
<ogra> hmm, weird
<ogra> snap find does indeed not find it
<ysionneau> my version of webdm is 0.20 also :o
<zyga> jdstrand: hey, how are you doing
<ogra> ysionneau, thats super ancient
<zyga> jdstrand: I would like to implement the setns feature
<ysionneau> I just unsquashfs'ed it and resquashed' it, to fix the wrapper script to run the correct binary
<zyga> jdstrand: I would appreciate any hints you have, I didn't fully read the converstation around that but I talked with stgraber at the sprint about it so I have an idea
<ogra> ysionneau, is this on an all-snap image or oon classic ?
<ysionneau> ogra: hmmm weird, that's on 16 series
<ysionneau> http://pastebin.com/MXQXxchN <= I'm using this to generate my image
<ogra> bull, so like i said, your app is broken, fix it to folow general standars for XDG dirs and it will work
<ogra> there is no way around that
<bull> daem
<bull> ogra,  should it work normal with debian install ??
<ogra> ysionneau, sudo snap install ubuntu-device-flash --devmode --edge
<bull> i tested it on  more then 5 PC
<bull> of my friends and mine
<ogra> bull, yes, because debian packages are not running in a sandbox and have full insecure root access
<ogra> ysionneau, see mvo's mail to the mailing list about new images and how to build them, we now publish updates for u-d-f via a snap package
<jdstrand> zyga: are you talking about for the shared mount namespace per snap bug?
<ysionneau> ah nice ogra
<ysionneau> do you think it's because of my old udf ? :o
<mup> Bug #1595993 changed: go binaries use bind on startup, requiring network-bind <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1595993>
<ogra> ysionneau, well, mainly because of your old ubuntu-core
<bull> ogra,  why you guys don't want app to read data ??
<ogra> but i dont think you can build any working images with the old udf
<ysionneau> my old udf does not fetch a recent ubuntu-core ? :(
<ysionneau> hmmm my image kinda work though
<ysionneau> maybe everything is in the "kinda"
<ogra> bull, there are plenty apps in the store that read data from various places
<ogra> bull, they simply follow established standards
<ogra> yours does not seem to
<ogra> ysionneau, definitely :)
<ysionneau> error: unknown flag `edge' <=
<ysionneau> (I'm on debian testing)
<bull> its not like that , it simply cant read /snap/supercalc/x1/trollconf
<ogra> ysionneau, is your snapd up to date ?
<ysionneau> I just installed it
<ogra> ogra@anubis:~$ snap --version
<ogra> snap    2.12+ppa203-1
<ogra> snapd   2.12+ppa203-1
<ogra> series  16
<ogra> ubuntu  16.04
<ysionneau> Get:5 http://debian.univ-lorraine.fr/debian unstable/main amd64 snapd amd64 2.0.8+1 [4,352 kB]
<ogra> i think you need at least 2.11
<ysionneau> yann@imperium:~/dev/workspace2$ snap --version
<ysionneau> snap
<ysionneau> snapd unknown (series 16)
<ogra> oh
<bull> ogra ty
<ogra> bull, that is not what the DENIED message says
<ogra> it does not try to reat /snap/supercalc/x1/trollconf there
<ogra> so what makes you think it cant ?
<bull> then?
<bull> ogra,  okay i will dig it ,
<bull> ogra,  my app can read anything inside $SNAP right >?
<ogra> bull, yes
<ysionneau> even in debian unstable it seems to be snapd 2.0.8+1 :/
<bull> i have few more question - i have an app which writes data to user's home directory , do snap allow that ?
<ogra> and it can write to $SNAP_DATA (for daemons/services) and to SNAP_USER_DATA (for user apps)
<ogra> bull, you can either write to SNAP_USER_DATA or you can use the home interface in your snapcraft.yaml
<bull> oh $SNAP_DATA  ?
<ogra> note that this does not allow access to "dot" dirs unside home
<bull> :)
<ogra> *inside
<zyga> jdstrand: yes
<bull> damn
<bull> what :D
<ogra> since that would be a security hole
<ogra> (apps could spy on other apps etc)
<bull> qt writes app data inside .local/data/yourapp.com/
<bull> that mean snap will break qt ??
<ogra> so set the right XDG variable to make it write to SNAP__USER_DATA instead
<ogra> again, there are tons of Qt apps in the store that work fine
<jdstrand> zyga: I think it would be helpful to read through that bug before we talk about it. I can say, at the highest level you simply give setns the pid and CLONE_NEWNS for the mount you want to go into
<bull> this is not easy for everyone , so why don't you guys make set these paths since you know snap will write data there only
<bull> ogra,  there should be better documentation in site
<ogra> the desktop-launcher sets these paths usually
<jdstrand> zyga: so, 'just' need enter the mount namespace of another command if it is running, otherwise create a new one
<ogra> but if your app does not respect the XDG variables you have to fiix the app
<bull> what snap allow and what not !! where user have to fix their apps and everything
<bull> okay thanks
<ogra> bull, btw, the guys that do app packaging are in https://gitter.im/ubuntu/snappy-playpen ... perhaps they have some ideas
<zyga> jdstrand: yes, this is obviously a race, I wanted to think about how to solve this
<jdstrand> zyga: 'just' is the hard part. I can think of a robust implementation using security labels. I don't yet for cross-distro
<ogra> bull, i told you what snap allows and obviously other packagers do not have big problems with that
<zyga> jdstrand: I was thinking that snap-confi e could fork a per-$SNAP_NAME process that just hangs around forever
<zyga> jdstrand: that sets up a separate mount  namespace
<bull> ogra, what you think of making snapcraft gui ?? will it be a task that can be attained or what ?
<zyga> jdstrand: but doensn't hold any files open and chdirs to /
<zyga> jdstrand: with the sole goal of being easy to find
<zyga> jdstrand: I could use prctl to tweak the process name so that I can find it
<zyga> jdstrand: and I could use /proc/$pid/exe to find the executable as a confirmation check
<jdstrand> don't do that
<jdstrand> not the prctl part anyway
<ogra> bull, well, why not ... (not that i'd use it ... after all you have to manually edit files, create wrappers etc so in the end you use an editor anyway)
<jdstrand> since applications can change their command name
<bull> i mean it will make easy pack snaps and we can help users showing more info , scanlog etc
<zyga> jdstrand: snap-confine --zygote $SNAP_NAME would not run any apps
<zyga> jdstrand: it would just sleep forever having unshared the mount namespace
<bull> ogra,  we will having simple buttons to create files , check errors in yaml file
<bull> :D
<zyga> jdstrand: each snap-confine that actually wnats to start an app would wait for the zygote or launch one
<ogra> bull, sure, i wont hold you back ...
<zyga> jdstrand: (with the usual trickiness on how to make this race-free and reliable)
<ogra> but for me packaging is mostly a commandline task anyway ... and all the tools i need there are existing already
<bull> i initiated a github repo plz keep me updated with features and stuffs we can add to it
<jdstrand> zyga: the security label approach was-- fork, note its PID, create a sumlink from /var/lib/snapd/mountpids/snap.hello-world -> /proc/<pid>/ns (or whatever). then enter that namespace, then verify the security label of that process, if different, die()
<ogra> so you shoudl try to find someone who wants to use such a tool and have him/her give you feedback
<jdstrand> zyga: you could do your technique with the symlink approach
<ogra> https://gitter.im/ubuntu/snappy-playpen is probably the best place for this
<bull> ogra, you are in deep bro , you know everything so its easy for you , i seen people and myself find it hard to figure things out :D
<ogra> yes, thats why i'm saying i'm the wrong target audience
<ogra> i know that bzoltan's team aslo wroks on integration snapcraft into the ubuntu SDK
<jdstrand> zyga: but don't have --zygote
<ogra> probably you can help there or give them your tool for integration ot for ideas at least
<ogra> *integration of
<bull> all i want from you to guide me like you doing here , if i go wrong with the concept anywhere in the gui version of snapcraft , i need you to guide me
<bull> i will be asking few more people relating to project for sure
<ogra> no, you dont
<bull> :D
<ogra> there are 282 people in this channel, do you think i'm the only one with knowledge ?
<jdstrand> zyga: ie, run the app, fork this process that will hang around, note its pid, create the symlink, go into it. on the next app launch the symlink exists, so go into it. on systems with a security label, also verify it
<bull> no, i mean you are one of them , chill
<zyga> jdstrand: mmmm
<ogra> bull, also, the packaging specialists are realy at https://gitter.im/ubuntu/snappy-playpen ... as i said a few times already
<zyga> jdstrand: and the forked one should just sit around forever?
<bull> zyga, ty
<jdstrand> zyga: with this idea, yes
<zyga> jdstrand: I'll finish my current call and wrap my head around this and get back to you, thank you for the idea
<jdstrand> zyga: note, niemeyer specifically requested reviewing the design, and I know tyhicks (and maybe ratliff) would as well as me
<mhall119> zyga: quick work there, thanks :)
<bull> mhall119, hi :)
<mhall119> hi bull
<zyga> mhall119: my pleasure, I'm sorry I didn't finish the article on content sharing
<bull> i snapped supercalc but it running only with devmode for now there is a bug in my app which wont allow it to run , http://paste.ubuntu.com/23078334/
<bull> mhall119,  https://github.com/keshavbhatt/supercalc
<ogra> bull, soo ... if you fix the broken line in your wrapper the error will go away ...
<bull> ogra, and whats that >??
<ogra> (you could have poinnted me to that before ... )
<ogra> shell vearibles do not allow spaces ... fix your line 3
<bull> popey, already checked that
<bull> ogra, wait
<bull> ogra,  you mean this-  XDG_CONFIG_DIRS= $SNAP/trollconf   to ---- XDG_CONFIG_DIRS=$SNAP/trollconf
<bull> ?
<ogra> yes
<bull> daem
<ogra> (not sure if that will help when your app doesnt respect the freedesktop standards though ... but it will fix your error)
<bull> okay :D let me check
<ysionneau> hmm doesn't seem it works nicely to run snapd and stuff in docker
<ogra> i think there is a bug open for that
<bull> anyone interested in packing a awesome qml music player https://github.com/keshavbhatt/kmusicplay
<bull> ogra, will the changes will added to stage area automatically when i will run snapcraft after making chnages to wrapper script ?
<ogra> no. you need to clean
<ogra> (at least the stage and prime steps i think)
<bull> this is not good feature snapcraft offering :D
<bull> cleaning stage will download dependencies again right ??
<ogra> no. thats pull
<bull> okay ty
<ogra> (as described in detail in "snapcraft --help" )
<bull> ty
<mup> PR snapd#1686 closed: boot: add support for "devmode: {true,false}" in seed.yaml <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1686>
<mhall119> well, now I've submitted fixes to snapcraft and snap-confine, I guess snapd is next
<mhall119> zyga: are you still going to do a blog post?
<ysionneau> ogra: on Ubuntu Xenial, I can install webdm but not snapweb is found (on amd64), normal?
<ysionneau> no*
<bull> ogra,  am not compiling my app from source using snapcraft , am just copying the binary using snapcraft , so do you think compiling with snapcraft qmake plugin will make the difference ??
<zyga> mhall119: yes, just swamped with more important things now
<ogra> ysionneau, yeah, try "sudo snap install snapweb --edge"
<ogra> (it seems to only be in the edge channel)
<ogra> bull, no idea, most of the time you dont need to change the apps ...
<ogra> but yours seems special
<eldarkg> Hello guys. What about the state of this bug https://bugs.launchpad.net/snappy/+bug/1580740 (xdg-open)
<mup> Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-needed> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740>
<ogra> eldarkg, i know that the needed bits in the ubuntu-core package landed last week, not sure which bits of snap-confine are needed additionally for it though, seb128 and zyga might know
<eldarkg> ogra: thx
<mhall119> zyga: I recall you mentioned working on allowing content sharing slots to support multiple plugs (though I assume now that it should be the other way around), is that implemented?
<eldarkg> zyga: hello. Are u there?
<eldarkg> seb128: hi. Are u here?
<zyga> eldarkg: hey
<zyga> mhall119: no, thre's no bug report either, if you report it please give me a link
<eldarkg> zyga: what u say about bug https://bugs.launchpad.net/snappy/+bug/1580740
<mup> Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-needed> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740>
<zyga> mhall119: it the way I imagine it is that the current interface will start to refuse connecting more than one item
<zyga> mhall119: and there will be an attribute a slot can set, like "multi: yes" or similar
<zyga> mhall119: where the target will be a directory that will now instead contain individual bind mounts
<zyga> mhall119: e.g. plugins.d/plug-1 plugins.d/plug-2
<zyga> mhall119: where plug-1, 2, 3, etc would be maintained by snapd (the actual snap would just contain the empty directory)
<zyga> mhall119: there's a little feature work to support that but it is well understood
<eldarkg> zyga: how I can to give permission to snap app to open file with system viewer (like browser or evince)?
<mhall119> zyga: cool, though I assume you mean that the plug will have this attribute, since it is the consuming end of the interface
<zyga> mhall119: er, yeah, the consuming side
<zyga> eldarkg: that depends, what would the URL look like?
<zyga> eldarkg: this falls into content hub territory
<zyga> eldarkg: I agree this should be supported but I'm unsure how
<ogra> zyga, well, didnt we have some basic xdg-open integration ? i definitely landed a fix from the desktop team in ubuntu-core last week
<mhall119> zyga: thre was the snap-xdg-open ->(dbus)->xdg-open bridge that was being worked on
<zyga> ogra: we do but it is whitelist based
<ogra> right
<zyga> mhall119: I'm well aware of it
<seb128> eldarkg, hey
 * zyga has to package that for al the distros next
<ogra> i thought that was part fo the snap-confine package (i could be wrong indeed)
<zyga> though probably along with snapd itself
<eldarkg> zyga: url like the system path
<zyga> ogra: nope
<zyga> ogra: snap-confine will merge with snapd this week
<ogra> ah
<ogra> neat
<mhall119> zyga: is the whitelist a list of apps, or url schemas?
<eldarkg> seb128:  how I can to give permission to snap app to open file with system viewer (like browser or evince)?
<seb128> zyga, ogra, eldarkg, xdg-open is to open urls, it's not going to let you open content, that's content-hub material
<zyga> eldarkg: system path is not an URL as it lacks he scheme, a file:// url might be something but those may be confusing (due to how snap-confine works)
<seb128> eldarkg, browser or evince? those are different usecases
<zyga> mhall119: schemas
<zyga> seb128: I agree, hence my earlier comment
<ogra> seb128, bug 1580740 only talks about browser links
<mup> Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-needed> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740>
<seb128> ogra, right, but eldarkg seems to ask about evince
<ogra> and i know we landed the ubuntu-core side of it
<seb128> which we don't have addressed yet
<seb128> haven't*
<ogra> right
<eldarkg> seb128: open pdf with system viewer for example
<ogra> it also needs the new ubuntu-core promoted to the stable channel
<seb128> eldarkg, that needs work, you can't do that today
<ogra> (i'm running --edge on my desktop machine since last week, seems pretty stable )
<eldarkg> seb128: ok. Is it in process?
<seb128> eldarkg, not that I know of
<eldarkg> seb128: what about open url with browser?
<seb128> that's being worked on
<seb128> it should be working on the edge channel
<ogra> doesnt
<ogra> since the desktop side is still missing
<seb128> you just need an updated ubuntu-core and snapd-xdg-open installed
<ogra> right, that latter part isnt automatic
<seb128> ogra, install https://launchpad.net/ubuntu/+source/snapd-xdg-open
<ogra> yeah
<ogra> doing so now
<eldarkg> seb128: sudo snap refresh --edge ubuntu-core?
<seb128> I guess?
<seb128> ogra, ^ that refresh command is right?
<ogra> yeah
<ogra> (i always put --edge last ... not sure that mmatters though)
<ogra> hmm, nope
<ogra> virtual bool QGenericUnixServices::openUrl(const QUrl&): Unable to detect a web browser to launch 'https://krita.org/'
<eldarkg> seb128: another snapcraft things?
<lazyPower> greetings o/ it appears the rpi2 images for snappy-core are in a really inconsistent state. Is this known or should I start crafting a bug?
<ogra> lazyPower, since they are experimental thats not a surprise ... though last weeks images should be fine now
<lazyPower> ogra - well, not really. i flashed a couple boards this weekend. I'm unable to install snaps, and if i apt-get upgrade it bricks the board's modules (no networking, et-al)
<ogra> lazyPower, apt ???
<lazyPower> yeah, thats what i said
<lazyPower> its like it boots in classic mode
<seb128> ogra, :-/
<seb128> ogra, does xdg-open https://krita.org works?
<ogra> lazyPower, where did you get the images ?
<seb128> ogra, from hello.bash or something
<lazyPower> ogra - http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/
<ogra> seb128, works, yes
<ogra> lazyPower, eeek ... no ...
<seb128> ogra, do you have any gtk app snap?
<ogra> lazyPower, http://people.canonical.com/~mvo/all-snaps/16/
<seb128> ogra, if so can you try from a about dialog if you can open their website?
<mup> PR snapd#1699 closed: introduce the "lxd" interface <Blocked> <Created by tych0> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1699>
<lazyPower> ogra - ack will give this a go and let you know how i make out with it.  can i suggest we get some update lovin on the developer portal? its linking aginst the images i posted above, and the rpi2 image is terribly broken rn
<ogra> trying in my gitter app:
<ogra> LaunchProcess: failed to execvp:
<ogra> xdg-open
<ogra> seb128, ^^
<ogra> (thats using electron and is installed in --devmode)
<ogra> i wonder if snap refresh ubuntu-core doesnt really apply without reboot or restart of snapd
<ysionneau> ogra: I've installed snapweb --edge in an Ubuntu Xenial. Listing installed snaps does work this time. However, when I click on "Browse store", I get an error 500
<seb128> ogra, :-/
<ysionneau> on the /api/v2/packages
<ogra> ysionneau, yeah, its still buggy
<ogra> lazyPower, gimme a few, i'll wipe the dir on cdimage
<ysionneau> is someone actively working on fixing it?
<ogra> leftyfb, http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/ ... :)
<leftyfb> ogra: ?
<ogra> back to the "please use classic" text now ... that they were there was an accident ... we currently dont use cdimage for them
<ogra> the experimental images are good enough to get an alpha release though ... i guess we can put them there by end of the week
<ogra> niemeyer, do you happen to have the final kernel.yaml spec handy somehow ? i'm trying to figure out where/how to add daemons and binaries that are required for drivers
<ogra> (trying to get the rpi graphics driver working, but that needs a bunch of config binaries shipped along)
<elopio>  export BYOBU_CHARMAP=x ; . ~/.bashrc
<niemeyer> ogra: Daemons and binaries are not part of the kernel spec so far
<niemeyer> ogra: A daemon would be just like any other snap
<ogra> niemeyer, well, i have a workitem to get all-snap images ready for graphics for RTM
<ogra> and these binaryies need to go together with the drivers
<ogra> inside the kernel snap
<ogra> and also with udev rules and the like
<ogra> i was told in heidelberg that the kernel spac was done and would cover evereything :(
<ogra> niemeyer, many arm drivers actually need daemons to even init the drivers i.e. PVR/SXG ships the whole binary blob inside a userspace daemon, the kernel driver only provides some stubs that attaches to
<niemeyer> ogra: As I just said, there's nothing special about that
<ogra> and we cant realyl ship these separated from the kernel module
<niemeyer> ogra: Just add a daemon to the snap
<ogra> since they are 100% bound to each others version
<niemeyer> ogra: the kernel snap is still a snap
<ogra> niemeyer, right, but if i put something in /usr/bin in the kernel snap it will be ignored
<niemeyer> mvo: Can you think of any reasons why a daemon wouldn't work in the kernel snap?
<niemeyer> ogra: You won't put something in /usr/bin.. it's still a snap
<ogra> if the binary blob in the kernel expects its daemon to be at /usr/bin/foobar and the kernel snap doesnt bind mount it there the driver will not work
<niemeyer> ogra: Add a daemon just like any other snap
<ogra> and since it is a binary blob i cant change the path
 * ogra curses that he had a conflicting meeting in heidelberg when the kernel snap was discussed ... 
<niemeyer> ogra: THat's not usually how such daemons work
<ogra> niemeyer, tell that to the vendors :)
<niemeyer> ogra: Where can I see the code?
<ogra> you cant ... i.e. the pvr daemon is a binary blob
<ogra> i can probably get along with your suggestion for the pi for now though
<ogra> there the daemons just need the device nodes afaik
<lool> hi all
<lool> elopio: hey, how is it going?
<ogra> but i think long term the kernel snap needs some special handling for this ... especially once we go for more exotic arm devices
<niemeyer> ogra: Where can I find the code for that driver?  The binary blob is necessarily not alone or it'd not like against the kernel
<lool> elopio: before I left for a week you had built a snapweb with a hotfix for the store search issue http://people.ubuntu.com/~elopio/snaps/
<niemeyer> ogra: In general it is the deamon that talks to the module, not the other way around
<lool> elopio: did you end up pushing it in the source code / in the store? is there an armhf build of it?
<niemeyer> ogra: The module doesn't go looking for daemon paths in the filesystem
<elopio> lool: no, nothing much other than that. I have the PR here, I will propose it for you to +1.
<elopio> lool: I worked a little on multiarch with launchpad, but there's a problem in there that makes the import fail: https://bugs.launchpad.net/launchpad/+bug/1084403
<mup> Bug #1084403: no support for gpgsig tags <amd64> <apport-bug> <patch> <raring> <running-unity> <Bazaar Git Plugin:Triaged> <One Hundred Papercuts:Invalid> <Launchpad itself:Triaged> <pyMOR:Invalid> <bzr-git (Ubuntu):Triaged> <https://launchpad.net/bugs/1084403>
<lool> elopio: awesome thanks
<ogra> niemeyer, i'm pretty sure pvr does that (at lest it used to on the pandaboard and on the maguro phone we had), the pi stuff is on https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+packages ... raspberrypi-vc - 1.20150502.d280099-1
<elopio> in the meantime, we can have auto uploads from travis to amd64.
<lool> elopio: I actually need a fixed armhf
<lool> and I dont think we can build go under qemu-arm
<niemeyer> ogra: Do you have a link for the source code repository of the driver?
<lool> I could build it by hand
<ogra> niemeyer, sadly not
<ogra> niemeyer, only the deb src in that PPA
<niemeyer> ogra: Ok, so I cannot look at that right now, but I suggest investigating more carefully
<ogra> niemeyer, will do
<niemeyer> ogra: WIlling to bet the kernel module doesn't fire a daemon in user space
<ogra> iirc in pvr it was re-execing it with other options
<ogra> (pvr is the worst here though)
<ogra> the shiniest hardware you can imagine with the worst driver you can imagine :)
<niemeyer> ogra: Even there, willing to bet the kernel module doesn't start the daemon in user space
<bull> ogra, you know ogre ?
<ogra> bull, you know bill ?
<bull> haha :D no
<ogra> same here
<ali1234> how do you guys deal with constantly downloading the same deb files over and over?
<ogra> ali1234, sudo snap install packageproxy ... pint my sources.list to localhost:9999 and be done
<ogra> *point
<ali1234> does that work for foreign repos?
<ogra> needs config fiddling, but indeed it does ... (packagproxy just uses approx inside)
<ali1234> and what about if i do cleanbuild?
<ogra> thats different
<ali1234> how do i get the right sources.list inside it?
<ali1234> or multistrap? cdebootstrap?
<ogra> but there you could create an lxc container that doesnt get wiped
<bull> ogra, ogre is tekken character ,
<niemeyer> ogra:
<niemeyer> sudo cp /opt/pvr/pvr /etc/rcS.d/S60pvr.sh
<niemeyer> sudo chmod +x /etc/rcS.d/S60pvr.sh
<niemeyer> http://elinux.org/BeagleBoardUbuntuKarmic
<elopio> lool: I can build it in scalingstack. Do you need it right now?
<lool> elopio: the sooner the better, but can wait a bit
<lool> elopio: sharing details in query
<niemeyer> ogra: I need to be able to trust you to investigate those details carefully, otherwise we'll end up with a kernel snap that makes no sense
<ogra> niemeyer, yeah, i'm just starting digging here, still we will need GL libs in /lib abnd such ... there need to be bind mounts
<ogra> niemeyer, where are these described
<niemeyer> ogra: Have a look at the gl interface in snapd
<ogra> ok
<niemeyer> ogra: We may need to evolve it, but we're most of the way there already I think
<niemeyer> ogra: mvo has more insight than I do there
<ogra> right, i just need to know what the kenrel snap needs as a first step ... i.e. where and how do i ship them so they end up in the right places ... but i'll dig my way around
<niemeyer> ð
 * niemeyer => lunch
<bull> ð
<bull> :D
<ogra> btw, that beagle page only copies the start script around, there are a few MB in /opt/pvr it doesnt even mention :)
<ogra> niemeyer, enjoy your free afternoon :)
<bull> how to change name here ???
<ogra> geez ,... testing the new pi3 image here ... even the pi3 needs 10+ minutes for the first cloud-init run ... so depressing :/
<bull> hurrey
<qengho> ogra: What's taking the time?
<bulldog> bull is known as bulldog now :D
<ogra> qengho, hard to tell ... but i gues python :P
<ogra> python and arm have never been good friends
<ogra> yay
<ogra> pi3 with wlan0 ...
 * ogra can finally get rid of the wires on his desk
<ali1234> ogra: do you have a touchscreen display on your pi?
<ogra> nope
<ali1234> well, touchscreen is broken in ubuntu...
<ogra> send me one and i'll make it work :P
<ali1234> i assume you have hdmi connected then, if you're testing graphics?
<ogra> not atm, no
<lazyPower> are there any snaps using the dump plugin i can reference? i searched and did not find any in the snappy-playpen
<ogra> currently i'm rolling kernel snaps
<ogra> *testing* is far out
<ogra> first of all i'll need to *ship* all bits :)
<ali1234> ogra: how do i configure the packageproxy snap then?
<ogra> ali1234, https://github.com/ogra1/packageproxy
<lazyPower> nvm found it in the snapcraft repository
<ali1234> yes i've seen that
<ali1234> config.yaml, how do i change it? do i have to rebuidl the snap?
<ogra> sudo vi /var/snap/packageproxy/current/config.yaml
<ogra> edit the repos list
<ogra> then:  sudo systemctl restart snap.packageproxy.approx.service
<bulldog> we can build daily snap on launchpad too wow
<ali1234> okay. and what if i need to mirror two repos that have the same suite name?
<ali1234> er, distro name sorry
<ogra> ali1234, you give them different aliases
<ogra> you just need to reflect that in your sources.list then
<ali1234> okay. and by default this server is accessible on my lan, correct?
<ogra> if you find it to compilcated you can also just use apt-cacher or a squd based packageproxy
<ogra> yes, sure ... it listens on 9999 on the machine you install it on
<ogra> on all interfaces the machine has
<ali1234> the main issue for me is that i am trying to make a reproducible build script, but other people aren't going to have a package proxy
<ali1234> actually two build scripts, one using multistrap and the other one using debirf
<ogra> well, but other people probably have gigabit fiber lines ... who knows :)
<ali1234> yes but it means i have to maintain two versions of the script... one for me and one for everyone else
<ali1234> unless there is an entirely transparent way to do it
<ogra> i dont thin there is
<ogra> +k
<xavi> Hi all!, even though I guess this is not the best channel, any one can point me to some doc in order to mount encrypted partitions with snappy ?
<xavi> or mailing list
<ali1234> the other issue is that since i am doing a bootstrap then the apt config ends up inside the resulting image which i don't want
<ali1234> ah i know
<ali1234> i can put the hostnames in /etc/hosts
<ali1234> to redirect them to my local cache
<ali1234> then my config doesn't change
<ali1234> does snap see the hosts's /etc/hosts?
<mvo> ogra: just reading backlog, maybe we should have a call later today (after dinner) or tomorrow morning to catchup on this? and do a strawman proposal
<ogra> mvo, tomorrow rather ...
 * ogra feels monadyish and wants to drop out early today
<ogra> and i'd also like to collect more info about the pi and dragonboard setups first
<ogra> one thing that bothers me a bit are namesapces ... if i ship daemons or such in the kernel snap, they won't be callable with their names but only via pi2-kernel.$dameon-name
<mvo> ogra: ok
<qengho> 
<eldarkg> I don't know it is a right place or not. But how to create automatic builds in LP one repo (with snapcraft.yaml) when changed another repo (with build app source)?
<mhall119> zyga: am I correct to assume that code shared via the content-hub will run under the confinement profile of the consuming snap?
<ali1234> there's a snap in the store that looks fishy, what do?
<bulldog> ali1234, which one ? :D
<eldarkg> seb128: I don't know it is a right place or not. But how to create automatic builds in LP one repo (with snapcraft.yaml) when changed another repo (with build app source)?
<seb128> eldarkg, no idea about that, try asking on #launchpad?
<eldarkg> seb128: thx
<seb128> yw!
<zyga> mhall119: content hub or the content interface?
<ali1234> http://askubuntu.com/q/815431/12435
<elopio> lool: here's the pr: https://github.com/snapcore/snapweb/pull/50
<mup> PR snapweb#50: Patch getting all the snaps <Created by elopio> <https://github.com/snapcore/snapweb/pull/50>
<elopio> lool: but now it is failing to build: http://paste.ubuntu.com/23078669/ Do you know grunt?
<mhall119> zyga: content interface
<mhall119> sorry, not sure why I typed content-hub
<mhall119> muscle memory
<lool> tyhicks, jdstrand: Hi! are abstract sockets connections allowed by default when one has network interface (and connect() etc. are allowed)?
<lool> elopio: ah crap, I had that myself at some point
<jdstrand> lool: no. https://bugs.launchpad.net/snappy/+bug/1604967
<mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <conjure> <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
<mhall119> seb128: was it you who said the generic dbus name interface was being worked on?
<lool> elopio: there are super specific installation instructions, perhaps try in a clean chroot?
<lool> elopio: the deps are a bit ouf of date and hardcoded
<jdstrand> cc tyhicks ^
<lool> jdstrand: ok, I was just told otherwise by someone who had an unconfined daemon but confined client
<lool> ysionneau: ^
<jdstrand> lool: we will, but not for a little while yet (other higher priority items are in front of that)
<seb128> mhall119, talk to jdstrand
<seb128> mhall119, bug #1590679
<mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
<lool> jdstrand: that's fine, I was actually surprized they *could* connect when I was expecting not
<jdstrand> lool: so, we want snaps to be able to connect to themselves
<mhall119> thanks seb128
<seb128> yw
<lool> jdstrand: these would be 2 separate snaps according to ysionneau
<jdstrand> I'd be interested in seeing those snaps
<lool> ysionneau: if that's indeed possible, it sounds like a bug we should plug
<ysionneau> please don't plug this before 9 september
<elopio> lool: we are now building with snapcraft, it worked last time I tried.
<elopio> I'm playing with cleanbuild now.
<lool> elopio: +1-ed the pull request
<jdstrand> ysionneau: can you provide the snaps you are using?
<ysionneau> jdstrand: the unix listener is devmode, the one connecting is not devmode
<lool> elopio: it's super sensitive to local node modules
<ysionneau> jdstrand: I'll send it to you in pm, but keep it to yourself please
<jdstrand> mhall119: there is a PR for that. it needs work. It has gotten deprioritized behind other requests, but we'll get there. if you need to up the priority, please escalate with your manager to talk to ratliff about getting it prioritized over other things
<mhall119> ratliff: ^^ we need this dbus interface to support gnome/elementary/kde applications
<mhall119> now that the content interface is available, it's the only other blocker that I currently know of
<jdstrand> mhall119: note, ratliff knows that information. we have a card for it with that in it. the question is if it should be escalated beyond other cards. your manager should use the stakeholder process if you want it prioritized over other items
<ratliff> ack, mhall119 as jdstrand said, I have that information available, jdstrand has a lot of high priority work on his plate
<ratliff> if there is a business reason to reprioritize, then please let me know
<mhall119> ratliff: winning DE's over to snap is the business reason
<mhall119> I can have dpm take it though the stakeholder process
<jdstrand> mhall119: please escalate with your manager
<ratliff> yes, please do
<jdstrand> mhall119, dpm: note that it is high prioirity already, it is just behind several others things. I added you to the card
<mhall119> thanks jdstrand
<bulldog> snapcraft said you missing a file , so i added it now . when i run snapcraft it still cant find file
<bulldog> how to deal with this
<bulldog> without cleaning everything ,
<zyga> mhall119: correct,
<zyga> mhall119: confinement is process-based
<mhall119> bulldog: what is the actual error message?
<bulldog> mhall119, i forgot to copy a file which i mentioned in wrapper script , and ran snapcraft , , i added file now , but snapcraft is not aware
<bulldog> it is showing same error [Errno 2] No such file or directory
<ogra> you need to clean
<mhall119> bulldog: was the missing file in one of your source parts?
<bulldog> mhall119, no not in source . it is in the same directory where yaml file is
<ogra> (either stage or prime if you dont want ti to download everything again)
<ogra> *it
<bulldog> ogra, i dont wana download 58 mb again my neetwork is not so fast its 300kbp:(
<bulldog> okay
<bulldog> :D
<ogra> thats why i said that
<bulldog> i was lil late to get that \
<mhall119> bulldog: snapcraft clean -s stage
<mhall119> then snapcraft snap again
<ogra> it is the same thing as the other few times today or the few times over the weekend ... use clean with the right stage
<bulldog> mhall119, i will try
<mhall119> -s is your friend :)
<elopio> lool: https://github.com/snapcore/snapweb/pull/51
<mup> PR snapweb#51: Add missing dependencies to snapcraft. Build the snap in travis <Created by elopio> <https://github.com/snapcore/snapweb/pull/51>
<elopio> the grunt thing seems to happen only here. But let's land this first so we notice early if the build is broken.
<bulldog> :)
<bulldog> ogra,  i wont repeat that :D
 * ogra will quote you on that :)
<bulldog> ogra, mhall119 i cleaned both prime and stage still it says file not in - /home/bull/snap/uweather/parts/glue/build/Trolltech.conf'
<bulldog> glue is name of part ,
<bulldog> i already cleaned build step too
<mhall119> bulldog: Trolltech.conf was the missing file?
<bulldog> yeah , am having this in my wrapper script
<mup> PR snapd#1717 opened: daemon,overlord: add subcommand handling to snapctl <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1717>
<mhall119> hold up, is it failing to build the "glue" part because it's missing the Trolltech.conf?
<bulldog> yeah
<mhall119> then you need to clean that part
<mhall119> to at least the build stage
<bulldog> snapcraft clean glue ??
<mhall119> yeah
<bulldog> it iwill delete downloaded stuffs :D
<ogra> no, thats "pull"
<ogra> build comes after pull
<bulldog> i cleaned build already\
<ogra> "snapcraft --help" has a very nice description
<bulldog> i cleaned all three build , stage and prime
<mhall119> bulldog: is the file in parts/glue/src/?
<bulldog> mhall119, wait let me put it on github
<mhall119> yes please
<bulldog> https://github.com/keshavbhatt/uweather-snap
<bulldog> mhall119, https://github.com/keshavbhatt/uweather-snap
<bulldog> mhall119, i know this will build in your case , but what am facing is a condition other users can face !
<bulldog> if you want emulate the condition , remove trolltech.conf from base dir , then run snapcraft
<mhall119> bulldog: in this case you have to clean all the way down to "pull
<mhall119> "
<bulldog> it will end with no such file directory error , then copy trolltech.conf to the place back
<mhall119> because Trolltech.conf is in your "glue" part's source, it won't find it until you re-pull that part
<bulldog> then run snapcraft again
<bulldog> mhall119, i pulled it with snapcraft pull glue
<bulldog> but it again do same
<mhall119> you need to clean the pull stage before it will re-run it
<mhall119> otherwise it sees that it's already been pulled, and won't pull again
<bulldog> so thats a confirm bug i faced it so many times before thats why ogra noticed me asking same again aand agian
<mhall119> bulldog: snapcraft clean -s pull glue
<mhall119> then snapcraft snap
<bulldog> :D
<mhall119> but that will, unfortunately, re-pull all of your stage-packages as well
<bulldog> it will delete downloded stuffs
<mhall119> yup
<bulldog> haha
<bulldog> daem
<mhall119> but you probably don't need all of them, the desktop-qt5 part should pull them into your snap
<ogra> and thats by design ... not a bug
<bulldog> so its not logical to add a single file or single change , we need download stuffs which we deleted :D
<mhall119> bulldog: only if you are doing both from the same part
<bulldog> what if our dependencies are sized 1gb ??
<bulldog> :D
<mhall119> put them in a separate part
<bulldog> and let we learning snapcraft :D
<bulldog> mhall119, okay i will try
<mhall119> I believe your dependencies are mostly all in desktop/qt5 already, so having them in your "glue" part is redundant
<ogra> yeah, would just download them twice
<bulldog> haha , am stupid :D
<bulldog> i thought you added only some paths in that qt5 launcher
<bulldog> so dependencies are in there too :D , it was downloading stuffs but i was gone for  dineer
<bulldog> mhall119, i have these dependencies , http://paste.ubuntu.com/23079032/
<bulldog> qt5-launcher comes with whole qt dependencies  ??
<mhall119> desktop-launch is what you want to use
<mhall119> bulldog: look at https://github.com/ubuntu/snappy-playpen/tree/master/qcomicbook for an example
<bulldog> okay ty
<bulldog> i cleaned glue :D
<bulldog> i have not been able to snap anything yet :D , but snappy will be simple one day, and i will be able to make snaps for my applications  :D
<mup> PR snapd#1717 closed: daemon,overlord: add subcommand handling to snapctl <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1717>
<bulldog> mhall119, i removed dependencies in yaml file , and ran snapcraft clean glue , and then snapcraft -  bu it still downloading dependencies wth is this
<bulldog> downloaded 57mb again :(
<bulldog> and still the same message
<bulldog> i should clean it all :3
<bulldog> modifications in snapcraft.yaml atleast should be recognosed by snapcraft.
<ogra> what would "snapcraft clean glue" be or do ?
<bulldog> i dont understand what is the holy reason behind making this so much complex damn
<ogra> (i guess since snapcraft doesnt know what you mean it simply ignores the "glue" )
<bulldog> ogra,  it cleaned it and downloaded , staged and primed glue again
<ogra> khow would it do that
<ogra> it doesnt know what glue means ... thats neither a command nor an option
<bulldog> as i can see it didnt said (skip already done)
<ogra> (again ... see snapcraft --help)
<bulldog> glue is part
<ogra> yes
<bulldog> so why it downloaded stuffs again if it was useless command and was not recognized
<bulldog> by snapcraft
<mhall119> bulldog: what does your snapcraft.yaml look like now
<ogra> because you tiold it "after: [desktop/qt5]
<mhall119> ah, yes, desktop/qt5 is the part that will download the dependencies now
<ogra> that cleans desktop/qt5 along i think
<bulldog> it is getting more then rocket science now :D
<bulldog> will a normal user able to use snapcraft ??
<bulldog> haha :P
<ali1234> "snapcraft clean" really doesn't make any sense at all
<ali1234> pretty much the only way to use it is to clean everything every time
<mhall119> bulldog: a normal user wouldn't have gotten into the situation you're in now, they would start with having desktop/qt5 from the beginning and not have to worry about backtracking
<bulldog> mhall119, wait
<mhall119> ali1234: you can clean by part, by step, or both
<ali1234> which makes no sense
<mhall119> ali1234: what would you assume it does?
<bulldog> mhall119, plz plz fix my yaml file   - this is old  one https://github.com/keshavbhatt/uweather-snap
<ali1234> i would assume it cleans by step only
<ogra> ali1234, i never clean everything
<bulldog> it clean all i think
<ogra> (well, i sometimes do, but thats really really rare)
<bulldog> all steps of all parts
<ogra> ali1234, "snapcraft clean -s stage" is what i use most
<ali1234> how do you clean the built files?
<ogra> well, then i use -s build ...
<ali1234> how do you force to redownload a part?
<ogra> the majority of my snaps doesnt build anything from source
<mhall119> bulldog: where is your new snapcraft?
<bulldog> okay if am not a normal users then can you  make a snap of my qt5 app - https://github.com/keshavbhatt/deskie
<ogra> ali1234, snapcraft clean <partname> -s pull
<bulldog> mhall119, http://paste.ubuntu.com/23079116/
<mhall119> ali1234: snapcraft clean -s pull ${part}, then snapcraft pull ${part}, will re-download everything for it
 * ogra wonders if anyone ever reads "snapcraft --help" ... thi sis all in there 
<ali1234> yeah that syntax is terrible
<mhall119> bulldog: and that one doesn't work?
<ali1234> it should be snapcraft clean pull -p <partname>
<bulldog> ogra, i been reading that from two or three days :D
<ogra> ali1234, file a bug and convince sergiusens that this is better ;)
<ali1234> 99% of snaps only have one part
<ogra> but after all it is still logical
<bulldog> ogra,  help is really cool but does not do what a user will except
<mhall119> ali1234: -p to specify a partname? that's already assumed
<ogra> it surely does what i expect
<bulldog> haha
<mhall119> I'd recommend -f to mean "force", or -c to mean "clean first"
<ali1234> mhall119: "snapcraft clean foo" "foo" should be assmed as a step, not a part
<ogra> and it isnt like i had any of my fingers in snapcraft development, i'm just a user like anyone else
<sergiusens> bulldog that's an interesting contradiction, the help cannot be really good and at the same time not do what you expect
<ogra> just working my way along based on what snapcraft --help tells me
<ogra> sergiusens, i have that if i switch my terminal to a chinese locale though
<bulldog> sergiusens, it looks like other help manuals but , when i use those steps it create situations like i mentioned above
<mhall119> sergiusens: would you consider a -c/--clean flag on step commands, that would perform a call to clean on that step (and for a part if specified) before running the step?
<sergiusens> mhall119 that would break expectations, we cannot do that until snapcraft 3.0 comes along
<mhall119> who's expectations?
<bulldog> sergiusens, i can emulate the conditions which will make that help manual do what you don't expect
<bulldog> seriously :D
<ali1234> ogra: snapcraft --help doesn't tell you anything useful about clean subcommand
<ogra> ali1234, huh ?
<ogra> snapcraft [options] clean [<part> ...] [--step <step>]
<ogra> ...
<ogra> Options specific to cleaning:
<ogra>   -s <step>, --step <step>              only clean the specified step and those
<ogra>                                         that depend upon it. <step> can be one
<ogra>                                         of: pull, build, stage or prime.
<bulldog> ogra, yeah that part is cool
<ogra> ...
<ogra> The available lifecycle commands are:
<ogra> ...
<ogra>   pull         Download or retrieve artifacts defined for a part.
<ogra>   build        Build artifacts defined for a part. Build systems capable of
<ogra>                running parallel build jobs will do so unless
<ogra>                "--no-parallel-build" is specified.
<ogra>   stage        Stage the part's built artifacts into the common staging area.
<ogra>   prime        Final copy and preparation for the snap.
<ogra>   snap         Create a snap.
<bulldog> we having a copy haha
<ogra> thats not clear ?
<ali1234> no
<bulldog> haha
<ali1234> wtf is a "lifecycle command"?
<ali1234> or an "ecosystem command" for that matter?
<bulldog> yeah :D
<ali1234> these are just nonsense words
<bulldog> snapcraft lifecycle command
<ogra> obviously a lifecycle command is one of the steps in the lifecycle towards getting a snap out of a source tree
<ali1234> obviously
<ogra> i'm not natively english speaking, perhaps thats why i understaood it with the first reading, not sure
<ali1234> it's written in engineer speak
<ogra> indeed
<nacc> ali1234: no, it's written in snap knowledge speak, i would argue
<ogra> because it is for engineers
<nacc> ali1234: it assumes (for better or worse) that you know about snaps ahead of time, somewhat
<ogra> i wouldnt expect non engineers to use snapcraft
<bulldog> thats why i planned to make a gui and add my own sense to make normal users feel like home, but am kinda not able to snap anything yet
<nacc> once you do, the 'lifecycle' terminology makes a lot more sense
<bulldog> ogra, am 19 , and a biology student
<ogra> beyond perhaps being told by an enginneer to pull that source tree and call "snapcraft" inside
<ali1234> here is an example of how the help isn't very helpful. suppose i have a snap that points to a git repository and i push a commit to the repository
<ali1234> now i need to somehow make snapcraft download my new commit
<ogra> then ou hopefully have an LP autobuuild set up :)
<ali1234> it isn't clear how i should do this
<nacc> ali1234: the snap doesn't really point at the git repository in my mind, the yaml does
<ali1234> should i snapcraft pull?
<nacc> ali1234: in which case, just build it again
<ali1234> or maybe i should snapcraft clean -p pull?
<ogra> (which magically will just build your snap if your branch changes)
<ali1234> nacc: no, that specifically does not work
<nacc> ali1234: or set up the autobuild as ogra says
<ogra> (and even auto-upload it for you)
<ali1234> snapcraft says "oh, already pulled that, let's not pull it again"
<ogra> so let the buildds do it for you
<ogra> and stop caring ;)
<nacc> ali1234: or use 'cleanbuild' or a fresh env or whatever
<ogra> yeah
<nacc> i've yet to actually run `snapcraft build` on my host system, as it seems ... less than ideal :)
<ali1234> nacc: so yeah we are back to "vlean the whole thing every time you make a change"
<ali1234> how do you write snapcraft.yaml then?
<bulldog> ogra, plz do an experiment with my app deskie , its a qt5 app and i was able to pack it and run it on 14.04 to 16.04 of ubuntu https://github.com/keshavbhatt/deskie
<mup> PR snapd#1718 opened: daemon,overlord: add subcommand handling to snapctl <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1718>
<ogra> ali1234, because on a bildd that costs you nothing
<ali1234> do you just bang it out and then upload it to loaunchpad and see if it works?
<bulldog> ogra, snap it plz
<ogra> bulldog, well, you explain my team why i dont work on images then :P
<nacc> ali1234: well i mean i don't want to pollute my host system with random build deps for things anyways
<nacc> ali1234: so i always use cleanbuild locally
<nacc> ali1234: or the lp builders
<ali1234> nacc: so you never use clean
<ogra> ali1234, bzr push ... or git push ... the rest is magic
<ali1234> bzr push what?
<nacc> ali1234: no, not had to at all, as i dont' have anything to clean locally
<ogra> your tree that you have set up an autobuild for on lp
<nacc> ogra: is there a wiki page or blog post on setting up the autobuild, by any chance? might be a good reference
<bulldog> ogra, i like new things comin , snapcraft is one of them but its really pain in @ , i got unexpected error and messages which i never seen in my life after making sanp for https://github.com/keshavbhatt/deskie
<ali1234> btw cleanbuild doesn't work for me
<bulldog> ali1234, bzr push your local bzr repo
<ogra> nacc, not sure ... i guess i should blog about that ... once i find some time :)
<bulldog> ogra, after snapping deskie , and running it - it says svg errors lol qml qrc errors i mean what the hack is going on , do qt need to change its coding style if a developer wana pack a snap later for his app ??
<ogra> ali1234, so is your branch on LP in giit or bzr ?
<nacc> bulldog: are you sure you have all the deps in the snap?
<ali1234> branch containing what?
<nacc> ali1234: your snapcraft.yaml and all the parts it refers to (probably)
<ogra> ali1234, your snapcraft.yaml
<ali1234> no
<nacc> if there are any local ones
<ali1234> it's on my harddisk
<bulldog> nacc , yes i was having em all , even i added qtsvg lib
<bulldog> yeah its all in it
<ogra> well, then you cant use LP obviously :)
<ali1234> i can push the snapcraft.yaml
<nacc> ali1234: cleanbuild requires a working lxd setup fwiw (other than i have not see any issues with it)
<bulldog> ogra i have lp , i know how to push branch :D
<ogra> you can push it to LP ... the go to the website, click "create snap package" fill the form and have it auto-build for every commit
<ali1234> nacc: i have that, apt throws 500 server errors
<nacc> bulldog: hrm, i'd help but i need to go afk for a bit -- i'll try and ping later and see if i can help out
<ali1234> ogra: so if my snapcraft.yaml hasnt changed, how do i make it rebuild?
<bulldog> nacc, thanks bro :*
<ali1234> push an empty commit?
<ogra> ali1234, you click the "request build" button in the UI or use launchpad-lib to trigger a manual build
<bulldog> bzr will do it for you
<ogra> launchpad-lib script
<nacc> ogra: i think in this case, ali1234 is asking if the autobuild will autobuild rebuild if the underlying part changes? no, that wouldn't make sense, as you'd want it to be controlled by the app owner
<bulldog> ogra, is very helpful in nature :) he is on all the time :*
<ogra> nacc, ah, right
<nacc> ali1234: so in your case, you'd push to your git tree (if you can), and have a git hook that causes a rebuild of the snap, possibly
<ali1234> i don't want it to do anything automatically
<nacc> ali1234: then it's trivial to do manually :)
<ali1234> my snapcraft.yaml doesn't even work yet
<nacc> ok, afk for real now :/
<bulldog> bye nacc
<ali1234> anyway, i don't think any of this excuses the poor documentation of clean
<bulldog> nacc, wait , you can find Mut module for deskie in other branch named snap_package_recipe
<bulldog> clean is really confusing from day one :D
<bulldog> for a normal user :P
<bulldog> it would be better if debian team figured out these security , isolating user data , interfaces, and other goals of snap :D  in their .deb packaging format
<ali1234> oh no please
<ali1234> deb packaging is terrible
<bulldog> haha
<bulldog> why ??
<bulldog> whats wrong there ?
<ali1234> because there is literally no correct way to do it
<bulldog> what do you mean - no correct way to do it
<bulldog> i simply do dpkg-buildpackage -uc -us
<ali1234> i mean that, given any piece of software you can imagine, there is no way to package it in a deb file that matches any of the documentation about how to create a deb file
<ali1234> literally everything is a corner case
<bulldog> hmmm thats true and this seems to happening with snapcraft too
<ali1234> at least snapcraft has a clean command
<bulldog> haha
<ali1234> dpkg has a clean command, but it is totally reliant on the packager writing a clean rule that works
<bulldog> smapcraft is awesome , but what if both powers into one
<ali1234> and 99.9% of packagers don't bother
<bulldog> am fine with debian packaging if you ever need help call me , keshavnrj@gmail.com
<ali1234> please fix the Qt package to make dpkg-buildpackage work if you run it twice in the same unpacked source
<bulldog> debian packaging backed with lp is super cool , just keep the branch updated and it will make sure everything will work
<bulldog> i dont build from source with dpkg :D
<bulldog> my way of doing is different
<bulldog> i have lots of apps in software center , and am not wrong  with my style of packaging with dpkg-buildpackage
<ali1234> my experience of debian packaging is as follows: apt-get source <package>, enter the directory, make changes, dpkg-commit them, write changelog entry, attempt to build package, doesn't work, delete the source dir and start over
<bulldog> i mean i dont left out any dependency so my apps works well on 12.04 to 16.04
<bulldog> thats official way if you packing for debian :D
<ali1234> when building on launchpad it is pretty much the same except there's a half hour upload step and a 4 hour wait for it to build
<bulldog> yeah , if you want daily build then the way you explained is right
<ali1234> i dont want daily build
<ali1234> i want to test the change i made
<bulldog> i mean you can do manual too
<bulldog> where r u from ?
<ali1234> why does it matter?
<bulldog> just asking :)
<bulldog> am from India , i don't feel insecure :D revealing this truth :P
<ssweeny> jdstrand, I wonder if you have some advice on how to make my udisks mounts visible outside of the snap? I talked briefly with zyga about it and he said I could create "specially designed bind mounts" to do it. I tried bind-mounting /run/media/ onto itself and making that shared from a wrapper script in the snap but that doesn't seem to work, and when I try to add the bind-mount in the interface (interfaces.SecurityMount) I get denials for snap-con
<ssweeny> fine trying to make the mount
<jdstrand> ssweeny: I'm not sure. udisks2 is running in its own private mount namespace. I think the intent of the udisks2 interface would be to make those mounts in the global mount namespace
<ssweeny> jdstrand, I agree, but I'm not sure how to go about that
<jdstrand> you can't at the moment cause once your in the namespace you can't get out
<jdstrand> otoh the only way I could see doing that is somehow having snap-confine not do a private mount
<jdstrand> for that interface
<ogra> hotel california namespace ?
<ssweeny> you can check out any time you like, but you can never leave :)
<ogra> ;)
<ssweeny> jdstrand, would that be a quirk to add to s-c?
<ssweeny> looks like there's already some custom stuff for lxc in the quirks source file
<ssweeny> jdstrand, alternatively this could be an argument for udisks being part of the core snap :)
<jdstrand> heh, yeah
<jdstrand> hmm
<jdstrand> this darn mount namespace
<jdstrand> its causing several problems
<ali1234> ogra: so it turns out you can do export http_proxy=http://localhost:9999/" and now packageproxy will cache any repo that you fetch with apt
<ali1234> with no config changes
<bulldog> ogra, i missed something in snapcraft file i added it now what should i do now to make snap out with the new changes
<jdstrand> ssweeny: I can't really think of anything that would work beyond telling snap-confine to not do it or add an out of process helper for udisks to request it do the mounts on its behalf
<ssweeny> jdstrand, OK I'll look at quirking snap-confine then. If we're adding a mount helper to core then I'd rather just propose udisks itself go in
<jdstrand> tyhicks: hey, sorry to interrupt you. so, the udisks2 PR has a problem. basically, it runs as a snap, it mounts things, but those mounts are in its private mount namespace but they should be made in the glabl namespace
<tyhicks> hey
<jdstrand> tyhicks: so that something using the pluggable-storage interface has access to the mounts (eg, in /media)
<jdstrand> tyhicks: I can only think of two ways to deal with this-- snap-confine doesn't do the private mount namespace or an out of process helper that udisks could ask to do the mounts
<jdstrand> tyhicks: can you think of another option?
<tyhicks> jdstrand: by "snap-confine doesn't do the private mount namespace" do you mean that it wouldn't set up the private mount namespace for the udisks2 snap but would continue to do so for all the others?
<jdstrand> tyhicks: that is what I meant
<tyhicks> ok
 * tyhicks thinks
<jdstrand> somehow, if you say you 'slots: [ udisks2 ]', then you don't get a private mount namespace
<kyrofa> elopio, any chance you're still setup to test nextcloud?
<jdstrand> otherwise, you continue to do so
<kyrofa> elopio, I pushed an update to --beta that changes the HTTPS stuff (more info in the PR description here: https://github.com/nextcloud/nextcloud-snap/pull/23)
<mup> PR nextcloud/nextcloud-snap#23: Add support for HTTPS <Created by kyrofa> <https://github.com/nextcloud/nextcloud-snap/pull/23>
<ssweeny> jdstrand, tyhicks, even if I could get ONE shared mount point that would help since mounts under that could also be shared
<mup> Bug #1615773 opened: Allow for seccomp blacklist rather than whitelisting <lxd> <Snappy:New> <https://launchpad.net/bugs/1615773>
<tyhicks> jdstrand: in theory, I guess another option would be for udisks2 to use setns() to rejoin the global mount namespace before peforming a mount but that doesn't seem to be an improvement over the other options
<tyhicks> (there's also the problem of getting the global mount namespace fd to udisks2)
<jdstrand> tyhicks: that doesn't seem possible. you get EPERM
<jdstrand> tyhicks: once you ushare you don't seem to be able to go back
<tyhicks> "Changing the mount namespace requires that the caller possess both CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities in its own user namespace and CAP_SYS_ADMIN in the target mount namespace."
<ogra> ali1234, just dont build go projects ;)
<tyhicks> jdstrand: ^ (from the setns man page)
<ali1234> ogra: why? it passes through requests it doesn't understand
<ali1234> turns out it only caches repos that you defined in the config
<ogra> go builds fall over when proxies are involved afaik
<ogra> (if you export, that will apply to everything in that shell)
<jdstrand> tyhicks: I tried doing nsenter on pid 1 with those capabilities and it didn't work
<jdstrand> tyhicks: I had the same thought over the weekend for the 'ip netns exec' issue
<ali1234> so in my shellscript i should do "env http_proxy=... multistrap" ?
<jdstrand> tyhicks: granted, I wasn't able to exhaustively test it. if you'd like, I can, but I kinda thought the EPERM made sense since the point of this is that that the process is contained
<tyhicks> jdstrand: EPERM does make sense but I'm confused in that the man pages suggest that it should be possible
<tyhicks> jdstrand: does the setns() option make for a cleaner design?
<jdstrand> I'm not sure
<tyhicks> if it does, I can read through the code to figure out what is going on
<jdstrand> it might be because I was using nsenter from within the mount namespace
<jdstrand> and that was why I got an eperm
<jdstrand> whereas if the fd was passed in, I wouldn't
<tyhicks> that's possible
<jdstrand> I guess snap-confine could open() /proc/self/ns/mnt and not close it, then udisks2 could setns on it?
<jdstrand> tyhicks: is that what you were thinking?
<ali1234> ogra: why can't i use bulleted list in config.yaml?
<tyhicks> jdstrand: that's what I think would have to happen
<jdstrand> tyhicks: I'm also interested in this re 'ip netns exec'
<tyhicks> jdstrand: but if snap-confine and udisks2 is going to all of that trouble, why put it into a new namespace to begin with?
<jdstrand> right. udisks2 could easily deal with not having a mount namespace
<jdstrand> but, we keep hitting complications with this...
<tyhicks> with the mount namespace?
<jdstrand> tyhicks: yes. so, all the really hard stuff about snap-confine and udisks2 is not around avoiding the private mount setup. it is about the interaction between the declared interface influencing snap-confine
<jdstrand> tyhicks: (ie, whether avoid mount namespace or open(), everything else is the same)
<jdstrand> meh
<jdstrand> I was sorta thinking just avoid it, but now I'm thinking the setns may be viable for ip
<tyhicks> couldn't snapd to tell snap-confine if it should stick the launched process into a new mount namespace or not?
<tyhicks> s/snapd to tell/snapd tell/
<jdstrand> tyhicks: yeah-- that is what I'm saying is the hard part. that needs to be designed, etc. is it part of the .fstab thing that's there, is it a new backend, etc
<sergiusens> elopio when you have time, can you give #740 another peek?
<tyhicks> jdstrand: right
<tyhicks> jdstrand: I now understand what you're saying
<jdstrand> where I'm conflicted is that if we do the setns approach for ip, maybe we should for udisks2 (trying to avoid two different backends for similar problems)
<bulldog> good night guys see u tomorrow
<tyhicks> jdstrand: it seems kludgy to me to stick udisks2 into a new mount namespace, pass it the fd for the global mount namespace, and then expect it to immediately setns() to the global mount namespace
<jdstrand> tyhicks: that's a fair point
<tyhicks> jdstrand: also, have you verified if a mount in the global mount namespace is automatically propagated to all the per-command mount namespaces?
<jdstrand> tyhicks: /media is one of the directories that snap-confine bind mounts
<tyhicks> oh
<tyhicks> hmm
<ssweeny> jdstrand, tyhicks this is more likely to apply to /run/media and all-snaps systems, since a classic system would likely already have udisks, right?
<jdstrand> tyhicks: it's in setup_snappy_os_mounts()
<jdstrand> ssweeny: it would
<mup> PR snapcraft#749 opened: Allow registering private packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/749>
<tyhicks> jdstrand: so that means there's another option...
<tyhicks> just a sec
<jdstrand> tyhicks: you thinking about some (r)slave option?
<tyhicks> jdstrand: well, all snaps get the rslave bind mount of /media today
<jdstrand> right
<jdstrand> actually, I can test now
<tyhicks> jdstrand: I think that if udisks2 received an rshared bind mount of /media, it's mounting activity would be propagated to all the rslave bind mounts
<jdstrand> all I need to do is see if I can see the mounts in /media if I plug in a usb key from within the snap
<jdstrand> so the quirk is rshared
<jdstrand> interesting
<tyhicks> yes
<tyhicks> by default, the mount syscall for snaps would be: mount(src, dst, NULL, MS_BIND | MS_REC | MS_SLAVE, NULL)
<ssweeny> tyhicks, I'm not sure that's true for all-snaps. on my rpi2 /media is read-only
<tyhicks> udisks2 would get: mount(src, dst, NULL, MS_BIND | MS_REC | MS_SHARED, NULL)
<ssweeny> zyga told me that was just for snaps-on-classic
<tyhicks> ssweeny: oh, you're correct
<tyhicks> jdstrand: ^
<tyhicks> if (is_running_on_classic_distribution()) {
<tyhicks>   setup_snappy_os_mounts();
<tyhicks> }
<jdstrand> it would be MS_SHARED for /run then otherwise (/run/media)
<jdstrand> man, soo many mounts
<tyhicks> yes, it makes for a lot of confusion
<jdstrand> fyi, on classic, the private mount doesn't get in the way of /media
<jdstrand> ssweeny: I like tyhicks idea of using MS_SHARED
<ssweeny> jdstrand, ok, what do I need to do?
<tyhicks> jdstrand: what about ssweeny's point that using MS_SHARED would only work on classic?
<jdstrand> tyhicks: I thought you agreed with my point on /run
<jdstrand> tyhicks: on all snaps, it is in /run/media. /run is also one of these
<jdstrand> tyhicks: so with udisks2 on all snaps, mount /run with MS_SHARED, no?
<tyhicks> jdstrand: where in the snap-confine code is /run getting mounted on non-classic systems?
<tyhicks> I couldn't see it
<jdstrand> tyhicks: I'm not being clear. on all-snaps, for udisks, mount /run with MS_SHARED on /run
<tyhicks> jdstrand: ah, so this would be an entirely new mount that we'd need to set up on all-snaps
<tyhicks> jdstrand: thanks for clarifying
<jdstrand> I guess we're back to it is just as easy to skip setup_private_mount()
<tyhicks> pretty much
<jdstrand> well
<tyhicks> snapd needs to let snap-confine know to do something special for this one snap
<jdstrand> we can't really do that though
<jdstrand> not your last comment
<tyhicks> why not?
<jdstrand> we can't really skip setup_private_mount unless we give up on content sharing
<jdstrand> for that interface
<jdstrand> tyhicks: absolutely snapd must do something special for slot implementations of the udisks2 interface
<jdstrand> ok
<tyhicks> no matter what, snapd is going to have to do something special
<jdstrand> yes
<jdstrand> we were typing at the same time
<tyhicks> ok
<tyhicks> MS_SHARED is probably the best implementation when snapd does that special thing :)
<jdstrand> my comment was supposed to be:
<jdstrand> "I guess we're back to it is just as easy to skip setup_private_mount()
<jdstrand> well
<jdstrand> we can't really do that though"
<jdstrand> maybe
<jdstrand> ok
<tyhicks> MS_SHARED definitely fits well into the fstab backend
<jdstrand> ssweeny: let's try this: in sc_setup_mount_profiles() parse the .fstab file for shared and mount those with MS_SHARED. then the udisks2 interface uses the SecurityMount backend to mount /run with shared
<jdstrand> ssweeny: you should bounce that off zyga
<jdstrand> ssweeny: because today the SecurityMount backend only mounts exports from snaps, not the OS
<ssweeny> jdstrand, aha, ok
<jdstrand> let me rephrase for clarity: then the udisks2 interface uses the SecurityMount backend to specify mounting /run with shared
<jdstrand> or even /run/media
<ssweeny> ok that makes sense
<jdstrand> (snapd is obviously not doing the mounting)
<jdstrand> cool. sorry it took so long. tyhicks, thank you for the MS_SHARED option
<ssweeny> ok, 1) add SecurityMount entry with shared to udisks interface and 2) patch snap-confine to process that and mount appropriately
<ssweeny> jdstrand, is there a good way to test my snap-confine patch on an all-snaps system? I don't imagine I can replace the existing binary
<ssweeny> testing udisks on a classic system seens like asking for pain
<jdstrand> ssweeny: spread tests allow you to do crazy stuff and I highly advise using those when you are getting close to PR. before that point, you can either generate your own core snap (sudo unsquashfs ./snap ; modify ; snapcraft snap ./squashfs-root) or use overlayfs
<ssweeny> jdstrand, awesome, thanks!
<tyhicks> I've got one other way that I test snap-confine changes
<tyhicks> what I've been doing for testing snap-confine changes on an all-snaps system is building snap-confine, then copying it to the home directory of my all snaps system (you'll need to make root the owner and set the setuid bit), then make a copy of the wrapper script in my home directory, and then modify the copied wrapper script to launch the snap-confine in my home directory
<tyhicks> kinda kludgy but it allows for pretty quick manual testing
<jdstrand> that would work, but soon it won't once snap-run is around
<ssweeny> also awesome, tyhicks! thanks!
<ssweeny> jdstrand, how long do I have? :)
<ssweeny> (before that won't work I mean)
<ssweeny> I'm hoping to get this all wrapped up this week
<tyhicks> I think you'll be fine this week
<jdstrand> ssweeny: something along these lines: http://paste.ubuntu.com/23079343/
<jdstrand> that is for overlay
<jdstrand> it is not bad to setup either
<ssweeny> yeah seems pretty straightforward
<ssweeny> jdstrand, tyhicks, I need to run out for a bit. thanks so much for the help!
<jdstrand> yw
<tyhicks> np
<ali1234> ogra: okay approx is actually broken... doesn't do what it claims
<sergiusens> elopio https://github.com/snapcore/snapcraft/pull/749
<mup> PR snapcraft#749: Allow registering private packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/749>
<lool> elopio: looked good, +1 for me
<ali1234> ogra: http://paste.ubuntu.com/23079392/
<ali1234> also don't you just love debian software with no upstream, no documentation, and no maintainer?
<mup> PR snapd#1719 opened: firstboot: add firstboot assertions adding <Created by mvo5> <https://github.com/snapcore/snapd/pull/1719>
<mup> PR snapcraft#750 opened: storeapi: remove dependency on the 'success' attr <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/750>
<mup> PR snapd#1720 opened: interfaces: add lxd-support interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1720>
<jdstrand> stgraber: ^
<kyrofa> jdstrand, I've run into an interesting issue
<kyrofa> jdstrand, I have a service running in-snap. Some user interaction changes the settings for it and the service needs to be restarted. The service saves in PID and includes the ability to stop the previous PID and start a new one
<kyrofa> jdstrand, problem is, that seems to (logically) remove control from systemd, which means now the snap can't actually be removed because services aren't stopped
<kyrofa> (the snap can't be unmounted because files are in use)
<kyrofa> jdstrand, I've done it this way because I assume services can't be controlled via systemctl from within the snap
<kyrofa> jdstrand, is there a better way for me to be doing that?
<jdstrand> kyrofa: you're right about services not able to control themselves via systemd from within a snap
<jdstrand> kyrofa: https://www.freedesktop.org/software/systemd/man/systemd.service.html has interesting things wrt to this
<kyrofa> jdstrand, hmm... I could kill it and let systemd respawn it I suppose
<jdstrand> kyrofa: snappy's daemon handling is rather rudimentary at the moment. You might like: restart-condition: always
<kyrofa> Indeed
<jdstrand> kyrofa: then you just stop and systemd starts it again
<jdstrand> kyrofa: see 'Restart' in the aforementioned page
<kyrofa> jdstrand, alright I'll give that a shot, thanks!
<jdstrand> np
 * ahoneybun tries to snap : https://github.com/jamiemcg/remarkable
<kyrofa> jdstrand, FYI, that works great
<kyrofa> jdstrand, though I'm concerned about potential abuse there
<jdstrand> kyrofa: glad to hear :)
<jdstrand> kyrofa: what abuse? a snap keeping systemd busy?
<kyrofa> jdstrand, a snap being unremovable without manual intervention
<kyrofa> jdstrand, is there a way to determine all pids running within the snap?
<jdstrand> yes
<jdstrand> at least on systems with apparmor
<jdstrand> systemd is supposed to handle that, but I see you found a case where it doesn't
<jdstrand> you can check what processes are running under snap.${SNAP_NAME}.*
<jdstrand> I imagine snappy remove should probably try to detect that and say "sorry, please stop all processes from this snap before removing" (obviously that isn't the actual text :)
<kyrofa> jdstrand, alright, thanks :)
<kyrofa> jdstrand, another question: I'm setting a PATH in snap run and noticing that it's not set in the app. Any change snap-confine is stripping that?
<kyrofa> s/change/chance/
<kyrofa> jdstrand, ah, it seems so: http://pastebin.ubuntu.com/23079882/
<mhall119> is /usr/lib/x86_64-linux-gnu/ inside a snap's runtime different from the host?
<kyrofa> mhall119, it's probably the one contained within the core snap
<ahoneybun> mm travis does not like me mhall119
<ahoneybun> https://github.com/ubuntu/snappy-playpen/pull/221
<mup> PR ubuntu/snappy-playpen#221: Added otter-browser <Created by ahoneybun> <https://github.com/ubuntu/snappy-playpen/pull/221>
#snappy 2016-08-23
<stgraber> jdstrand: I guess it's fine. I can't really test this until we get the snap moved though :)
<mup> Bug #1615566 changed: snapcraft SDK <Snappy:Invalid> <https://launchpad.net/bugs/1615566>
<mup> Bug #1615030 changed: Ability to completely remove a snap from the snap store <Snappy:Invalid> <Software Center Agent:Confirmed> <https://launchpad.net/bugs/1615030>
<mup> Bug #1612909 opened: Unable to install snappy in Fedora <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1612909>
<zyga> o/
<zyga> mwhudson: hey, can you tell me what is your workflow for snap-confine in debian
<zyga> mwhudson: I have the repo from alioth, I see some work towards 1.0.40
<zyga> mwhudson: I'd like to finish that and release it to sid and yakkety
<zyga> jdstrand: dh-apparmor is not in main, yet snap-confine build-depends on it
<zyga> jdstrand: somehow it never caused issues but isn't this against the policy/
<zyga> niemeyer: latest spread (from a snap) gives me this output: 2016/08/23 11:36:40 Allocating &{linode ubuntu-16.04-64-grub ubuntu-16.04-64-grub    %!s(int=1) %!s(*spread.Environment=&{<nil> [] map[]}) []}...
<zyga> niemeyer: similarly the output is very wrong after that
<autonomouse> Hi folks. General question: I've got a simple one file python2 script that I'd like to snap. I have my snapcraft.yaml in the same folder. was hoping that I'd just be able to do this?: http://paste.ubuntu.com/23080902/    but it doesn't seem to be able to find it in the scripts directory: "[Errno 2] No such file or directory: .../prime/scripts/script.py". Do I need a makefile?
<mup> Bug #1616006 opened: clean remove of snapd <Snappy:New> <https://launchpad.net/bugs/1616006>
<zyga> autonomouse: you need setuptools support AFAIK
<autonomouse> zyga, ok, I'll look into that now. thanks
<ogra> mvo, urgh ... i guess we didnt update the pi3 gadget along ... http://paste.ubuntu.com/23081105/
<lool> davidcalle: heya
<lool> davidcalle: do we have online references on building kernel snaps? e.g. on snapcraft.io
<heart> Hello everyone, I do not know if this is the right place to ask. Are there restrictions in running a docker container that needs to access a serial port? I do not know, permits or other? In docker normally just expose the device with --device
<lool> davidcalle: if not, I have seen various base materials fly around that would be good starting points for a kernel page
<lool> ysionneau: what was your issue with docker?
<lool> heart: privileged containers are required for this; it migth work, if it doesn't I'd be interested in the error you're gettig
<lool> heart: note however that this is basically giving root to anything running in that container
<mvo> ogra: indeed, looks like this is missing
<ogra> yeah, just comitted and pushed
<heart> lool: naturally, I think I have some problem even with privileged mode. I continue to investigate and let you know
<heart> lool: I'm working with a dell edge gateway
<ogra> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/5596/rev/2/ ... please approve
<mvo> ogra: done
<ogra> thx
<mup> PR snapd#1721 opened: dependencies: update godeps <Created by mvo5> <https://github.com/snapcore/snapd/pull/1721>
<ogra> mvo, hmm ... http://paste.ubuntu.com/23081147/
<mvo> ogra: hm, no netwokring?
<ogra> (pi3 with the snappy_boot script chaNGES IN TEH GADGET)
<ogra> EEK
<mvo> ogra: ha! CAPSLOCK
<ogra> geez, i need to rip off that caps key
<mvo> ogra: I remapped mine - ctrl:nocaps
<ogra> mvo, deliberately since the pi3 now has wlan support
<ogra> so the cable is unplugged
<mvo> ogra: oh, this may be a general image bug
<ogra> butu before it actually told me that the networking job is waiting
<ogra> mvo, well, i actually think its a systemd bug (or at least the systemd network bringup part) that it does not sense if a cable is plugged in
<ogra> pitti, ^^^
<ogra> (and it is now about 2years old too ... )
<ogra> should not be hard to check for a connected cable really ...
<mvo> ogra: hm, pi2 without network cable booted ok
<ogra> i guess you need two NICs ?
<mvo> ogra: possible, I can see if I find a wlan thing
<ogra> i'll do a re-flash after my test runs
<ogra> and will check if plugging it in actually makes a difference (the dragon only has wlan, the pi2 only eth)
<ogra> sigh ... cloud-init still not finished
<ogra> thats close to a 5 min firstboot now :/
<ogra> ah, now i have the prompt
<ogra> ubuntu@localhost:~$ cat /etc/network/interfaces.d/enxb827ebc92b03
<ogra> allow-hotplug enxb827ebc92b03
<ogra> iface enxb827ebc92b03 inet dhcp
<ogra> ubuntu@localhost:~$
<ogra> aha
<ogra> sdo it created a config for the wired NIC ... regardless if it is in use
<ogra> (and i remeber we had an additional option in there to wotrk around that bug in 15.04 )
<ogra> mvo, hmm, funny, it doesnt hang on the second boot
<ogra> so it is the combo of firstboot and the allow-hotplug line
<mvo> ogra: oh, I think I know
<mvo> ogra: there is a race in the network bringup code
<ogra> yay
<ogra> :P
<mvo> ogra: there is a fix in a PR :)
<ogra> \o/
<mvo> ogra: I will extract it and push a separate pr, its currently part of a big brnach
<ogra> ok
 * ogra does a quick ubuntu-core armhf build to check the upgrade mechanism
<ogra> mvo, in snapweb, all installed snaps listed after the first boot are marked non-removable, *except* the kernel ...
<ogra> i guess we dont want users to allow removing the only kernel that is installed ?
<mvo> ogra: definitely not
<ogra> is that info from snapd thats wrong or is it a snapweb bug
<bull> guys see the design  , https://github.com/keshavbhatt/snapcraft-gui
<mvo> ogra: `$ sudo snap remove pi2-kernel
<mvo> error: cannot remove "pi2-kernel": snap "pi2-kernel" is not removable
<mvo> `
<pitti> ogra, mvo: ifupdown doesn't block boot on allow-hotplug, is that what's hanging?
<mvo> ogra: so that won't work
<mvo> ogra: snapweb is buggy
<pitti> anyway, too little information/context here -- please file a bug with the details if there is any
<ogra> mvo, right, but it shouldnt even show me the "remove snaÃ¼p" button
<ogra> pitti, seems to be the interaction with snappy firstboot ... still, why is systemd not checking the cable state and just ignore the interface ?
<mvo> ogra: yes, bug
<ogra> mvo, right, where ? :)
 * ogra wants to file it 
<ogra> is it snapd giving wrong info or is it snapweb not respecting it
<pitti> ogra: what are you using? ifupdown or networkd?
<ogra> pitti, ifupdown obviously
<pitti> ifupdown support for hotplugging/cable state is quite bolted on, but it works in general, so again -> bug
<pitti> ogra: "obviously" â not really any more :)
<ogra> (i'm not sure what creates the /e/n/i entry though ... that might be snapd)
<ogra> pitti, obviously because we have an /e/n/i file after first boot :)
<ogra> for the NIC
<mup> PR snapd#1721 closed: dependencies: update godeps <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1721>
<mup> PR snapd#1715 closed: asserts,overlord/devicestate: simplify private key/key pairs APIs, they take just key ids <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1715>
<bull> mhall119, https://github.com/keshavbhatt/snapcraft-gui
<mup> PR snapd#1722 opened: many: support install and remove by revision <Created by chipaca> <https://github.com/snapcore/snapd/pull/1722>
<davidcalle> bull: very cool!
<bull> davidcalle,  ty did you compiled it ??
<davidcalle> bull: yes, runs just fine
<bull> wow :D ty
<jgdx> ogra, am I doing this the right way? e.g. bug 1616048 and bug 1616045
<mup> Bug #1616048: Create interface for ofono <snapd (Ubuntu):New> <https://launchpad.net/bugs/1616048>
<mup> Bug #1616045: Create interface for the power daemon <snapd (Ubuntu):New> <https://launchpad.net/bugs/1616045>
<jgdx> I look at snapd/interfaces/builtin and can't find it, then I search for a bug for it in the snapd package on launchpad.
<ogra> jgdx, yeah, i belive that is right ... there is a tag you should set for interfaces
 * ogra looks for it
<ogra> snapd-interface
<ogra> set that too, then zyga and jdstrand see it on their lists
<jgdx> ogra, cool, thanks. I think I'm going to create ~20 of these
<ogra> :)
<ysionneau> lool: any news about a build with the bug fix on snapweb for armhf?
<lool> ysionneau: no, elopio has a solution to provide one, but I +1-ed his pull request yesterday after he EOD-ed
<lool> ysionneau: he should be up soon; however the fix is merged in snapweb master if you want to rebuild
<ogra> dooes that include a fix for bug 1610026 ?
<mup> Bug #1610026: snapweb fails to start after reboot <snapweb:Confirmed> <https://launchpad.net/bugs/1610026>
<morphis__> jgdx: are you planing to work on the ofono interface for snapd?
<jgdx> morphis__, no
<morphis__> jgdx: ok
<ogra> hmm, do we have any example snap that uses a bzr branch in the "source:" option ?
<sergiusens> ogra https://github.com/snapcore/snapcraft/blob/master/demos/libpipeline/snapcraft.yaml
<ogra> sergiusens, ah, awesome, thanks !
<mup> PR snapcraft#749 closed: Allow registering private packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/749>
<lool> wililupy: I had asked for permission to comment/edit on https://docs.google.com/document/d/1mo_Xkg9yBotGRg4qMYYuVn1d35NwGLpCkxE3T_p85P8/edit?ts=57bc4e2f#heading=h.d2h64kdfycq but it seems it's not the latest one
<lool> wililupy: FYI there were some "mlnx" references in the one you sent to Dell but I guess that's ok
<lool> wililupy: there were a couple of things I wanted to suggest for simplification
<lazyPower>  ogra - i apologize, i checked my logs and dont have enough history. Can you re-link me to the latest RPI2 images for snappy?
<lool> lazyPower: https://people.canonical.com/~mvo/all-snaps/16/
<lazyPower> s/snappy/ubuntu core/
<lazyPower> ah, ta  lool
<ogra> the fast frenchman !
<ogra> :)
<tyhicks> zyga (cc jdstrand): regarding dh-apparmor, only run time depends need to be in main now
<tyhicks> zyga: the policy changed during the 16.04 dev cycle
<ogra> WOAH !
<ogra> cjwatson, https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz ... i have split the Makefile from the kernel snap branch into its own bzr tree, this is what i get when trying to build now
<ogra> is that LP, the firwall or actually bzr (as it claims)
<cjwatson> ogra: we talked about that bug before, I think; https://bugs.launchpad.net/snapcraft/+bug/1606203
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203>
<ogra> oh, i remember .. the huge amount of output confused me
<cjwatson> I analysed it at the time and was pretty sure it was a bzr bug, but I don't remember the precise chain of reasoning
<ogra> hmm ... i could perhaps just switch to git, but i exactly wanted to avoid mixing bzr and git for the kernel snaps
<ogra> kyrofa, sergiusens, ^^ any chance this could be quickly fixed in snapcraft (unsetting http_proxy for bzr source pull) ?
<ogra> i guess a simple os.putenv('http_proxy'.'') would do ?
<kgunn> sergiusens: mvo ever seen a bug like this?
<kgunn> http://pastebin.ubuntu.com/23081827/
<kgunn> it says change in progress, but then no change listed?
<ogra> or "del os.environ['http_proxy']" rather
<mvo> kgunn: hm, what does "snap change 34" show?
<mvo> kgunn: but definitely strange
<kgunn> mvo: http://pastebin.ubuntu.com/23081849/
<kgunn> ...it's all ok actually
<kgunn> now
<ogra> you were just to impatient :)
<kgunn> at least, it acted like it had not removed the pkg, but in reality it had
<kgunn> no it timed out...
<ogra> snapd works async (super annoying if you ask me)
<kgunn> but it really was removed
<jdstrand> mvo: hey, is https://github.com/snapcore/snapd/pull/1720#issuecomment-241602474 something you can help with or should I go to the store?
<mup> PR snapd#1720: interfaces: add lxd-support interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1720>
<kalikiana> kgunn: it looks like what I've seen when trying to remove snaps which were still running. I believe there's a bug for that.
<kyrofa> kgunn, yeah I just recently ran into that as well
<kyrofa> kgunn, I caused it by restarting services by hand instead of letting systemd do it
<mup> PR snapd#1723 opened: image: prepare-image: import snap assertions as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/1723>
<kgunn> kyrofa: i did admittedly kill a process
<kyrofa> kgunn, which means when the snap was being removed, it asked systemd to stop everything and then tried to unmount, but my service was outside systemd
<kyrofa> (so the mount was still in use)
<mup> PR snapd#1724 opened: snap: add  `snap download` implementation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1724>
<mup> PR snapd#1697 closed: interfaces/builtin: allow bind in the network interface <Created by tych0> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1697>
<mup> PR snapcraft#740 closed: Allow debugging cleanbuild runs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/740>
<mup> PR snapcraft#750 closed: storeapi: remove dependency on the 'success' attr <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/750>
<kyrofa> jdstrand, I should be good to go as far as running snaps with an encrypted home is concerned nowadays, right?
<jdstrand> kyrofa: yes. snap-confine is now in -updates
<jdstrand> kyrofa: and it has the policy changes needed for that
<jdstrand> kyrofa: were you seeing a problem? there was a weird ubuntu-image bug related to ecryptfs, but that is different than what you're asking about
<kyrofa> jdstrand, no, I saw the bug and never bothered to try
<jdstrand> ah
<jdstrand> yes, it should all be fixed now
<kyrofa> jdstrand, my background with bugs relating to ecryptfs is... bad. Last time it just got eaten
<kyrofa> (the click chroot thing for the SDK)
<jdstrand> hmm
<jdstrand> eaten
<jdstrand> well, if you are seeing issues with policy, feel free to talk to me. if it is misbehaving, you can talk to tyhicks
<kyrofa> Sounds good, glad to know it should all be fixed now!
<kyrofa> Thank you :)
<tyhicks> the click chroot issues were systemd and schroot bugs
<mup> PR snapd#1725 opened: overlord/hookstate: use snap run posix parameters <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1725>
<tyhicks> I ended up fixing them because everyone kept calling them ecryptfs bugs but they were both years old schroot bugs that were never fixed
<lool> jdstrand: heya, around?
<kyrofa> tyhicks, heh
<lool> jdstrand: couple of questions related to docker snap
<lool> jdstrand: currently it uses /var/run/docker.sock
<joc_> kyrofa: do you know if any of the snapcraft plugins copy the parts/<name>/src dir to the build dir?
<lool> jdstrand: I find that problematic for 2 reasons
<kyrofa> joc_, dump, I believe
<lool> jdstrand: one is that it conflicts with the .deb, so you can't snap install on classic if you had the deb and vice-versa
<lool> jdstrand: the other reason is that it kind of breaks the model where one could simply fork the docker snap and rename it, or embed it into another snap (e.g. snap containing docker runtime + docker images) as it's not relocatable anymore
<lool> jdstrand: tianon suggested you wanted to keep the docker.sock name though
<lool> I mean the /var/run pathname
<joc_> kyrofa: it makes the snapcraft help sources text a bit redundant, particualy for the source-subdir, as nothing seems to do what is described
 * zyga votes +1 for $SNAP_DATA-based socket 
<zyga> (and interface attrs and hooks)
<lool> jdstrand: other question is: do you mind approving the docker 15.04 snap in the review queue?
<lool> jdstrand: it adds the /home permissions you said were ok to add for 15.04
<joc_> kyrofa: we were just investigating why a python3 part was failing and realised that attribute is ignored by the plugin but it's not mentioned anywhere
<lool> zyga: yeah, I was thinking like a docker-socket bin to get the socket name for people that want to get it programatically
<zyga> lool: that will be exposed with the snapctl tool I suspect
<zyga> lool: you can use it to ask for an attribute easily
<kyrofa> joc_, I'm not sure I understand where you're coming from, here
<lool> zyga: so the docker snap would set an attribute and it could be queried?
<lool> like config, but runtime?
<zyga> yes
<zyga> that's the hook a few people are working on
<zyga> kyrofa, pstolowski
<jdstrand> lool: I am
<lool> yeah, that sounds like a good fit when that's avail
<kyrofa> joc_, so you're having a problem with source-subdir?
<jdstrand> lool: ideally I would like to see the socket in SNAP_DATA
<joc_> kyrofa: basically i'm saying there is a bug that the help text for the python3 plugin doesnt say the source-subdir will not have any effect
<joc_> kyrofa: but was also thinking there is bug with "snapcraft help sources" output because almost no plugins do what that says with respect to source-subdir
<kyrofa> joc_, or just a bug in the python3 plugin. The code looks like it should work fine-- what do you see happening?
 * kyrofa reads `snapcraft help sources`
<jdstrand> lool: renaming it in /run to be /run/snap.docker.sock or something would be ok too. I don't object to it being somewhere else-- I just wanted to make sure that it was understood that if it was moved that might break other tools that expect it in a particular location. if that is understood and people are ok with it, fine (also, there is nothing saying that if it was in SNAP_DATA now that we couldn't change it back)
<joc_> kyrofa: all the easy_install commands etc are run in the src dir
<lool> jdstrand: it's certainly true that it will break existing constructs
<kyrofa> joc_, yeah that's a bug in python3. Indeed, I agree that there's a bug in `help sources`, but it's because the source-subdir docs are wrong
<lool> jdstrand: I'm not really sure how to avoid this and move the socket though
<kyrofa> joc_, this is what SHOULD happen:
<lool> unless we implement a complex mechanism in the .deb and in the snap to try to take the socket if it's unowned, but that seems broken too
<lool> or just fail install
<lool> BTW, most people install the docker .deb from docker inc which we can't change for this
<zyga> lool: I'
<jdstrand> lool: I think I heard on the list not to worry about conflicting with debs. that in the fullness of time snap install or something higher would guide the user in some manner
<kyrofa> joc_, the entire `source` should be copied build, including the subdir. However, the subdir should be the working directory
<zyga> lool: I've implemented something that lets us poke arbitrary holes as "quirks" for various snaps
<jdstrand> lool: and that now users can just remove the deb
<kyrofa> joc_, the docs are how things used to work, but then we realized that projects typically need the rest of the project tree
<lool> jdstrand: fair enough
<kyrofa> Looks like that never got updated, though
<lool> jdstrand: I'll suggest adding an upstream flag so that people don't hardcode the pathname in docker run commands though
<lool> something like --share-daemon or so
<joc_> kyrofa: yeah makes sense
<jdstrand> cool
<elopio> mvo: your rpi2 image from the 19th has been trying to boot for 5 minutes. Is that normal?
<elopio> ah, it was snapweb failing to start. Just what manik said yesterday, probably.
 * ogra sighs so unsetting http_proxy doesnt survive the selftest in snapcraft when building it :(
<ogra> why does the test even care :/
<elopio> ogra: tell me more. What do you mean with snapcraft selftest?
<ogra> elopio, i need to move parts of the kernel snap build int a separate bzr branch ... which resulted in this beautiful error https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
<ogra> which seems to be bug 1606203
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203>
<ogra> elopio, so i tried a quick hack http://paste.ubuntu.com/23082327/ ...
<ogra> which results in https://launchpadlibrarian.net/280550295/buildlog_ubuntu-xenial-amd64.snapcraft_2.15.1+ppa1_BUILDING.txt.gz
<ogra> i dont really get why the bzr test in snapcraft would care about me deleting a (most likely non--existing) env var
<elopio> ogra: ah, that's a test to make sure that the env var is deleted :)
<ogra> elopio, not really, see the paste
<ogra> ii dont touch the test code at all
<ogra> i only del the var before calling pul
<ogra> *pull
<elopio> let me see...
<ogra> its a super dumb patch
<elopio> ogra: what the error is saying is that those attributes are not in os.environ.
<ogra> perhaps i should use os.unsetenv() instead ...
<ogra> elopio, yes, they indeed wont be unless a build happens in LP
<ogra> (i mean a snapcraft build, not the build of the snapcraft package)
<ogra> and i dont really want to set them, since that would actually taint the test
<ogra> i would like it to just ignore it
<elopio> ogra: why don't you do os.environ["HTTP_PROXY"] = ""
<ogra> i can surely try that, do you think the test wont complain then ?
 * ogra tries 
<elopio> you will get a different result for sure. That's all I can say :)
<ogra> lol
<ogra> well, ppushed to the PPA, lets see
<ogra> (one day all image bulds will actually work without me hacking up snapcraft ... )
<elopio> that would be nice. But this thing of removing the proxy env var from a plugin doesn't seem likely to get upstream.
<kgunn> kyrofa: hey, got one you might have an idea on....
<ogra> elopio, well, it makes building bzr projects oon LP impossible
<ogra> elopio, and a fix in bzr is very unlikely to happen
<kgunn> so, i'm needing to run a script as part of my snapcraft step
<kgunn> using something that will be in stage
<kgunn> and then make sure the output of that goes into prime
<elopio> ogra: but isn't that a launchpad problem? snapcraft should just use whatever env vars are set in the system.
<ogra> elopio, no, it is a bzr bug
<ogra> see bug 1606203
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203>
<kgunn> kyrofa: so i want it to be a post-step to the first part
<kgunn> isn't there a "gate on"
<elopio> kgunn: after: [first-part]
<kgunn> to make sure the script is in stage
<kgunn> ah thanks elopio
<kgunn> after...
<kgunn> that's what i couldn't recall
 * ogra hugs elopio ... the snapcraft package built with that change
 * ogra taps foot waiting for the PPA publisher so i can try if it actually fixes the kernel snap build
<elopio> 5^_^
 * elopio goes to swimming lessons. bbl.
<ogra> enjoy !
<tsimonq2> ogra: it would be awesome to have a snap that is the Linux kernel
<tsimonq2> ogra: with all the different channels too!
<ogra> tsimonq2, well, the kernel snap i build is far more then the linux kernel (it is more a "hardware enablement snap" ...
<ogra> we just call it the kernel snap ... for our images
<ogra> but the kernel team actually has plain linux snaps
<ogra> talk to ppisati_ :)
<tsimonq2> ppisati_: are there kernel snaps I can try? :D
<mup> PR snapd#1725 closed: overlord/hookstate: use snap run posix parameters <Created by kyrofa> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1725>
<kyrofa> kgunn, in a meeting at the moment, but I'll take a look in a sec :)
<zyga> Pharaoh_Atem: hey
<sergiusens> ogra just use launchpad git
<sergiusens> bzr is clearly unsupported
<ogra> sergiusens, well, ut is still the quasi default ...
<ogra> *it
<sergiusens> ogra not for kernel stuff ;)
<ogra> well, i dont do kernel stuff
<ogra> i do build stuff :P
<ogra> as a git hater i was surprised to easily find my way around in github ... but that is because for every prob i can find some howto or help doc ...
<ogra> using LP git means i actually need to be familiar with git at a level i dont trst myself yet
<ogra> sergiusens, so reading between your lines i guess you agree with elopio that there is no chance to fix bug 1606203 at all in snapcraft ?
<ysionneau> lool: I was able to build snapweb ... but for amd64, I don't even know how to cross compile it for armhf
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203>
<ogra> s/fix/work around/
<ogra> (note that your argument works both ways ;) if bzr is dead anyway snapcraft could as well just ship a tivial hack for the workaround)
<mup> PR snapd#1726 opened: store,tests: have just one envvar SNAPPY_USE_STAGING_STORE to control talking to staging <Created by pedronis> <https://github.com/snapcore/snapd/pull/1726>
<sergiusens> ogra should be fixed in launchpad or bzr itself
<ogra> sergiusens, well, neither will happen it seems
<sergiusens> ogra so you default to bullying snapcraft? ;-)
<ogra> "bullying" with a two line change, yeah
<sergiusens> ogra you might as well just disable the proxy in bzr for that matter
<sergiusens> I am already bitter that we need to do that preload thing to support the g* things, don't make me add more hacks :-)
<ogra> g* things ? go you mean ?
 * ogra watches https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/3413 ... 
<mup> PR snapd#1727 opened: dirs,snap: define methods for SNAP_USER_DATA and SNAP_USER_COMMON <Created by zyga> <https://github.com/snapcore/snapd/pull/1727>
<ogra> aaand it works \o/
<ogra> to bad you wont accept it :/
<kyrofa> kgunn, ah, sounds like elopio answered your question
<kyrofa> kgunn, yeah, I'd do it with after and a Makefile or local plugin
<mup> PR snapd#1728 opened: asserts: Add a key-proof assertion <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1728>
<Pharaoh_Atem> zyga: hello
<zyga> Pharaoh_Atem: hey, you pinged me earlier
<thresh> hello
<Pharaoh_Atem> zyga: yep
<Pharaoh_Atem> snapd doesn't seem to work on Fedora at all
<Pharaoh_Atem> it's throwing errors about communicating to the store API
<thresh> how do I set LD_LIBRARY_PATH for my snapped application?
<thresh> I have a .so installed in a non-standard catalogue, and rpath was previously used to point to it.
<zyga> Pharaoh_Atem: hmmm
<zyga> Pharaoh_Atem: looking
<zyga> Pharaoh_Atem: perhaps store is down or something
<zyga> Pharaoh_Atem: I'm not patching anything related to that
<Pharaoh_Atem> zyga: works on ubuntu
<thresh> basically my .so's have:  0x000000000000000f (RPATH)              Library rpath: [/lib/vlc]
 * zyga tries
<thresh> which translates to something else under snap
<zyga> thresh: just move it to /usr/lib in your snap
<zyga> Pharaoh_Atem: trying with 2.12 from COPR
<thresh> zyga, it's a private library, no need for it to be in /usr/lib/.
<zyga> thresh: it's not in usr/lib of the system, just of your snap
<thresh> zyga, I know, but that still applies
<thresh> why clutter something?
<ogra> why do you care
<thresh> because I like tidy things
<ogra> $SNAP/usr/lib is already private to your snap
<ogra> and is automatically in your LD_LIBRARY_PATH when you exec your snap
<thresh> also because it works under every other Linux distribution without issues, including Ubuntu, without moving it to /usr/lib
<thresh> not sure why snap must be so different I need to include apparent hacks?
<zyga> thresh: perhaps use ${ORIGIN} in your rpath
<ogra> well, then write a wrapper, and hack up LD_LIBRARY_PATH
<zyga> thresh: though AFAIR we strip rpath in snapcraft
<zyga> thresh: though a hand-made snap will work
<ogra> but i think just putting it in the snap owned usr/lib is a way sane move
<sergiusens> or $SNAP/lib
<zyga> hmm
<zyga> Pharaoh_Atem: I see something odd, checking
<zyga> Pharaoh_Atem: ah, no sorry, after starting and enabling the snapd.socket I can find snaps
<zyga> Pharaoh_Atem: did you have anything specific that failed that I can try to reproduce?
<Pharaoh_Atem> snap find .
<zyga> trying
<zyga> worked OK
<zyga> Pharaoh_Atem: which version are you on?
<zyga> Pharaoh_Atem: also what error do you see?
<mup> PR snapcraft#705 closed: parser - Remove namespacing and subparts <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/705>
<zyga> Pharaoh_Atem: unrelated, I have a new package for review
<zyga> really small and simple too
<Pharaoh_Atem> zyga: what is it?
<zyga> the xdg-open thing
<zyga> let me upload it for review
<Pharaoh_Atem> snapd-xdg-open?
<zyga> yep
<zyga> I'll merge it into snapd later, I've started the work on mering snap-confine into snapd first, this is mostly a time thing for me as test will need to be integrated across the stack
<Pharaoh_Atem> zyga: the issue occurred with snapd on fedora 23 gnome
<Pharaoh_Atem> I've not tried snapd on fedora 24
<zyga> Pharaoh_Atem: I'm testing on 24
<zyga> Pharaoh_Atem: hmm, can you pastebin the error please?
<Pharaoh_Atem> yeah, give me a sec
<zyga> thanks
<Son_Goku> zyga: "error: cannot list snaps: net/http: Client Transport of type *store.LoggedTransport doesn't support CancelRequest; Timeout not supported"
<zyga> hmm, this looks like a different issue
<zyga> I guess one of the deps in F23 is out of date in a way that doesn't fail at build time!
<Son_Goku> zyga: "error: cannot list snaps: net/http: Client Transport of type *store.LoggedTransport doesn't support CancelRequest; Timeout not supported"
<Son_Goku> zyga: "error: cannot list snaps: net/http: Client Transport of type *store.LoggedTransport doesn't support CancelRequest; Timeout not supported"
<zyga> can you please file a bug on this (in fedora)
<Son_Goku> zyga, I get variants of that error on every action with snapd
<zyga> I'll get this fixed
<Pharaoh_Atem> well, since snapd isn't in fedora, I'll file it in zyga/snapcore-fedora
<zyga> I bet this involves other golang packages
<zyga> Pharaoh_Atem: ah, ok
<zyga> Pharaoh_Atem: that's fine
<Pharaoh_Atem> did you see the decision that was made by FESCo?
<zyga> yes
<zyga> I didn't read the discussion notes
<zyga> I plan to do that tomorrow, I was helping with some snap-confine things yesterday and today
<Pharaoh_Atem> any progress on getting selinux support implemented?
<mup> PR snapd#1726 closed: store,tests: have just one envvar SNAPPY_USE_STAGING_STORE to control talking to staging <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1726>
<zyga> Pharaoh_Atem: none, I'm split among many tasks; I'm helping more upstream lately (with different things) and I dind't have any time to make more selinux progress
<zyga> Pharaoh_Atem: in two weeks from now I should be more free (fingers crossed)
<zyga> Pharaoh_Atem: we're trying to finish some high-profile features first
<zyga> (hooks mainly)
<Pharaoh_Atem> like what?
<zyga> hooks will finally allow us to have configuration in snaps and richer interaction with interfaces
 * Pharaoh_Atem shgs
<Pharaoh_Atem> *sighs
<Pharaoh_Atem> zyga: https://github.com/zyga/snapcore-fedora/issues/5
<zyga> Pharaoh_Atem: thanks, I'll boot 23 and investigate
<zyga> Pharaoh_Atem: I bet it's "just" a simple upgrade of another package
<zyga> (I need to learn how to do those now)
<Pharaoh_Atem> this is why you need to apply to be comaintainer of the snapd deps
<zyga> Pharaoh_Atem: that would be a smart idea, I didn't consider this
<zyga> Pharaoh_Atem: I want to write a tool that gives me the full dep tree in fedora and the git commit of each package
<Pharaoh_Atem> I suggested it back at the sprint as well
<elopio> ysionneau: we can roll back to the rev. that wasn't using snapcraft, that could crossbuild. But now I'm trying to get it build with snapcraft in armhf, and publish it.
<zyga> Pharaoh_Atem: and compare this across distros
<zyga> Pharaoh_Atem: ah, sorry, I didn't remember that
<Pharaoh_Atem> zyga: that shouldn't be difficult, since Fedora has APIs for its repositories and when changes occur in the repos
<Pharaoh_Atem> mdapi and fedmsg will be your best friends there
<zyga> yep, it's just another TODO item :)
<zyga> I
<Pharaoh_Atem> shame that debian never finished their project to adopt fedmsg
<zyga> I'd love to do it quickly/soon though as it is more and more of an important release blocker
<Pharaoh_Atem> it would have been awesome to see it in place
<Pharaoh_Atem> https://wiki.debian.org/FedMsg
<zyga> Pharaoh_Atem: look at fedora bug 1369560
<mup> Bug #1369560: Add "Extract here" to archive manager context menu <amd64> <apport-bug> <freya> <third-party-packages> <elementary OS:Confirmed> <https://launchpad.net/bugs/1369560>
<zyga> Pharaoh_Atem: just a quick note, there's no upstream release yet so Source0 is dummy/broken
<zyga> Pharaoh_Atem: I'll polish some quirks and do a release soon (I wasn't touching that project earlier)
<zyga> Pharaoh_Atem: I wasn't sure if dbus services have a RPM macro or not
<mup> PR snapcraft#751 opened: python3 plugin: run setup.py in source subdir if such option exists <Created by yphus> <https://github.com/snapcore/snapcraft/pull/751>
<zyga> Pharaoh_Atem: I also sent an update to snap-confine 1.0.40, some interesting new things and bug-fixes there :)
<zyga> Pharaoh_Atem: it's already in bodhi
<Pharaoh_Atem> zyga: why is snapd-xdg-open in ubuntu-core?
<zyga> Pharaoh_Atem: a quick question, if I add a patch for /snap to snapd, can we progress on the review request?
<zyga> Pharaoh_Atem: even ahead of FESCo decision?
<Pharaoh_Atem> zyga: yes
<zyga> Pharaoh_Atem: just another TODO item to move it
<zyga> Pharaoh_Atem: I'll probably do that, I sent some pull requests upstream for this but I have a few more to make (mainly tests, I want to ensure it's not broken in any way)
<Pharaoh_Atem> if you patch it to move to /run/snap or /var/run/snap or anywhere else FHS compliant, I can approve the package
<zyga> Pharaoh_Atem: I picked /var/lib/snapd/ because it's not ephemeral yet
<zyga> Pharaoh_Atem: that will be done separately in some future release
<Pharaoh_Atem> so then /var/lib/snapd/mounts?
<zyga> Pharaoh_Atem: actually snap/ (mounts is for "mount profiles")
<Pharaoh_Atem> ah
<zyga> Pharaoh_Atem: /var/lib/snapd/snap
<Pharaoh_Atem> okay
<Pharaoh_Atem> that's going to get confusing
<zyga> the same "snap" as in /snap
<Pharaoh_Atem> since there's snaps/ already
<Pharaoh_Atem> which is where downloaded snaps exist
<zyga> Pharaoh_Atem: it contains the actual snaps, yeah
<Pharaoh_Atem> maybe runsnap/?
<Pharaoh_Atem> something that makes it more obvious
<zyga> Pharaoh_Atem: well, that's not for users to see (/var/lib/snapd), /snap is different but I just want to carry on
<Pharaoh_Atem> sure
<zyga> Pharaoh_Atem: well, the actual directory is trivial to change ;)
<zyga> Pharaoh_Atem: I was just working on the changes to make that trivial
<Pharaoh_Atem> but yes, if you patch it, there will be no blockers to the review left
<zyga> Pharaoh_Atem: I was using FIXME as it was easy to grep for in logs
<zyga> Pharaoh_Atem: cool, glad to hear that
<Pharaoh_Atem> your preset request has already been provisionally approved for f24, f25, and rawhide
<zyga> yep, I saw
<zyga> just pending on the review
<zyga> so so close to being generally useful :)
<Pharaoh_Atem> the only other thing left to make snaps actually worth using is selinux support
<zyga> I guess F25 is going to be out soon so selinux won't be there on time but F26 looks realistic
<zyga> and I guess I can update it in earlier releases later
<mup> PR snapcraft#752 opened: Ant properties, build target, and destination directory options <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/752>
<Pharaoh_Atem> remember I said you can ship it as a module subpackage
<Pharaoh_Atem> for snap-confine
<Pharaoh_Atem> or snapd
<Pharaoh_Atem> or wherever it is
<zyga> Pharaoh_Atem: yep, I mean the whole stack, selinux, policy package, snapd and snap-confine support
<zyga> (it's everywhere, snap-confine = mechanism, snapd = policy)
<mup> PR snapd#1698 closed: tests: add all-snap spread image tests <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1698>
<Son_Goku> zyga, well, I know there are quite a few folks interested in seeing the SELinux integration for snapd
<zyga> Son_Goku: can you help me to get in touch with them
<zyga> Son_Goku: together this can be done faster, I bet
<Son_Goku> well, there are a few fedora-derived distros that may be considering shipping snapd
<zyga> Son_Goku: like? :)
<zyga> wa
<Son_Goku> well, if I'm particularly happy about snapd in fedora, I may recommend that Korora and a few others ship it
<Son_Goku> along with flatpak
<zyga> Son_Goku: do you know of any developers that are familiar with selinux that I could work with to speed things up?
<bull_> guys snapcraft gui https://files.gitter.im/ubuntu/snappy-playpen/nRqJ/Screenshot-from-2016-08-24-00-34-18.jpg
<Son_Goku> unfortunately, aside from Dan Walsh and a few other guys in #fedora-selinux, I don't really know anyone
<zyga> Son_Goku: I met some folks at flock but I'd like to have someone that can work with me closely to design and implement selinux
<zyga> I realize that Dan might have other priorities
<mup> PR snapd#1729 opened: tests: spread all-snap test cleanup <Created by mvo5> <https://github.com/snapcore/snapd/pull/1729>
<zyga> Son_Goku: how about yourself?
<zyga> Son_Goku: I'm new to selinux, you are new to go (right?)
<Son_Goku> yep
<zyga> Son_Goku: together this will at least increse the bus factor :)
<Son_Goku> haha
<zyga> Son_Goku: and I bet having another person to work with will improve the design
<mup> PR snapd#1664 closed: integration-tests: add update-rollback stress tests <Created by fgimenez> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1664>
<mup> PR snapd#1729 closed: tests: spread all-snap test cleanup <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1729>
<Pharaoh_Atem> zyga: so do you intend to patch the /snap path for Fedora?
<zyga> Pharaoh_Atem: yes
<zyga> Pharaoh_Atem: a few tests fail in weird ways, I'm just chasing that now
<Pharaoh_Atem> cool
<Pharaoh_Atem> at least your tests will be hardier :P
<zyga> it's all good in practice, something that's specific to tests is flaky
<ssweeny> jdstrand, I'm trying to use snap-confine with your overlayfs suggestion (https://paste.ubuntu.com/23079343/) but I'm getting apparmor denials on snap-confine itself trying to create a tmpfs dir
<jdstrand> ssweeny: can you paste the denials?
<ssweeny> jdstrand, https://paste.ubuntu.com/23083124/
<jdstrand> ssweeny: are you creating the /tmp/snapd.quirks_* dir in your code or was this already there?
<ssweeny> jdstrand, that was already there
<jdstrand> ssweeny: ok, then it sounds like there is a bug. zyga, fyi ^
<zyga> jdstrand: hmm
<zyga> which distro and release is this on?
<jdstrand> ssweeny: you can copy /etc/apparmor.d/usr.lib.snapd.snap-confine to /tmp and modify it
<jdstrand> ssweeny: then do: sudo apparmor_parser -r /tmp/usr.lib.snapd.snap-confine
<ssweeny> zyga this is on a series 16 all-snaps system
<zyga> jdstrand: I believe upstream is correct here,
<jdstrand> oh
<zyga> ssweeny: ssweeny probably a bug in our ppa packaging then
<jdstrand> maybe ssweeny is using new code but didn't copy the profile over
<ssweeny> that could be
<jdstrand> zyga: he is building it himslef
<zyga> jdstrand: ah, then most likely so
<zyga> ssweeny: the relevant parts are https://github.com/snapcore/snap-confine/blob/master/src/snap-confine.apparmor.in#L168
<jdstrand> ssweeny: ok, then diff what is in /etc/apparmor.d/usr.lib.snapd.snap-confine and ./src/snap-confine.apparmor.in
<jdstrand> ssweeny: and add the new rules in the manner I described
<ssweeny> jdstrand, zyga cool, thanks!
<zyga> ssweeny: note the file is an .in file with @LIBEXECDIR@ that needs to be replaced with /usr/lib/snapd in your case
<ssweeny> right
<zyga> I think it would be useful to have a way for devtools to support snap-confine
<zyga> we actually could, with file bind mounts
 * zyga has good ideas :)
<ssweeny> :)
<zyga> ogra: could I add a tweak to the initrd that bind mounts snap, snapd, snap-confine and the snap-confine aa profile from /snap/$SOME_RESERVED_NAME/current/
<zyga> ogra: this would let us *boot* a custom snapd for testing
<zyga> and would simplify devtools considerably
<zyga> down to "no customization required"
<mup> PR snapd#1727 closed: dirs,snap: define methods for SNAP_USER_DATA and SNAP_USER_COMMON <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1727>
<ssweeny> jdstrand, I added some code to add MS_SHARED to the mount like you said but I'm still not seeing the mount outside of the snap
<mup> PR snapd#1730 opened: dirs,snap: handle empty root directory in SetRootDir <Created by zyga> <https://github.com/snapcore/snapd/pull/1730>
<ssweeny> jdstrand, here's the diff as well as the SecurityMount string being returned in snapd
<ssweeny> https://paste.ubuntu.com/23083177/
<jdstrand> ssweeny: note, I didn't write this portion of the code
<jdstrand> ssweeny: what does the .fstab file look like?
<ssweeny> jdstrand, /run /run none bind,rw,shared 0 0
<Pharaoh_Atem> zyga: btw, in regards to dbus-1 service location, there's no special macros for it
<Pharaoh_Atem> so what you have is fine
<Pharaoh_Atem> zyga: however, I'd be more comfortable with snapd-xdg-open if it had a release and was in the snapcore organization instead of the ubuntu-core one
<zyga> Pharaoh_Atem: the organization was changed already
<zyga> Pharaoh_Atem: I will do a release with a few simple upstream tweaks tomorrow
<zyga> Pharaoh_Atem: (like empty NEWS files and others, this is not a gnu project)
<Pharaoh_Atem> you don't need those files
<zyga> Pharaoh_Atem: you can consider that provisionally done :)
<zyga> Pharaoh_Atem: I know but without a macro in configure.ac they get added
<Pharaoh_Atem> ah
<zyga> Pharaoh_Atem: I did it in snap-confine :)
<jdstrand> ssweeny: did you verify you are entering that part of the code?
<ssweeny> jdstrand, not directly. let me do some instrumenting real quick
<jdstrand> ssweeny: did you see if it worked outside of your code? eg, mount --bind /run /run ; mount --make-shared /run
 * zyga EODs
<zyga> take care guys
<jdstrand> ssweeny: but this is getting into the area where I advised getting zyga's input (zyga, that isn't an invitation to come back from eod :)
<zyga> haa
<zyga> I was typing /exit
<zyga> what's that?
<jdstrand> zyga: https://paste.ubuntu.com/23083177/ and this in .fstab: /run /run none bind,rw,shared 0 0
<zyga> ssweeny: did you try SNAP_CONFINE_DEBUG=1
<jdstrand> zyga: I really don't want to keep you from eod though
<ssweeny> zyga, yeah I can ping you tomorrow
<zyga> jdstrand: that's not allowd by the snap-confine apparmor profile AFAIR
 * zyga looks at the pastebin
<jdstrand> at this point I'd need to dive in quite deep to debug
<jdstrand> ssweeny: do you have apparmor denials?
<ssweeny> I added that to the profile for the time being just to see if it works
<zyga> ssweeny: can you pastebin the output of whatever you were testing with that variable set please
<zyga> I can stay for 5 more minutes :)
<zyga> I'm waiting for a review anyway
 * jdstrand doesn't have much longer
<zyga> I should EOD at 18:00 one day and just have a walk
<ssweeny> zyga, do I just export that variable on my shell or does it need to be part of the snap command?
<ssweeny> I'm not seeing additional debug output with it exported
<mup> PR snapd#1731 opened: firstboot: generate netplan config rather than ifupdown <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1731>
<zyga> ssweeny: you have to export it
<zyga> ssweeny: SNAP_CONFINE_DEBUG=1
 * zyga really EODs
<mup> PR snapd#1730 closed: dirs,snap: handle empty root directory in SetRootDir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1730>
<mup> PR snapd#1732 opened: many: respect dirs.SnapSnapsDir in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1732>
<ssweeny> jdstrand, thanks again for the help. I'll play around a bit more and I'm sure I'll have more questions tomorrow :)
<jdstrand> ok
<mhall119> jdstrand: is there any way for a snap command to call sudo?
<mhall119> or does the user have to launch the snap command with sudo?
<jdstrand> the latter
<jdstrand> that came up on the list recently-- I gave a very detailed response
<mhall119> thanks jdstrand
<kyrofa> tyhicks, ping
<tyhicks> kyrofa: hey
<kyrofa> tyhicks, snapd has a section of the daemon's REST API which would ideally be accessible from all apps/hooks. Right now we have snapd-control which opens the thing up completely, but we definitely don't want to make that implicitly available to all apps/hooks, so I'm working on splitting out what I'm calling the "public" bits of the API into a separate socket
<kyrofa> tyhicks, my question for you is, can we allow access to that socket without implicitly allowing access to other stuff?
<kyrofa> tyhicks, here are the denials I get without any profile changes: http://pastebin.ubuntu.com/23083538/
<tyhicks> kyrofa: do clients connect over a unix domain socket?
<kyrofa> tyhicks, indeed
<tyhicks> kyrofa: yes, we can allow all snaps to access the public socket and only allow snaps with snapd-control to access the private socket
<kyrofa> tyhicks, does that require setsockopt etc. to be in the default templates? Or can we somehow limit that to only that one socket (argument filtering, maybe?)
<tyhicks> kyrofa: well, the network interface is autoconnect and it already allows setsockopt
<kyrofa> tyhicks, but it allows a bunch of other stuff, too
<kyrofa> tyhicks, another potential way to do this: this REST calls in question are coming from a helper binary written by us. Can it somehow be covered by a slightly more lenient profile?
<kyrofa> (the binary is called by the apps/hooks in question)
<Birchy> why doesn't OpenAL work in Snappy?
<tyhicks> kyrofa: that's possible - we'd need to set up a profile transition
<tyhicks> kyrofa: the CAP_NET_ADMIN denial is worrisome - do you know what is causing that?
<kyrofa> tyhicks, the helper binary is written in go; looking at the bug, it seems to be a known issue
<kyrofa> tyhicks, and ignorable, I think?
<tyhicks> oh, yes
<kyrofa> Very helpful snappy-debug message, there
<tyhicks> I fixed that upstream and it hasn't made it back into xenial yet
<tyhicks> oh, it has made it into xenial but maybe you're using an old kernel
<kyrofa> Yeah that's possible, this is linode
<tyhicks> $ git describe --contains 793d301b
<tyhicks> Ubuntu-4.4.0-25.44~218
<kyrofa> tyhicks, would such a transition require snap-confine changes, or is that something we can setup at the profile level?
<kyrofa> Yeah, 4.4.0-21 here
<tyhicks> kyrofa: it is something that we could set up at the profile level
<kyrofa> tyhicks, can that be done for seccomp as well?
<tyhicks> that explains it, good to know that CAP_NET_ADMIN is definitely not needed
<tyhicks> kyrofa: it cannot :/
<kyrofa> tyhicks, hrm
<tyhicks> kyrofa: why are inet and inet6 sockets being created?
<kyrofa> tyhicks, honestly, no idea
<kyrofa> :P
<tyhicks> kyrofa: if this is being done over a unix domain socket, AF_UNIX should be used instead of AF_INET or AF_INET6
<tyhicks> that would get rid of those 3 denials
<kyrofa> Yeah I'll investigate that
<mup> Bug #1465724 changed: net_admin apparmor denial when using Go <verification-done-xenial> <Snappy:Fix Released by tyhicks> <linux (Ubuntu):Fix Released> <linux (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1465724>
<kyrofa> It might just be the libs reaching out somehow. The setsockopt is probably the bit issue there
<kyrofa> big*
<tyhicks> reading somaxconn is something that go does every time a go program is ran
<tyhicks> so that could safely be allowed
<kyrofa> In the default profile?
<kyrofa> I didn't think that seemed too dangerous
<tyhicks> I think so
<tyhicks> that leaves the setsockopt
<Birchy> how would I allow an application access to /run/udev?
<kyrofa> But apparmor has become a lesser concern for me anyway considering the possible profile transition
<tyhicks> kyrofa: the default seccomp template has this:
<tyhicks> # needed by ls -l
<tyhicks> socket
<tyhicks> connect
<tyhicks> kyrofa: we'll need to speak with jd strand about this tomorrow but since socket and connect are already allowed, it seems reasonable to allow setsockopt in the default template, too
<kyrofa> tyhicks, okay, I'll make a note to speak to him. Thank you, you've been tremendously helpful! I think that covers everything :)
<tyhicks> kyrofa: it is looking like we won't need a profile transition and some simple changes can be made to the default template to allow what you need
<tyhicks> kyrofa: have a good one! :)
<kyrofa> Agreed!
<kyrofa> You too!
<kyrofa> tyhicks, hey, missed you at the last sprint. Will you be at the next one you think?
<tyhicks> kyrofa: I will be - see you there :)
<kyrofa> Awesome!
#snappy 2016-08-24
<ahoneybun> mhall119, do you have that geany snap around?
<ahoneybun> I'm learning python and the book recommends it
<ahoneybun> I'm trying to snap a lot of things away lol
<liuxg> is docker supported on 16.04 core?
<liuxg> does anyone know how to compile a armhf version of a snap?
<mhall119> ahoneybun: I have an amd64 binary if you want it
<firstofthe300> Hey guys
<firstofthe300> I am working on my first snap package
<firstofthe300> its a Mono app (please no flame...I didn't pick the language)
<firstofthe300> I don't see an xbuild plugin
<firstofthe300> anybody have an idea on how to get around that issue?
<mup> PR snapd#1733 opened: interfaces: add lxd-support interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/1733>
<mup> PR snapd#1720 closed: interfaces: add lxd-support interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1720>
<mup> PR snapd#1732 closed: many: respect dirs.SnapSnapsDir in tests <Created by zyga> <Conflict> <https://github.com/snapcore/snapd/pull/1732>
<mup> PR snapd#1734 opened: boot: add missing udevadm mock to fix FTBFS <Created by mvo5> <https://github.com/snapcore/snapd/pull/1734>
<liuxg> lool, when I run the classic.create command on 16.04 desktop, I get the error like chroot: failed to run command '/var/lib/classic/enable.sh': No such file or directory, what could be the problem for it? http://paste.ubuntu.com/23084232/
<lool> liuxg: is this the classic snap from edge?
<lool> liuxg: also, you need to sudo classic.create
<liuxg> lool, yes, I installed it by using the command "sudo snap install --devmode --edge classic" on 16.04
<lool> liuxg: oh on 16.04 desktop? I'm not sure that's supported; I guess it could work there, but there might be bugs
<liuxg> lool, in fact, I switched to root user, and I ran the command under root.
<liuxg> lool, so, do you mean that it only works for arm devices?
<lool> liuxg: it might only work on Ubuntu Core images
<liuxg> lool, OK. I got it. thanks. After I run the classic.create, then follow by classic.shell. I can start to install the development env there, right? Sorry, I never did it before. I might need to get an arm device to have a try.
<lool> liuxg: yes, you basically get a chroot where you can install stuff
<lool> liuxg: it just wont start any services on boot or such
<liuxg> lool, nice. I think this could be the easist way to cross compile. Many thanks for your help!
<lool> liuxg: pleasure
<mup> PR snapd#1734 closed: boot: add missing udevadm mock to fix FTBFS <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1734>
<lool> elopio, ysionneau: I tried building a snapweb snap for armhf on a rpi3 running xenial, but I failed with: http://paste.ubuntu.com/23084299/
<lool> elopio: How had you built the amd64 one?
<lool> I followed the README.md instructions
<dz0ny> lool: phantomjs cannot run under arm
<dz0ny> you have to manually compile phantomjs with specific patches
<lool> dz0ny: argh
<lool> dz0ny: oddly, we used to have builds for this, do you know which change caused this? and do you have a recipe for building phantomjs?  O:-)
<dz0ny> lool: https://github.com/ab77/beastcraft-telemetry/blob/master/grafana-armhf/README.md#build
<dz0ny> this might help you
<dz0ny> I was asking in mailing list of how people handle different architectures and building snaps
<dz0ny> and no one replied
<dz0ny> the problem is that you need totally different declaration for devices too
<dz0ny> and snapcraft is not ready for that
<lool> dz0ny: what do you mean for "declaration for devices"?
<dz0ny> different paths, libs, patches etc
<dz0ny> in snapcraft
<dz0ny> yaml
<lool> dz0ny: oh you mean for cross-building?
<dz0ny> mhm
<dz0ny> aka the snapcraft.yaml for ffmpeg on amd64 wont compile on arm
<lool> I dont quite get the link with snapcraft; this is with the node plugin pulling deps, I dont believe snapcraft is aware of phantomjs specifically
<lool> ah there's no way to express build differences between host arches in snapcraft.yaml
<lool> indeed
<dz0ny> because environment is different
<lool> outside of your own plugins / upstream build system
<dz0ny> mhm
<lool> justinmcp_: heya
<lool> justinmcp_: did you by any chance poke at snapweb recently? did you manage to build it for armhf?
<lool> elopio: nevermind, saw your https://bugs.launchpad.net/snapweb/+bug/1616280
<mup> Bug #1616280: building on armhf fails because of phantomjs <snapweb:New> <https://launchpad.net/bugs/1616280>
<mup> PR snapd#1714 closed: many: hook in start of code to fetch/check assertions when installing snap from store <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1714>
<lool> dz0ny: unfortunately I couldn't find a corresponding libicui18n.so.48 to run the prebuilt phantomjs binary there  :-/
<mup> PR snapd#1735 opened: tests: fixes to make the ubuntu-core-16 image usable with -keep/-reuse <Created by mvo5> <https://github.com/snapcore/snapd/pull/1735>
<liuxg> has anyone successfully booted raspberry pi2? I flashhed my raspberry 2 device at the instructions at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ I cannot see the HDMI output
<ogra> liuxg, there should definitely be a login prompt after a while ... boot output goes to serial though
<liuxg> ogra, oh, my godness. I do not have a serial cable for it.
<liuxg> ogra, so HDMI has no output, right?
<ogra> HDMI has output
<ogra> just no boot messages
<liuxg> ogra, I connect it to my DELL monitor, there is no message at all. do you mean, I need to buy a serial cable for it?
<ogra> oh, wait, you dont use a snappy image ?
 * ogra just saw the link
<liuxg> ogra, I flashed it at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<ogra> right, i thought you run a snappy image ... the server image might not enable HDMI, not sure about that
<liuxg> ogra, is that the ubuntu core image? or it is a just a classic ubuntu?
<tvoss> niemeyer: o/
<ogra> the one described on that page is ubuntu server
<ogra> http://people.canonical.com/~mvo/all-snaps/16/ has the experimental snappy images
<liuxg> ogra,  so, I can use the same instructions to flash the snappy image?
<ogra> liuxg, i use: xzcat all-snaps-pi2.img.xz | sudo dd of=/dev/sdc bs=32M
<ogra> (with sdc being my SD card reader)
<liuxg> ogra, OK, many thanks for your help on this. I will flash my raspberry 2 device
<mup> PR snapd#1736 opened: tests: port integration tests to spread <Created by mvo5> <https://github.com/snapcore/snapd/pull/1736>
<ogra> zyga, if you put that behind something like a commandline option, sure, why not
<ogra> (the initrd change)
<mwhudson> mvo, zyga: Uploading snap-confine_1.0.40-1.dsc: done.
<sergiusens> good morning
<liuxg> ogra, I just flashed the snappy software, but I still do not see the output
<mvo> mwhudson: yay, thank you - was the git repo of any help for you?
<mwhudson> mvo: yes
<ogra> liuxg, how long did you wait ? the fiirst boot can take a while
<mwhudson> definitely
<mwhudson> mvo: i sent a mail with details
<liuxg> ogra, I waited for more than 10 mins
<ogra> well, then you should see something (i surely do here)
<liuxg> ogra, do you see it via the HDMI output? I connect it to the hdmi port of my DELL monitor
<liuxg> ogra, if that is the case, how can I connect to it? using the ssh?
<ogra> yes, after the boot is done i get a login prompt
<ogra> (until that shows up it stays black though, since the boot output goes to serial, as i said)
<ogra> if you know the IP you can just "ssh ubuntu@$IP" after it booted
<liuxg> ogra, yeah, that could be problem for it. there is no more ouput, so the screen is black
<ogra> well, all i can say is that iit works fine with the LG monitor i use here
<ogra> for both, pi2 and 3
<liuxg> ogra, I do not know what is wrong here for the DELL monitor
<ogra> do you perhaps switch the input via a menu on the monitor ?
<ogra> *have to switch
<liuxg> ogra, yes, I did that. it is hdmi 2 port
<liuxg> ogra, anyway, I am now trying to boot it again.
<ogra> liuxg, you could try to edit cmdline.txt on the system-boot partition of the SD and add "console=tty1" or some such to the cmdline
<liuxg> ogra, if I do "console=tty1", I can still see it on the serial link, right? how to get it working on the HDMI port?
<ogra> no, tty1 should switch it to the HDMI port
<ogra> (or might be tty0 ... i forgot ... if 1 doesnt work, try 0)
<liuxg> ogra, thanks. I will try that.
<liuxg> ogra, I just tried to login using the ssh. I connected it to my router, and it worked for me.
<ogra> ah, good
<liuxg> ogra, there is no output yet :) anyway, at least, I can try sth.
<ogra> liuxg, journalctl -b should show the boot log
<ogra> there should be a line like: "Started Getty on tty1"
<ogra> right before "Reached target Login Prompts."
<ogra> if you see that both, then i'd guess there is a hardware issue (cable, monitor setup etc)
<zyga> slangasek: hey, thanks :)
<liuxg> ogra,  http://paste.ubuntu.com/23084694/, this is the output. do you mean we need to set it to tty0?
<ogra> no, it tells you it starts a getty so there is a login promppt ... tty1 should be fine
<ogra> ubuntu@pi3:~$ ps ax|grep getty
<ogra>  2920 ttyS0    Ss+    0:00 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt220
<ogra>  2921 tty1     Ss+    0:00 /sbin/agetty --noclear tty1 linux
<ogra> if you see that, then there is definitely a login prompt ... and i'd say there is something with the cable or monitor
<liuxg> ogra, OK. I got it. I see it like http://paste.ubuntu.com/23084702/
<zyga> slangasek: if you are around, how can I help you to accept latest SRU into xenial-updates?
<ogra> yeah
<ogra> check the cable, check the monitor again ...
<ogra> from a software POV everything is there
<liuxg> ogra, do you think whether I need to change it to tty0 to have a try?
<ogra> no, i doubt that will change anything ... (but you can indeed try :)  )
<zyga> ogra: good, I know a lot of people that could use this
<zyga> mwhudson: thanks for the release!
<ogra> zyga, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial ... make a debdiff against initramfs-tools-ubuntu-core from there and show it to mvo or me
<ogra> cyphermox, why is there a subiquity in the image build PPA ^^ ?
<zyga> ogra: thanks, I'll try
<ogra> (and what is probert )
<mwhudson> zyga: np
<ogra> cyphermox, note that this PPA is for image content ...
<mwhudson> ogra: src:subiquity builds console-conf
<ogra> console-conf ?
<mwhudson> the first boot configurator thing
<ogra> mwhudson, we dont seed subiquity ... there are more and more packages showing up in that PPA that are not inside the image
<mwhudson> console-conf and probert will be inside the image soon
<ogra> ah, k
<ogra> mwhudson, but they will be SRUed once they are ready ?
<mwhudson> yeah
<ogra> (long term plan is to get rid of most stuff in that PPA before GA release=
<ogra> )
<ogra> preferably of everything ... :)
<mwhudson> new packages so not much chance of regression ;-)
<ogra> yeah
<ogra> well, it adds a new feature that replaces an existing one i guess ... so there is chance of regression
<ogra> but thats fine in the edge channel
<mwhudson> i'm finding that i can only boot an all-snaps image in qemu once
<mwhudson> if i boot it again, it can't find partitions
<ogra> using the vvery latest image from mvo ?
<mwhudson> no
<ogra> aha
<mwhudson> using an image i made from bits i got out of some image from mvo last week i guess
<ogra> there were some fixes on friday ...
<mwhudson> ok
<ogra> (and also a new u-d-f iirc)
<mup> PR snapd#1737 opened: tests: update listing test for latest stable image <Created by mvo5> <https://github.com/snapcore/snapd/pull/1737>
<ogra> mwhudson, i just did 5 reboots with that image, no issues here
<mwhudson> ogra: ok, i'll grab the newest bits tomorrow then
<ogra> (apart from the known "no eth0" one)
<mwhudson> still from http://people.canonical.com/~mvo/all-snaps/16/ ?
<ogra> yep
<mwhudson> talking of the no eth0 thing...
 * mwhudson makes some comments on a PR
<ogra> :)
<ogra> i dont see that issue on rpi
<ogra> it even gets its weird enxb827ebc92b03 device name and still works
<cyphermox> ogra: right, like mwhudson said
<ogra> yeah, all fine then
<mwhudson> oh god cyphermox is awake, time for bed!
<ogra> haha
<cyphermox> hehe :)
<mvo> ogra: do you think you could make /etc/systemd/{user,system}.conf.d/ available via the ubuntu-core snap as writable directories? this is something for the plano people that they really need urgently
<ogra> mvo, sure, why not
<ogra> just needs to be added to writagble-paths
<mvo> ogra: and I think we need to add the dirs to the image via livecd-rootfs, it appears to be missing
<mup> PR snapd#1737 closed: tests: update listing test for latest stable image <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1737>
<ogra> mvo, hmm, why does systemd not create them ?
<ogra> (can it actually handle these dirs if it doesnt actually create them ?)
<ogra> (i would expect the package to create them if it can process content from there)
<mup> PR snapd#1738 opened: tests: the stable ubuntu-core snap has snap run support now <Created by mvo5> <https://github.com/snapcore/snapd/pull/1738>
 * mvo lunch
<liuxg> ogra, I just installed hello and hello-world examples into my raspberry pi 2 device, when I run the apps, I get error like "mkdir: cannot create directory '/home/ubuntu/snap/hello': Permission denied". what could be the problem for it?  http://paste.ubuntu.com/23084828/ thanks
<zyga> liuxg: which version of snap-confine that system has?
<zyga> liuxg: can you see any apparmor denials?
<liuxg> zyga, if I use "sudo", it is fine http://paste.ubuntu.com/23084831/
<ogra> zyga, i guess he uses mvo's image ... so whatever was the snap-confine in the image build PPA on friday
<ogra> (not sure why that package is still in the PPA)
<liuxg> zyga, yes, I took the software from http://people.canonical.com/~mvo/all-snaps/16/
<liuxg> ogra, to my best understanding, we should not use the "sudo" to get it running, right?
<ogra> ubuntu@pi3:~$ sudo snap install hello-world
<ogra> hello-world (stable) 6.3 from 'canonical' installed
<ogra> ubuntu@pi3:~$ hello-world.env
<ogra> mkdir: cannot create directory â/home/ubuntu/snap/hello-worldâ: Permission denied
<ogra> ubuntu@pi3:~$
<ogra> i get the same here
<ogra> ubuntu@pi3:~$ ls -l /home/ubuntu/
<ogra> total 4
<ogra> drwxr-xr-x 3 root root 4096 Aug 23 11:49 snap
<ogra> aha
<ogra> that definitely workd yesterday
 * zyga looks
<liuxg> ogra, is there anything broken?
<zyga> liuxg: any DAC ownership along the way?
<zyga> liuxg: I mean anything like a root-owned directory in the way?
<liuxg> zyga, I do not quite understand what you mean, sorry
<zyga> liuxg: any apparmor denials?
<zyga> liuxg: I meant to ask if anything along /home/ubuntu/snap/hello-world is owned by root
<zyga> liuxg: can you also run the same command without sudo but with SNAP_CONFINE_DEBUG=1 set
<liuxg> zyga, http://paste.ubuntu.com/23084841/
<liuxg> zyga, where should I change that variable? in the command line?
<zyga> liuxg: just an environment variable
<zyga> export SNAP_CONFINE_DEBUG=1 should do it
<zyga> that may be the problem
<liuxg> zyga, yes, this time, it is right.
<zyga> chown everything in $HOME/snap
<zyga> liuxg: and see if this occurs again
<liuxg> zyga, to "ubuntu" user?
<zyga> yes
<liuxg> zyga, do I need to set the SNAP_CONFINE_DEBUG=1 to 0 again?
<zyga> liuxg: it's just temporary, you can unset it, it doesn't hurt
<liuxg> zyga, yes, now, it works.
<ogra> zyga, see my paste above
<ogra> $HOME/snap is root.root
<zyga> ogra: that's not correct
<zyga> ogra: is that reproducible?
<ogra> zyga, no, and it worked yesterday
<liuxg> zyga, is this a bug in the image?
<zyga> I don't know yet
<zyga> can anyone with an image rm -rf $HOME/snap and run hello world without sudo
<zyga> and see what happens
<ogra> i never ran hello-world with sudo
<ogra> yet the dir is root owned
<ogra> though i dont know if it was like that before i installed hello-world
<zyga> ogra: it could be snap-confine itself, it runs as root,
<zyga> ogra: can you do a quick test as I've described?
<ogra> zyga, works fine
<liuxg> ogra, after I use classic to build my snap app, where can I find the .snap file? is it in the $HOME directory somewhere?
<zyga> ogra: ok, uff, that's not bad then
<ogra> liuxg, in the dir you ran snapcraft
<liuxg> ogra, after I exit the class, I need to install it under snap instead of being in classic, right?
<liuxg> ogra, can I just do installation there like "sudo snap install *.snap" under that folder?
<ogra> liuxg, the home dir is shared between classic and non-classic ...
<zyga> liuxg: perhaps it would work from classic, as long as you can access the socket
<zyga> liuxg: you can give it a try
<ogra> you should just find your snap in your home if you built it there
<cpaelzer> trying to transition from copy to dump plugin - I haven't found a single place describing that. I formerly used copy+files to rename-and-install files that the native build system of the project didn't add. Trying to rebuild that function with dump+organize now - are there known examples for that to take a look at?
<cpaelzer> wow that was more text than I thougth when typing :-/
<liuxg> ogra, yes, you are right. thanks
<cpaelzer> hmm, might even work with nil plugin since I might only need organize ...
<cpaelzer> anyway I'll trial and error through that, but if one has a nice pointer to a collection of examples using dump (other than the tomcat maven demo) that would be nice
<ogra> zyga, very weird, i cant get it into that state anymore
<ogra> cpaelzer, you need to add "source: ."
<ogra> and rename "files:" to "filesets:"
<ogra> at keast that worked for me
<cpaelzer> ogra: I had added source . (and similar things) but it always complained about stuff not being a directory and/or not being around at install stage
<cpaelzer> ogra: but I'll give it a try once more
<cpaelzer> and afaik the filesets do not have the renaming part I need
<cpaelzer> that would be organize and that is what breaks on the "has to be in the install stage"
<ogra> cpaelzer, https://github.com/ogra1/classic-snap/blob/master/snapcraft.yaml
<cpaelzer> hrm, really - ok :-) that seems easier
<ogra> https://github.com/ogra1/classic-snap/commit/f467a6634cdc2e43e496eaaf9d12616aae29bf6c
<ogra> thats the change i did to go from copy to dump
<ogra> (ignore architecture and version)
<cpaelzer> ogra: your example is nice although IMHO it doesn't match filesets as documented in docs/snapcraft-parts.md and docs/snapcraft-syntax.md
<cpaelzer> my issue really seems to be that the "renaming" has to be done on install stage
<ogra> well, i was lazy :)
<cpaelzer> ogra: your example did bin/*: bin
<ogra> it worked, so i left it as is
<cpaelzer> bin/* afaik is only the identifier and you never refer to it :-)
<cpaelzer> I can't use that to rename
<ogra> yeah, i copy bin/* to bin/ after all
<ogra> without name changes
<cpaelzer> if I'm right your line could be "foobar: bin" and still work
<mup> PR snapd#1732 closed: many: respect dirs.SnapSnapsDir in tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1732>
<cpaelzer> yep, foo: bin does just the same
<cpaelzer> fyi that is the way it had to be written for the copy plugin in my case https://gitlab.com/paelzer/ntpsec/blob/snapify-ntpsec/snapcraft.yaml
<cpaelzer> TL;DR the two copy sections did: "take file from local tree and place in snap under different name"
<cpaelzer> still struggling to recreate that with dump and/or nil plugin
<ogra> right, not sure how you do a rename ... ask kyrofa or sergiuens
<cpaelzer> sergiusens: kyrofa: ^^
<kyrofa> cpaelzer, it depends upon the way the filesystem looks when the copy occurs
<mup> PR snapd#1739 opened: cmd/snap: use UserDataDir and UserCommonDataDir <Created by zyga> <https://github.com/snapcore/snapd/pull/1739>
<kyrofa> cpaelzer, it was written to try and mimic `cp` as much as possible, with the exception that `foo: bin/` (note the trailing slash) will create the bin/ dir
<cpaelzer> kyrofa: hi, I just gave up a few minutes ago and filed bug 1616459 which summarizes it much better
<mup> Bug #1616459: dump plugin not a full super-set to the now deprecated copy plugin <Snapcraft:New> <https://launchpad.net/bugs/1616459>
<cpaelzer> kyrofa: if you could take a look there and advise that would be great
<kyrofa> Sure thing
<mup> PR snapd#1740 opened: many: respect SnapMountDir in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1740>
<mup> PR snapd#1741 opened: firstboot: do not use absolute /sbin/udevadm in firstboot.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/1741>
<mup> PR snapd#1741 closed: firstboot: do not use absolute /sbin/udevadm in firstboot.go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1741>
<zyga> slangasek: ping, what's the status of snap-confine SRU
<mup> PR snapd#1739 closed: cmd/snap: use UserDataDir and UserCommonDataDir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1739>
<mup> PR snapd#1739 closed: cmd/snap: use UserDataDir and UserCommonDataDir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1739>
<mup> PR snapd#1742 opened: firstboot: properly mock udevadm <Created by mvo5> <https://github.com/snapcore/snapd/pull/1742>
<mup> PR snapd#1742 closed: firstboot: properly mock udevadm <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1742>
<jcastro> mvo: is snap-confine released into distro at a cadence or ad-hoc? I'm asking because the juju team would like 1.0.40, which has a bugfix for allowing us to use lxd with snapped Juju.
<kyrofa> jdstrand, hey, remember the new snapd socket we discussed yesterday?
<kyrofa> jdstrand, through trial and error, it seems these are the profile changes necessary to make use of it: http://pastebin.ubuntu.com/23085069/ . Can you give me your thoughts when you're able?
<jdstrand> kyrofa: hey, yes
<jdstrand> kyrofa: looks totally fine except please use @{PROC} instead of /proc
<kyrofa> jdstrand, ah, wonderful! It was a few more things than I was hoping, so I'm glad it looks okay
<mup> PR snapd#1743 opened: many: use StripGlobalRootDir and respect SnapMountDir <Created by zyga> <https://github.com/snapcore/snapd/pull/1743>
<kyrofa> Hey nessita, it looks like https://myapps.developer.ubuntu.com/dev/click-apps/register-name-dispute has been removed? Does it have a replacement by any chance? We try to point people in the right direction from snapcraft
<kyrofa> But doing it online, it seems all ajaxy
<nessita> kyrofa, hum, let me check... did you ask sergiusens? I think he had some info
<nessita> but I can check nevertheless
<kyrofa> nessita, no, I don't believe he's around just yet
<nessita> kyrofa, is my understanding that filing a dispute ocurrs now in the same URL as name registration https://myapps.developer.ubuntu.com/dev/click-apps/register-name/
<zyga> jdstrand: lately ad-hoc because SRU was bumpy
<zyga> jdstrand: it is supposed to be co-released with snapd
<nessita> kyrofa, it requires a submission and then you can file the dispute
<zyga> jdstrand: the plan is to get current SRU out, then do small SRU with just a few patches for apparmor and then a big SRU with all of 1.0.40 or .41
<kyrofa> nessita, hmm. So there's no URL to which we can direct people? What do we envision happening within snapcraft?
<jdstrand> zyga: I'm not sure what question I asked but glad to hear the answer :)
<jdstrand> jcastro: see zyga's response to me :)
<nessita> kyrofa, why do you say we have no URL? the URL is https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ and this was arranged after a bug report, let me find it
<kyrofa> nessita, ah, so just direct people to that URL and say "try to register it again" essentially?
<kyrofa> That works
<nessita> kyrofa, right
<mup> PR snapd#1744 opened: snap: use "up to date" instead of "up-to-date" <Created by mvo5> <https://github.com/snapcore/snapd/pull/1744>
<kyrofa> nessita, okay great, thank you!
<nessita> kyrofa, I will confirm 100% when fgallina is here
<nessita> kyrofa, he can give you the exact URL
<kyrofa> nessita, I appreciate it :)
<morphis> niemeyer, zyga: it would be awesome if you can comment on https://github.com/snapcore/snapd/pull/1669
<mup> PR snapd#1669: interface: add usb device support to serial-port <Created by jocave> <https://github.com/snapcore/snapd/pull/1669>
<morphis> niemeyer, zyga: would like to get that discussion unblocked
<morphis> jdstrand, joc_: ^^
<mup> PR snapd#1745 opened: overlord/snapstate: respect SnapMountDir in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1745>
<zyga> jdstrand: the one to mvo about snap confine sru
<zyga> jdstrand: ahh, that was jcastro !
<zyga> sorry :)
<jcastro> zyga: excellent, thanks!
<zyga> morphis: looking
<niemeyer> morphis: What's the issue there?
<morphis> niemeyer, zyga: see jdstrand's comment
<niemeyer> morphis: I have a meeting soon and cannot go over this whole thread right now, but can discuss a particular aspect quickly if that's helpful
<morphis> niemeyer, zyga: more or less jdstrand wanted your sign off on this
<morphis> to make this future ready
<niemeyer> morphis: What is "this"?
<morphis> the way we're modifying the serial-port interface
<morphis> niemeyer: its fine if you comment later today
<niemeyer> morphis: What is the urgency of this issue?
<morphis> niemeyer: RTM :-)
<niemeyer> morphis: I see non-trivial topics being covered there, such as hot-plugging of devices, which we most likely cannot address for RTM
<niemeyer> or GA, for that matter
<niemeyer> morphis: Those will indeed require some careful design that we don't have the bandwidth for right now
<morphis> niemeyer: hotplug etc. isn't supposed to be done with this, but jdstrand wanted the current implementation to no be broken when we add sth like hotplug in the future
<morphis> niemeyer: we don't want to discuss hotplug, we're ok with a static implementation which joc_ implemented
<morphis> niemeyer: jdstrand just wants your sign-off on that to make sure what we've implemented is in line with possible thoughts around a future hotplug solution
<niemeyer> morphis: What is the urgency of this issue?  I thought we had sorted a basic serial-port that should work for now?
<morphis> niemeyer: exactly, we have it sorted and the impl is there
<sergiusens> kyrofa nessita yes it has been removed and I talked to cprov about it, I silently fixed it without complaining
<morphis> but still jdstrand wanted you or zyga to comment
<niemeyer> morphis: Ok, so why do we need the PR?
<morphis> so, this is the reimplementation of the zigbee interface
<kyrofa> sergiusens, ah, so is bug #1616471 already fixed?
<mup> Bug #1616471: URL for name takeover is incorrect <Snapcraft:Triaged> <https://launchpad.net/bugs/1616471>
<lool> elopio: I've disabled the karma-phantomjs dep and the build proceeds a bit but it fails with: /tmp/tmpc2celh4b: 4: exec: /home/ubuntu/go/src/github.com/snapcore/snapweb/parts/assets/npm/bin/gulp: not found
<lool> Command '['/bin/sh', '/tmp/tmpc2celh4b', '/home/ubuntu/go/src/github.com/snapcore/snapweb/parts/assets/npm/bin/gulp', 'install']' returned non-zero exit status 127
<morphis> niemeyer: which had the approach of assingning a particular device via pid/vid to the device cgroup of the snap
<lool> elopio: despite gulp being installed for my user
<sergiusens> kyrofa this just means you need to pay more attention during standups ;-)
<lool> elopio: would you know how to fix this one?
<nessita> sergiusens, fabian is about to contact you, he was not aware of the breakage, he is about to add a redirect
<lool> justinmcp_: around?
<sergiusens> nessita it is all fine
<morphis> niemeyer: as in the end it still just allows access to a serial port we agreed in the discussion with jdstrand that this should be added to the serial-port interface
<sergiusens> nessita 2.15 is in xenial-updates already, don't waste time on this
<niemeyer> morphis: What we discussed before and is merged uses a path, not pid/vid
<niemeyer> morphis: This is already landed
<niemeyer> morphis: Why do we need something else right now?
<kyrofa> sergiusens, haha, that was days ago!
<morphis> no, not what we discussed for quite a long time for USB based tty for zigbee support
<morphis> that is what we want to add here
<morphis> as there are zigbee usb dongles we need to support with RTM
<morphis> and as you said, real hotplug support is past RTM/GA we need a interim solution for that
<morphis> and that is the PID/VID based device-cgroup thing
<kyrofa> sergiusens, anyway, sorry for not catching that. Thanks for chiming in :)
<niemeyer> morphis: Yes, and I thougth the interim solution was already merged
<niemeyer> morphis: Why does it not work?
<morphis> niemeyer: it works :-)
<niemeyer> morphis: Ok, so we don't the the PR..?
<niemeyer> need the
<morphis> we need it as the iterim solution isn't merged yet
<morphis> so that PR is the interim solution
<niemeyer> morphis: We're going in circles.. I'm asking what seems to be like a simple question: we have a serial-port interface today, which we discussed and I assumed it would solve your problems. Why is that code not enough for you what you need for GA?
<morphis> niemeyer: ok, lets go over it step by step:
<morphis> we have serial port which allows path based access to serial nodes in the system
<morphis> all ok, works fine
<morphis> but it doesn't solves the problem of hotpluged usb devices which create new tty's
<morphis> that is why we came up with the VID/PID attributes for the interface based approach
<morphis> we had that first in an interface named 'zigbee'
<morphis> but then in a discussion with jdstrand and joc_ we came to the conclusion that it makes more sense in the existing serial port interface
<morphis> that implementation is now what is in https://github.com/snapcore/snapd/pull/1669
<mup> PR snapd#1669: interface: add usb device support to serial-port <Blocked> <Created by jocave> <https://github.com/snapcore/snapd/pull/1669>
<morphis> that is all fine, satisfies our needs for RTM
<niemeyer> morphis: Why do we need to support hotplugging right now?
<jdstrand> niemeyer: to be clear. the serial-port as implemented wasn't meeting morphis' and co's needs. they had a meeting with me on how to move forward and we discussed. I said to implement it as a PR but that it would need sign-off from the interfaces team to make sure it fit with future plans. In the PR comment, I tried to give thoughts on reconciling the PR's approach with possible future plans
<morphis> niemeyer: as we have a specific product which requires this
<jdstrand> niemeyer: afaic, we don't need to completely flesh out the future plans, but wanted to make sure we thought about where we were going before landing what is in the PR
<jhobbs> does 'snap' respect http_proxy and https_proxy?
<niemeyer> morphis: Of course.. many things are being attributed as dependencies of a product, but this is a technical question
<niemeyer> morphis: We didn't discuss hot-plugging of devices in the last sprint, or anytime recently.. so it's a bit of an issue to have it in the roadmap days before freeze
<morphis> niemeyer: we're discussing this since beginng of june
<morphis> niemeyer: see https://github.com/snapcore/snapd/pull/1405
<niemeyer> morphis: So I'm trying to get down to the details: the fact you want a specific device to work, which likely has a specific vendor ID and product ID, implies it can also have a specific path in the filesystem
<mup> PR snapd#1405: interfaces: add zigbee-dongle interface <Reviewed> <Created by jocave> <Closed by jocave> <https://github.com/snapcore/snapd/pull/1405>
<ahasenack> is "snappy" in ubuntu-core the same as "snap" in ubuntu?
<ahasenack> or is snappy some older version before a rename took place?
<niemeyer> morphis: I'm discussing that sort of issue since early last year.. I'm pointing out we do not have hot-plugging of devices in the roadmap, which I hope you can understand and agree
<zyga> ahasenack: conceptucally yes
<morphis> niemeyer: absolutely, that is why we all agreed on having the PID/VID approach
<morphis> to have a interim solution which covers a very specific use case
<niemeyer> morphis: Yep, so.. VID+PID means a fixed device.. means a fixed path.. means the current serial-port interface works
<jdstrand> niemeyer: the problem with the zigbee dongle interface was that it was too-specific. morphis can correct me, but this device is not at all common, and there may be other not at all common devices out there for products, so having an interface for every no at all common device that for all intents and purposes is a serial port seemed not the right approach
<morphis> niemeyer: having a fixed device path requires a udev rule and we need an interface to put that in place ..
<niemeyer> morphis: The "interim solution" is not a magic thing.. we cannot bolt down such a major feature with no design consideration
<niemeyer> jdstrand: Yes, what I'm suggesting is not hot-plugging
<niemeyer> jdstrand: Which is exaclty the point I'm making.. we're not going to have hot-plugging of devices on this GA
 * jdstrand notes this is why we wanted to have the discussion with the interfaces team before committing :)
<morphis> niemeyer: then we can really go back and hardware the vid/pid in the interface code and name that interface 'zigbee' again
<morphis> s/hardware/hardcode/
<jdstrand> well, it sounds like that PR might then be a springboard for a future discussion, but that leaves zigbee
<niemeyer> morphis: Yes, and we discussed quite a bit those UDEV rules, right?
<niemeyer> morphis: You changed the approach completely on this PR
<morphis> sure, we fixed the udev backend especially for this
<niemeyer> jdstrand: thanks for raising this
<jdstrand> niemeyer: note that morphis didn't do that on his own. we had a long hangout to come up with this. zigbee is a serial-port
<niemeyer> jdstrand: zigbee _has_ a serial port
<jdstrand> I would prefer if we are going to hardcode, perhaps we take a different approach
<jdstrand> maybe add a different attribute to the serial-port interface. eg, type=zigbee
<jdstrand> then we hardcode in the interface what that ends up as
<niemeyer> jdstrand: Not much benefit
<jdstrand> rather than a new interface called zigbee-dongle
<jdstrand> I am very wary of interface clutter
<niemeyer> jdstrand: Well, some benefit actually
<jdstrand> zigbee just isn't used a lot, aiui (morphis please correct me)
<niemeyer> jdstrand: It has the benefit of allowing other serial ports to be used, at the cost of not being able to tell whether a particular device is a zigbee dongle or not, and thus connect things that do not work
<jdstrand> right
<niemeyer> jdstrand: that's not super important in this case
<niemeyer> jdstrand: (the fact it's not used a lot)
<jdstrand> but it also reduces clutter
<jdstrand> and at least keeps the changes in the interface where hotplugging would happen
<niemeyer> jdstrand: we shouldn't add or not add interfaces just based on the number of devices shipping with them.. there are other considerations which are more important on that decision making
<jdstrand> a problem with android for developers has always been that the perms were too confusing
<jdstrand> I'm not saying it is the only consideration. I'm sayingit is a consideration on where its support lies
<jdstrand> a new interface is a bigger thing than an attribute in an existing
<jdstrand> but, most importantly, this zigbee dongle (again, aiui) is a serial port
<niemeyer> morphis, jdstrand: We have a team meeting now..
<jdstrand> and we know we want to hot plug serial ports of all kinds in the future
<jdstrand> and we can assume there will be other serial ports like zigbee
<niemeyer> morphis, jdstrand: Thanks for those details.. I'll go through the whole PR today, think about the possibilities given what we just discussed above, and come back to you
<morphis> niemeyer: thanks!
<jdstrand> so grouping these serial port things into serial-port interface makes sense to me
<morphis> niemeyer: I am open to what ever you come up with, as long as we can support the given use case
<niemeyer> morphis: The use case is a zigbee USB dongle, to be clear, right?
<morphis> niemeyer: yes
<niemeyer> morphis: Ack, thanks
 * ogra shakes fist at googl
<ogra> e
<joc_> niemeyer: note i also have the hidraw PR open which is (fairly) marked as blocked by the serial-port PR - it uses excatly the same approach just for a different device subsystem
<joc_> just in case that provides another angle to the review
<joc_> sergiusens: josepht: i notice that using filesets on parts in SPS doesnt work (filed a bug earlier), $variables don't get expanded, is that a known problem?
 * jdstrand -> errands and lunch
<josepht> joc_: not that I'm aware of.  We'll take a look.
<mup> PR snapd#1746 opened: many: have AuthContext expose device store-id, serial and serial-proof signing to the store <Created by pedronis> <https://github.com/snapcore/snapd/pull/1746>
<mup> PR snapd#1747 opened: Collect attr hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/1747>
<dbarth> hey there, i'm trying to install a new build of snapweb in a kvm snappy instance, but it fails when looking up the snap package.yaml
<morphis> niemeyer: please take joc_'s comment in account, the hidraw interface covers exactly the same problem
<dbarth> the snap has a snap.yaml instead; which component(s) do i need to i need to put in sync?
<kyrofa> dbarth, try installing snapweb from edge
<kyrofa> dbarth, oh wait, are you using 15.04?
<dbarth> yeah, old one
<dbarth> that's probably the issue
<jgdx> any way to do a rebuild of one part and have e.g. prime updated with the new build of that part?
<kyrofa> jgdx, you can use `snapcraft clean <part>` or even `snapcraft clean <part> -s build` if you just want to rebuild that part
<kyrofa> jgdx, then run `snapcraft` again
<jgdx> kyrofa, neat, thanks
<dbarth> kyrofa: i guess i'll go with mvo's latest images
<kyrofa> dbarth, what device are you using?
<dbarth> mostly a kvm, i have a pi2 and pi3 around if that's better
<kyrofa> dbarth, no that's fine, though you know you can use snaps on normal ubuntu as well?
<kyrofa> dbarth, if you want an all-snap image though, yeah, use mvo's
<dbarth> kyrofa: sure ;) but i'd rather stay on the kvm for now
<mup> PR snapcraft#619 closed: Add source-checksum option <Created by tsimonq2> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/619>
<mup> PR snapcraft#661 closed: Added a test Jenkinsfile <Created by elopio> <https://github.com/snapcore/snapcraft/pull/661>
<sergiusens> joc_ it is known now ;-)
<mup> PR snapd#1748 opened: Basic support for validation assertion <Created by ralsina> <Conflict> <https://github.com/snapcore/snapd/pull/1748>
<joc_> sergiusens: good :)
<joc_> sergiusens: out of interest, are there any tests run which build snaps from parts in sps?
<sergiusens> joc_ first another question, wth is sps? :-)
<joc_> sergiusens: hehe i was told that's the official name of the parts service thingy
<sergiusens> joc_ oh, I hope it isn't; SPI was a bad name already and it has been killed ;-)
<natefinch> hey - where do I file bugs on the snap tool itself
<joc_> bugs.launchpad.net/snappy
<natefinch> thanks
<kyrofa> natefinch, see the room title :)
<natefinch> kyrofa: doh, sorry :)
<kyrofa> Err, topic. Whatever it's called
 * sergiusens goes out for lunch
<noise][> parts service is parts service, please don't call it SPS
<icey> why isn't snapcraft installable via snap yet?
<kyrofa> icey, because it need access to the archives. Eventually it'll build inside lxc containers which will enable its snappification
<icey> woot kyrofa!
<mup> Bug #1616508 opened: snap install overwrites its own output <Snappy:New> <https://launchpad.net/bugs/1616508>
<joc_> noise][: i stand corrected, will drop the TLA
<leftyfb> Is there a way to use snapcraft to snap an app that uses an install.sh for it's installation?
<ppisati_> my pull requst failed during the autopkgtest snaps with a
<ppisati_> FAIL timed out
<ppisati_> message repated here and there
<ppisati_> http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-snaps-cloud/371/console
<ppisati_> do any of you know how to grok this>?
<slangasek> zyga: I am not around at 3am... :)  You might have better luck getting the SRU Team member of the day to accept it? https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<kyrofa> leftyfb, yes but you'd need to either wrap it in a build system (e.g. a Makefile that calls the install.sh) or make a local plugin that builds your part
<ogra> jdstrand, so i talked to niemeyer about the kernel snaps during our meeting, seems your warnings are prefectly right and the snapcraft team actually needs to drop all the lines from the "type: kernel" builds
<ogra> jdstrand, sergiusens is looking into that, so once it is there the kernels should just auto-land
<ogra> ppisati_, FYI, i did split the makefile out of the kernel-snap trees, they now all use the same
<ogra> (from a separate bzr tree)
<mup> Bug #1616515 opened: warn uploaders and downloaders when a package or deps has CVEs <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1616515>
<ppisati_> ogra: nice!
<icey> is there currently a plugin / method for snapping a go package that uses gdm for dependency management?
<mhall119> sergiusens: can you remember me how to make snapcraft look for packages from a PPA?
<kyrofa> icey, no, you probably need a new plugin for that-- pull requests welcome!
<kyrofa> icey, note that you can create a local plugin, by the way
<mup> PR snapd#1749 opened: many: split public snapd REST API into separate socket <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1749>
<kyrofa> jdstrand, here is that diff in PR form: https://github.com/snapcore/snapd/pull/1749/files#diff-a34e166c5b3016c122430c5884f41e9b . If you have a minute to take another look at give it a +1 I'd really appreciate it
<mup> PR snapd#1749: many: split public snapd REST API into separate socket <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1749>
<sergiusens> mhall119 add the ppa to your host
<sergiusens> joc_ oh, and yes there are tests
<joc_> sergiusens: in the snapcraft source? should i try and add one with filesets?
<mhall119> sergiusens: that's less than ideal
<mhall119> sergiusens: would you be opposed to me submitting a patch to snapcraft to allow additional archive sources to be added via the snapcraft.yaml?
<mhall119> at least for stage-packages
<mhall119> but build-packages in a cleanbuild environment too perhaps
<mup> Bug #1616507 opened: app names cannot contain underscores <Canonical Click Reviewers tools:New> <Snapcraft:Opinion> <Snappy:New> <https://launchpad.net/bugs/1616507>
<mup> PR snapcraft#753 opened: Add the arm64 architecture to the nodejs plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/753>
<mup> PR snapd#1719 closed: firstboot: add firstboot assertions importing <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1719>
<zyga> slangasek: noted, tank you
<zyga> thank you
<ahasenack> where can I find snappy logs? I installed the snap I'm developing, the service is not starting, I would like to know why
<kyrofa> ahasenack, check syslog
<kyrofa> ahasenack, or use systemctl
<kyrofa> ahasenack, `systemctl status snap.<snapname>.<servicename>.service`
<ahasenack> kyrofa: does the snap, when running a service, become a systemd job?
<ahasenack> hm
<kyrofa> ahasenack, indeed
 * ogra taps foot
<ahasenack> kyrofa: yeah, ok, got it
<ahasenack> can't run squid even as root, it still tries some system call that snappy doesn't like
<ahasenack> Aug 24 13:48:17 nsn7 ubuntu-core-launcher[12191]: /snap/squid-deb-proxy/x3/usr/bin/run-squid.sh: line 24: 12198 Bad system call         $SQUID -z -N -f $CONFIG
<ogra> fchown() most likely
<ahasenack> kyrofa: is there a way to start it as non-root?
<kyrofa> ahasenack, are you familiar with snappy-debug?
<kyrofa> ahasenack, not if it's a service, no
<ahasenack> I don't really need it to start as root, then switch users, as it binds to a high port
<ahasenack> it could start as nobody
<ogra> well, there is currently no way to run it as anything else but root
<kyrofa> ahasenack, in snappy, services are run as root
<elopio> lool: are you using cleanbuild?
<leftyfb> i'm trying to snap rsync. But it doesn't seem to have permissions to write to my home directory
<leftyfb> " failed: Permission denied (13)"
<ogra> did you add the home interface ?
<leftyfb> ogra: not sure what that is
<ogra> https://github.com/ogra1/jtiledownloader/blob/master/snapcraft.yaml
<ogra> plugs: [home, x11, network, network-bind]
<ogra> (allows access to home, x11 and network bits)
<ogra> add "plugs: [home]" to your app definition
<leftyfb> ogra: what about it not allowing in /tmp either? Should there be a plugin for every directory/partition/filesystem?
<ogra> well, a snap has its own /tmp
<ogra> so /tmp is allowed ... but isnt your /tmp
<leftyfb> ogra: right, but if I want to rsync something into or from /tmp
<ogra> thats currently not possible ... you would have to fish it out from the snap dir
<leftyfb> http://pastebin.com/Tz5ijTyZ
<ogra> well, check with snap-debug
<ogra> theer are surely errors in syslog and such
<leftyfb> adding in the home plug works when rsync'ing to and from my home ... so that's good
<sergiusens> mhall119 what would the separation of concerns be wrt how launchpad works if ppa's can be added in snapcraft.yaml? wrt allowing ppa's when doing a cleanbuild, there's a bug for that and just waiting implementation
<sergiusens> mhall119 adding ppa's to the snapcraft.yaml language will get tricky when implementing the source engines as well; I'd rather not do that now regardless of the separation of concerns aspect with launchpad
<sergiusens> joc_ yes, an integration test would be ideal
<joc_> sergiusens: the tests would pull from the real parts service? there isnt a mocked version or something
<mup> PR snapcraft#754 opened: Use in plugin code to remove bad files <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/754>
<mup> PR snapcraft#755 opened: Enable the static checks for the integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/755>
<mhall119> sergiusens: I'm confused, what does launchpad have to do with it?
<sergiusens> joc_ integration tests use mocks, talk to josepht about the details
<sergiusens> mhall119 launchpad allows selecting which PPAs to add when building
<sergiusens> mhall119 as part of the environment setup
<mhall119> oh, I didn't realize that
<mhall119> but only PPAs?
<sergiusens> mhall119 yes, well not sure if anything else is allowed, cjwatson would know best
<mhall119> sergiusens: my plan was to append sources to whatever snapcraft currently gets
<sergiusens> mhall119 and gpg keys?
<mhall119> if launchpad adds PPAs to the host (chroot, container, whatever it is) that would still be used
<mhall119> could be auto-trusted or ignored I suppose....
<sergiusens> mhall119 would the language be clean enough for the day we need to support adding rpm sources?
<sergiusens> mhall119 we fail on unsigned repos today, I don't feel it is a good idea to move away from that
<mhall119> it could be, but that would require more work in the existing snapcraft cod
<mhall119> e
<joc_> josepht: if you could give me some pointers about how to write an integration test for snapcraft to test an aspect of building a remote part that would be great :)
<mhall119> sergiusens: so your source of trust is the fact that it's been added to the host?
<mhall119> I suppose the packaging could include a trust keyring
<mhall119> I wouldn't want to put the keys themselves in the snapcraft.yaml
<mhall119> sergiusens: basically I want to get Qt 5.6 dependencies for qupzilla, and there's no way for me to do that without adding those repos to my laptop and potentially breaking lots of stuff
<sergiusens> mhall119 for now then `lxc launch ubuntu:xenial`
<sergiusens> and work from there
<mhall119> yeah, but that's going to make handing the snap packaging duty over to upstream a more difficult sell
<sergiusens> mhall119 you could build Qt from sources and provide it as a part
<sergiusens> mhall119 also, I am not saying no, I am saying no for the time being
<cjwatson> mhall119: Launchpad itself will only let you configure PPAs, but there's nothing really to stop you adding other sources to snapcraft via the proxy, it's just a bit more manual
<mhall119> I've been told that's not easy, they have a non-standard build setup that our current plugins can't handle
<mhall119> cjwatson: the proxy?
<cjwatson> ok, maybe I shouldn't have mentioned mostly-internal details.  do you actually need an explanation of the internals at the moment?
<mhall119> I'd be happy with a how-to-use-them
<cjwatson> in that case you don't need any information about that :)
<josepht> joc_: There's a fake server here: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/fake_servers.py#L39
<mhall119> so I have an KDE Neon archie I want to pull qt dependencies from
<mhall119> archive
<cjwatson> LP builders can only talk to the outside world via an HTTP proxy (which is only available for snap builds, not other kinds of builds), but that's configured in the http_proxy environment variable and sane stuff (including apt) will honour that
<cjwatson> I don't really have an opinion on how it's configured in snapcraft.yaml etc. as long as the LP configuration mechanism keeps working
<sergiusens> mhall119 with what cjwatson says, you could get away with a custom snapcraft plugin that does something similar to what we do with the catkin one
<mhall119> okay...but how do I use that to tell snapcraft to get packages from an archive that's not installed in the build environment?
<sergiusens> you would not be supported in that path forever, but it will get the job done
<josepht> joc_: we're using something similar for the parser tests here: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/test_parser.py#L633
<mmcc> Hi folks, I am trying to snap a very simple Makefile based project, with one twist- the Makefile is generated by running perl on a Makefile.PL. Is there an easy existing way to tell snapcraft to do that before running make? Or do I need to add a 'pre-command' to the make plugin or something?
<sergiusens> tealeg hey, when do we get to see your plugin? :-)
<nacc> mmcc: i dont' think there is a trivial way; but you could, i think, write your own plugin (pretty easily) that inherits form the make one, and only overrides build() to call perl Makefile.PL first then super.build() ?
<nacc> mmcc: that plugin would go in parts/plugins/ in your snapcraft directory
<nacc> mmcc: and then your yaml would just refer to it
<mmcc> ah ok, that's 'local plugins' then. I saw a reference to that earlier. thanks
<nacc> mmcc: yeah
<josepht> joc_: though the fakes might not work in this case, you can also output you're own local copy of parts.yaml to ~/.local/share/snapcraft/parts.yaml and then call build
<nacc> mmcc: there might be a better way, but that's what i've done in the past when a makefile doesn't quite conform to the generic `make; make install` template
<mmcc> nacc, thanks!
<nacc> mmcc: np, i would also consider filing a bug report/feature request. I think there might already be one (so search first), for the notion of -- use this plugin, but do this one step first :)
<joc_> josepht: ok thanks, i'll try and put something together based on that tomorrow, the parts.yaml file should be enough as I don't see anything wrong with the contents of that when i've tried this
<mmcc> nacc: ok, I'll look. TBH I'm a little surprised that there isn't a generic 'shell' plugin, where I could put one command and then have my 'make'-based part run after it. Is that a conscious design decision?
<nacc> mmcc: probably? i'm not aware of those level of decisions :) the thing is such a plugin doesn't really make sense -- in that it'd have to take parameters which are arbitrary commands. It seems like it would become less useful (and prone for bad c&p and not using of good parts)
<leftyfb>  /snap/bin/rsync-leftyfb.rsync ... how do I get rid of that .rsync at the end?
<nacc> leftyfb: it's a naming thing, iirc
<Pharaoh_Atem> zyga: snap-confine is on its way to stable for f24
<nacc> leftyfb: if your snap and app name are the same, it magically drops the . naming
<nacc> leftyfb: but since your snap is called rsync-leftyb, it puts it in a sort-of namespace
<leftyfb> ah, I see
<nacc> leftyfb: i think there is a feature open, or something, to allow for specifing the naming, but i don't have bug # handy
<leftyfb> bingo, got it, thanks
<Pharaoh_Atem> zyga: also, any luck on the patches for moving /snap?
<Pharaoh_Atem> and it looks like someone left a comment for you to address in the review for snapd
<jgrimm> mmcc, nacc: fwiw: https://github.com/snapcore/snapcraft/pull/727
<mup> PR snapcraft#727: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <https://github.com/snapcore/snapcraft/pull/727>
<nacc> jgrimm: :) thanks!
<jdstrand> ogra: re kernel and reviews tools> ack
<nacc> jgrimm: i would almost suggest to Magical-Chicken that perhaps such a plugin should only be available in devmode (based upon e.g. monsterjamp's comment from 7 days ago)
<nacc> jgrimm: i've been thinking about that more lately, there are some things that are 'sane' in the context of trying to get going, but aren't necessarily sane in a GA/stable version
<nacc> jgrimm: e.g., testing hooks? maybe the shell app i have a bug filed for (so you can debug by dropping to your snap's environment)
<leftyfb> ok, so how do I go about publishing a snap of say, rsync so others can find it just by using the name "rsync" and not -leftyfb? Can I just remove -leftyfb from the name or do I have to go through some process?
<nacc> leftyfb: you probably need to register the name, yeah
<leftyfb> that's it?
<leftyfb> bah, it's reserved
<jdstrand> kyrofa: done
<nacc> leftyfb: you'd probably need to rename your snap to 'rsync', as well
<nacc> leftyfb: yeah, i'd expect it to be :)
<leftyfb> nacc: so we have to wait for all the original developers of applications to publish their own apps?
<nacc> leftyfb: no, but i think they reserved some common names in order to not let random folks camp on them
<leftyfb> ok, now this is kinda silly. Everything we upload gets .leftyfb added to the end of it. But I can't just upload "rsync" and have it turn out rsync.leftyfb because "rsync" is already taken. So I have to name it "rsync-leftyfb" which then also puts .leftyfb at the end of it making it "rsync-leftyfb.leftyfb".
<kyrofa> jdstrand, hey thanks!
<kyrofa> leftyfb, name the app the same as the snap, and you can just call it rsync-leftyfb
<mup> PR snapcraft#756 opened: Use block style for multiline YAML values <Created by josepht> <https://github.com/snapcore/snapcraft/pull/756>
<leftyfb> kyrofa: I had that. But when I uploaded it and tried to publish it it added .leftyfb to the end of rsync-leftyfb
<kyrofa> leftyfb, then did you try to install it from the store again? It should install as rsync-leftyfb
<kyrofa> Regardless of the store showing the .leftyfb
<kyrofa> leftyfb, well wait-- which series are we talking about?
<ogra> jdstrand, sergiusens with a patched snapcraft in the PPA like http://paste.ubuntu.com/23085847/ i now have end to end kernel snap builds and auto-uploads fully working
<leftyfb> kyrofa: series?
<kyrofa> leftyfb, when you upload the snap, which series did you select? 15.04 of 16?
<kyrofa> or*
<leftyfb> kyrofa: nowhere during the snapcraft upload process or the web ui publish process did it ask for a series
 * ogra refreshes to the new pi2-kernel snap ... lets see if it also boots now :)
<kyrofa> leftyfb, ah, 16 then. So yeah, did you try actually installing the one you published?
<leftyfb> about to
<leftyfb> kyrofa: ok, that worked
<kyrofa> leftyfb, in 15.04 snaps were snapname.publishername, so what you're seeing there might be a store leftover
<jgrimm> nacc, snappy-debug mentioned here: http://askubuntu.com/questions/783979/how-do-i-debug-snaps
<nacc> jgrimm: thanks
<tealeg> sergiusens: re the plugin - I've not seen any progress on the 32bit kernel calls that would effect SBCL and CCL - I do have a version working with GNU CLisp, but that is slightly less useful because a few key libraries don't play well with CLisp.
<tealeg> sergiusens: I could certainly bring the current state to the point where I could submit a pull request.
<natefinch> btw, I can't run any snaps: https://bugs.launchpad.net/snapcraft/+bug/1616586
<mup> Bug #1616586: all snaps report "multiple nvidia drivers detected, this is not supported." <Snapcraft:New> <https://launchpad.net/bugs/1616586>
<newsages> hola
<ogra> natefinch, duplicated
<ogra> (check the one i duplicated it against, there is an explanation and a workaround)
<newsages> como se crea una lib snap  para poder reutilizarla entre snaps?
<natefinch> ogra: lol, bogus indeed.
<ogra> :)
<ogra> zyga, is bug 1615248 yours ?
<mup> Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus <Snappy:New> <https://launchpad.net/bugs/1615248>
<ogra> or who maintains ubuntu-core-launcher nowadays
<mhall119> sergiusens: I know about $SNAPCRAFT_STAGE, is there another env var I can use to point to parts directories?
<natefinch> ogra: gotta say, I am not going to fiddle with any nvidia folders by hand.  Every time something mucks with my drivers, I end up spending most of a day in a command prompt trying to figure out what broke X.
<mhall119> or a way for partA to copy files from partB into the stage/prime area?
<ogra> natefinch, well ... dpkg -l |grep ^ii| grep nvidia-[0-9]
<mup> PR snapcraft#755 closed: Enable the static checks for the integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/755>
<ogra> natefinch, thats should be the only drivers in use
<ogra> (i assume it will only return one)
<ogra> all other dirs can be deleted
<natefinch> ogra: yeah, it only returns one, and that is the one with far more files in it (the other one only has two, presumably just cruft)
<ogra> yeah, you can safely delete them
<jdstrand> ogra: to be clear, you are talking about this warning: unknown entries in snap.yaml: 'dtbs,firmware,initrd,kernel,modules' lint-snap-v2_unknown_field
<lazyPower> woo first snap works \o/
<ogra> jdstrand, exactly ... i patched the image PPA snapcraft to not add them and the store just auto-approved all my builds
<jdstrand> nice
<lazyPower> next question i have, i've seen asked before but not answered, and i fear i know the ansewr. Is there a docker snap with a plug that i can use? I'm cycling towards snapping up kubernetes, and this is going to be a very complex snap
<jdstrand> I like that solution. I don't have to do anything :)
<ogra> jdstrand, well, sergiusens does :)
<newsages> How does one create a library for reuse between snaps ?
<tvoss> newsages: you create the library and make it accessible via snapcraft parts (see https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-parts/)
<natefinch> ogra: btw, renaming that spurious nvidia directory does fix the problem
<ogra> note that in the bug :)
<natefinch> ogra: I was on my way there :)
<ogra> :)
<tuxiano> Hi I installed darktable using snappy. Now I have issues opening files stored outside of my home directory (on a nfs drive). Is it somehow possible to extend the permissions of a snap app so that it can open such files.
<tuxiano> Same problem with vlc, too.
<arges> i'm testing snapd 2.13, which has a new interface 'kernel-module-control'. Besides installing the new package what else is required to make this interface visible? 'snap interfaces' doesn't show it, but a strings /usr/lib/snapd/snapd shows it existing in that binary
<ahoneybun> I had a good idea mhall119 lol
<kyrofa> arges, a snap that provides the slot, probably
<arges> kyrofa: i have this, but I get "has bad plugs or slots: kernel-module-control (unknown interface)" when trying to install the test package
<lool> elopio: no I'm not
<kyrofa> arges, it might be re-executing an older snapd from within the core snap
<mhall119> ahoneybun: snap find --channel=beta?
<mhall119> yeah
<elopio> lool: I'm having tons of different problems. I get less if I use cleanbuild.
<lool> elopio: I think the issue is in the gulp plugin; it expects gulp is installed in its own private dir
<kyrofa> arges, try running both the server and client with SNAP_REEXEC=0
<arges> kyrofa: ok i'll try that
<lool> elopio: I will try this, but lxd is a bit heavy for the rpi
<elopio> lool: while we solve the problems with snapcraft.yaml and launchpad, I quickly reverted to get the previous multiarchitecture build, so I have the 4 snaps uploaded to the store and waiting for a manual review.
<lool> it's not heavy in itself, but it's a lot of extra io
<lool> elopio: oh cool
<elopio> lool: the problem is now that the snap doesn't start, saying that ubuntu-app-launch failed to execv
<mup> Bug #1616605 opened: Cannot open files from NFS drive <Snappy:New> <https://launchpad.net/bugs/1616605>
<elopio> so I have like 3 workarounds, but none of them is easy to get finished.
<tuxiano> Just added a bug report: https://bugs.launchpad.net/snappy/+bug/1616605
<mup> Bug #1616605: Cannot open files from NFS drive <Snappy:New> <https://launchpad.net/bugs/1616605>
<lool> elopio: OMG
<elopio> lool: let me upload the snaps to my ftp so you can take a look.
<arges> kyrofa: still doesn't work
<lool> elopio: what's the startup issue?
<kyrofa> tuxiano, yes, we see that ;)
<kyrofa> arges, dumb question, but you're sure the kernel interface is in 2.13?
<arges> $ git tag --contains a22b514513c020673b290e3dd723d0bbe9a496ad
<arges> 2.13
<arges> https://github.com/snapcore/snapd/commit/a22b514513c020673b290e3dd723d0bbe9a496ad
<arges> kyrofa: ^^ yes
<arges> kyrofa: sudo /lib/systemd/systemd-activate -E SNAPD_DEBUG=1 -E SNAP_REEXEC=0 -l /run/snapd.socket /usr/lib/snapd/snapd
<arges> that worked ^^
<kyrofa> arges, ah, you only ran the client with SNAP_REEXEC?
<arges> kyrofa: I wasn't passing the enviornment variable correctly into snapd, so I just manually executed like that
<kyrofa> Ah, okay
<arges> so will I just need to wait until ubuntu-core is updated with the snapd then?
<arges> * with snapd 2.13 that is
<zyga> ogra: perhaps, checking
<kyrofa> arges, indeed. mvo or ogra might be able to move that along
<ogra> kyrofa, ?
<kyrofa> ogra, get the new snapd in a core snap soon
<mup> Bug #1615248 changed: ubuntu-core-launcher nvidia driver detection is bogus <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1615248>
<kyrofa> That came out commanding, I meant to just define what "that" was :P
<kyrofa> But yes, ogra, do as I say
<ogra> heh
<elopio> lool: http://paste.ubuntu.com/23086044/
<ogra> well, we build the daily snnap from the images PPA
<kyrofa> ogra, does that automatically go to edge nowadays?
<ogra> err
<ogra> the edge PPA
<elopio> lool: http://people.ubuntu.com/~elopio/snaps/
<lool> elopio: is that with --devmode?
<lool> elopio: thanks
<elopio> lool: no, without.
<ogra> yes, every UTC morning :)
<ogra> kyrofa, seems snapd failed to build https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages
<kyrofa> elopio, journalctl -u snap.snapweb.snapweb.service might be more helpful
<lool> elopio: I'll check it out tomorrow, thanks
<ogra> elopio, why does that only have 2.12 ^^ ?
<lool> elopio: I'm finishing lxd setup on rpi and kicking a cleanbuild
<mup> Bug #1616515 changed: warn uploaders and downloaders when a package or deps has CVEs <Snapcraft:Opinion> <Snappy:New> <https://launchpad.net/bugs/1616515>
<elopio> kyrofa: that's what I pasted.
<kyrofa> elopio, oh, that looked like status. That's all it gives you? Meh
<elopio> lool: same error with devmode.
<ogra> kyrofa, elopio is that bug 1610026 you are talking about ?
<mup> Bug #1610026: snapweb fails to start after reboot <snapweb:Confirmed> <https://launchpad.net/bugs/1610026>
<lool> elopio: ok, check dmesg for apparmor denials, if nothing then it's likely a missing +x or an unreadable data file somewhere
<elopio> ogra: no, that one happens with the one in the store. If I do snap install snapweb --edge, it starts here.
<lool> ogra: I believe this is another one
<ogra> ah, k
<ogra> kyrofa, arges, well, snapd comes from daily builds in https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages ... so as soon as 2.13 will show up there it will be in the ubuntu-core snap
<elopio> lool: yes, that sounds likely because the snap that I build from master using snapcraft starts. So something that snapcraft does that the build script doesn't.
<arges> ogra: ok good to know! thanks
<elopio> I'm just not sure which workaround to pursue now :S
<kyrofa> ogra, edge only though, right?
<ogra> kyrofa, well, mvo promotes them currently, we do not re-build
<ogra> (that will change once the PPAs are cleaned out)
<mup> PR snapd#1750 opened: store: request device session macaroon from store <Created by matiasb> <https://github.com/snapcore/snapd/pull/1750>
<ogra> so the edge package also ends up in the stable ubuntu-core currently
<lool> elopio: I'll poke it more tomorrow; I might have to go through the same pains you did, but I guess there is no alternative to debug this
<lool> or I could try running your snaps directly
 * lool EODs &
<elopio> lool: oh, it started!
 * ogra goes afk for a while too
<kyrofa> elopio, he's gone, sorry, you failed for today
<kyrofa> ogra, so they don't go into any channel by default?
<elopio> :'(
<elopio> kyrofa: he's gone too.
<kyrofa> Argh, europeans
<elopio> they stop working at lunchtime. We should move there :)
<kyrofa> Yeah that sounds nice
<elopio> nessita or noise][1: does it make sense for snapweb to require a manual review before I can publish it on edge?
<mup> PR snapd#1704 closed: snap: add key management commands <Created by cjwatson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1704>
<jdstrand> kyrofa: hey, otoh, if I found a bug in the desktop part, would I file that against snapcraft?
<sergiusens> jdstrand an issue on the github upstream maybe?
<nessita> elopio, hi! you mean there was an upload requiring manual review?
<jdstrand> sergiusens: ok, thanks
<sergiusens> jdstrand just trying to avoid more bugs :-)
<elopio> nessita: well, yes, I'm pushing packages there. But the idea is to make an upload for every change in master through launchpad, so that will be a lot of slow manual reviews and breaks the purpose of rapidly changing edge
<nessita> elopio, what's the error you are having?
<jdstrand> sergiusens: do you know where that is otoh?
<elopio> nessita: no error. It uses the snap-control interface which is restricted.
<nessita> elopio, right, so once we have the proper assertions per snap in place, we will be able to state "privileged interfaces" per snap in said assertion
<nessita> and that will be fed to c-r-t
<nessita> so manual review will not be required
<sergiusens> jdstrand https://github.com/ubuntu/snapcraft-desktop-helpers `snapcraft define <part-name>` should tell you as well iirc
<nessita> elopio, until then, you will need a +1 from a reviewer
<nessita> elopio, privileged interfaces is GA, so not far :-)
<jdstrand> sergiusens: thanks! 'define' tells me cool stuff but not the project or where to report bugs
<jdstrand> sergiusens: (fyi)
<elopio> nessita: alright, that sounds good. Could the assertion be only for edge? I think I would need a signature from the security team to push to stable in some cases.
<nessita> elopio, hummmmmmm good question, I think no, the assertion is per snap. Note that there is no way to restrict a snap revision to be publish in extra channels after approval
<mup> PR snapd#1751 opened: tests: add workaround for u-d-f to unblock all-snap image tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1751>
<sergiusens> jdstrand the 'source' could be an indication; but this is actually a good point, we should expose `origin` there :-)
<elopio> nessita: it might be fine. I can be trusted to ask for a review before moving the snap, but it would be great if this could be crypto enforced.
<elopio> nessita: so this means https://bugs.launchpad.net/software-center-agent/+bug/1580371 doesn't make sense anymore, right?
<jhodapp> I can't figure out why snapcraft can't find the test-client binary after building it, here's my snapcraft.yaml: http://pastebin.ubuntu.com/23086181
<nessita> let me check
<sergiusens> jhodapp might be related to your .pro file there
<sergiusens> jhodapp is the test-client in stage or prime?
<sergiusens> or even inside parts/test-client/install ?
<jhodapp> sergiusens, I only see it under part/test-client/build
<nessita> elopio, well, it makes sense a request, is just that our solution for it is the one using assertions instead of special-casing inside the source code
<jhodapp> *parts
<nessita> elopio, let me add a comment in there
<elopio> nessita: thanks. It is indeed a lot better than what we discussed before.
<elopio> nessita: and another question while that gets implemented. I pushed a snap and it's waiting in the manual review queue. Then I pushed a new version. Is there a way to cancel the first review? Or will the reviewers just ignore it?
<lool> elopio: oh cool, how did it start?
<lool> elopio: my cleanbuild failed :-(
<lool> elopio: http://paste.ubuntu.com/23086213/
<elopio> lool: the revert was missing a chmod +x, as you suggested.
<lool> cool
<elopio> lool: try the snaps from my ftp.
<nessita> elopio, I don't know for sure, let me check
<elopio> I will test in rpi2 after lunch.
<jhodapp> sergiusens, any ideas?
<mup> PR snapd#1752 opened: tests/main/ack: fix test/style <Created by pedronis> <https://github.com/snapcore/snapd/pull/1752>
<sergiusens> jhodapp is you `make install` dtrt wrt that PREFIX you set?
<lool> elopio: awesome, your snaps work fine!
<jhodapp> sergiusens, dtrt wrt?
<sergiusens> jhodapp do the right thing with regards to
<elopio> kyrofa: you see, I won!
<jhodapp> sergiusens, I believe it does, let me double check that
<elopio> luckily that means I don't have to solve all the bugs I collected and can get back to testing :)
<sergiusens> elopio please check the nodejs armhf one though :-)
<mup> PR snapd#1752 closed: tests/main/ack: fix test/style <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1752>
<sergiusens> elopio and the proxy one!
<elopio> sergiusens: the proxy is solved. It's building.
<jhodapp> sergiusens, do you mean from the parts dir or building test-client manually on its own?
<sergiusens> elopio +1 it then please :-)
<elopio> sergiusens: oh wait, you mean the https env var. I had already forgotten about that one.
<sergiusens> jhodapp does make install DESTDIR=/some-path work for this?
<sergiusens> for that project
<elopio> I think I know how to reproduce it without launchpad. Let me see...
<sergiusens> I am no qmake expert though
<mup> PR snapd#1728 closed: asserts: add a key-proof assertion <Blocked> <Reviewed> <Created by cjwatson> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1728>
<sergiusens> lool when are you joining the league of snapcrafters?
<sergiusens> ;-)
<jhodapp> sergiusens, let me check
<jhodapp> sergiusens, hmm, one problem might be that make install doesn't really seem to ever have anything to do
<mup> Bug #1616629 opened: could not unmarshal state entry "snap-type" <Snappy:New> <https://launchpad.net/bugs/1616629>
<jhodapp> sergiusens, yeah that's definitely the issue...the install target is messed up...ugg qmake :)
<nessita> elopio, sorry, I got distracted. I'm looking at snapweb details right now
<nessita> elopio, many revnos with red exclamation mark
<nessita> your question was.../
<nessita> ?
<nessita> (I see a warning of "
<nessita> (NEEDS REVIEW) 'snapd-control' requires approval lint-snap-v2_blacklist (snapweb, snapd-control)
<nessita> ")
<elopio> nessita: there are some revisions that I don't need reviewed, because I pushed newer. My question was how to tell about this to the reviewers.
<nessita> elopio, if you go to a revno detail do you see any button action at the bottom?
<nessita> like https://myapps.developer.ubuntu.com/dev/click-apps/5455/rev/14/
<elopio> nessita: no buttons.
<nessita> elopio, then no, sorry. I'm happy to reject as many revision as you instruct me
<elopio> nessita: I just need the last 4.
<elopio> one per arch.
<nessita> ok, let me reject 10 and below
<nessita> elopio, done
<elopio> thank you
<nessita> \o/
<nessita> jdstrand, so, how can we (store folks) know when is OK to approve some interface usage such as the one requested by elopio? (
<nessita> (NEEDS REVIEW) 'snapd-control' requires approval lint-snap-v2_blacklist (snapweb, snapd-control)
<nessita> )
<elopio> sergiusens: I can't test the nodejs thing. It's not what I thought and scalingstack uses only http proxy.
<elopio> sergiusens: furthermore, I don't understand. If I have an http_proxy=foo and https_proxy=bar, the workaround makes no sense. It will use https through my foo proxy.
<cmars> just noticed that the copy plugin is deprecated and it recommends "dump". seems to take a different configuration, how do i port it over?
<josepht> cmars: I've got a basic example here: https://git.launchpad.net/~joetalbott/+git/dump_example/tree/snapcraft.yaml
<kyrofa> josepht uses too many usernames
<cmars> josepht, thanks. I was using the files: attribute on the copy plugin to compiled artifacts in my project directory to the snap... how do I do that with dump?
<kyrofa> I keep trying to type @josepht on github
<cmars> josepht, is organize: doing the mapping that files: used to?
<mup> Bug #1616650 opened: snap refresh while command is running may cause issues <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616650>
<josepht> cmars: if you just want to get a copy you can include it in 'stage' option (and maybe 'snap')
<josepht> cmars: I'm using 'organize' to change the name of a file and then 'stage' and 'snap' to copy it into those partws
<josepht> *parts
<josepht> kyrofa: I'm 'josepht' on github :)
<cmars> josepht, ok, got it working, thanks!
<josepht> cmars: awesome! no problem
 * josepht -> dinner
<kyrofa> josepht, oh yeah, searching for you to assign bugs then :P
<mup> PR snapcraft#753 closed: Add the arm64 architecture to the nodejs plugin <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/753>
<sergiusens> elopio have you checked https://github.com/npm/npm/issues/2050
<sergiusens> elopio specifically the last comment
<sergiusens> elopio your suggestion is the same one we had for bzr
<sergiusens> have something external dtrt
<mup> Bug #1616657 opened: snapd install removes Unity launcher-compliant entries <Snappy:New> <https://launchpad.net/bugs/1616657>
<sergiusens> kyrofa want to look at snapcraft#754
<mup> PR snapcraft#754: Use in plugin code to remove unwanted files <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/754>
<sergiusens> ?
<sergiusens> kyrofa what are your thoughts on LP: #1616656 ?
<mup> Bug #1616656: intermittent failure to load correct plugin when a local plugin is a subclass of existing plugin <Snapcraft:Triaged> <https://launchpad.net/bugs/1616656>
<sergiusens> kyrofa hmm, maybe wait for my email reply to make it to the bug :-P
<kyrofa> Hahaha
<sergiusens> kyrofa there we go
<sergiusens> kyrofa but you are distracted reviewing my PR I suppose
<sergiusens> ;-)
<kyrofa> sergiusens, yeah I don't really have any good ideas there simply because I don't know python well enough. We need to research it
 * kyrofa -> dinner break, back in a bit
<nacc> kyrofa: sergiusens: have you asked barry about that? he'd be my goto python person :)
#snappy 2016-08-25
<ogra> kyrofa, they go into edge daily and after manual testing into stable ... in the future we will have different builds for different channels, today edge is the same as stable, just untested
<mup> PR snapcraft#757 opened: Export important project variables <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/757>
<sergiusens> kyrofa https://github.com/snapcore/snapcraft/pull/757 tell me what you think
<mup> PR snapcraft#757: Export important project variables <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/757>
<sergiusens> elopio ^
<liuxg> elopio
<liuxg> elopio, ping
<liuxg> previously, on 15.04 ubuntu core, I used the command "sudo snappy hw-assign piglow.sideload /dev/i2c-1" to assign the hw to access the i2c device. On the series 16, we need to use interface, how can I assign the hardware? thank
<liuxg> does anyone know how to assign a hw on series 16? I used to do on 15.04 like "sudo snappy hw-assign piglow.sideload /dev/i2c-1". thanks
<kyrofa> liuxg, no such capability exists right now. It will probably utilize hooks in some fashion, which also don't exist right now :)
<kyrofa> liuxg, that said, you can access to some things via interfaces, as long as the paths don't change
<liuxg> kyrofa, in that case, I cannot do anything for the moment. I want to get the piglow working. my app is running, but it does not access the hardwware.
<liuxg> kyrofa, thanks for your reply on this.
<kyrofa> liuxg, take a look here: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<kyrofa> Do any of those cover your use-case?
<liuxg> kyrofa, for the i2c-1 device, it seems that it is not covered there. also for the current raspberry pi 2 device, the interfaces are http://paste.ubuntu.com/23087199/. previously, on 15.04, it seems to be more dynamic. as long as the device is available, we can always do the assignment.
<kyrofa> liuxg, yeah, we'll get there
<liuxg> kyrofa, so, there will be a way to do that right? I think it should be generic instead of defining an interface for every device on the system. For example, I want to make use of the camera, the camera is there, but we cannot forecast how many more devices are there. on the contrary, the one on 15.04 is more flexible, and the command works for all
<kyrofa> liuxg, I can't speak for the overall design, but things will definitely get more flexible with hooks
<mup> PR snapcraft#738 closed: nodjs, gulp plugins: use http_proxy to connect npm registry <Created by m-shibata> <Closed by m-shibata> <https://github.com/snapcore/snapcraft/pull/738>
<mup> PR snapd#1753 opened: asserts: Add an account-key-request assertion <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1753>
<mup> PR snapd#1754 opened: tests: fix "tests/main/ack" to not break if asserts are alreay there <Created by mvo5> <https://github.com/snapcore/snapd/pull/1754>
<mup> PR snapd#1754 closed: tests: fix "tests/main/ack" to not break if asserts are alreay there <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1754>
<zyga> o/
<mwhudson> morning zyga
<mup> PR snapd#1755 opened: tests: remove snap confine workaround <Created by mvo5> <https://github.com/snapcore/snapd/pull/1755>
<ogra> ubuntu@dragonboard:~$ snap --version
<ogra> snap    2.12+ppa199-1
<ogra> snapd   2.12+ppa199-1
<ogra> series  16
<ogra> ubuntu  16.04
<ogra> mvo, ^^^^ is that right ?
<ogra> (i see 2.13+ppa206-1 on rpi)
<zyga> mwhudson: good morning
<zyga> mwhudson: I'm working on the namespace sharing feature in snap-confine
<zyga> mwhudson: interested in reviewing the idea?
<mvo> ogra: looks wrong, we should be on snapd 2.13
<mvo> ogra: I can have a look in a bit to ensure we really have 2.13 (or 2.13+something)
<mvo> ogra: did the /etc/systemd/system.conf.d dir make it?
<ogra> well, i just did an ubuntu-core rebuild since i thought it was a glitch in the edge PPA ...
<ogra> yeah, the dirs are in
<ogra> ("user" too)
<mvo> ogra: yay!
<mvo> ogra: thanks a bunch, plano people will love you for this
<ogra> mvo, there you go https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra> doesnt build for all arches
<ogra> (only amd64, armhf and i386)
<mvo> ogra: oh, meh :(
<ogra> mvo, i changed the arch list for that PPA, but s390x is missing yet ... (i guess i need to ping the LP team)
<ogra> mvo, do you know how we can trigger a build ?
<mvo> ogra: cool, I think thats not too terrible
<ogra> mvo, oh, and btw, kernel snap builds work end to end too now, incvluding auto-upload and publishing (with a hacked snapcraft in the PPA though)
<newcomer25> The whole Law is fulfilled in one statement: âYouâll love your neighbour as much as yourselfâ - Galatians 5:14
<newcomer25> God bless you all and have fun using snappy!
<ogra> what was that ?
<mup> PR snapd#1756 opened: asserts: add some stricter checks around format <Created by pedronis> <https://github.com/snapcore/snapd/pull/1756>
<mvo> ogra: yay
<mup> Bug #1616833 opened: need new interface: time-hardware <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616833>
<mup> Bug #1616834 opened: need new interface: time-adjust <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616834>
<cpaelzer> is there a "show me the generated apparmor and seccomp profile" shortcut - like being in tempfiles or even a command to show them?
<youmin> Hi, I tried to disable getty on tty1 with: systemctl disable getty@tty1.service but it doesn't work, of course, previously I remounted filesystem on write mode. Ideas?
<youmin> sorry,  but is anybody there
<youmin> ?
<mup> PR snapd#1755 closed: tests: remove snap confine workaround <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1755>
<ogra> youmin, only 290 people, why ?
<cpaelzer> youmin: sure there are, but most are busy hacking and only loock sometimes on chat :-)
<youmin> ok, sorry... but I think I have a simple issue
<youmin> when I disable getty on tty1 and I restart the system my configuration is lost, and of course I remounted the root partition
<youmin> anybody has ideas about why?
<cpaelzer> youmin: I can only speak for myself that I don't know the answer - sorry - how is that snap related, do you do that from "iniside" your snap?
<youmin> yes, I'm using dell gateway with snap
<cpaelzer> I'm afaraid you need to highlight a few more experienced users that can help or point you further - ogra zyga ^^ ?
<ogra> cpaelzer, no idea about that, i would have to dig deep into ancient code, the dell gateways still run 15.04 i think
<ogra> youmin, you could try to manually depete /etc/systemd/system/getty.target.wants/getty@tty1.service
<ogra> *delete
<youmin> orga: I did it, but I don't know why it appears again
<ogra> elopio, can you trigger a snapd build in the edge channel, we just noticed it never built for all arches, i cahcnged that but dont know how to triggera build for the missing ones
<philroche> I have created a snap for fswebcam (https://launchpad.net/ubuntu/+source/fswebcam) but it is a reserved name. I am not the project maintainer. Should I request the reserved name and transfer later if the maintainer wishes or use a new unique name like philroche-fswebcam?
<Son_Goku> zyga: ping
<mup> PR snapd#1746 closed: many: have AuthContext expose device store-id, serial and serial-proof signing to the store <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1746>
<mup> PR snapd#1756 closed: asserts: add some stricter checks around format <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1756>
<zyga> Son_Goku: hello
<zyga> Son_Goku: I saw your review, thank you
<zyga> Son_Goku: I will do an upstream release rather than to switch to a snapshot if I can avoid it
<Son_Goku> zyga, also how are the patches coming for moving /snap?
<zyga> Son_Goku: yes, all done, I just need to merge them upstream
<Son_Goku> hit the green button already then :P
<zyga> Son_Goku: then I'll combine them into one patch to ship before the next release
<zyga> Son_Goku: we just released last night but not everthing landed yet
<zyga> Son_Goku: my patches are just for tests, everything else shoud be easy
<zyga> Son_Goku: I need to look at snap-confine next, that is still a TODO
<zyga> Son_Goku: but today I need to finish one feature (small but important), so I'm looking at snap-confine 1.0.41 and snapd 2.14 as the fedora target :)
<Son_Goku> cool
<notadeveloper> hi
<cpaelzer> notadeveloper: ho
<notadeveloper> hi cpaelzer
<mup> PR snapd#1743 closed: many: use make StripGlobalRootDir public <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1743>
<mup> PR snapd#1738 closed: tests: the stable ubuntu-core snap has snap run support now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1738>
<mup> PR snapd#1751 closed: tests: add workaround for u-d-f to unblock all-snap image tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1751>
<icey> I've uploaded a snap to myapps.developer.ubuntu.com (yesterday afternoon, 16 hours ago?) but can't snap install it yet; it's in devmode so I'm trying to install it with --beta but all I keep getting is snap not found
<icey> how does one add dependencies (curl) to a plugin?
<mup> PR snapd#1757 opened: asserts: authority-id and brand-id of serial must match <Created by pedronis> <https://github.com/snapcore/snapd/pull/1757>
<ogra> icey, are you installing with --beta or with --devmode ?
<icey> orga the snap is (I think) published on the beta channel
<ogra> so you need both then
<ogra> (you pshould know which channel you published to though ... the UI shows it on myapps...)
<icey> ok, it finds it now, but I get a 401 when downloading :)
<ogra> that sounds like a bug ... is it actually published ?
<icey> myapps.delevelop.. says yes
<icey> ogra: ^
<ogra> whats the package name ?
 * ogra will try to confirm your error
<icey> ogra:  rust-coreutils
<ogra> icey, looks fine to me http://paste.ubuntu.com/23088826/
<icey> ogra: maybe I just tried too fast?
<ogra> (apart from the fact thet the daemon cant start)
<icey> ogra: shouldn't be a daemon :) I'm working through my first snap :)
<icey> gah I stillg et a 401
<ogra> well, the systemd units :)
<ogra> are you behind a proxy ?
<icey> ogra: https://paste.ubuntu.com/23088828/
<icey> shouldn't be behind a proxy
<ogra> icey, hmm, are you logged in (note that i am not and used sudo)
<ogra> perhaps thats the deifference
<icey> I am logged in, and no sudo
<icey> so almost exactly different :-P
<icey> let me pop up a container
<ogra> well, just use sudo
<ogra> i guess that simply overrides the liogin
<icey> seems happy when not logged in, as root
<icey> ogra:
<ogra> so there is something with the login credentials then i guess
<ogra> not sure whom you need to poke for this
<icey> ogra: I'll just raise a bug :)
<ogra> yeah
<morphis> niemeyer: ping
<icey> that's why I'm snapping things anyway eh :)
<mvo> pitti: can you help with a netplan question? https://github.com/snapcore/snapd/pull/1731/files#diff-52d12b07d34f6f20ac6190c87c325f8eR52 is the config what we generate (mwhduson to be precise), I use that and boot the system but no eth0 is coming up, how can I debug this? I fixed the verison:2 line?
<mup> PR snapd#1731: firstboot: generate netplan config rather than ifupdown <Blocked> <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1731>
<pitti> mvo: I already replied to mwhudson about that
<mvo> pitti: oh, ok. where can I read that reply?
<pitti> oh, he fixed the bad "dhcp4:"
<pitti> mvo: oh, good point, that's another bug; "ethernets:" is on the same level as "version 2:"
<pitti> mvo: easiest to just run "netplan generate" in the system and walk through the error messages
<mvo> pitti: cool, thanks, that was all I needed
<mvo> pitti: test is running now and will drop me in a debug shell in a minute, will figure it out, thanks for your help
<mvo> pitti: yay, just the indent
<pitti> mvo: Yet Another Moaning Language :)
<ogra> switch to ini :P
<mup> PR snapd#1758 opened: Use netplan <Created by mvo5> <https://github.com/snapcore/snapd/pull/1758>
<pitti> ogra: and call them .network!
<ogra> !
<zyga> jdstrand: hey
<zyga> jdstrand: around?
<zyga> tyhicks: or you? :)
<ogra> mvo, that snapd package in the image PPA seems to come from some autobuild, do you know why ?
<ogra> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=snapd&field.status_filter=published&field.series_filter=xenial
<mup> Bug #1614177 changed: Can not connect cups-control interface  <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1614177>
<ogra> mvo, that looks like dupplication since elopio  already builds it in the edge PPA
<jdstrand> zyga: yes
<ogra> sergiusens, your link is 404 (from the mail you just sent)
<ogra> oh, because fo the spasec
<ogra> *spaces
<zyga> jdstrand: I'd like to discuss the namespace sharing thing
<ogra> how crazy is that ....
<zyga> jdstrand: can we do it here on irc with you and gustavo?
<zyga> jdstrand: https://docs.google.com/document/d/13OoZKmVC-u3N-RskWTZeeZaO8Oz7N857bKnNA2RN-VQ/edit
<zyga> jdstrand: this is my idea of how we can do this
<jdstrand> zyga: yes, but I think tyhicks will want to be present too. he comes online in ~45 minutes
<zyga> jdstrand: that's fine, we can postpone until he is around
<ogra> pitti, we have a bunch of boards with wlan only or with wlan and eth ... we dont ship NM on ubuntu-core. will netplan be able to handle that (we use wpa-supplicant via ifupdown there atm)
<mvo> pitti: could you please add http://paste.ubuntu.com/23088949/ to nplan? that would help snapd
<mvo> ogra: in a meeting right now, we can talk later
<ogra> ok
<pitti> ogra: not ATM, wlan/wwan was supposed to be handled by NM
<ogra> :(
<ogra> thats not really mebedded firendly
<ogra> *embedded friendly
<ogra> (where size matters a lot)
<morphis> ogra: we have a network-manager snap ready in the store you can just use for that
<ogra> morphis, i dont want to use NM
<morphis> and modem-manager as well
<pitti> ogra: well, these discussion results are never final -- we build netplan as we want/need it, so it's certainly worth to file a bug at least and I'll check with slangasek/rharper etc.
<morphis> ogra: what is wrong with it?
<ogra> and i guess 90% f the embedded devs that use core wont want to use NM either
<ogra> morphis, overheard ...
<pitti> I thought the general direction was "drop ifupdown"
<ogra> *overhead
<ogra> morphis, you have a constantly running dbus service etc
<pitti> mvo: hm, shipping empty directories? I don't mind much, but how does that help OOI?
<ogra> ram, and disk space might be very limited
<morphis> ogra: that is a froth and back discussion, but in the end you want something which does some more management than just a few shells cripts
<morphis> even on IoT devices
<mvo> pitti: its about the writable path handling, we can workaround this if you want (or if you don't want the empty dir)
<morphis> Nest is using connman for a very good reason on their devices
<pitti> ogra: if you only need a static configuration, it might just be enough to drive wpasupplicant, not necessarily ifupdown or NM, I figure?
<ogra> morphis, well, adding wpa-ssid and wpa-psk to /e/n/i is enough mgmt for such devices usually
<pitti> ogra: i. e. some people actually do use networkd with wifi, it's just not very user friendly (no GUI etc.) -- but we don't care about that, and we don't have a gui with ifupdown either
<pitti> mvo: oh, I see
<mvo> pitti: for ubuntu-core we create a writable directory in the writable space and we need a mountpoint, this is why we need the dir, but I can workaround if needed
<ogra> pitti, well, it isnt static usually but dhcp ... but yeah, indeed ssid and psk need to be seeded
<mvo> pitti: one more hack in livecd-rootfs :)
<morphis> ogra: that still does the case where you want a lot more extended features
 * ogra cries a little reading mvo's last line 
<morphis> ogra: but I agree, its a per use case decision
<mvo> ogra: I cry a lot everytime I look at this code ;)
<pitti> ogra: sorry, I meant "static" in the sense of "fixed config files with fixed AP and password"
<ogra> morphis, right, i think netplan should support the non-NM case for wlan too
<ogra> pitti, yeah
<mvo> ogra: any concerns about the netplan landing? I'm keen to get it in today
<pitti> drwxr-xr-x root/root         0 2016-08-19 19:10 ./etc/netplan/
<ogra> mvo, not beyond ... "hey, i'm just trying to SRU livecd-rootfs" :)
<morphis> mvo, ogra, pitti: not sure, but did you do any testing with netplan and the nm snap to ensure both work fine together?
<ogra> and the patch will be gigantic, infinity will hate me forever
<pitti> mvo: https://git.launchpad.net/~netplan-developers/netplan/commit/?id=3ec75ae5
<ogra> morphis, not me
<pitti> mvo: but I can't upload it right now due to beta freeze
<mvo> pitti: \o/ - no worries
<ogra> pitti, we have our own archive ;)
<pitti> mvo, ogra: heh -- if you upload  it to that, please don't call it 0.10, but 0.9something
<ogra> (and are focused on xenial ... landing yakkety later is always fine)
<pitti> oh
<pitti> note that xenial's NM does NOT work with netplan
<ogra> pitti, x.y.z-0ubuntuX+ppaX
<ogra> is what we usually do
<pitti> the package has Breaks: network-manager (<< 1.2.2-0ubuntu4~) for a good reason
<ogra> ouch
<pitti> so we need to backport a couple of fixes and adjustments for that
<ogra> i doubt we can easily SRU the new NM ?
<pitti> s_langasek mentioned yesterday that we want to do that
<pitti> oh, we can
<pitti> SMOP
<ogra> heh, k
<icey> any good documentation on the interfaces available to snaps, or ways to access more unrestricted things (without --devmode)?
<pitti> it's nothing earthshattering, just a bug fix or two and adding support for /run/NetworkManager/ config files
<zyga> icey: hey, you can look at docs/interfaces.md
<pitti> ogra: well, not really "P"rogramming, more like "P"aperwork :)
<zyga> icey: you can request any interface, right now that will block you in the store for a manaul review if the interface is too "powerful:
<zyga> icey: I believe soon we will also use assertions for that
<ogra> pitti, heh, yeah, i know what you mean ... tyring to SRUall of https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<icey> zyga: the thing I'm trying to snap is the rust coreutils package, which ( I think) basically means it needs the world
<mup> PR snapd#1750 closed: store: request device session macaroon from store <Critical> <Reviewed> <Created by matiasb> <Merged by matiasb> <https://github.com/snapcore/snapd/pull/1750>
<pitti> ogra: can you please file a wishlist bug about wifi support?
<pitti> this hasn't come up so far
<zyga> icey: world?
<zyga> icey: what does it need
<ogra> pitti, netplan package or is there an upstream project ?
<pitti> ogra: nplan package is fine; https://bugs.launchpad.net/netplan also exists
<icey> zyga: look through the list of folders at https://github.com/uutils/coreutils/tree/master/src ; it's a cross platform implementation of all of those
<ogra> ok
<icey> so
<pitti> but distro package is usually better, auto-closing of bugs and you knwo when it is really "in"
<icey> complete filesystem access, for one
<ogra> pitti, uuuh ... there is a binary called netplan (from petter's "plan" package), did you know that ?
<pitti> ogra: I do, that's why the package is called "nplan" :(
<ogra> https://launchpad.net/ubuntu/+source/plan
<ogra> ah
<zyga> icey: that can be done with a sufficiently strong interface
<pitti> long discussion, executive decision etc. pp.
<zyga> icey: but also, remember about the chroot
<pitti> ogra: in the end it doesn't matter that much as nplan is installed by default
<mup> Bug #1602845 changed: unity7 interface does not work with libnotify <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1602845>
<ogra> yeah
<ogra> i just remember all the issues we have with the snappy mediaplayer :)
<icey> zyga: would it be possible for the command snapped to use something like $(pwd) as the run location? MOST of the coreutils act on either the specified location, or .
<zyga> icey: http://www.zygoon.pl/2016/08/snap-execution-environment.html
<zyga> icey: they all do
<zyga> icey: but read that first please
<icey> zyga will do :)
<icey> I'm sure I'll be back in a bit :)
<zyga> icey: one thing has changed since, we now chdir to /var/lib/snapd/void instead of refusing to run when we cannot preserve the working directory
<zyga> icey: it's better in practice
 * zyga -> coffee break
<ogra> pitti, bug 1616928
<mup> Bug #1616928: netplan should support managing wlan devices via wpasupplicant and ifupdown <nplan (Ubuntu):New> <https://launchpad.net/bugs/1616928>
<pitti> ogra: I suppose ifupdown is not actually a requirement (I'd really rather not have that), just "get my effing wifi working"
<ogra> pitti, yeah, just without any overhead
<josvaz> question on snap daemons, how do you stop a daemon:forking snap from the command line?
<ogra> (if you have only 128MB ram you really dont want to have NM and dbus running all the time
<ogra> )
<josvaz> use the snap binary or systemd (I don't see my snap listed in services --all-status)
<pitti> ogra: yep, agreed; I'll have a look how this can be made to work
<pitti> little reason to have the ifupdown wrapper around it, it could just generate a wpasupplicant conf directly
<ogra> josvaz, systemct ...
<ogra> l
<josvaz> ok
<ogra> there used to be a "snap service" command, but that got dropped (i think it will return eventually, but is currently not there)
<josvaz> thanks
<icey> this doesn't even seem to be happy in devmode: http://pastebin.ubuntu.com/23089017/
<cking> can somebody review my "sluice" snap, it's been pending since monday
<pitti> ogra: https://bbs.archlinux.org/viewtopic.php?id=178625 sounds promising -- apparently Arch has a wpasupplicant@<iface>.service which DTRT (we don't, but I can't imagine it is rocket science)
<pitti> ogra: essentially, we just need to start it once the interface comes up, which can be done with a relatively simple udev rule even
<pitti> Odd_Bloke: so, this seems doable indeed
<pitti> Odd_Bloke: sorry, meant ogra
<Odd_Bloke> pitti: :)
<pitti> IRC <tab> clearly isn't clever enough -- what is all this talk about smart devices??
<sergiusens> ogra_ you can thank dekko from breaking urls ;-)
<Guest37767> I have a question regarding the connection of my snap to a USB flash drive. With the "strict confinement" option, using the plugs "home", I can't access to the usb flash drive. Is there an other interface to connect to the usb ports ?
<mup> PR snapd#1731 closed: firstboot: generate netplan config rather than ifupdown <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1731>
<mup> PR snapd#1757 closed: asserts: authority-id and brand-id of serial must match <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/1757>
<zyga> tyhicks, jdstrand: do you have a moment to discuss the ns sharing design
<jdstrand> mhall119: hey, didrocks seems afk, is there someone who can look at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7 ?
<mup> PR ubuntu/snapcraft-desktop-helpers#7: common/desktop-exports: don't dereference target symlink on upgrades <Created by jdstrand> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7>
<tyhicks> zyga: yes, I'm reviewing the doc now
<jdstrand> mhall119: feel free to direct me to whoever
<zyga> tyhicks: thank you, we don't have to have a hangout or anything, just give me feedback and suggestions please
<mhall119> jdstrand: not sure I'm qualified to give a "looks good" on that, but your explanation of the issue and fix sounds reasonable
<niemeyer> zyga: This is significantly more complex than what I hoped for
<niemeyer> cc jdstrand tyhicks
<zyga> niemeyer: ideas welcome, this is the most basic version that lets us share the mount namespace IMHO
<jdstrand> zyga: can you make that a numbered list so it is easier to speak to?
<zyga> yes, sure
<zyga> ne
<zyga> done
<jdstrand> thanks
<jdstrand> so the gist of this is 4 and 6
<jdstrand> 4 gets us what to give to 6
<zyga> correct
<zyga> the rest is just implementation detail, apart from the fork that is mandatory
<jdstrand> and the rest is how to get there safely and cleanup
<zyga> (because of how the mount namespace is diffrent from other namespaces, apparently)
<zyga> (i.e. you cannot just bind mount it directly unlike the others)
<tyhicks> will snapd know which snaps need to share namespaces?
<jdstrand> so, 1 is about creating the mountpoint in a non-racy way. if I am in 1b, what is the next step?
<zyga> tyhicks: AFAIK the design is that all processes belonging to a given snap share a namespace, if desired this can be delegated to an interface later
<zyga> jdstrand: if you "lose" you spin lock on the files you'd open in 6 to become symlinks and then proceed
<zyga> jdstrand: we can switch from spinlock to anything that lets them coordinate
<jdstrand> zyga: so, once symlink is there, go to step 6
<jdstrand> (might be nice to capture that)
<zyga> jdstrand: correct, assuming 3.8 or more recent kernel
<zyga> jdstrand: done
<jdstrand> ah, well, 3.8-- there are 3.4 kernels out there-- maybe call that out in a comment as something that should be changed for 3.4 or to add a patch to the list for 3.4 backports
<zyga> good point
<zyga> jdstrand: hmm, which version of ubuntu had a 3.4 kernel? I'll use that for testing
<cpaelzer> elopio: hi, just saw your feedback on PR 716
<jdstrand> I suspect you have to unshare() in a forked process because this is after this process' unshare() and unshare() twice is not allowed
<cpaelzer> elopio: what do you suggest with "waf part in the wiki instead of putting it in our integration test" ?
<cpaelzer> elopio: I surely can add stuff to the wiki, but I don't get the "instead of integration test" part of it yet
<zyga> jdstrand: no, it is just because of how it doesn't work otherwise for the mount namespace, it you cannot bind mount /proc/self/ns/mnt unless under some extra conditions that are not captured by the manual page IMHO
<zyga> jdstrand: I found this by googling and experimenting,
<zyga> jdstrand: you have to be in another namespace
<zyga> jdstrand: to do the bind mount
<zyga> jdstrand: odd but ... well
<zyga> jdstrand: so the parent is in the vanilla namespace, the child sits in the new namespace(s) and the parent does the bind mount
<jdstrand> zyga: precise has 3.2. not sure otoh what had 3.4-- I don't think anything in Ubuntu iirc. android bsps of course (eg, touch kernels)
<zyga> jdstrand: 3.2 is good
<zyga> jdstrand: the pivot point is 3.8
 * zyga fetches precise
<mup> PR snapd#1757 closed: asserts: authority-id and brand-id of serial must match <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1757>
<jdstrand> zyga: 2b should say 'waits to be killed in step 5'
<jdstrand> I know I'm being pedantic, but trying to make sure we understand what each step is doing
<mhall119> what does the new browser-support interface provide?
<jdstrand> mhall119: it's in docs/interfaces.md: "Can access files and IPC needed by modern browsers. This interface is
<jdstrand> intended to be used when using an embedded Chromium Content API or using the
<jdstrand> sandboxes in major browsers from vendors like Google and Mozilla. The
<jdstrand> ``allow-sandbox`` attribute may be used to give the necessary access to use
<jdstrand> the browser's sandbox functionality."
<zyga> jdstrand: done
<zyga> jdstrand: I'm very grateful for this!
<jdstrand> mhall119: basically, electron works without specifying allow-andbox and people like google and mozilla can use it with allow-sandbox: true for chrome and firefox respectively
<mhall119> jdstrand: ah, ok
<zyga> jdstrand, tyhicks: if you don't mind I'd like to change the directory a little to .../$SNAP_NAME/mnt so that we can have .../$SNAP_NAME/mutex explicitly
<zyga> and use openat() easily
<jdstrand> zyga: super pedantic: 'snap-confine parent waits for the eventfd event created in step 2b'
<zyga> jdstrand: done
<jdstrand> zyga: step 4: 'when the eventfd event is received, ...
 * zyga would like to have "anhor references" so that 2b can be auto-numerated 
<jdstrand> '
<zyga> jdstrand: done, correct me if anything is wrong (I think you can also do suggestions in the doc)
<jdstrand> zyga: so, if step 2 fails, a losing process in 1b will spin forever?
<zyga> jdstrand: yes
<zyga> jdstrand: hmm
<zyga> jdstrand: if only IPC was easy
<jdstrand> well, that's what reviews are for
<zyga> jdstrand: hmmm, maybe an IPC (dbus?) service for making namespaces?
<zyga> jdstrand: then everone just calls a method on the bus and gets an FD back
<zyga> jdstrand: or an error
<jdstrand> I don't think we want dbus
<zyga> jdstrand: sockets are good too :)
<jdstrand> well
<zyga> jdstrand: do we need that to stay reliable?
<jdstrand> let me rephrase
<tyhicks> I'd rather not have the setuid root snap-confine get as complicated as talking over dbus
<jdstrand> adding dbus as a requirement means that 14.04 cloud images will pull in dbus
<jdstrand> and they'd probably prefer not to do that
<jdstrand> plus that
<zyga> jdstrand: that's a fair point
 * zyga thinks
<lazyPowe_> lool o/ hey there
<zyga> jdstrand: if 2 fails we could remove the mutex
<zyga> jdstrand: and fail in that process
<lool> lazyPowe_: Hi!
<zyga> jdstrand: and other processes could restart the attempt
<zyga> jdstrand: with inotify they could observe the directory
<zyga> jdstrand: to know mutex is gone (no spinlock)
<lool> lazyPowe_: the docker snap will likely not be sufficient for kubernetes
<lool> lazyPowe_: it's WIP at https://github.com/snapcore/snapd/pull/1619
<mup> PR snapd#1619: Add initial "docker" interface based on some of 15.04's privileges <Blocked> <Created by tianon> <https://github.com/snapcore/snapd/pull/1619>
<zyga> jdstrand: this could be done by snap-confine-ns, to have less stuff in snap-confine itself
<zyga> jdstrand: which could be confined very strictly to do that one thing (share or setup the ns)
<lazyPowe_> lool - well, thats fine by me for now :) I was just noticing this is you https://github.com/lool
<elopio> cpaelzer: hello. Have you seen https://wiki.ubuntu.com/snapcraft/parts ? You can put in there a part to be reused. I thought waf would be a good case for that.
<lool> lazyPowe_: it is me, what did I do again?
<lool> and before anyone ask, I certainly didn't reboot it
<elopio> instead of copying the waf source in your snap, you would use: after: [waf], and snapcraft will bring it from the wiki.
<jdstrand> removing the mutex and allowing losing process to try to win seems reasonable
<lazyPowe_> lool - i found this https://github.com/infosiftr/snap-docker/tree/docker-interface
<zyga> tyhicks: how do you feel about the whole design?
<lazyPowe_> is this the snap and code in reference on the list / snapcore/snapd
<elopio> ogra_: hey, answering the old ping. There is a button in launchpad called trigger build, do you mean that?
<tyhicks> zyga: well, I don't prefer snap-confine having to do all of this work
<lool> lazyPowe_: not sure what you mean with reference on the list / snapcore/snapd, but it's the only repo we use for docker snap; I believe master branch is the current series 16 one though
<lazyPowe_> ok, i was looking for some prelim work. I'd like to help collab/contribute
<zyga> tyhicks: would you feel better if this was a separate executable?
<zyga> tyhicks: it would still be running as root (via snap-confine)
<ogra_> elopio, i dont have it
<jdstrand> zyga: perhaps: '2c. if 2, 2a or 2b fail, remove the mutex so losing processes in 1b can compete for 1a)
<jdstrand> '
<tyhicks> zyga: I'm not against the design but it sure seems like it'd be nicer if snapd could prepopulate the namespace directories
<zyga> tyhicks: hmmm
<cpaelzer> elopio: I've seen that in the past, but it appeared to me a bit too "unofficial" and since I want to get an external project to use snaps I'd prefer to have waf "properly" in snapcraft
<zyga> tyhicks: can we rely on this? snapd may not be up
<zyga> jdstrand: ^ ?
<lazyPowe_> lool - i'm mostly interested in tracking the progress so I can maybe contribute whats needed to run k8s on top of a docker snap. Thanks for confirming that is the upstream
<cpaelzer> elopio: I might not see the whole of it - could I use that mechanism to "just keep the integration test" in such a part, but let the rest be in "official" snapcraft?
<tyhicks> zyga: oh... if that's true, then we probably can't rely on it
<ogra_> elopio, but it seems a new build is ongoing anyway now ... so no worries
<lool> lazyPowe_: did you start with a k8s snap already?
<zyga> tyhicks: I can move the code into any other process but it has to do the thing anyway, yes, we could pre-populate the namespaces a little but I suspect it's going to be more complex this way (what if the group allocation changes, etc)
<jdstrand> tyhicks: doesn't the unshare() require root?
<lool> lazyPowe_: so status is that it's mostly done, but there is some pending feedback on the interface and final tweaks to make; waiting on the pull request to be unblocked
<jdstrand> tyhicks: in 2a
<lazyPowe_> lool - i've got the client snap completed, i'm now on to trying to stand up a stand-alone snap
<tyhicks> jdstrand: yes, it does for certain namespaces
<tyhicks> jdstrand: why do you ask?
<jdstrand> tyhicks: I was trying to think through your suggestion of moving it somewhere else
<tyhicks> (it definitely does for mount namespace)
<lool> lazyPowe_: cool; would be happy to hear news on progress of this effort, and perhaps even contribute if I find the time  :-)
<lool> lazyPowe_: how do you use k8s BTW?
<lazyPowe_> lool - juju deploy kubernetes-core usually
<tyhicks> jdstrand, zyga: I was just thinking that sorting out all of this lock contention stuff is a pain to get right and it'd be nice if something else had already populated the namespaces
<jdstrand> I was thinking maybe snap run could do it, but then I said "no, it can't"
<lool> lazyPowe_: BTW one thing we have been debating is location of docker socket for the snap; ISTR k8s has two docker daemons; it would be interesting to hear if you run into issues with this and the snap
<tyhicks> jdstrand, zyga: however, that'd have to be done in early boot
<jdstrand> well
<jdstrand> lets take a step way back
<zyga> tyhicks: whoever does it has to solve the same problem
<jdstrand> the snap can't run unless the squashfs is mounted
<jdstrand> snapd is mounting the snaps
<zyga> tyhicks: that cannot be done in early boot because groups are dynamic and will change as snaps are added or removed
<lazyPowe_> lool - we would favor bins on disk over another engine bridge using the snap delivery method
<jdstrand> after it mounts the snaps, couldn't it create what is needed for snap-confine to setns into?
<zyga> jdstrand: that's not true, systemd does it
<zyga> jdstrand: even withou snadp running on the next boot
<jdstrand> eh
<zyga> *without
<lazyPowe_> that primary bridge is used in 1 of 2 cases - to isolate the control plane, or to provide ancilliary components to the "workload" docker instance. Such as SDN through Flannel in a container.
<zyga> *snapd
<jdstrand> that's fine. a systemd unit could do it
<jdstrand> I'm not saying it should. just talking here
<zyga> ok
<tyhicks> zyga: if a snap is installed, snapd could set up the namespaces before mounting the newly installed snap
<zyga> tyhicks: that's true
<zyga> tyhicks: snapd could manage all of this in /run/snapd/ns
<tyhicks> zyga: if a snap is uninstalled, and there are no more users of the $SNAP_NAME group identifier, then the namespaces can be torn down after the last snap in the $SNAP_NAME group is unmounted
<zyga> tyhicks: but we need something that pre-populates that after reboot
<elopio> ogra_: https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+request-builds
<zyga> tyhicks: I like how this gives us a nice way to clean up, yes
<ogra_> elopio, i developed that part :P i'm talking about https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages and the snapd package in there
<zyga> tyhicks: and a way to correctly depend on the thing that creates those namespaces to run before snap-confine
<ogra_> elopio, (i do know how to trigger an ubuntu-core snap build :) )
<tyhicks> zyga: right - so then snap-confine just needs to look in /run/snapd/ns/$SNAP_NAME/* and start calling setns()
<elopio> cpaelzer: the wiki is pretty official. You would keep the waf plugin in snapcraft, and a waf part in the wiki. The part will just contain the waf python files you are putting in the integration test.
<niemeyer> zyga: Yes, I can surely have ideas.. I was hoping someone else would also have some of those so we could find something simple that works
<tyhicks> zyga: there's no need to worry about locking and coordinating with other processes
<jdstrand> the after reboot scenario could be handled by a systemd unit that runs before any of the snap mounts
<tyhicks> correct
<niemeyer> zyga: Let's park that change until someone can have more ideas, please
<ogra_> elopio, the prob was that the snapd package in the edge PPA was only built for x86 and armhf ... not for the other arches ... so they ended up with an old snapd
<tyhicks> niemeyer: we're discussing another option right now
<jdstrand> it just goes through all the installed snaps and sets up the namesapces. then snap install/remove handles while the system is running
<niemeyer> tyhicks: Nice, thanks!
<elopio> ogra_: :) now I understand you
<ogra_> :)
<tyhicks> np
<ogra_> its all fine now
<elopio> ogra_: it has 6 architectures selected.
<ogra_> (well, someone needs to request s390x for the edge PPA still )
<ogra_> elopio, yes, i selected them today butt could not trigger a rebuild
<jdstrand> so, one disadvantage of this is that you have namespaces setup with nothing going into them. this would only affect snaps with no daemons
<cpaelzer> elopio: uh I see so it would only hold the extra stuff I've moved from the waf upstream into the integration test and that way "stay out of tree"
<jdstrand> I'm not saying this is necessarily a problem, just that it should be called out
<elopio> ogra_: and how did you solve it? I see the build queue has only 2 archs.
<tyhicks> jdstrand: yes, I don't like that aspect of it
<cpaelzer> elopio: I guess the integration test then is the one using the after [waf] - yeah if that works I'm good
<zyga> jdstrand: yes, that's true, this brings me to my other point, if this was managed through interfaces then we could have more control over which processes share what
<cpaelzer> elopio: I'm giving it a try til the next meeting starts
<zyga> jdstrand: and perhaps, no lurking namespaces that are never used
<zyga> (well, never is inaccurate)
<elopio> cpaelzer: yes, thanks.
<ogra_> elopio, i didnt ... i enabled all the other arches i could (except for s390x for which we'll need domeone like cjwatson ) ... thats all ... now the daily build job seems to have kicked in
<tyhicks> jdstrand: it parallels the fact that we have a ton of mounts set up that may not be in use but it is just adding to that problem...
<ogra_> *someone
<zyga> tyhicks: technically snapd reads the meta file from all the snaps almost all the time
<zyga> tyhicks: but I agree
<jdstrand> zyga: well, niemeyer and I discussed the option of exposing this to the developer, but we felt this was a confusing choice of an implementation detail to have to deal with
<ogra_> elopio, so the "i can not trigger a build" issue has resolved itself due to the daily job
<jdstrand> tyhicks: that is an extremely fair point
<zyga> jdstrand: which developer? this would be an implementation detail in snapd interfaces, not something anyone can change willy nilly
<elopio> ogra_: but I think we are still missing something: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+builds
<jdstrand> tyhicks: this is a process though that needs to stick around, no?
<jdstrand> zyga: but the developer has to know to opt into the interface
<cjwatson> ogra_: https://answers.launchpad.net/launchpad for that kind of request
<zyga> jdstrand: ah, understood, yes
<tyhicks> hmmm
<jdstrand> zyga: plus, this is trying to solve a devmode issue
<zyga> jdstrand: as a counter point, will we ever have to share the mount namespace across snaps for any reason?
<jdstrand> (as well as strict)
<ogra_> elopio, https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages i see armhf, arm64 and ppc64el binaries if i expand the snapd package ... and amd64/i386 waiting for a free buildd
<elopio> ogra_: oh, scratch that. It's because the others already build.
<tyhicks> zyga: does the process that created these namespaces have to stick around or can the namespaces persist without a process?
<jdstrand> zyga: that would I think definitely need to be exposed in an interface
<ogra_> cjwatson, thx
<zyga> tyhicks: well, they persist here
<jdstrand> zyga: but there is no consensus on if we should support that
<zyga> tyhicks: through the bind mount
<tyhicks> right
<tyhicks> ok
<zyga> tyhicks: (here the child that created the process dies before we setns)
<elopio> ogra_: great, you solved it and I just came late to make a mess. Please continue :)
<ogra_> lol
<tyhicks> jdstrand: so no process needs to stick around after 10:17 < elopio> ogra_: it has 6 architectures selected.
<tyhicks> bah
<jdstrand> in fact, architects I've spoken to are leaning against sharing the mount namespace between snaps, even of the same publisher
<tyhicks> copy and paste fail
<zyga> jdstrand: ack, then we can use systemd and other units
<zyga> jdstrand: hmm, will this be a problem for 14.04 support?
<elopio> ogra_: for the record, the way I trigger a build is to push to the ppa. You can do that manually triggering http://162.213.35.179:8080/job/github-snapcraft-daily-ppa/
 * ogra_ feels honored, tyhicks picked my line for his paste error :D
<tyhicks> jdstrand: no process needs to stick around after /run/snapd/ns/$SNAP_NAME.NS is created
<zyga> jdstrand: there are two actions that would have to happen if snap-confine just consumes pre-made namespaces
<zyga> jdstrand: snapd would have to run a tool/service that creates/remvoes them on demand on install/remove
<jdstrand> oh, huh. they persist through the bind mount. that clarifies something with ip netns for me
<zyga> jdstrand: and the said tool would have to run with system startup before snapd itself is up
<zyga> jdstrand: or more accurately, before the .mount units are preocessed)
<ogra_> elopio, aha, that was the button i was missing this morning ... noted for next time
<zyga> jdstrand: (this will be interesting when we have snap name renames
<zyga> )
<zyga> (perhaps it could be based on snap ids)
<zyga> (but this is not a major point)
<jdstrand> ok, then tyhicks' point re this is inline with all our bind mounts is even more salient
<zyga> ohhhhhhhh
<zyga> hmm, wait
<zyga> it cannot fully inline with our bind mounts
<zyga> because bind mount is just the persistence mechanism
<zyga> setns is the actual thing, this would still be separate
<jdstrand> that's note really what I meant
<ogra_> jdstrand, tyhicks zyga, i saw you guys talking about creating groups .... of thats user groups, please take into account that we have two group DBs when you design anything around it, one is readonly with static GIDs and the other is dynamic ... the static one might grow over time, so if you create dynamic groups, please leave a large enough gap
<jdstrand> tyhicks was just saying having this extra thing laying around is not much different than having extra things hanging around elsewhere
<tyhicks> ogra_: we're talking about groups of kernel namespaces
<tyhicks> ogra_: that are shared among commands in snap
<ogra_> tyhicks, that doesnt relate to userspace groups ?
<zyga> jdstrand: as in mounted snaps just being there?
<tyhicks> ogra_: nope
<ogra_> (i,e /etc/group )
<ogra_> ok
<ogra_> then ignore me :)
<jdstrand> zyga: that, but more everything snap-confine sets up that the snap may not strictly need
<tyhicks> ogra_: it was worth mentioning :)
<zyga> jdstrand: right
<zyga> jdstrand: so how can we simplify this
<ogra_> yeah, i have a mental highlight on such stuff :)
<jdstrand> all I was saying is that if there is no process sticking around, I find this more compelling and am less bothered by this thing that is there
<mup> PR snapd#1759 opened: asserts: fix GPG key generation parameters <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1759>
<jdstrand> one could argue for the shared mount namespace pre-setup with the same logic as pre-mounting snaps
<jdstrand> snap-confine *could* do the mounts of snaps if they aren't already there, but it doesn't
<jdstrand> zyga: I'm not sure it needs to be simplified
<qengho> So, when do snaps refresh? My small experimental set suggests it's automatic on snappy images and manual on snappy-on-classic.
<zyga> jdstrand, tyhicks: have a look at the 2nd attempt below
<zyga> qengho: look at the snapd.refresh.timer
<jdstrand> zyga: in this manner, snap install doesn't have to do anything
<zyga> jdstrand: correct
<mup> PR snapd#1760 opened: overlord/state: prevent change ready => unready <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1760>
<zyga> jdstrand: can the mount unit describe post-unmount actions
<zyga> jdstrand: so that we can clean up those files?
<jdstrand> maybe. let me look
<tyhicks> zyga: hmm, I think there's still a race here :(
<tyhicks> zyga: so this solved the race problem of the namespace creation and other processes joining the newly created namespace
<jdstrand> https://www.freedesktop.org/software/systemd/man/systemd.mount.html
<jdstrand> (not directly)
<tyhicks> zyga: but now we have to solve the problem of actually setting up the mounts in the namespace
<zyga> tyhicks: oh
<zyga> tyhicks: fair point
<zyga> tyhicks: actually, more complex
<zyga> tyhicks: it's not just a race
<zyga> tyhicks: it's a wtf do we do?
<zyga> tyhicks: because some things are common across snaps
<zyga> tyhicks: (and those should not be re-done)
<zyga> tyhicks: but some depend on interfaces
<tyhicks> zyga: I think this problem is present in both first and second attempt, right?
<zyga> tyhicks: so now one process can change behavior based on the interfaces of another process
<zyga> tyhicks: yes
<zyga> tyhicks: but it's a very serious problem
<zyga> tyhicks: (feature)
 * tyhicks thinks
<zyga> tyhicks: so, going back to snap-confine-does-all idea, this is easy to make race-free
<jdstrand> can one of you describe the problem with an example? (this may have already been considered)
<zyga> jdstrand: sure, two things start up, they have the same mount namespace and then start to apply all the mounts and bind mounts that snap-confine does
<zyga> jdstrand: so they cannot assume they start with a well-defined state
<zyga> jdstrand: so they probably don't do what people intended
<jdstrand> hmmm
<zyga> let's get back to the original problem
<zyga> what was desired? so that two processes share the filesystem
<tyhicks> only one process should set up the bind mounts and others must wait before their snap command is started
<zyga> can we unshare twice?
<zyga> if we can setns() and then unshare()
<zyga> we can do the rest with the fstab interface
<jdstrand> right, so in the initial thoughts on this, it was 'if shared mount not there, set it up and do all the mounts, then pivot_root ; else, setns and pivot_root'
<zyga> jdstrand: except that the two processes may have different .fstab files
<zyga> files*
<tyhicks> if they have different fstab files, they can't share the same mount namespace
<zyga> or new conditions on the hostfs would result in different mounts (lxd quirk)
<tyhicks> it is as simple as that
<zyga> well, not entirely
<jdstrand> zyga: wrt the content interface, we said it would necessarily have to be snap-global and that would be covered in documentation
<zyga> but perhaps they can share a part they care about
<zyga> jdstrand: oh, we did? I wasn't aware of that
<jdstrand> yes, it should be in the bug
<zyga> jdstrand: note that right now it is just the content interface but any future interface can use the mount backend
<jdstrand> sure. I brought up content because we want to make sure we consider the future .fstab stuff
<jdstrand> I think that .fstab ends up also being global, but I don't know everything we're thinking of putting there
<zyga> jdstrand: what if we did this, setns(), unshare(), process all the stuff
<zyga> would that be sufficient for the network thing
<zyga> s/stuff/mounts/
<zyga> with a shared subtree at the right spot, they would see what they want
<zyga> and fstab is still per process
<zyga> (app)
<zyga> mount namespace is not really fully 'unshared' because of shared subtrees and how that mixes everything up
<tyhicks> how do you make sure that one snap's fstab doesn't stomp on the shared subtree with a mount that isn't in the other snap's fstab?
<zyga> tyhicks: you don't but we control the fstabs, it's about how we make the sharing sensible
<zyga> tyhicks: you can stump if that's the idea
<tyhicks> zyga: ok, so it is handled by interface code reviews
<tyhicks> that's acceptable
<tyhicks> possibly error prone but still perfectly acceptable
<zyga> jdstrand: how do you feel about this?
<jdstrand> zyga: note from 'man ip-netns': http://paste.ubuntu.com/23089359/
 * zyga reads
<jdstrand> zyga: (that was in response to an earlier question)
<zyga> by creating a mount namespace
<zyga>        and bind mounting all of the per network namespace configure files into
<zyga>        their traditional location in /etc
<zyga> jdstrand: thanks, I see
<zyga> jdstrand: so as long as we don't do funny stuff to /etc/netns or /etc, it would be OK
<zyga> jdstrand: (we do bind mount /etc from the host)
<zyga> jdstrand: but that mount won't be seen by the host (mount done by ip-netns)
<zyga> jdstrand: and thus won't be seen by separate processes ran by snap-confine
<zyga> jdstrand: so unless I'm mistaken, we have to share the actual namespace after it is initialized for this to work
<jdstrand> well, I want to be sure we  think about handling this for anything that might use a mount namespace. ip netns exec is just one thing
<zyga> jdstrand: agreed
<zyga> the fstab handling could be split into global and per-process, the global one would be shared by the namespace sharing
<zyga> the local one could do anything extra needed
<jdstrand> ok, so can someone clarify option #3 for me?
<zyga> and the global one would have to be pre-made by the snap-namespace tool
<zyga> jdstrand: option #?
 * zyga is amazed that this all works in the kernel and it doesn't leak memory
<jdstrand> it sounds like you and tyhicks came up with a different variation
<jdstrand> can you explain that variation?
<zyga> tyhicks: can you just write your idea down in the sname doc
<zyga> tyhicks: you can now edit
<zyga> jdstrand: this also gets tricky
<tyhicks> zyga: I didn't come up with an idea about how to handle the fstab processing race
<zyga> jdstrand: whenever .fstab changes we have to invalidate
<zyga> jdstrand: and more races show up
<arges> hi. how long does the typical published snappy app take to show up via 'snap find' ?
<tyhicks> arges: immediate in the snaps that I've published
<arges> tyhicks: that's what i've been told. Trying to determine if I screwed something up.
<zyga> arges: snap find doesn't look at snaps in channels other than stable AFAIK
<arges> zyga: ah. yea i published to edge.
<jdstrand> arges: do you have a link to the page in the store and I can look
<jdstrand> arges: if it fails automated review, then it won't publish
<jdstrand> arges: and a human needs to look at it
<arges> jdstrand: it says 'published' and passed the reviews, but it may be because its in edge
<jdstrand> ok
<arges> but no idea how to install an edge snap from the store
<tyhicks> arges: snap install --edge SNAP
<arges> tyhicks: didn't work for me
<jdstrand> --channel=edge ?
<arges> jdstrand: nope
<arges> : )
<arges> $ sudo snap install --channel=edge crash-arges
<arges> error: cannot install "crash-arges": snap not found
<jdstrand> arges: what is the name of the snap or the url in the store
<arges> fwiw
<jdstrand> ?
<arges> https://myapps.developer.ubuntu.com/dev/click-apps/5771/
<ogra_> arges, confinement strict or devmode ?
<arges> ogra_: devmode
<ogra_> then add --devmode to that line
<ogra_> else it wont find it
<arges> ogra_: magic. it works
<ogra_> ;)
<jdstrand> zyga, tyhicks: ok, I'm kinda confused where we are
<arges> jdstrand: tyhicks ogra_ zyga thanks all
<zyga> jdstrand: I think I'm at the point where I see that it is more complex to correctly share the mount namespace (after it is configured)
<jdstrand> what option are we talking about, what are we changing and why, how is it implemented?
<zyga> jdstrand: so the simplistic snap-namespace idea from "2nd attempt" part of the document is not sufficient
<jdstrand> zyga: can you explain why given the understanding that things like 'content' are snap-global?
<zyga> jdstrand: because you have to start to invalidate those now as interface are changed
<jdstrand> can you give a concrete example?
<zyga> jdstrand: sure, we pre-share a namespace with (hypothetical) snap-namespace, and save the ns to a file as we were planning to, now processes are starting that are racing to open that file while you are racing to create a new namespace because of interface connection changes
<zyga> (and replace the old one without stacking them forever, we have to unlink or unmount the old one)
<tyhicks> so I understand the problem of racing on initial fstab processing but I don't know enough to reason about the interface connection changing problem
<jdstrand> ok. so a snap plugs the content interface. snap-namespace creates the shared mount. the use disconnects the content interface, we have to handle the namespace created by snap-namespace while snap.app2 may be accessing it
<sborovkov> Hi. Couple of questions - I noticed that snap login eventually expires. Is there recommended mechanism I am supposed to use to handle that? Also I have snap in edge channel - so I have to use snap --refresh --edge screenly - to update it - does that mean I should add cronjob to get new updates from store for it?
<jdstrand> zyga: something like that ^
<zyga> jdstrand: actually I think the old namespace will run fine until the process quits, it is about /run/snapd/ns/foo/mnt that has to be unmounted / unlinked and re-created in a race-free way
<zyga> jdstrand: though nothing today protects us from concurrent interface reconfigurations and snap-confine reading those files so maybe that's not a new problem
<zyga> jdstrand: so my point is that the perceived simplification with out-of-bound setup is not really there
<zyga> jdstrand: because that tool has to solve the same problem
<zyga> jdstrand: and that tool has to process a large chunk of what snap-confine does now (set up all mounts)
<tyhicks> it doesn't have to set up all the mounts
<jdstrand> zyga: yeah. another option would be snapd would have to go in and setns() and umount
<jdstrand> which also isn't easier
<tyhicks> there could be a simple lock file that all snap-confine processes take before setting up the mounts
<zyga> tyhicks: how much processing do you think is required there (in snap-namespace) given that snap-confine does pivot_root and a lot of mounts
<zyga> tyhicks: can you detail how you'd see the initially (shared) namspace and the per-snap-confine mount operations to happen
<zyga> tyhicks: what would each of those do?
<elopio> ping mwhudson: what are the plans for go 1.7? will it get to xenial? yakkety?
<tyhicks> zyga: well the locking problem is easy - have an advisory lock file that must be help before setting up the mounts
<tyhicks> zyga: what I don't have an answer to is how to different between different fstab files
<zyga> tyhicks: different fstab files can be ignored for now, how would the lock file help given the fact that we now start with a non-pristine mount envinronment?
<zyga> tyhicks: can you write down how that would work, I bet I'm missing something you are thinking about
<tyhicks> yes, give me a minute to think through the details
<tyhicks> zyga: see the bottom of the dock
<zyga> tyhicks: so that would be all-in snap-confine?
<tyhicks> zyga: yes
<tyhicks> heh... s/dock/doc/ all this container-like talk has docker in my head :)
<tyhicks> zyga: it works with either "1st attempt" or "2nd attempt"
<tyhicks> again, what it doesn't solve is differences in two fstab files
<zyga> tyhicks: yep
<zyga> tyhicks: that's fine
<zyga> tyhicks: I think this is doable, I'd deal away with the .complete file
<zyga> tyhicks: so that it just looks nicer in the FS
<jdstrand> tyhicks: can you give a concrete example with two .fstab files? (I think this is covered by documenting these are snap-global)
<zyga> tyhicks: but that's a minor point (the actual namespace file can be the complete file_
<zyga> )
<zyga> jdstrand: hmmm
<tyhicks> zyga: I think you need .complete but we can talk about that later
<zyga> tyhicks: one hole: the lxd quirk
<zyga> tyhicks: look at quirks.c please
<tyhicks> jdstrand: I don't know enough about snap-global to give you an answer
<jdstrand> tyhicks: you misunderstand
<jdstrand> tyhicks: what I mean by 'snap global' is that you don't differentiate between commands in a snap. all the commands get the same set of mounts. so if one command plugs content (a consumer of .fstab), all commands gets content
<tyhicks> jdstrand: nice, so that solves that problem
<jdstrand> tyhicks: so all the mounts are global to the snap. we simply document that
 * tyhicks looks at quirks.c now
<zyga> tyhicks: this part specifically: https://github.com/snapcore/snap-confine/blob/master/src/quirks.c#L138
<zyga> tyhicks: if /var/lib/lxd didn't exist when we first start a process but gets created later, the mount namespace won't have that
<zyga> tyhicks: if the fstab profile changes, we also have to invalidate the mount namespace (I guess snapd can do that by unlinking the file)
<zyga> tyhicks: so we have to take that into account (the unlink) but I guess this is simple
<tyhicks> zyga: the mount namespace is shared so wouldn't future processes see the bind mounted /var/lib/lxd? (depending on mount propagation, of course)
<zyga> if we can open() we win and we got a fd for setns
<zyga> tyhicks: no, because that if won't run initially
<tyhicks> zyga: why not?
<jdstrand> tyhicks: I think zyga's point is that a snd app invocation skips step 5
<jdstrand> s/snd/2nd/
<zyga> tyhicks: because if is is not there initially (/var/lib/lxd) then nothing will create the bind mount later
<zyga> tyhicks: because in this design the .complete file says "the mount namespace is ready, just use it"
<jdstrand> zyga: quirks could be handled as part of step 4-- it would just need to see if the quirked mount point is already mounted
<zyga> tyhicks: and the namespace that was initially created may have been done some before (or worse, after) the directory changed the state of its existence
<jdstrand> well, 4 and 6
<zyga> jdstrand: 4 in the new design?
<jdstrand> but you get the idea
<jdstrand> yes
<zyga> jdstrand: hmm
<tyhicks> man, I'm confused about the quirks problem
 * zyga doesn't get the idea
<zyga> let me re-read
<jdstrand> always try to run the quirks code
<zyga> would that be safe?
<jdstrand> zyga: imagine app 1 starts and a quirk is present, it gets mounted
<zyga> we'd stack the quirk mount
<jdstrand> that's easy
<jdstrand> imagine app 1 starts and the quirk mount isn't present, ekip it
<tyhicks> (if you two are close to identifying a solution for the quirks problem, it is probably better to work towards that instead of explaining the problem to me)
<jdstrand> app 2 starts and the quirk mount point is present but not mounted. mount it
<zyga> ah
<zyga> jdstrand: so the idea is that quirks have to be aware of this
<jdstrand> I guess you can put it that way
<zyga> jdstrand: and do the right thing (whatever it is) in presence of the shared mount namespace
<jdstrand> yes
<zyga> jdstrand: e.g. it is not in /var/lib/lxd on the host, unmount it
<jdstrand> ie, decouple quirks from the shared mount
<zyga> jdstrand: and rmdir the thing
<zyga> jdstrand: that's more complex but doable
<zyga> jdstrand: but somewhat less nice because it would require code that runs very rarely and might be buggy
<jdstrand> so long as the shared mount namespace is there, the quirks code can figure out something to do
<jdstrand> well
<jdstrand> we can think through other options wrt that, but I think this keeps the thorniest part, the locking, simple
<zyga> jdstrand: I think we're back to the original plan with a few tweaks on locking but nothing major
<tsimonq2> a/or
<tsimonq2> whoops sorry
<zyga> tyhicks, jdstrand: do you want me to prototype this?
<zyga> or are we putting this back on the feature shelf
<jdstrand> zyga: this is important
<jdstrand> as evidenced by sabdfl's comments in the bug and to me
<zyga> niemeyer: ^^
<jdstrand> we need to fix ip netns exec in devmode snaps. shared mounts is the path to do that
<zyga> niemeyer: I'd like your ack to start working on this
<jdstrand> (fyi, niemeyer is aware of the importance)
<niemeyer> zyga: Ack on what?
<jdstrand> but I think what would benefit a conversation with niemeyer is a cleaned up proposal with the new locking
<jdstrand> (not to mention, JamieBennett said this was prioritized)
<zyga> niemeyer: to work on the snap-confine changes required to implement mount namespace sharing as described by the "3rd attempt" in the docs
<zyga> jdstrand: good point, let me do that
<zyga> niemeyer: sorry to ask prematurely, I'll write a doc that describes what we discussed and how it would work
<zyga> niemeyer: and aks you to review it then
<jdstrand> zyga: also, why attempt #2 was rejected would be good
<niemeyer> jdstrand: Yes, that'd be appreciated, thank you
<niemeyer> zyga: Sounds good, thanks
<zyga> jdstrand: I think we rejected it because it'd effectivly do much of what snap-confine does, and would not win us anything; what do you think?
<zyga> and it had more complex locking
<zyga> thouh 3rd attempt has yet to implement asynchronous invalidation done by snapd when interfaces are changed
<zyga> ok, I'll start writing something
<tyhicks> zyga: no matter what, a combination of (1 or 2) and 3 is needed
<zyga> tyhicks: yeah, I think we agree on how this must work
<zyga> tyhicks, jdstrand: thanks for your time
<zyga> I'll write a new proposal and share it
<jdstrand> zyga: one way to solve the async problem is for snap-confine to notice that if mnt.complete exists, see if anything is in the mount point. if nothing, tear it down and start anew. this has the advantage of not messing with running processes
<mhall119> mvo: ping, can I set runtime envvars for a snap yet?
<jdstrand> that should probably be handled in a future commit
<zyga> jdstrand: yes, essentially either we reach .complete and see the mnt file (and by see I mean we opened both) or we tear-and-restart
 * jdstrand nods
<zyga> it's somewhat confusing in semantics as two processes can be in one snap and not share a namespace though
<zyga> that is pretty annoying :/
 * zyga thinks if that means we're back to the drawing board
<jdstrand> this is precisely why for a system like snappy avoiding use of namespaces is a good thing. the mount one is arguably the easiest to deal with and look how hard it is! :)
<zyga> 1: a mount namespace that cannot be invalidated; 2: a set of mounts to process that can be safely undone; that would let us still share one namespace across fstab changes
<zyga> jdstrand: I fully agree
<mup> PR snapd#1761 opened: integration-tests: remove them in favour of the spread tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1761>
<zyga> jdstrand: and I bet I still don't grok shared subtrees with all their subtle details correctly
<jdstrand> (ie, being in teh global namespace and mediating through other means is is way simpler)
<jdstrand> zyga: who does? :P
<zyga> jdstrand: don't you and tyhicks? :-)
<jdstrand> I'll defer to tyhicks :)
<zyga> the fact that you can bind mount *a symlink* over somewhere to share a namespace was my "o_O" moment of the day
<jdstrand> I find myself always reminding myself with man pages, etc
<zyga> or that you can bind mount over files to make symlinks
<zyga> that's damn powerful
<zyga> I'd love to see an atomic mount flag that unbinds anything present there
<zyga> hmm
<zyga> tyhicks: is that just MS_REMOUNT?
<zyga> MS_REMOUNT|MS_BIND
<tyhicks> zyga: that would probably work but we'd have to test
<zyga> tyhicks: no worries, I'll explore this myself
<zyga> cool stuff :)
<mhall119> jdstrand: I'm trying to snap qupzilla, a qtwebengine based browser, and I'm getting: http://paste.ubuntu.com/23089689/
<zyga> this is why I love this work :)
<mhall119> jdstrand: is that a problem with the browser-support sandboxing?
<mhall119> http://paste.ubuntu.com/23089692/ is the snap.yaml, I wasn't entirely sure how to set allow-sandbox:true
<mvo> mhall119: almost, #1254  needs to land
<mhall119> mvo: ack, how close is that?
<mvo> mhall119: it could land today, except there are test failures that need to be debugged
<mvo> mhall119: but days
<mhall119> ok
<mvo> mhall119: not weeks like before, the big pre-requiste (new ubuntu-core) has landed
<jdstrand> mhall119: use either the 'allow-sandbox' attribute or launch with --disable-setuid-sandbox
<mup> PR snapd#1735 closed: tests: fixes to make the ubuntu-core-16 image usable with -keep/-reuse <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1735>
<jdstrand> mhall119: note that 'allow-sandbox: true' is going to require manual approval and is only meant as transitional policy for official upstream like mozilla and google until they modify their sandboxes to work with snappy
<jdstrand> mhall119: qtwebengine may have some other way to disable it. I don't know
<mhall119> jdstrand: is my snap.yaml correct to set allow-sandbox: true?
<zyga> jdstrand: unrelted question, is the apparmor process label in any way related to cgroups?
<jdstrand> mhall119: yes
<jdstrand> mhall119: oh, your snap doesn't have the sandbox as setuid
<mhall119> what does that mean?
<jdstrand> mhall119: your only option is --disable-setuid-sandbox
<jdstrand> mhall119: chromium uses a setuid sandbox to setup stuff
<jdstrand> mhall119: snaps aren't allowed to ship setuid binaries
<mhall119> wasn't this interface created to support chromium's use case?
<jdstrand> mhall119: I'm sure there is a configuration option for qtwebengine to compile without it. electron does this for example
<jdstrand> mhall119: the interface was created to support mozilla and google's official browsers with their privileged sandbox mode, and the chromium content api without the privileged sandbox mode
<jdstrand> mhall119: you should update to not use the privileged sandbox mode
<jdstrand> mhall119: this is a transitional interface to block these companies while they adjust their implementations to work with snappy
<jdstrand> err
<jdstrand> to unblock*
<jdstrand> mhall119: just do like electron and it'll be fine
<mhall119> jdstrand: where can I find how electron does it?
<jdstrand> compile it without the setuid sandbox
<jdstrand> that's all electron does
<jdstrand> you'll have to look at qupzilla's build options
<mup> PR snapd#1762 opened: Spread cups control <Created by mvo5> <https://github.com/snapcore/snapd/pull/1762>
<mvo> ogra_: just fyi, I prepare new images currently - with the new netplan stuff and for the first time from the beta channel :)
<mhall119> jdstrand: it does say "Running without the SUID sandbox!" in the output...so maybe it's something else?
<jdstrand> mhall119: I thought you were asking about the setuid sandbox. what is your question?
<jdstrand> failed to execvp:
<jdstrand> /snap/qupzilla/x1/usr/lib/x86_64-linux-gnu/qt5/libexec
<mhall119> jdstrand: trying to track down the error
<mhall119> yeah, just found that it was a bad envvar value
<mhall119> I have lots of other errors now, but at least that one is resolved :)
<mhall119> thanks jdstrand
<jdstrand> cool :)
<smoser> hey, i have an snapcraft.yaml that is building a nodejs thing happily.
<smoser> however, i'd like to add a symlink as part of that build.
<smoser> what i need to do is just execute: ln -s azure-cli bin/azure
<zyga> jdstrand, tyhicks: can you please re-review the document I shared earlier
<mhall119> smoser: I think you can create the symlink first, put it in the same directory as your snapcraft.yaml, and then use a copy plugin to put it where you want it
<smoser> but how do i "create the symlink first"
<mhall119> with your command above
<zyga> jdstrand, tyhicks: I've switched the docs to comment mode, please feel free to comment or suggest changes
<zyga> when you ack on it I will share it with gustavo again
<tyhicks> zyga: I already left one comment
 * tyhicks reviews the rest
<smoser> but that breaks the idea that you just run 'snapcraft'
<cjwatson> ogra_: you said "all arches" but you didn't list powerpc and that's not currently enabled; do you want that too?
<smoser> and probably breaks anything that would do that for me in an automated fashion
<smoser> because i then have to tell it "run 'ln' first"
<smoser> or maybe i'm  missing something.
<zyga> tyhicks: thinking about it, we could keep the .lock file global, if there are more namespaces to share we'll just use one file to protect them all
<zyga> tyhicks: this feels better because we either use one set or anther set of namespaces, not some random collection from the first set and second set together
<zyga> tyhicks: I won't make the change back unless you say so though
<tyhicks> zyga: if we use a global lock file, how do we indicate that all namespaces are initialized?
<zyga> tyhicks: you can only look for them when they are initialized
<zyga> tyhicks: just set them up
<tyhicks> ok
<zyga> tyhicks: and then bind mount them
<zyga> tyhicks: not before
<zyga> tyhicks: you can set them up without that file being there
<zyga> tyhicks: the only thing that can happen is snapd unmounting them as we do
<zyga> tyhicks: but that's a failure case that brings us back to the "let's do everything separately and cache if I can with the lock held" problem
<tyhicks> zyga: ok, you can change it back to a global lock
<zyga> tyhicks: OK
<zyga> done
<tyhicks> zyga: ack from me
<zyga> tyhicks: thank you!
<tyhicks> zyga: thank you!
<zyga> tyhicks: do you feel that we will support more namespaces as time progresses?
<zyga> tyhicks: (that we will unshare more?)
<tyhicks> zyga: I think it is something that we will need to be prepared to do
<zyga> jdstrand: given tyler's ack I'll share this with gustavo
<zyga> niemeyer: please re-review if you can (same URL, also linked from bug repott)
<zyga> report*
<tyhicks> zyga: there's one thing that I just realized I'm not clear on: how does snap-confine know when to set up the shared namespace?
<zyga> tyhicks: when it cannot setns() one
<tyhicks> zyga: so it will do this routine for every snap that gets launched?
<tyhicks> I guess Design Requirement #1 makes that clear
<tyhicks> I have no problem with that
<tyhicks> I just wasn't clear
<tyhicks> thanks
<jdstrand> zyga: sorry got pulled aside. couple of typo/clarifications in the doc. ack from me
<blackboxsw>  hmm, is snappy-playpen supposed to be examples of best practices? Trying to run snapcraft v2.15.1 doesn't build  for multiple qt-based example snaps such as texworks, 2048, qownnotes, vlc etc. Snapcraft chokes on the after clause containing a shared remote part desktop/*  the slash causes processing to barf with \u29f8' in position 48: ordinal not in range(128)
<blackboxsw> it seems in some cases (like game-2048) I'm able to replace the nasty '/' with a hyphen because there are not desktop-qt5 and desktop-qt4 shared remote parts published at https://wiki.ubuntu.com/snapcraft/parts
<mup> PR snapcraft#758 opened: Add an integration test for parts with filesets <Created by jocave> <https://github.com/snapcore/snapcraft/pull/758>
<qengho> blackboxsw: It's not Best, not necessarily. It lags behind snapcraft by a bit.
<blackboxsw> shall we push changes to snappy-playpen to resolve these build issues for the time being?
<qengho> blackboxsw: Yes. Or file bugs reports.
<wililupy> Question: After I build my image and install it on my device, I run snap list and it doesn't show any snaps. Is this normal?
<blackboxsw> qengho, I've been watching https://bugs.launchpad.net/snapcraft/+bug/1607015 in hopes that it'll get addressed, but I'm not certain when that would be.
<mup> Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Confirmed> <https://launchpad.net/bugs/1607015>
<qengho> blackboxsw: yep. Me either.
<qengho> wililupy: I think you should see at least ubuntu-core package. :\
<wililupy> ubuntu@localhost:~$ snap list
<wililupy> No snaps are installed yet. Try 'snap install hello-world'.
<Pharaoh_Atem> zyga: how are you progressing on the removal of /snap?
<ogra_> cjwatson, no, i was referring to the arches snappy supports, sorry ... only s390x
<qengho> blackboxsw: I don't know a lot here, or if this will help, but I think you should use parts as they're named in  https://parts.snapcraft.io/v1/parts.yaml
<blackboxsw> +1 qengho. I think so too, I *think* we probably need to remove the unusable desktop/* parts though as it seems like they cannot be sourced as a "remote part" in the after clause of snapcraft.yaml. It seems the desktop/(qt4|qt5|gtk2|gtk3)  is replaced with a snapcraft parseable desktop-(qt4|qt5|gtk2|gtk3) etc.
<ogra_> qengho, blackboxsw see bug 1607015
<mup> Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <Snapcraft:Confirmed> <https://launchpad.net/bugs/1607015>
<ogra_> (thats the reason for the breakage)
<blackboxsw> ogra_, I commented on that bug ;)
<ogra_> ah, that was you :)
<blackboxsw> s/blackboxsw/Chad Smith/ :)
<ogra_> well, the playpen guys are most active on gitter
<ogra_> https://gitter.im/ubuntu/snappy-playpen to be precise
<blackboxsw> yeah I had filed the duplicate https://bugs.launchpad.net/snappy/+bug/1612441
<mup> Bug #1612441: Cannot include wiki-defined part desktop/gtk2 in after clause <landscape> <Snappy:New> <https://launchpad.net/bugs/1612441>
<blackboxsw> thx for the pointer  ogra_
<ogra_> :)
<josepht> '/' is going to be deprecated in snapcraft 2.16.  The wiki has been updated with the '-' version of those parts as has the origin repo.
<mup> PR snapd#1763 opened: many: clarify/tie down model assertion <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1763>
<mup> PR snapd#1760 closed: overlord/state: prevent change ready => unready <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1760>
<mup> PR snapd#1722 closed: many: support install and remove by revision <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1722>
<nacc> did anything change recently for local plugins?
<nacc> (in 16.10's snapcraft, i guess)
<nacc> i keep getting 'unknown plugin: glide', even though i have parts/plugins/glide.py ?
<qengho> nacc: Did it work before?
<nacc> qengho: similar syntax has worked before, yeah
<nacc> the 'glide' plugin i have locally is a pretty trivial subclass of the go plugin
<qengho> nacc: Try with "strace -e trace=file -f -o snapcraft.strace snapcraft". Then, "grep glide snapcraft.strace".
<mup> PR snapd#1703 closed: tests: test all snap ubuntu core upgrade <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1703>
<nacc> qengho: hrm, i see it looking (stat'ing) parts/plugins, but not even trying to open said file
<qengho> nacc: I remember that the plugins were supposed to start with "x-". Maybe that matters?
<nacc> qengho: just tried changing that locally, still no dice
<nacc> qengho: x-glide.py and x-glide in yaml
<qengho> Er, "glide" in yaml. "x-glide.py" on filesystem.
<nacc> qengho: it must be a search thing, as i'm using cleanbuild and it's not even kicking off the container, it would be nice to know what it's searching for
<nacc> qengho: oh really?
<nacc> let me try that
<nacc> qengho: still says 'unknown plugin' :/
<nacc> qengho: ah but that did change the strace! :)
<qengho> nacc: pastebin that grep.
<mup> PR snapd#1761 closed: integration-tests: remove them in favour of the spread tests <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1761>
<nacc> qengho: http://paste.ubuntu.com/23090363/
<qengho> stat but no open. Huh.
<nacc> yeah, weird
<qengho> nacc: Now pastebin "
<qengho> nacc: Now pastebin "grep plugins snapcraft.strace"
<nacc> qengho: bah, i figured it out
<nacc> qengho: it was a mistake in the import
<nacc> qengho: but since importerrors are suppressed...
<nacc> qengho: thanks for the help!
<qengho> Ah hah.
<nacc> this feels like a common thing (and python will raise a far more helpful ImportError than 'unknown plugin' :)
<qengho> nacc: Yeah, maybe that ImportException suppression should check the stack depth. Mind filing a bug?
<nacc> qengho: yep, will do
<qengho> nacc: Thank you.
<jcastro> rcj: Hey I could only get your cloudprint snap to work when I installed it in devmode
<nacc> qengho: summarized at LP: #1617052
<mup> Bug #1617052: snapcraft: do not suppress ImportErrors for top-level exceptions with local plugins <Snapcraft:New> <https://launchpad.net/bugs/1617052>
<jcastro> rcj: nm, I didn't read your instructions in the yaml file
<mup> PR snapd#1764 opened: Mvo's snap-download2++ <Created by chipaca> <https://github.com/snapcore/snapd/pull/1764>
<Guest94467> Hi ! I have a short question: Is it possible to access a mounted USB drive from a snap using a "strict" confinement ?
<rcj> jcastro, good to hear that you got it working.  sorry I didn't see this earlier to help you out
<mup> PR snapd#1724 closed: snap: add  `snap download` implementation <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1724>
<mup> PR snapd#1763 closed: many: clarify/tie down model assertion <Critical> <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/1763>
<jhobbs> i'm trying to package a snap made from two python2 parts, each of which includes some .so depenencies that are built during the packaging
<jhobbs> some of the .so's are for the same packages and so are at the same path, but have some small differences in them, because they were built at different paths, and at different times maybe - non functional differences
<jhobbs> I end up with an error like this "Parts 'tempest' and 'ceilometer' have the following file paths in common which have different contents:"
<jhobbs> I would like to exclude those paths from one of the parts and keep it in the other - is filesets the right way to do that?
<kyrofa> jhobbs, yes, though the real keywords you're looking for are stage and/or snap (which can use filesets if you like, but don't require them)
<jhobbs> ah stage is doing it! yay!
<jhobbs> thanks kyrofa
<kyrofa> jhobbs, sure thing!
<Guest94467> To access to the USB ports from a snap (strict confinement), is there a way to create an interface (plug/slot) ? or something else ?
<mwhudson> elopio: it's in yakkety already, i should think about making it the default soon i guess
<mwhudson> elopio: not going to SRU it to xenial, you can add ppa:gophers/archive though
<elopio> mwhudson: thanks! I wanted to make a snap that requires go1.7. snapcraft doesn't support PPAs yet, but today we were talking about adding build deps as parts instead.
<elopio> mwhudson: would you be insterested in making parts for go?
<mwhudson> elopio: i guess so, i'm not very familiar with how that end of things works
<mwhudson> can you just download the deb and unpack it with dpkg-deb? :)
<mwhudson> so i see a long conversation about netplan in the scrollback, i guess i should read it
<elopio> mwhudson: we could, yes. That's the cool thing about the parts. We could have go1.7-from-deb, go1.7-from-archive, go1.7-build-from-source. If we do this nicely, then the part that depends on go could use them interchangeably.
<elopio> it's late and I'm hungry. I'll bbs.
<cjwatson> ogra_: ta
<wililupy> How can I verify snap env variables?
<wililupy> I think my $SNAP_APP_PATH and $SNAP_APP_DATA_PATH are incorrect for my startup script.
<kyrofa> wililupy, those are 15.04 variables. Are you using 15.04?
<wililupy> kyrofa: no, 16.04. I changed them in my script to $SNAP and $SNAP_DATA
<wililupy> re-compiling and building now....
<kyrofa> wililupy, yeah that's what you need
#snappy 2016-08-26
<wililupy> kyrofa, that seemed to fix it. The modules and everything load up, but it is still quite odd that a clean custom image I build with ubuntu-device-flash shows no snaps installed until I install my snap, and then it downloads ubuntu-core and then when I reboot my system, it crashes. A clean install would show three snaps, ubuntu-core, my custom-kernel and pc, but now it says no snaps installed.
<kyrofa> wililupy, sorry, I'm not sure what the situation is regarding all-snaps images. Have you tried downloading one of mvo's?
<wililupy> I was just going to try that when my snapcraft snap finished and I tested that.
<wililupy> Looks good so far, I have a dependency missing, so I have to figure that out...
<wililupy> kyrofa: I am using a modified version of your fboss snap from github to work with the Wedge 100.
<kyrofa> wililupy, ah, oay
<kyrofa> okay*
<wililupy> kyrofa: I'm going to push my updates to my fork and then look at mvo's all-snap tomorrow. I am including the kmods with the snap, so it is a little easier to try with the all-snap image instead of a custom kernel.
<beisner> hi ev, niemeyer - looking to start using spread asap while we're redeploy some openstack ci infra.  i've got a fresh xenial instance, can launch and list lxc a-ok as my user, but can't get spread to do the examples:  http://pastebin.ubuntu.com/23091151/  ideas?
<kyrofa> beisner, yeah, try running it from source instead
<kyrofa> beisner, the snap doesn't have permission to reach out like that
<kyrofa> beisner, do you need help with that?
<kyrofa> (qemu backends have the same problem)
<kyrofa> The snap is only really useful if you're using remote backends
<mwhudson> $ sudo snap refresh --beta --devmode ubuntu-device-flash
<mwhudson> - Setup snap "ubuntu-device-flash" (9) security profiles (cannot setup apparmor for snap "ubuntu-device-flash": cannot load apparmor profile "snap.ubuntu-device-flash.ubuntu-device-flash": cannot load apparmor profile: exit status 10
<mwhudson> what?
<mup> PR snapcraft#759 opened: Remove the useless call to os.path.join from the go plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/759>
<mwhudson> well rebooting and reinstalling fixed that
<beisner> hi kyrofa thanks for the info.  just for kicks i removed the snap, reinstalled it in devmode, still the same.   so, go get ftw?
<smoser> what does this mean ?
<smoser>  Cannot get permission from the store to upload this package.
<smoser> trying to have launchpad build a snap package for me
<smoser> it says:
<smoser> If you ask Launchpad to automatically upload builds of this snap to the store on your behalf, then the login service will prompt you to authorize this request.
<smoser> so i expected it to ask me or something, but it just says fail
<mup> PR snapd#1765 opened: many: move network initialization to a separate service <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1765>
<mup> PR snapcraft#760 opened: Removed statements not unused by the tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/760>
<mup> PR snapd#1766 opened: image, asserts: add new asserts.Fetcher.SavedRefs() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/1766>
<zyga> good morniong
<zyga> *morning
<josvaz> Question about snaps and folder access / interfaces. For my snap I need to mount a folder so that the normal users can write to it and the snap can read it.
<josvaz> how can I achieve that?
<mup> PR snapd#1766 closed: image, asserts: add new asserts.Fetcher.SavedRefs() helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1766>
<ogra_> mvo, mind if i ubpublish all the canonical-* snaps ?
<mvo> ogra_: not at all
<Guest80394> Hi ! I am sorry to disturb the channel. I have a short question: I try to connect a USB drive to my snap. I did not find a way to do this with the "strict confinement" mode. It only works with the "devmode". Is there a way using interfaces ?
<zyga> Guest80394: hey, I don't believe there is right now but it should be simple to add
<zyga> Guest80394: look at the home interface, a similar interface could mediate access to /media or /run/media or anything like that
<zyga> Guest80394: it should be very easy to contribute if you want to
<Guest80394> ok, I will look at this !
<ogra_> mvo, hmm, did we seed subiquity already ? my serial console is a huge readable mess after rebooting on all my images
<ogra_> *unreadable
<ogra_> mvo, http://paste.ubuntu.com/23092374/
<ogra_> the last line fill multiple pages
<ogra_> '*fills
<zyga> Guest80394: look at zygoon.pl, I posted some articles about this there
<zyga> Guest80394: and ping me here for advice :-)
<mvo> ogra_: it landed last night
<mvo> ogra_: apparently a hard landing
<Guest80394> Thanks a lot !
<ogra_> mvo, extremely buggy ... and it seems to run regardless if the system is cionfigurede
<ogra_> *configured
<mvo> ogra_: lets talk to cyphermox, mwhudson or slangasek about the bugs in console-conf: http://paste.ubuntu.com/23092374/
<ogra_> on the dragonboard i now have a network config dialog
<mvo> ogra_: if its too buggy we can revert the upload
<mvo> ogra_: its a single line in livecd-rootfs from last night
<ogra_> it is more than console-conf ... unless that also does network config etc ... and it is definitely not safe for serial
<mvo> ogra_: it does
<mvo> ogra_: and yeah, it takes over the gettys
<ogra_> ah, i thought it cionfigures the coneole :)
<mvo> ogra_: its a bit misleading the name
<ogra_> right, if it does so, it should probably use settings from d-i or so to make sure you dont end up with multiple lines of control chars :)
<ogra_> in any case i cant do any unattended reboot anymore
<mvo> ogra_: and I want my getty back
<mvo> ogra_: if its too anoying, just revert, I think that is fine
<ogra_> the boot hangs at a prompt (which i cant even see on the pi... but see on the dragonboard (different serial consoles i guess))
<ogra_> mvo, oh, fun ... and it doesnt recognize my configured wlan0 devices on both boards ... so i'm stuck in the config screen
<ogra_> i'll unseed it once i reported all the bugs ... oh my
<mvo> ogra_: oki doki, thanks
<mup> PR snapd#1747 closed: overlord, daemon: add collect attribute hooks <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/1747>
<mup> PR snapd#1767 opened: overlord, daemon: add collect attribute hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/1767>
<mup> PR snapd#1763 closed: many: clarify/tie down model assertion <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1763>
<mup> PR snapd#1616 closed: tests, integration-tests: implement the cups-control manual test as a spread test <Decaying> <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1616>
<mup> PR snapd#1759 closed: asserts: fix GPG key generation parameters <Created by cjwatson> <Conflict> <https://github.com/snapcore/snapd/pull/1759>
 * ogra_ sighs ... so how do i get out of this .. i cant boot at all anymore 
<ogra_> (it tries to configure the already configured wlan devices, falis and drops me back to the start screen ... there is no way to skip)
<mup> PR snapd#1759 closed: asserts: fix GPG key generation parameters <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1759>
<mup> Bug #1617231 opened: subiquity kills serial console after regular update <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1617231>
<mup> Bug #1617232 opened: subiquity goes into endless configuration loop, no way to get out <Snappy:New> <https://launchpad.net/bugs/1617232>
<ogra_> pitti, i fear in the light of that one ^^^ Bug 1616928 should get a higher urgency
<mup> Bug #1616928: netplan should support managing wlan devices via wpasupplicant <nplan (Ubuntu):Triaged> <https://launchpad.net/bugs/1616928>
<ogra_> (assuming that subiquity actually tries to use netplan in the backend)
<mup> Bug #1617236 opened: console-conf falls over trying to create already existing logdir <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1617236>
<mup> PR snapd#1753 closed: asserts: add an account-key-request assertion <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1753>
<pitti> ogra_: ah, I can't get out either, as even though it is online it doesn't accept any email address of mine for registering to the snap store
<ogra_> what a mess
<pitti> ogra_: but yes, wlan is another issue indeed
<ogra_> pitti, file a bug ..., i'll unseed it now and re-spin ubuntu-core afterwards
<pitti> communication breakdown -- when this was discussed a few weeks/months ago, the plan was still "use NM for wifi"..
<ogra_> pitti, well, the worst is that the console-conf process actually consumes 16-25MB ...
<pitti> ogra_: yep, will do; I'm sorting out some other console-conf issues with mwhudson (currently blocked on getting a VM image that actually works)
<pitti> ogra_: welcome to python :)
<ogra_> and it spawns a new process every time i ctrl-c out of it
<ogra_> yeah, the worst choice for arm
<ogra_> i guess that bumps our ram requirements from ~64MB to 128 for embedded boards ...
<ogra_> :(((
<pitti> for those you could skip console-conf somehow perhaps (kernel arg or pre-create the firstboot stamp file etc.)?
<ogra_> so you mean for all of them ?
<ogra_> :)
<ogra_> (like all boards)
<ogra_> so depressing :/
<ogra_> cyphermox, mwhudson, slangasek, i unseeded console-conf again for now, it breaks to many things atm
<ogra_> woah ...
<ogra_> ubuntu@dragonboard:~$ ps ax -orss=,args=|grep 24228
<ogra_> 24228 python3 /usr/bin/console-conf
<ogra_> ubuntu@dragonboard:~$ sudo kill -9 24228
<ogra_> ubuntu@dragonboard:~$ ps ax -orss=,args=|grep 24228
<ogra_> 24228 python3 /usr/bin/console-conf
<ogra_> very reluctant to be killed :P
<pitti> Restart=always
<mup> Bug #1617250 opened: 401 errors trying to install a snap <Snappy:New> <https://launchpad.net/bugs/1617250>
<mup> Bug #1617251 opened: console-conf unkillable <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1617251>
<ogra_> pitti, weeeelll ... wouldnt a restart assign a new PID ?
<pitti> but systemctl stop console-conf.service also is broken as there are about three endless loops
<pitti> ogra_: ^
<pitti> ogra_: err yes, kill -9 not working??
<ogra_> right
<ogra_> it keeps the PID
<ogra_> no matter how often i kill -9
<mup> PR snapd#1744 closed: snap: use "up to date" instead of "up-to-date" <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1744>
<rogpeppe> so, i've just made a snap that contains a single Go binary (app) that just makes HTTP connections. to make it work, I had to configure it with network, firewall-control and network-bind plugs. Anyone know why? It seems like I should only need "network".
<rogpeppe> also, when I didn't have the required plugs, the binary just hung when I ran it. Is that the expected failure mode?
<ogra_> it needs to create a socket ... "network" is only for client side things ... for the socket creation you need -bind ...
<ogra_> not sure why you would need firewall though
<rogpeppe> ogra_: how can you be a network client without creating a socket?
<ogra_> (i definitely dont need it for any of my network server snaps )
<rogpeppe> ogra_: ah, it's possible i don't need firewall-control - i added that first
<rogpeppe> ogra_: i'd have thought that network-bind was only necessary for listening on network ports, not making outgoing connections
<ogra_> https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<rogpeppe> network-bind says "Can access the network as a server"
<ogra_> network
<ogra_> Can access the network as a client.
<ogra_>     Auto-Connect: yes
<ogra_> network-bind
<ogra_> Can access the network as a server.
<ogra_>     Auto-Connect: yes
<rogpeppe> ogra_: yeah. and this program isn't a server.
<rogpeppe> ogra_: it's just making an outgoing connection
<ogra_> so if your binary actually only does client connections network should be enough
<rogpeppe> ogra_: that's what i thought
<ogra_> aks jdstrand once he is up :)
<rogpeppe> hmm, and now i can't replace the snap because (whenever i do snap install or snap remove) i get 'snap "bhttp" has changes in progress'
<ogra_> well, look at snap changes (and "snap change $number" for details) ...
<rogpeppe> hmm, and that's because i aborted a "remove" operation that seemed to be taking forever. i did "snap abort" and i still can't do "snap remove"
<ogra_> iirc you can also "snap abort"
<ogra_> give it a bit, it works async ...
<rogpeppe> ogra_: yeah, i tried that. but "snap remove" takes forever
<ogra_> might need some time to time out
<rogpeppe> ogra_: well, ok, i'll give it a few minutes
<rogpeppe> ogra_: do you think 5 minutes should be enough?
<ogra_> no idea :)
<stub> I've got a daemon that insists on not being run as root. Should my wrapper create the user and suid to it? Would that actually work?
<ogra_> no, it wouldnt
<ogra_> snap daemons always run as root
<rogpeppe> ah, looks like this might be the culprit: Aug 26 11:52:56 snazzy umount[9073]: umount: /snap/bhttp/x1: target is busy
<ogra_> are you in there with your shell ?
<stub> ok, so for now I need to patch unless they have hidden an option in there somewhere to allow it...
<rogpeppe> ogra_: no, but there's a <defunct> process running the binary
<ogra_> ouch
<ogra_> stub, i fear so, yeah ...
<mup> Bug #1617275 opened: the home interface doesn't allow access to $HOME/snap-confine <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1617275>
<rogpeppe> ogra_: ok, success: i did "kill -9" on the defunct process, then aborted the remove operation and tried again and it worked.
<rogpeppe> ogra_: not a fantastic user experience though... :)
<ogra_> rogpeppe, definitely not, file bugs ;)
<rogpeppe> ogra_: will do; it'll be the third bug this morning :)
<ogra_> i'm at 5 for today :) chase me ;)
<rogpeppe> ogra_: https://www.google.co.uk/imgres?imgurl=http://t1.gstatic.com/images%3Fq%3Dtbn:ANd9GcTLjo_Nzd7eLrqGEG9ddoRlkUaAV7Q24KziKV2u5i6R-weg4Kgb&imgrefurl=http://books.google.com/books/about/Snappy_Little_Bugs.html%3Fid%3DrC3iGAAACAAJ%26source%3Dkp_cover&h=769&w=621&tbnid=URJ9QWARZ6Uq5M:&tbnh=160&tbnw=129&docid=bPGBY9Q323zj2M&itg=1&usg=__-RYGSWUfDcjgnJL1FRx3M0oDlwI=
<rogpeppe> ogra_: :)
<ogra_> haha
<rogpeppe> ogra_: https://bugs.launchpad.net/snappy/+bug/1617278
<mup> Bug #1617278: remove hung forever due to defunct process <Snappy:New> <https://launchpad.net/bugs/1617278>
<ogra_> thx
<mup> Bug #1617278 opened: remove hung forever due to defunct process <Snappy:New> <https://launchpad.net/bugs/1617278>
<rogpeppe> ogra_: ok, it seems that only network and network-bind are needed. but what's weird is that the binary won't run at all (even to print a help message) without both of those plugs.
<ogra_> i guess your syslog should have some DENIED lines then
<rogpeppe> ogra_: this is the line i see:
<rogpeppe> Aug 26 12:10:40 snazzy kernel: [117476.140023] audit: type=1326 audit(1472209840.610:190): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=10082 comm="bhttp" exe="/snap/bhttp/x3/bin/bhttp" sig=31 arch=c000003e syscall=49 compat=0 ip=0x5fbcb4 code=0x0
<zyga> rogpeppe: that's bind
<rogpeppe> zyga: syscall 49?
<zyga> rogpeppe: it gets killed when it cannot use a syscall it tries
<zyga> rogpeppe: yes, 49 is bind
<ogra_> mvo, seeing https://github.com/snapcore/snapd/pull/1684 ... should we also unseed the package (we explicitly have it in livecd-rootfs currently)
<mup> PR snapd#1684: many: drop ubuntu-core-snapd-units package, use release.OnClassic instead <Reviewed> <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1684>
<rogpeppe> zyga: hmm, i wonder why... i wonder if i can make it panic when it does that
<zyga> rogpeppe: panic?
<zyga> rogpeppe: you get SIGKILL from the kernel
<rogpeppe> zyga: also, is it right that the binary should just hang when it does that?
<zyga> rogpeppe: it kills the offending thread
<rogpeppe> zyga: hmm, not the whole process?
<zyga> rogpeppe: depending on the way your program works it will just hang
<zyga> rogpeppe: nope
<rogpeppe> zyga: ok, that's probably the reason - it's a go program with multiple threads
<zyga> rogpeppe: yeah, it's unpredictable what will happen
<rogpeppe> zyga: any way to configure different behaviour?
<zyga> rogpeppe: not at present, I believe there's a bug about switching seccomp to return EPERM, we may be able to revive it
<rogpeppe> zyga: ah, i see now - the Go net package uses bind to probe to see if the kernel has ipv6 functionality
<zyga> rogpeppe: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001708.html
<zyga> rogpeppe: that's correct, there's a separate bug about that, I've done the same investigation
<rogpeppe> zyga: so you can't have *any* Go program that imports /net without allowing the network-bind plug
<rogpeppe> zyga: i think i'll raise a Go bug about this
<rogpeppe> ah, there already is a bug: https://github.com/golang/go/issues/16789
<zyga> I'm looking for the bug on golang
<zyga> er
<zyga> snapd
<zyga> I cannot find it
<ogra_> i think you can work around that by using a wrapper script with exec, so that systemd handles it differently
<zyga> I'm sorry
<mup> Bug #1617264 opened: confusing error when installing snap when not logged in <Snappy:New> <https://launchpad.net/bugs/1617264>
<mattyw> hey folks, the icon guidelines link here is broken: https://developer.ubuntu.com/en/publish/creating-a-good-icon/
<mattyw> ^^ where should I report that
<mattyw> and can anyone tell me what dimension a snaps icon should be?
<ogra_> what do you think is broken about it ?
<ogra_> (my icons all work fine still)
<mvo> ogra_: good point about unseeding the scripts bits
 * ogra_ is happy about every bit he can remove ... :) just working on getting rid of all the partitioning tools and initramfs-tools in ubuntu-core 
<ogra_> (well, at least initramfs-tools-ubuntu-core ... seems apparmor has a hard dep on the generic initramfs-tools )
<zyga> Chipaca: https://github.com/snapcore/snap-confine/pull/120/files
<mup> PR snap-confine#120: Fix regression test when re-exec kicks in <Created by zyga> <https://github.com/snapcore/snap-confine/pull/120>
<zyga> Chipaca: care for a quick review of what we've just discussed?
<Chipaca> zyga, three things
<Chipaca> zyga, you're not stopping the .socket
<Chipaca> zyga, and, you can start/stop n all together in a single line
<zyga> Chipaca: I'm also not using it though I guess I can just stop it and be on the safe side
<zyga> oh?
<zyga> how :)
<Chipaca> zyga, systemctl stop foo bar baz
<zyga> ah
<zyga> thanks, doing that
<Chipaca> zyga, also also, systemctl stop snapd.{service,socket,refresh.timer}
<Chipaca> but not sure if the bash these things run in has brace expansion
<zyga> I've just spelled it out
<Chipaca> fair
<zyga> Chipaca: fixed, I also dropped sudo
<zyga> look again please
<Chipaca> zyga, question: instead of âumount $(ls -1d /snap/ubuntu-core/* | grep -v current | tail -1)â, wouldn't âummount /snap/ubuntu-core/$(readlink /snap/ubuntu-core/current)â work?
<zyga> Chipaca: perhaps, I didn't write this, jdstrand did
<zyga> Chipaca: I'm happy to improve it when it is green again
<Chipaca> ah ok
<Chipaca> zyga, go for it (once green)
<zyga> thanks
<rogpeppe> so i seem to have published my snap (https://myapps.developer.ubuntu.com/dev/click-apps/5803/feedback/) but i still can't "snap install" it. anyone know what I'm doing wrong?
<rogpeppe> is it just that i have to wait for a while for things to happen behind the scenes?
<zyga> rogpeppe: is that snap published to the stable channel?
<Chipaca> rogpeppe, what icon does the revision have next to it? a thumbs up, or a green box?
<rogpeppe> zyga: i think so. (i ran "snap release")
<rogpeppe> Chipaca: checking
<rogpeppe> Chipaca: a green box
<Chipaca> rogpeppe, and what's the snap called?
<rogpeppe> Chipaca: bhttp
<Chipaca> rogpeppe, if i can ask :-)
<rogpeppe> Chipaca: so that URL is personal?
<Chipaca> rogpeppe, yes
<rogpeppe> Chipaca: is there a URL for the snap that I can share?
<Chipaca> i get âYou just tried to access a feature which you don't have permission to use.â
<Chipaca> rogpeppe, what channels is it published to?
<rogpeppe> Chipaca: i'm not sure where there's a page i can search for snaps
<rogpeppe> Chipaca: stable
<Chipaca> rogpeppe, i can confirm it isn't there :-)
<Chipaca> rogpeppe, I was about to point you at https://snapfui.herokuapp.com/ but it's broken right now :-(
<Chipaca> beowulf, ^
<rogpeppe> Chipaca: what technique did you use to confirm that?
<ogra_> uappexplorer :)
 * rogpeppe googles that
<Chipaca> rogpeppe, "snap find bhttp"
<Chipaca> rogpeppe, is it ARM-only?
<Chipaca> or i386 or something other than amd64 or all
<rogpeppe> Chipaca: no, it's amd64-only
<Chipaca> hmmm
<rogpeppe> Chipaca: AFAIK
<rogpeppe> Chipaca: i didn't set any architectures
<rogpeppe> Chipaca: one mo, i'll send you a screenshot
<Chipaca> rogpeppe, you could wait until somebody with more access than i takes a look, or you can send me a screenshot :-)
<ogra_> rogpeppe, does it have a little green box next to the version in the UI ?
<Chipaca> rogpeppe, m v o   should be able to see things, but he's a busy person
<Chipaca> ogra_, yep
<ogra_> hmm
<mup> PR snapd#1768 opened: many: automatically restart all-snap devices after os/kernel updates <Created by mvo5> <https://github.com/snapcore/snapd/pull/1768>
<rogpeppe> Chipaca: http://imgur.com/a/5YksP
<rogpeppe> it *looks* like it's published to me, but maybe i'm missing some crucial piece of info
<mattyw> ogra_, hey there, sorry, this is very out of context now, but where you replying to me above? (the broken link)
<Chipaca> rogpeppe, that should work
<Chipaca> nessita, are you around?
<ogra_> mattyw, oh, i missed you meant a link, i thought you meant the instructions themselves
<ogra_> mattyw, not sure where to file it, davidcalle or dholbach might be able to point oyyu to the right place
<rogpeppe> Chipaca: right, but... you verified that it's not actually there, right?
<Chipaca> rogpeppe, right
<Chipaca> rogpeppe, hence me poking nessita
<rogpeppe> Chipaca: ok, i give up for now. i need to do some actual work :) let me know if you work anything out, please?
<ogra_> rogpeppe, if you scroll to the very bottom of the page there is also an "unpublish" button ?
<nessita> Chipaca, indeed I am
<rogpeppe> ogra_: you think i should unpublish so that i can try to publish again?
<Chipaca> nessita, ohi
<Chipaca> nessita, given http://imgur.com/a/5YksP
<ogra_> rogpeppe, no, i just want to know if that button is there
<rogpeppe> ogra_: yes, it's there
<Chipaca> nessita, which is https://myapps.developer.ubuntu.com/dev/click-apps/5803/
<Chipaca> nessita, what's missing, that snap can't find it?
<nessita> Chipaca, let me check
<Chipaca> nessita, thank you
<nessita> version 0 looks suspicius, but "in paper" shouldn't be an issue
 * nessita checks more
<zyga> tyhicks: https://github.com/snapcore/snap-confine/pull/119
<mup> PR snap-confine#119: Make snap mount directory configurable <Created by zyga> <https://github.com/snapcore/snap-confine/pull/119>
<zyga> tyhicks: I didn't change the apparmor profile yet but I'm about to
<nessita> Chipaca, not finding anything obvious, but I can't find it in CPI either, debugging more
<cyphermox> ogra_: I can haz logs? what does it break?
<cyphermox> the issue is this is hard to fix when I can't upload myself to that PPA and people leave pretty early
<Saeron> hi guys
<Saeron> i was looking for ubuntu disk image writer on snap
<Saeron> there are nor a lot of apps on this repo
<ogra_> cyphermox, you got a bunch of bugs ;)
<Chipaca> Saeron, early days :-)
<Chipaca> Saeron, it would be a nice one to snap up, i agree
<Saeron> can someone tell me if anyone can make a snap of this app
<Saeron> i men ihave to be the developper?
<Chipaca> Saeron, yes, anyone can make a snap of that app
<Saeron> the problem is i am not actually using ubuntu
<Saeron> and i cant find this app on manjara thats what i want a snap for it
<ogra_> cyphermox, but in general i think having some tool that adds an additionyl 25MB RAM requirement is not really a good idea, is there no way to do it in ncurses or dialog instead of python3 ? it currently actually doubles our minimal ram reqs.
<cyphermox> ogra_: there shouldn't be that much; we build images with nearly the same stuff (probably a few revs behind in livecd-rootfs, but that's it) in our PPA with no issues whatsoever
<cyphermox> no, there isn't. We'll have to see about the RAM usage. I'm shocked that it's as much as you say
<Saeron> so exits the posibility of a good soul make a snap from this app?
<ogra_> cyphermox, on the dragonboard i get two console-conf binaries each occupying 25MB RSS ... i noted that in one of the bugs
<Chipaca> Saeron, are you looking for the gtk version?
<Saeron> yes i am looking for the main ubuntu version
<ogra_> cyphermox, but thats totally not unusual for python on arm ... it is about 10x slower and eats a lot more ram thgan i.e. C or perl
<Saeron> Chipaca: yes
<Chipaca> Saeron, i could snap it, but over the weekend, not now
<Saeron> Chipaca: its all right, is not at urgent need is just i like a lot dat app and i think is a good one
<cyphermox> ogra_: where did you open the bugs?
<Saeron> Chipaca: thx, is gonna be awesome to have dat app on manjaro :)
<Chipaca> :-)
<ogra_> cyphermox, against the snappy project with additional tasks against the subiquity package
<ogra_> you should find them all under subiquity
<Saeron> Chipaca: i hope have time soon for see how to craft this apps
<Saeron> Chipaca: its really necesary to have ubuntu for do it?
<Chipaca> Saeron, i don't know about that side of things i'm afraid
<Chipaca> sergiusens might, if he's around
<ogra_> cyphermox, i know that mvo and pitti also did hit other bugs, not sure against what they filed them
<sergiusens> I am
<sergiusens> what's up?
<Chipaca> sergiusens, snapcraft on !ubuntu
<Chipaca> sergiusens, workie? no workie?
<sergiusens> Chipaca planned, not there yet
<Saeron> Chipaca: afraid about what
<ogra_> Saeron, he is afraid he doesnt know about it :)
<Saeron> what?
<ogra_> (justa phrase=
<ogra_> )
<ogra_> *just a
<Saeron> are you kidding me ?
<Chipaca> Saeron, just an expression of apology for not knowing something
<ogra_> ?
<sergiusens> Chipaca the plans we have involve snapd and core work as well; but that was a brainstorm with zyga, probably needs a concrete design
<Saeron> ok but what you dont know?
<Chipaca> Saeron, <Chipaca> Saeron, i don't know about that side of things i'm afraid
<Saeron> about if i can craft snap on othres dist diferents from ubuntu?
<mup> PR snapcraft#761 opened: Remove dangling symlink from JDK plugin <Created by gnuoy> <https://github.com/snapcore/snapcraft/pull/761>
<Chipaca> Saeron, means: i don't know
<Chipaca> Saeron, I then went on to mentions sergiusens was the person to ask about that
<Chipaca> Saeron, and he has since said that it won't work
<ogra_> but that it is planned
<Chipaca> ogra_, yes. Yes.
<ogra_> :)
<ogra_> nobody is kidding you ... we just seem to have a communication breakdown :)
<Saeron> ok xd i dont understand nothing jajajajaja
<sergiusens> Saeron subscribe to https://bugs.launchpad.net/snapcraft/+bug/1602258
<mup> Bug #1602258: Support other distributions as sources (Fedora, Mageia, openSUSE, Debian) instead of Ubuntu <centos> <debian> <fedora> <mageia> <opensuse> <rfe> <rpm> <snapcraft> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1602258>
<Chipaca> hmmm
<Saeron> ok now
<Chipaca> Saeron, from your laugh i suspect spanish would work better
<sergiusens> indeed ;-)
<Saeron> there is not suport for others dis
<Saeron> Chipaca: yeah i am a poor spanish
<Saeron> Chipaca: dont know a lot about english
<Chipaca> Saeron, nada de pobre, eh?
<Saeron> Chipaca: asi que tambien eres espaÃ±ol :)
<Chipaca> Saeron, bueno, eso, que no funciona. Que estÃ¡ planeado, pero en realidad lo que estÃ¡ planeado es planearlo.
<Saeron> Chipaca: ok bueno si haces el favor de hacer el paquete cuando tengas tiempo
<Chipaca> Saeron, sÃ­p, parece interesante, y el fin de semana es largo para mÃ­ \o/
<Saeron> Chipaca: no hay prisa, es simplimente lo que mejor me servia para raspberry pi
<Chipaca> Saeron, perfecto
<Saeron> Chipaca: a mi se me esta haciendo ya largo con una version de tftop en tcp que tengo que hacer en java
<ogra_> Chipaca, if my guessing of that spanish is correct he should be able to use the classic shell on his pi to use snapcraft
<Chipaca> and now back to your regularly scheduled programme
<Saeron> Chipaca: :(
<Chipaca> ogra_, he needs something to write things for the pi, not on the pi
 * zyga sees spanish everywhere
<ogra_> he can write wherever he wants .. and just build on the pi
<Saeron> ogra_: mm maybe but i only have raspberry pi 1 so i think i cant
<Chipaca> zyga, you're hallucinating
<zyga> Chipaca: must be the coffee
<zyga> ;-)
<ogra_> zyga, nah, it is all german, just with bavarian accent :P
<Chipaca> zyga, it's the lack of mediterranean sun.
<Saeron> ogra_: snap is not aviable on rp1 unfortunally :(
<ogra_> oh, pi1
<ogra_> yeah, sorry, that wont work
<zyga> Chipaca: it's surprisingly sunny here; always when holidays run out I guess
<Chipaca> zyga, hence the qualifier
<zyga> ogra_: I may learn some german soon, we're planning on visiting friends in dusseldorf
 * Chipaca -> tea and meetings
 * zyga spread and meetings
<zyga> and meetings
<zyga> and hopefully some code after
<ogra_> and altbeer :)
<ogra_> (regarding dÃ¼Ã¼sseldorf)
<zyga> oh
<ogra_> -Ã¼
<zyga> I need to package snapd-glib
<zyga> well
<zyga> that's easy by now
 * zyga gets around to do it
<ogra_> it isnt packaged ?
<ogra_> i thought it is
<sergiusens> ogra_ for all distros he means ;-)
<zyga> ogra_: maybe, I'm checking
<mup> PR snapd#1769 opened: snap: add export-key --account= option <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1769>
<ogra_> sergiusens, ah, i thought for ubuntu
<mup> PR snapcraft#759 closed: Remove the useless call to os.path.join from the go plugin <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/759>
<ogra_> urgh
<ogra_> morphis, so i just tried to install the nm snap on my pi3 (which has a perfectly fine configured /e/n/i setup for the wlan0 device already) ... over ssh ...
<ogra_> that now locked me out completely
<ogra_> why is it killing existing connections like that ?
<mup> Bug #1617302 opened: Specifying a nonexistent part does cause any errors <Snapcraft:Triaged> <Snappy:New> <https://launchpad.net/bugs/1617302>
<sborovkov> Hello. How do I keep snap in edge channel up to date? Should I add cron job to call snap refresh --devmode snap-name?
<ogra_> sborovkov, on a snappy image ?
<ogra_> if the image uses edge as well it will just auto-update
<sborovkov> ogra_: I have classic image
<ogra_> (though --devmode will not autop-refresh i think)
<ogra_> ah, k
<ogra_> there i dont know then
<sborovkov> Yes, that's why I was thinking what should I do. Considering that I need to specify both --devmode and snap's name to get it to refresh
<ogra_> yeah, i guess for --devmode there is no way around that
<ogra_> edge on an image that knows about edge wouldnt be a prob
<ogra_> hmm
<sborovkov> Do you know if there is some recommended mechanism to make it so that snap login does not expire?
<ogra_> ppisati_, did you actually notice that since we moved the dtb on the pi3 so high in ram you cant actually boot with mem= anymore ?
<ppisati_> ogra_: uhm nope
<ppisati_> ogra_: you mean to reduce the visible memory?
<ogra_> yeah
<ppisati_> nope
<ogra_> seems it reduces enough to also hide the dtb
<ogra_> my kernel just hangs
<ppisati_> i have vague memoris of faffing with that options
<ppisati_> *memoris
<ppisati_> and i remember i disoverd way it hanged when reducing the visible memory
<ppisati_> but it was long ago
<ogra_> hmm, even hangs with mem=1024m
<ppisati_> and i'm not even sure it was the raspi board
<ogra_> which shoudl actually be more than the board has (944)
<ogra_> probably not related to the dtb position then
<ppisati_> i wonder if the fw has anything to do with it
<ppisati_> since the dtb, usually, has an empty memory field
<ppisati_> and it's a task of uboot to fill that field
<ogra_> well, theer are also various gpu defaults that might kick in
<ppisati_> right
<ppisati_> and then we take a slice for the gpu too
<mup> Bug #1617314 opened: Cannot run daemons as non-root <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1617314>
<ogra_> yeah
<ogra_> so i guess it isnt a good system to try out differenmt ram sizes
<ppisati_> uhm nope
<ogra_> i know i was abnle to boot 15.04 on the BBB with mem=64m ... wanted to try out how the 16 images behave in that regard
<ogra_> but i guess i'd need a BBB image to actualyl do that (dragon is arm64 so not really representative)
<ppisati_> probably yes
<smoser> so these failures here: https://code.launchpad.net/~smoser/+snap/azure-cli
<smoser> thats simply "builders do not have internet access" right ?
<smoser> am i missing somethign? or does that kind of mean that some large percent of the snapcraft.yaml that people would create will not work there.
<morphis> ogra_: because nm currently doesn't take care of any connections defined in /etc/network/interfaces.d
<morphis> only about those which are in /etc/network/interfaces
<morphis> whoever introduced interfaces.d didn't adjust nm for this
<morphis> we have a patch for that pending
<ogra_> morphis, well, it would be nice if it could simply check for a default route and not kill existing connections
<morphis> but normally it should ignore all interface which are configured by ifupdown
<ogra_> i dont care if it trashes my /e/n/i setup as long as it doesnt lock me out out of the blue
<morphis> ogra_: in this case it takes control over wlan0 completely as it doesn't see its already managed by ifupdown
<morphis> ogra_: how should I do that if it does not have any provisioning information for that interface?
<ogra_> i.e. how would i switch over to nm on a remote device
<morphis> what do you mean by that?
<ogra_> morphis, by looking for a default route
<ogra_> morphis, i would expect nm to not touch anything until i configured it ... simply installing the package should not kill my existing connection
<ogra_> it shoudl notice there is a default route added to an interface ... and leave that interface alone until i tell it to use it
<morphis> afaik that makes things quite more complex, nm is supposed to be a network manager which is installed by default
<ogra_> it would even be fine if it already trashed my /e/n/i setup (and tells me it did) but doesnt ifdown the device
<morphis> ogra_: it shouldn't trash your ifupdown setup
<morphis> it should just ignore those interfaces ifupdown has under its control
<morphis> it then gives metrics to the various routes
<pstolowski> kyrofa, hey, can you ping me when you're back and have a moment for HO? i'd like to talk about snapctl
<nessita> rogpeppe, hi, I'm debugging the issue with bhttp, would you give me some detils about how you uploaded the snap to the store? was it manually, with snapcraft, or LP?
<rogpeppe> nessita: with snapcraft
<nessita> rogpeppe, did you also release the revno with it? (so I can try to reproduce)
<rogpeppe> nessita: what does "release the revno" mean?
<ogra_> morphis, well, i obviously installed nm to make use of it ... but doing that via ssh simply deconfigures the device during package install
<nessita> rogpeppe, with snapcraft you first build the snap and push it to the store, and then you decide to release a revno to a given channel (release == publish)
<ogra_> (to make use of it = i dont care about /e/n/i anymore)
<ogra_> morphis, what makes you think an oem would pre-install nm
<morphis> ogra_: as said, if a device is configured via ifupdown it should be ignore, that it isn't as of today is a bug and will be fixed
<ogra_> morphis, if i'm that hypothetical lawnmower manufacturer and have 500MB diskspace for OS and apps on that lawnmower, i surely dont want a 25MB nm package installed (25MB that i cant use for my autopilot app then)
<rogpeppe> nessita: i ran: snapcraft release bhttp 2 stable
<morphis> ogra_: second thing is taking over a network device which isn't configured by ifupdwon but manually by the other
<ogra_> morphis, well, it shouldnt matter how the device was configured before ... all that should matter is that it is actively in use (default route)
<morphis> that is a different story and the easiest you can do is to reset the device to make sure you take it over in a well known state
<ogra_> right, so i send out a technician to hit the reset button ;)
<tyhicks> zyga: why does the snap mount dir need to be configurable?
<morphis> ogra_: so we over two (or three) ways today to configure network, netplan, ifupdown and nm
<morphis> all play together and all three is what you can use as a manufacturer
<smoser> anyone able to comment on my question above ? basically snap building on launchpad wont work unless everything comes from the repo or the ubuntu archive (or i guess a ppa) right ?
<ogra_> morphis, right, this isnt about how it was configured ... only about what is currently in use
<morphis> ogra_: if you go and build your own you're off and it gets harder to support all of these
<morphis> ogra_: yeah and it takes only ifupdown as indicator for that right now
<zyga> tyhicks: because some distributions will use a different location
<zyga> tyhicks: I've just updated the pull request to adjust apparmor profile (there's almost no change in practice)
<morphis> ogra_: what should we then do with such a device in nm?
<zyga> tyhicks: similar changes are almost ready for snapd
<morphis> mark it as unmanaged?
<zyga> tyhicks: https://github.com/snapcore/snap-confine/pull/119/commits/c77ce3d7e521b93a2375bbad5019338bb176f9cc is the new thing
<mup> PR snap-confine#119: Make snap mount directory configurable <Created by zyga> <https://github.com/snapcore/snap-confine/pull/119>
<mup> Bug #1598225 changed: htop unable to send signals to other processes <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1598225>
<nessita> rogpeppe, thanks
 * zyga lunch
<morphis> ogra_: size is a thing which matters for sure, there are some parts we can still optimize to reduce the footprint of the snap
<morphis> but in the end Ubuntu chose NetworkManager which hasn't the smallest footprint and isn't made for this
<tyhicks> jdstrand: thanks for reviewing the profile changes
<morphis> then you want connman or just ifupdwon
<tyhicks> jdstrand: I already reviewed the code changes
<tyhicks> I'll leave a comment
<ogra_> morphis, i installed nm to configure it with nm ... but i cant because nm locked me out on package install
<ogra_> my point is that it should respect that the device is in use ... i will most likely want to then set up an nm config (because i installed the package) and reboot
<ogra_> so what did configure the device before doesnt really matter ... that i cant configure nm now does though
<ogra_> morphis, well, add a check for the default route to the systemd start script ... and make sure to not tear down the device if the default route points to it
<mup> Bug #1586547 changed: allow browsers to use user namespaces in its sandbox <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1586547>
<morphis> ogra_: so you configured the device with ifupdown before?
<ogra_> morphis, well, i perfer using /e/n/i or wpa-supplicant directly, so i dont waste ram and diskspace (this isnt only about the 25MB disk but also about eating system resources)
<morphis> sure
<ogra_> morphis, yeah ... but it shouldnt matter how it was configured
<ogra_> sint i just installled a tool that i will likely use in the future to configure it
<ogra_> *since
<ogra_> so the past shouldnt be taken into account ... if i install nm it is fine to assume i want to configure my devices with it ... what matters is the present
<ogra_> since i can snap install nm via ssh
<mup> Bug #1596717 changed: please add getsockopt to pulseaudio interface <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1596717>
<mup> Bug #1600085 changed: interface for making bpf syscalls <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1600085>
<mup> Bug #1605768 changed: incomplete 'opengl' interface <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1605768>
<morphis> ogra_: can you file a bug agaisnt https://bugs.launchpad.net/snappy-hwe-snaps ?
<ogra_> will do
<morphis> awe: can we easily tell network-manager to not reset a network device a default route is configured for when its first started?
<awe> morphis, ?; can you give me some more context?
<morphis> ogra_ describes his use case: he has a network device configured and a default route set
<awe> configured by...?
<morphis> now he installs the nm snap which removes all routes + interface configuration on first start
<awe> nm?
<morphis> awe: manual
<awe> or cloud-init/ifupdown
<awe> totally manual?
<awe> as in no eni or eni.d iface?
<morphis> if it would be ifupdown it should be ignored but isn't right now due to us not respecting e/n/interfaces.d/
<awe> right; s16?
<morphis> awe: or phrase it like this: should be ignore whenever it is not configure by ifupdwon or nm itself
<morphis> awe: yes
<awe> if so, doesn't your new snap fix?
<morphis> awe: it does and it would ogra_ problem
<morphis> but he worries that this will be a problem for people who may configure their interfaces manually and then lock themself out
<mup> Bug #1603113 changed: add fuse filesystem interface <lxd> <snapd-interface> <Snappy:Fix Released by stgraber> <https://launchpad.net/bugs/1603113>
<morphis> which should be a very small number as everything is meant to be ifupdown/netplan in the default ubuntu core images
<ogra_> apw, morphis bug 1617344
<mup> Bug #1617344: snap install of network-manager should not tear down the device holding the default route <snappy-hwe-snaps:New> <https://launchpad.net/bugs/1617344>
<ogra_> awe, it shouldnt matter how the device was configured (could be some shell script i put in place myself that called "ifconfig up" and dhclient) ... it should just not kill my current ssh connection
<ogra_> awe, so that i have a chance to put an nm confiig in place after i installed the nm package ;)
<awe> well.... that's what you get for mixing a manually configured device with a daemon that wants to own everything
<mup> Bug #1583371 changed: GPIO interface request <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1583371>
<awe> let me give some thought to how we can address this...
<ogra_> awe, just make the nm syystemd job chec for the default route and do not touch the device til there is an nm config for it i guess
<awe> did you add an iface into e/n/i.d?
<morphis> ogra_: that would be a little bit of a hack as you still want nm to take over control when its configured correctly
<morphis> awe: he did
<awe> then why don't we just add ssweeny's patch?
<morphis> yes
<awe> doens't that solve the problem?
<morphis> not in ogra's eyes :-)
<ogra_> awe, yes, thats the current default recommendation, using /e/n/i.d/wlan0 ...
<morphis> he says we should ignore the device regardless of it was configured when it provides the current default route
<ogra_> awe, all i want it that i'm not locked out of the device just because i installed a package :)
<morphis> ogra_: first of all if you install a network-manager you should know what you do
<ogra_> right, i just dont want to have my ssh connection killed when installing NM
<morphis> its quite a fundamental thing for a system
<awe> ogra_, we're sitting on a patch that fixes the problem
<morphis> ogra_: and you wouldn't when its properly configured with ifupdwon
<awe> not sure why we'd want to do anything different?
<ogra_> awe, good then
<morphis> ogra_: so securing the remaining 1% of use cases where the user configured the device manually sounds a bit like overhead
<awe> +1
<ogra_> morphis, well, i perhaps (or rather most likely) installed nm to manage the device with nm in the future
<ogra_> and perhaps my device sits on a pole in the arctic sea
<morphis> ogra_: but then you should have configured it properly with ifupdown
<awe> ogra_, people are going to use netplan or cloud-init
<ogra_> when the device gets killed by the package install i have no way to actually put any nm config in place
<awe> if they device in the north pole
<awe> and they configure manually
<ogra_> awe, how do you knwo ?
<awe> and then install NM blindly without having tested it first...
<awe> welll
<morphis> they shoot themself off IMHO
<awe> yup
<morphis> we can't prevent them from running "sudo shutdown -h now" as well
<awe> I suppose the other thing we could consider
<ogra_> awe, imagine i'm an OEM with a 233MHz/128MB device that runs on solar power to measure sea temp ... and i use ubuntu-iage to roll myown very minimal image
<awe> and you're not going to stage your software first?
<awe> and test?
<ogra_> i do stage my software ... and i do test it ... it worked and i installed it on that pole
<ogra_> now someone comes along and tells me i should rather use nm even though that eats my resources ...
<mup> PR snapd#1710 closed: tests: add content-shareing binary test that excersises snap-confine <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1710>
<ogra_> so i ssh into the device, notice there is actually enough space to use nm (yay) ... and install nm
<ogra_> *boom*
<awe> ogra_, is there a way to install a snap and have a job disabled upon install?
<morphis> no
<ogra_> i have to find a ship that goes to my pole to reset the device
<morphis> you wouldn't do such a critical operation on a production device
<awe> exactly
<awe> that's what I keep saying
<morphis> without testing and having the gurantee it works
<ogra_> awe, no, and why would you
<awe> this would be a good case for it, no?
<ogra_> all i want is that my current connection doesnt get orn down out of the blue
<ssweeny> jdstrand, zyga, so I'm back to this mount namespace thing. I got debug output from snap-confine by changing the daemon to a command and running it from a shell. Here's the output: https://paste.ubuntu.com/23093357/
<ogra_> *torn
<ssweeny> jdstrand, zyga, I'm still not seeing the mounts outside of the snap though
<awe> ogra_, you want to hop on #nm and discuss?
<morphis> ogra_:  it does not if you have it configured properly with ifupdwon
<ogra_> being locked out of a device just because you install some package is evil
<ogra_> we should prevent that
<morphis> ogra_: but you would discover in your testing that this is broken and wouldn't do it
<ogra_> i.e. look at ubuntu server ... if you upgrade ssh it will *never ever* kill your current sshd
<ogra_> and snap should not behave different in that regard
<ogra_> no matter what package i install
<morphis> ogra_: we support that use case very well (if that single bug is fixed I mentioned before)
<nessita> Chipaca, rogpeppe bhttp is now available, we are still troubleshooting but we re-publihs it to unblock you
<awe> ogra_, I still think the right way to do this would be so have NM installed in a state where it's idle, until enabled
<ogra_> morphis, well, thats fine then
<awe> I honestly don't think playing around with the code that handles the routing table for a case where someone's manually configured their device is correct
<ogra_> awe, whatever keeps my sshd alive is fine :) i dont care how it is solved
<awe> as morphis said, in 99.99% of the cases, cloud-init or netplan will be used, and NM will stay from any devices configured via those
<ogra_> locking people out of thir devices is just wrong ... thats the core point here
<awe> in this, the person has locked themselves out
<ogra_> awe, i suspect most peope doing actual embedded stuff will not want to use NM
<awe> they were flying without a net
<awe> I agree
<ogra_> since your resources are precious on such HW
<morphis> ogra_: and we support that for 99% percent of the use cases and the remaining 1% should be discovered in testing before deploying such a fundamental change in a critical production environment
<awe> that said, I definitely could see a need for being able to specify that a service is disabled by default upon install
<ogra_> morphis, well, you never know what weird manager takes over that sea tem measuring project  ... and what insane orders he gives to devs ;)
<ogra_> *sea temp
<awe> to allow the service to be *configured* before it's used
<morphis> ogra_: then he is responsible
<sergiusens> smoser we have an open bug for that launchpad issue (pull/build with or without internet access for the latter step)
<morphis> awe: sure that is another use case we could support but that would require some features we don't have in snapd yet
<ogra_> morphis, doesnt matter ... before he gets fired he gives a bunch of interviews telling the press how badly ubuntu snappy sucks ;)
<awe> agreed, I'm just saying that's the way I'd handle this
<ogra_> awe, and i agree ... we should have a way to handle initial state for systemd units
<ogra_> but we dont atm
<morphis> ogra_: but somebody could say similar if ubuntu core doesn't prevent you from stopping the machine with "sudo shutdown -h now" on critical machines
<sergiusens> smoser if cjwatson gets his way we need to build in pull, I am not against that as I was before as that pull will only ""build"" your deps and not your actual referred to source
<smoser> sergiusens, i went asking in launchpad, and cjwatson said
<ogra_> morphis, indeed :)
<smoser> <cjwatson> Builders have internet access but only during the pull phase.
<smoser> <cjwatson> ... which is the case here.
<smoser> <cjwatson> There's a known but undiagnosed problem with npm.
<smoser> <cjwatson> https://bugs.launchpad.net/launchpad-buildd/+bug/1588870
<mup> Bug #1588870: npm doesn't seem to use snap proxy <lp-snappy> <launchpad-buildd:Triaged> <https://launchpad.net/bugs/1588870>
<awe> ogra_, patches welcome... but as mentioned, this probably should be discussed with upstream
<awe> you could do the same thing with the deb pkg
<ogra_> does that kill my running interface ?
<morphis> ogra_: I am not against adding sth in nm to ignore already configured devices but I have the feeling that the effort to implement this (which could be very tricky) isn't worth it
<ogra_> i dont think it does
<morphis> ogra_: if it is configured with ifupdwon the deb doesn't :-)
<awe> it's the same code ogra_
<morphis> but if it is configured manually it will for sure
<ogra_> morphis, well, whatever the solution is, as long as my ssh connection persistst i'm all fine
<awe> just in a deb instead of a snap
<ogra_> awe, same systemd unity ?
<morphis> ogra_: ok, then lets ignore the 1% and concentrate on the 99%
<ogra_> *unit
<awe> ogra_, NM wants to own all of the networking on a device
<awe> unless it's explicitly told otherwise
<morphis> ogra_: in gernal yes
<awe> again... if you really want this fixed, then hop on #nm with me, and we can discuss there
<awe> but I agree with morphis
<ogra_> hmm, so if i'd install  ubuntu-desktop+rdesktop remotely on a cloud instance that would kill the cloud instance networking ?
 * ogra_ doubts thats ture 
<ogra_> *true
<morphis> ogra_: if you install the nm deb package no matter where, it will take over all not by ifupdown managed network devices
<sergiusens> smoser yeah, doing all that in `pull` would make your build/install twice (go through it). It is what we do with the python plugins today
<smoser> sergiusens, so is that an easy snapcraft.yaml config change that i can make  to try ?
<ogra_> morphis, ah, in that case thats probably the ifupdown setup that prevents it from doing that in the cloud
<morphis> ogra_: yes
<ogra_> and that patch you guys talked about will actually add that feature to the snap ?
<morphis> it will
<ogra_> well, then all is fine
<morphis> ogra_: or said differently, I suspect nm on the desktop has the same problem with /etc/network/interfaces.d as the snap has
<morphis> as this isn't fixed anywhere yet
<rogpeppe> nessita: ok, thanks
<rogpeppe> nessita: do you know what might've gone wrong?
<morphis> ogra_: even not in the deb packages we have nor upstream
<nessita> rogpeppe, nothing is standing out, we are now trying to reproduce the same flow you used to see if we have a bug
<nessita> rogpeppe, also, we are adding more logging because we noticed we need some more for cases like this (ie no errors but still log when publishing ocurrs)
<ogra_> morphis, well, i remember when asac maintained NM it never touched ifupdown devices
<ogra_> due to a distro patch though
<ogra_> and thats is years ago
<zyga> jdstrand: hey
<zyga> jdstrand: I've updated the milestones on launchpad so that snapd 2.12, .13 and .14 exist
<ogra_> it has definitely been cpable of that for quite a while
<ogra_> *capable
<zyga> jdstrand: and .12 although released, can be used as a bug target
<zyga> jdstrand: when you update bugs like you did just now would you mind also flipping the milestone to include this information
<morphis> ogra_: it ignores /etc/network/interfaces, yes
<ogra_> right
<morphis> ogra_: but not interfaces.d
<zyga> jdstrand: this is very useful for looking at changes per whole milestone
<ogra_> ah !
<morphis> ogra_: not sure when this was introduced but nobody added support for that in nm
<morphis> and that is what we're fixing
<ogra_> i think i.d exists forever (years for sure) but hasnt been widely used
<zyga> is robert ancell somewhere far away from europe, timezone-wise?
<ogra_> zyga, only australia ... not that far
<zyga> ah
<ogra_> (could be worse ... like .nz)
<zyga> ok, I'll just talk to him later tonight
<zyga> er. wait, it's Friday
<ogra_> he
<zyga> well, on Sunday then
<morphis> ogra_: maybe that is the reason why :-)
<ogra_> yeah :)
 * ogra_ hugs morphis and awe 
<morphis> :-)
<sergiusens> smoser it is not in snapcraft.yaml where the change is needed but the plugins instead
<cjwatson> sergiusens: the logs suggest that npm *is* being called in pull though
<cjwatson> oh, no
<smoser> bah.
<smoser> ok. so 2 changes needed.
<cjwatson> I must have misread it
<smoser> so.. i have figured it out.
<cjwatson> sergiusens is right, it's just about moving the dep install into the pull phase
<smoser> as documented npm pays attention to HTTP_PROXY and HTTPS_PROXY as it says
<smoser> that i simply not true
<smoser> however, you can make it care with --proxy= and --http-proxy=
<smoser> so i'm looking at a change to the nodejs plugin that will add --proxy= and --http-proxy= according to environment variables
<sergiusens> smoser it is really not a proxy problem; network is disabled for `build` from launchpad itself
<smoser> sergiusens, sure, but it doesnt read proxy anyway
<smoser> so moving it to another stage doesn't fix it unless you make it respect proxy, right?
<sergiusens> smoser npm is supposed to read http_proxy and https_proxy
<smoser> or do they have un-fettered access to internet in pull
<smoser> sergiusens, yes. it is documented as doing so
<smoser> it does not
<sergiusens> elopio ^ maybe reopen the PR
<zyga> Pharaoh_Atem: does this look okay? https://github.com/snapcore/snap-confine/pull/121
<mup> PR snap-confine#121: Allow the use of capabilities over setuid bit <Created by zyga> <https://github.com/snapcore/snap-confine/pull/121>
<bulldog> hi everyone once again am here :D
<Pharaoh_Atem> zyga: LGTM
<bulldog> with updates on snapcraft-gui :P
<zyga> Pharaoh_Atem: will setcap be a problem for fedora's %install target?
<zyga> Pharaoh_Atem: I suspect it runs under some sort of fakeroot but I'm not sure
<zyga> (does it?)
<elopio> smoser: sergiusens: the problem seems to be when http_proxy is http:// and https_proxy is https://
<bulldog> check out https://github.com/keshavbhatt/snapcraft-gui
<Pharaoh_Atem> rpm runs chroot() for all actions, including building packages, I believe
<elopio> smoser: have you seen https://bugs.launchpad.net/snapcraft/+bug/1611372 ?
<mup> Bug #1611372: add proxy support for nodejs plugin <Snapcraft:Invalid> <https://launchpad.net/bugs/1611372>
<zyga> chroot is one thing, does it run as root so that setcaps can run
 * zyga just goes to try
<Pharaoh_Atem> zyga: though the best place to ask these things is in #rpm.org
<zyga> ok
<Pharaoh_Atem> zyga: you'll need libcap as a BR though
<Pharaoh_Atem> err
<Pharaoh_Atem> zyga: you'll need /usr/bin/setcap
<Pharaoh_Atem> as a BR
<Pharaoh_Atem> fuck
<Pharaoh_Atem> it's /usr/sbin/setcap
<smoser> elopio, hm..
<zyga> as BR?
<smoser> my path was not goign to be to set config ('npm config')
<zyga> build requires?
<zyga> that's okay, that's easy
<smoser> but to set flags on the npm install line
<smoser> npm install --proxy= --https-proxy=
<smoser> which works
<zyga> Pharaoh_Atem: I'm about to call it a day, I will do a .41 soon and with .14 around the corner (of snapd) we should have all the we need
<zyga> Pharaoh_Atem: over weekend I'll look at selinux for the socket
<zyga> and maybe more :)
<zyga> Pharaoh_Atem: I'm going to break and spend some time with my family, I'll grab you next week :)
<zyga> have a good weekend everyone!
<Pharaoh_Atem> bye
<smoser> hm..
<zyga> tyhicks: https://github.com/snapcore/snap-confine/pull/121
<mup> PR snap-confine#121: Allow the use of capabilities over setuid bit <Created by zyga> <https://github.com/snapcore/snap-confine/pull/121>
<Pharaoh_Atem> zyga: it'd be awesome if you could get the alternate path stuff done today
<zyga> Pharaoh_Atem: for snap-confine it is ready upstream, for snapd it was (sans test) for a while
<barry> anybody know what this problem is:
<barry> $ sudo snap install hello-world
<barry> $ hello-world
<barry> multiple nvidia drivers detected, this is not supported
<barry>  
<barry> can't check bugs because launchpad.net/snappy is timing out for me
<nacc> barry: there's a bug for that
<zyga> barry: I do
<zyga> barry: yes, one sec
<barry> cool, thx
<zyga> barry: https://bugs.launchpad.net/snap-confine
<zyga> barry: ideas welcome
<zyga> barry: if you come up with something simple it will be fixed in the next release
 * barry looks
<zyga> oh alberto suggested an idea
<nacc> https://bugs.launchpad.net/snap-confine/+bug/1615248 this one?
<mup> Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1615248>
<zyga> sound like a plan if security agrees with it :)
<zyga> tyhicks: can you please also look at https://bugs.launchpad.net/snap-confine/+bug/1615248 and tell me if looking at /sys/module/nvidia/version can be used as a way to know which driver to bind mount
<zyga> tyhicks: if so I can easily do that
<zyga> barry: as a workaround, purge unused drivers
<zyga> barry: sorry!
<barry> zyga: thanks, will try that
<nacc> zyga: why does u-c-l care about nvidia drivers? just for context
<zyga> nacc: because world is terrible and it has to
<zyga> nacc: and for real...
<zyga> nacc: because on classic there is no kernel snap so no nvidia modules or userspace so we have to take them from the classic world
<zyga> nacc: so snap-confine has logic to find and bind mount the driver
<zyga> nacc: into the snap execution environment
<zyga> nacc: there's a different version of that for ubuntu and for arch, so far no other distro is supported
<nacc> zyga: ah!
<zyga> nacc: and they differ quite widely because of how packaging there works
<nacc> zyga: sure, it was just a surprising bug to my naive view of what u-c-l woudl care about :)
<zyga> nacc: and also among driver versions (nvidia switched to libglvnd or whatever that name is GL vendor) later
<zyga> nacc: well, surprise ;)
<zyga> nacc: I wish I had nvidia GPU with recent drivers to test
 * zyga has to order and expense GTX 960
<bulldog> how to browse all snap packages availble in store
<elopio> kyrofa: can I interest you in https://bugs.launchpad.net/snapcraft/+bug/1615242 ?
<mup> Bug #1615242: etcd tree drives snapcraft dump plugin insane <Snapcraft:Confirmed> <https://launchpad.net/bugs/1615242>
<barry> zyga, nacc i followed up on the bug.  i'm going to try to purge the old drivers and reboot.  if i come back then at least i'll know that wasn't a horrible idea ;)
<elopio> smoser: so npm install --proxy=http://... --https-proxy=https://... works ?
<bulldog> snap find wont load all packages :(
<elopio> if so, that looks better than the other solution.
<ogra_> zyga, barry, well, long term the nvidia driver should really stop leaving cruft behind :)
<barry> ogra_: of course! ;)
<ogra_> that seems to go on since multiple releases ...
<bulldog> ogra_, how to browse all snap packages available in store any idea ?? snap find not working
<barry> btw, i'm not sure this will solve the problem because i think i'll still be left with nvidia-367 and nvidia-367-prime
<ogra_> bulldog, no idea, all i know is that it was disabled
<ogra_> bulldog, you could try if uappexplorer helps
<bulldog> ogra_, no i want list all packages available  in snapcraft-gui
<ogra_> eeek ... mvo !!
<ogra_> (why did he just share the ps gadget with me again)
<ogra_> *pc
<barry> anyway.  rebooting with fingers crossed
<ogra_> bulldog, well, they you have to wait til snapd grows such a feature
<smoser> elopio, it does
<smoser> but now i just seem to see HTTP_PROXY and HTTPS_PROXY working
<bulldog> ogra_, snap find was there for that but it is dropped feature idk why :(
<smoser> so maybe all we need is to do the build in the pull
<smoser> as was suggested
<smoser> what environment does the buildd set up for us?
<ogra_> bulldog, no, it wasnt .... it just listed 100 random snaps
<smoser> is that documented?
<bulldog> ogra_,  oh :D
<elopio> smoser: I don't know. You need somebody from launchpad.
<bulldog> ogra_, and what snap find <snapname > does is look for package online ??
<ogra_> yes
<bulldog> daem , but thats not gonna help me :D
<ogra_> just talk to the local snapd
<bulldog> wont look online ??
<ogra_> it has a REST API
<ogra_> sure it will look online
<bulldog> cool
<ogra_> thats the only package DB that exists
<ogra_> so it has to look online :)
<bulldog> i wil allow users to look online and then allow them install via gui
<bulldog> ty :P
<ogra_> i think a gui to manage interfaces would abe a lot more interesting though
<ogra_> *would be
<bulldog> manage interfaces mean ??
<barry> zyga, nacc purging the old drivers doesn't help
<ogra_> snaps are installable through the software center already, so there is a GUI installer
<bulldog> showing users the interfaces snap will use or what ?
<ogra_> but there is no GUI tool yet to manage the snap interfaces
<ogra_> only a few of them connect automatically
<bulldog> ogra_, am making all in one ,snapcraft-gui have a package manager too
<ogra_> well, as you like
<bulldog> ogra_, make me clear about managing interfaces
<smoser> sergiusens, you said do the build twice ?
<smoser> why not *only* in the pull as oppoosed to pull and build ?
<bulldog> what u mean ?? how you want user manage em
<ogra_> bulldog, well, snap interfaces ... snap connect ... guis for these ...
<ogra_> so that you can manage permissions for installed snaps
<bulldog> oh
<ogra_> currently that requires commandline
<ogra_> even if you installed through the software center
<bulldog> ogra_, is it a feature available in cli snapd
<ogra_> snap help
<ogra_> :P
<bulldog> ogra_, :D
<kgunn> ogra_: you used to have a dragonboard readme with how to setup wifi i used to cheat with :)
<kgunn> but now it's missing
<bulldog> ogra_, can we allow any snap allow interface access ?? with command line?
<ogra_> kgunn, http://paste.ubuntu.com/23093640/
<kgunn> ogra_: thanks!
<bulldog> ogra_, what u mean by manage man ??
<ogra_> bulldog, no, only defined plugs can use defined interfaces
<Chipaca> seb128, does gnome-software not use polkit right now?
<bulldog> plz , so what u mean by manage
<ogra_> Chipaca, most likely
<ogra_> bulldog, manage the connections
<bulldog> example please
<Chipaca> ogra_, I imagined so; I'm trying to understand an email
<ogra_> bulldog, "snap interfaces"
<bulldog> seen that
<seb128> Chipaca, no it doesn't, why would it?
<ogra_> bulldog, https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<bulldog> ogra_, let me check it
<seb128> Chipaca, that was not needed until those recent snapd changes
<Chipaca> seb128, I ask because robert ancell's first approach to snapd was adding polkit support
<ogra_> seb128, no admin rights for installing packages ?
<seb128> Chipaca, right, which the snappy team rejected
<Chipaca> seb128, so I imagined that was how you wanted to do it
<ogra_> i would have thought sw-center asks for a pw
<seb128> ogra_, aptdaemon does
<ogra_> ah
<bulldog> google making a non linux based OS .DAEM :@
<ogra_> bulldog, and ? even the linux foundation does that https://www.linuxfoundation.org/news-media/announcements/2016/02/linux-foundation-announces-project-build-real-time-operating-system
<ogra_> it'S just a kernel after all
<bulldog> ogra_, am not a IT Student ,what u think about my future ? lol
<bulldog> choosing Biology as my subjects in school was biggest mistake i made :(
<cyphermox> ogra_: do you happen to still have around copies of the broken OS snaps? I keep getting timeouts from Launchpad; it would help to be able to debug this for myself
<ogra_> barry, indeed purging doesnt help :) you need to remove the dirs to cheat the check mechanism
<slangasek> ogra_: so I have an update for the pc amd64 gadget snap to make it ubuntu-image compatible; AFAICS nothing in u-d-f will care about the stuff I'm adding, so it should be safe to merge this, and from my side it's ready to merge now or in the near future.  Thoughts?  lp:~vorlon/snappy-hub/snappy-systems/
<ogra_> slangasek, oh, did you just share the pc gadget with me ?
<ogra_> (silly that the store doesnt tell who actually did that share request)
<slangasek> ogra_: hmm? no
<ogra_> ah, well, then it was mvo
<slangasek> ogra_: I have no store privs :)
<ogra_> :)
 * ogra_ neither
<slangasek> ogra_: oh, but it was also just shared with me :D
 * ogra_ pokes LP with a pointy stick ... 
<slangasek> ogra_: does this mean I should be able to upload the snap now?
<ogra_> timeouts galore
<ogra_> slangasek, yep
<slangasek> wow
<ogra_> slangasek, oooooh !!!!!!!
 * ogra_ dances
<slangasek> ogra_: I guess it would help me if you would steer the upload for the moment, I haven't used the store much yet and would flounder - so your input on the merge question is still appreciated
<ogra_> slangasek, tell me when i can drop the grub packages :)
<slangasek> haha
<slangasek> not yet
<ogra_> (just saw your change)
<ogra_> well, go ahead and upload ... if edge breaks it breaks ... its edge after all
<ogra_> (just dont release it to stable :)
<slangasek> not until a) we actually fix ubuntu-image to implement mbr stuff (we're almost there), b) we get everyone to use ubuntu-image instead of ubuntu-device-flash ;)
<ogra_> slangasek, its one checkbox to unpublish it ... iirc the store just falls back to the former version then
<ogra_> ah, right, udf doesnt have mbr handling at that level for grub
<ogra_> cyphermox, armhf http://people.canonical.com/~ogra/snappy/ubuntu-core_360.snap ... arm64 http://people.canonical.com/~ogra/snappy/ubuntu-core_361.snap
<mvo> ogra_: yes, me
<ogra_> (i dont have x86 ones)
<ogra_> mvo, ah ... did anything change that you shared it again with me ?=
<ogra_> or was that group vs user ?
<mvo> ogra_: I think for some reason you were not listed as a collaborator
<ogra_> well, i had access :)
<cyphermox> ogra_: in that case, do you happen to also have the other snaps I need to build an armhf image?
<cyphermox> (preferably the same ones you used)
<mvo> slangasek: I'm writing a mail now about this, but you are already ahead of me (like always :)
<mvo> slangasek: you can upload the gadget in any way you want, u-d-f does not actually look at the content, it has its own version that is known to work
<ogra_> cyphermox, just pi2-kernel and pi2 or pi3 for a pi image ... and dragoboard + dragonboard-kernel for a dragonboard image ... you need the udf snap
<ogra_> (installed i mean)
<cyphermox> ok
<ogra_> mvo, please make sure to only share with snappy-dev people if it comes to ubuntu-core or kernels ... since that controls also who can trigger builds via the LP UI
<mvo> ogra_: you can control that list too
<ogra_> oh, i didnt know
<ogra_> oh, kyrofa is a powerful man :)
 * ogra_ notes he has ubuntu-core access :)
<cyphermox> well, for one I see /var/lib/console-conf is not a writable path; so console-conf explodes because of that
<slangasek> cyphermox: oh. do we have livecd-rootfs or ubuntu-core-config changes still in our ppa that haven't made it over to snappy-dev?
<slangasek> cyphermox: we actually have a newer version of ubuntu-core-config in our ppa; can you reconcile those and give me (or ogra) something to publish to snappy-dev/
<ogra_> note that i made a change to that package yesterday ... so your changelog might be behind
<slangasek> ogra_: ok; so my plan is to locally validate the MBR case (once I finish all the bits in ubuntu-image to actually implement this), then publish
<ogra_> yeah
<ogra_> you need to accept the invide to th3e pc gadget still :)
<ogra_> (says the store)
<slangasek> yawp, accepting now
<cyphermox> slangasek: doesn't seem to me like it's a different version of ubuntu-core-config at all
<cyphermox> oh, wrong ppa
<ogra_> cyphermox, dont forget the dir needs to exist if you add it to writable-paths ... so make sure to also add it to your debian/dirs file in console-conf
<cyphermox> it still doesn't explain why everything seemed to be working correctly when I and mwhudson did the testing on amd64.
<ogra_> did you build with the right PPAs and proposed enabled ?
<cyphermox> yes
<ogra_> when creatinmg your ubuntu-core
<ogra_> then this is indeed weird
<slangasek> cyphermox: surely, the difference is some dependency in *our* ppa that is missing from snappy-dev
<cyphermox> not to explain these failures
<ogra_> no
<ogra_> there is a writabvle dir missing, that cant be due to a dependency ...
<cyphermox> well I'm simply going to copy all the packages to our PPA, and build an image from there
<ogra_> could be due to a a version number not being high enough though
<ogra_> ubuntu-core-config - 0.6.40+ppa6
<ogra_> that is whats in the snappy-dev PPA
<ogra_> yours needs to be higher to be considered indeed
<slangasek> no, ours needs to be merged into the snappy-dev ppa
<ogra_> sure, i was referring to cyphermox' test buiulds
<ogra_> wheer he added your PPA additionally
<slangasek> cyphermox: please don't copy things from snappy-dev ppa to ours, there really should be no need
<cyphermox> the only way we can reliably figure this out is to reduce the delta between the two ppas, and build more images
<cyphermox> I won't do this in "prod"
<ogra_> dont hold back :)
<ogra_> there is no prod
<cyphermox> well, snappy-dev must not be broken, is this not the case?\
<ogra_> there is only edge (where you admittedly can annoy devs)
<slangasek> cyphermox: ~canonical-foundations/ubuntu/ubuntu-image should be a thin layer on top of the snappy-dev ppa.  You shouldn't need to copy things over, that will just clutter
<ogra_> snappy-dev can be broken for a bit, as long as you unbreak
<slangasek> cyphermox: I see the ppa doesn't actually have a ppa dep that I thought it did; I'll add that now
<cyphermox> it shouldn't matter for the build actually, snapcraft.yaml defines the PPAs to use
<slangasek> ah
<ogra_> for ubuntu-core ?
<ogra_> nope
<cyphermox> yes
<ogra_> the Makefile does
<cyphermox> well, that code branch
<ogra_> unless you changed my setup drastically
<cyphermox> the Makefile, then
<slangasek> cyphermox: in which case, you just need to be sure that everything present in snappy-dev is merged into ours
<ogra_> snapcraft.yaml only defines the outer chroot
<slangasek> not copied wholesale
<ogra_> the actual build PPAs come from the live-build call in the makefile
<ogra_> http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk/view/head:/Makefile
<ogra_> from the "ENV" var at the top
<cyphermox> yes
<ogra_> if you dont explicitly add it to the EXTRA_PPAS var in there it wont be taken into account inside the live-build chroot
<slangasek> PROPOSED=1 PROJECT=ubuntu-core SUBPROJECT=system-image EXTRA_PPAS='snappy-dev/image snappy-dev/edge canonical-foundations/ubuntu-image' IMAGEFORMAT=plain SUITE=xenial ARCH=amd64 lb clean
<slangasek> LGTM?
<ogra_> yeah
<cyphermox> that isn't the issue
<rogpeppe> in snapcraft.io, it says:
<rogpeppe> ~/snap/<name>/current/      â $SNAP_USER_DATA that can be rolled back
<rogpeppe> ~/snap/<name>/common/       â $SNAP_USER_COMMON unversioned user-specific data
<rogpeppe> is that still true?
<rogpeppe> i don't see any "current" or "common" directories inside ~/snap/<name>
<rogpeppe> just x[0-9] directories
<elopio> rogpeppe: they are in /var/snap
<elopio> rogpeppe: please file a bug about that.
<rogpeppe> elopio: ok
<rogpeppe> elopio: so what's the role of the directories in ~/<name>/x[0-9] ?
<rogpeppe> elopio: they definitely seem to be used
<wililupy> Thats odd. I use the image from all-snaps on my device, it shows the three snaps, but one that I create does not...
<elopio> rogpeppe: your snap can read and write files in that directory.
<ogra_> wililupy, which ubuntu-device-flash snap did you use ? is it up to date ?
<rogpeppe> elopio: so it's independent of current and common?
<rogpeppe> elopio: it seems that $HOME points there
<wililupy> ogra_: version 10 Rev 9 in devmode
<elopio> I'm not sure if it has an env var. Maybe there's something wrong and it should be the same as the one in /var.
<ogra_> yeah, sounds correct
<rogpeppe> elopio: yeah, it's $HOME, because i was being confused because i ran the command and it wasn't finding data files that i was expecting
<wililupy> I updated it yesterday. It did work before giving me the 3 snaps on a clean image, but since then it hasn't. The image works, but as soon as I install a snap, it downloads ubuntu-core and then hoses up the device after a reboot.
<camako>  CMAKE_C_COMPILER
<camako> ugh ignore that
<ogra_> wililupy, which ubuntu-snap version ?
<ogra_> err
<ogra_> ubuntu-core
<ogra_> should be in the 360's somewhere
<wililupy> ogra_, 16.04.1 Rev 352
<ogra_> that sounds outdated
<camako> Do we have a known CI problem? Just updated my PR for the playpen and the travis job failed ---- > https://travis-ci.org/ubuntu/snappy-playpen/builds/155385333
<camako> "No CMAKE_C_COMPILER could be found"
<camako> "No CMAKE_CXX_COMPILER could be found"
<camako> ?
<wililupy> ogra_ I just ran sudo snap refresh --edge ubuntu-core and it updated to 366
<ogra_> yay
<ogra_> see if that works then
<wililupy> I'll give it a shot after my snap finishes building.
<camako> Hmmm I see that other's jobs are failing too ---> https://travis-ci.org/ubuntu/snappy-playpen/builds/130943227
<wililupy> Another quick question, after updates, how to I get rid of the previous versions? I have 7 /dev/loop* but only 2 snaps running. I'd like to get rid of the 3 previous versions of ubuntu-core that I'm not going to use. Plus I haven't been able to get rollback to function right...
<mup> Bug #1617399 opened: snapcraft.io documents persistent state incorrectly <Snapcraft:Invalid> <Snappy:Confirmed> <https://launchpad.net/bugs/1617399>
<ogra_> i dont think rollback is there yet
<wililupy> ogra_, I'll have to remember that for my demo ;)
<rogpeppe> is there any way i can give permission to a snap to open a page in a web browser?
<ogra_> i see code landing for it regulary ... but doesnt look like it released yet
<ogra_> rogpeppe, theoretically snapd-xdg-open should provide that ... but i think it is still broken
<ogra_> (install the deb and see )
<rogpeppe> ogra_: ah, i haven't seen that
<rogpeppe> ogra_: is that an interface that can be installed?
<ogra_> but mind you, i think it still doesnt work right ...
<ogra_> no, shouldnt need any interfaces
<ogra_> it will become part of snapd or a dependency or some such
<rogpeppe> ogra_: this particular code uses sensible-browser to open the web page
<rogpeppe> ogra_: are you saying that would need to change?
<ogra_> well, it hands it through to the host
<ogra_> but that bit doesnt work yet
<rogpeppe> ogra_: so... how does this work? the snap executes a command called "snapd-xdg-open <url>" ?
<rogpeppe> ogra_: or rather, i guess, how *would* it work if it did work? :)
<ogra_> if your app tries to open an url it intercepts that
<ogra_> and then calls xdg-open on the host
<rogpeppe> ogra_: what does it mean to "open a URL" ?
<ogra_> open a web link
<rogpeppe> ogra_: what does my app need to do to trigger that?
<rogpeppe> ogra_: when you say "open", what's that?
<ogra_> iirc only the http mime types are implemented yet
<rogpeppe> ogra_: call the open command?
<rogpeppe> s/call/exec/
<ogra_> if you click a url on an app ...
<rogpeppe> ogra_: this is a command-line app
<ogra_> that would spawn something in the os ...
<rogpeppe> ogra_: there's no UI
<mup> PR snapcraft#760 closed: Removed statements not used by the tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/760>
<ogra_> but since your snap doesnt run in an actual os this call is handed over to xdg-open on the host
<ogra_> oh, not sure ift works from some non UI call
<rogpeppe> ogra_: so my code would need to exec the xdg-open command?
<ogra_> you could try to just call xdg-open directly and hope for the best
<rogpeppe> ogra_: odd, the browser code calls xdg-open in freebsd, netbsd and openbsd but not linux
<ogra_> but it might only be hooked into the desktop launchers ... so no guarantee that anything happens if you do that from a cmdline app
<rogpeppe> s/browser/open-browser/
<rogpeppe> ogra_: ok, so a command line app probably can't open a page in a web browser.
<ogra_> probably
 * ogra_ has no idea ... :)
<rogpeppe> ogra_: fair enough :)
<ogra_> i know it is supposed to work from gui apps (but currently doesnt)
<sergiusens> rogpeppe the code or the execution of such code?
<rogpeppe> sergiusens: ?
<sergiusens> maybe it defaults to some sort of os system() since it cannot find xdg-open in path
 * ogra_ wonders why everyone and his grandma tries to snap neovim :)
<Pharaoh_Atem> because vim is evil
<Pharaoh_Atem> :)
<ogra_> lol
<ogra_> right
<rogpeppe> sergiusens: this is the code: https://github.com/juju/webbrowser/blob/master/webbrowser.go
<Pharaoh_Atem> of course, the vim codebase finally had DOS support removed
<ogra_> geez, really ?!?
<ogra_> the world ends !
<rogpeppe> sergiusens: it would be quite nice if we could make that code work in a snap; or at least return an appropriate error.
<Pharaoh_Atem> ogra_: yep, vim 8.0 will be the first version of vim to not be able to run on DOS
<ogra_> not a big loss if you ask me :)
<Pharaoh_Atem> anyone able to review/merge zyga's PR? https://github.com/snapcore/snapd/pull/1745
<mup> PR snapd#1745: overlord/snapstate: respect SnapMountDir in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1745>
<sergiusens> rogpeppe it is indeed in the code
<hatch> I've noticed that tab complete doesn't work - appears to be a regression https://bugs.launchpad.net/snapcraft/+bug/1570506 should I file another bug or re-open this one?
<mup> Bug #1570506: Snapcraft should use bash-completion <verification-done> <Snapcraft:Fix Released> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Released> <snapcraft (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1570506>
<sergiusens> rogpeppe oh and sensible-browser is `alternatives` based. ogra_ you sill love this :-)
<sergiusens> rogpeppe I would switch to xdg-open
<sergiusens> about the error though, the code should raise the error, is it not?
<ogra_> oh, lovely
<cyphermox> ogra_: how can I make sure my ubuntu-device-flash or whatever is good enough to create proper images?
<ogra_> cyphermox, just make sure to have the latest snap
<ogra_> mvo updates it regulary
<cyphermox> I don't have snaps
<mup> PR snapd#1684 closed: many: drop ubuntu-core-snapd-units package, use release.OnClassic instead <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1684>
<ogra_> then you cant use udf
<ogra_> we only hae it as a snap now
<ogra_> *have
<cyphermox> how is it called?
<cyphermox> $ snap install ubuntu-device-flash
<cyphermox> error: cannot install "ubuntu-device-flash": snap not found
<elopio> hey hatch! does it fail for the commands? Like snapcraft p<tab><tab> ?
<ogra_> --devmode --edge
<ogra_> (or --beta ... should both work)
<hatch> elopio: those work but I can't do `snap install he<tab>`
<elopio> hatch: right, those have never worked, so no regression. Let me try to find the bug.
<hatch> where 'he' is the hello world snap in my current path
<hatch> elopio: ohh ok, I looked but maybe my search foo is weak :)
<ogra_> yeah, thats a very old bug ...
<ogra_> open since snap's childhood
<hatch> haha, it happens :)
<elopio> hatch: https://askubuntu.com/questions/795253/how-can-i-enable-auto-completion-for-the-snap-command/795412#comment1199447_795412
<hatch> thanks elopio
<ogra_> bug 1600083 ... but i think there is an older one
<mup> Bug #1600083: 'snap' tool bash completion does not complete local file names <Snappy:Confirmed> <https://launchpad.net/bugs/1600083>
<ogra_> there must be one in the 15xxxx numbering
<elopio> hatch: snapcraft however has no bug for $ snapcraft upload he<tab>. Could you please file one?
<hatch> elopio: I'd imagine that would simply be an expansion on https://bugs.launchpad.net/snappy/+bug/1600083 no?
<mup> Bug #1600083: 'snap' tool bash completion does not complete local file names <Snappy:Confirmed> <https://launchpad.net/bugs/1600083>
<elopio> hatch: no, because it's in a different project. https://bugs.launchpad.net/snapcraft
<hatch> ohh I see
<hatch> sure
<elopio> thank you.
<cyphermox> ogra_: presumably I shouldn't have to download the gadget and kernel snaps locally to be able to run this correctly?
<ogra_> right
<ogra_> note you need sud and the full path though
<ogra_> sudo /snap/bin/ub....
<cyphermox> of course
<cyphermox> that's not the issue
<cyphermox> it can't find the gadget  snap
<ogra_> which one ?
<ogra_> (show me your command)
<cyphermox> why don't you paste me a full command I can use?
<ogra_> because i would have to type it myself :P
<ogra_> (it isnt like i have 500 terminal windows open here keeping old commands around :P)
<cyphermox> sudo /snap/bin/ubuntu-device-flash --verbose core rolling -o console-conf.img --channel edge --enable-ssh --gadget canonical-pc --kernel pc-kernel --os ubuntu-core_16.04.1_amd64.good.snap
<ogra_> --gadget pc
<ogra_> the rest looks fine
<cyphermox> I tried that too
<ogra_> --enable-ssh is a no-op
<ogra_> oh
<ogra_> s/rolling/16/
<ogra_> havent seen that one in a while :)
<cyphermox> thing is, there is just about no documentation on all of this
<ogra_> that should fix you
<cyphermox> yeah, it does
<ogra_> and it is obsolete code :)
<ogra_> slangasek, and barry will make sure we have proper docs for image building once we have a tool :)
<cyphermox> ogra_: I really don't care which tool, as long as I can make an image that works.
<ogra_> udf is really dead and buried since quite some time ...
<ogra_> which is why it isnt promoted anywhere or any docs are put up
<ogra_> mvo wrote a long mail when it switched to be a snap though
<ogra_> documenting the command call
<cyphermox> why isn't that in a wiki or doc somewhere?
<ogra_> because it changes nearly weekly
<ogra_> or used to at least
<ogra_> and now it is dead
<cyphermox> right, surely something replaces it?
<cyphermox> that thing should also be documented.
<ogra_> yes, ubuntu-image
<ogra_> as i said above
<cyphermox> and how do I use that?
<ogra_> it isnt ready yet
<slangasek> cyphermox: you can grab it from git@github.com:CanonicalLtd/ubuntu-image.git and follow the instructions in docs/notes.rst for the moment
<slangasek> which is incredibly hairy
<slangasek> until I validate the mbr work ;)
<cyphermox> that's fine
<cyphermox> for now ubuntu-device-flash will do; if there are any more days of mucking necessary, I will dogfood ubuntu-image.
<ogra_> cyphermox, note that the worst bug i filed is actually bug 1617231 though ... testing on amd64 wont really help with all the serial breakages on the different devices
<mup> Bug #1617231: subiquity kills serial console after regular update <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1617231>
<ogra_> (beyond subiqity not respecting that the system already has user and network setup)
<ogra_> i'm not sure what exactly you use as UI library ... but colors are definitely a very bad idea for that ;)
<cyphermox> ogra_: the point *is* that you won't have the ubuntu user, and that the network setup you might really want to change to something else.
<cyphermox> as for the colors; something to look into
<ogra_> i definitely dont
<cyphermox> then hitting Done should DTRT
<ogra_> (i mean, yes, i might want to use another user ... but definitely not switch away from ifupdown for my wlan)
<cyphermox> everything is switching away from ifupdown
<ogra_> the tool seems to detect there is a working connection
<slangasek> console-conf doesn't give you the option to switch away from ifupdown for wlan at the moment
<ogra_> but doesnt accept it
<cyphermox> well, wlan is admittedly probably not working correctly right now, netplan probably doesn't do anything to make it work
<ogra_> slangasek, well, currently it doesnt do anything at all except hogging 50MB in my ram and breaking all serial consoles :P
<ogra_> (and being unkillable ... even with sudp kill -9 )
<ogra_> *sudo
<ogra_> (which is very very odd)
<slangasek> ogra_: the last is certainly not a bug in our package ;)
<slangasek> the first two are serious bugs, yes
<ogra_> well, i have no explanatiojn for the last at all
<slangasek> I guess the first means that subiquity doesn't currently have a proper serial console driver
<slangasek> sure
<slangasek> but it's not a bug in our package, because kill -9 is handled in the kernel
<ogra_> yeah
 * ogra_ goes afk
<ogra_> cyphermox,  i'll check IRC sporadically in case you need anything like an ubuntu-core build or anything (slangasek has upload permission to the snappy-dev PPA afaik)
<slangasek> ogra_: as does cyphermox now :)
<ogra_> ah, cool
<ogra_> snappy-dev people can also trigger ubuntu-core builds, but i think the store currently auto-accepts only mvo and me for the uploads
<lazyPower> elopio o/
<mbruzek> Hello elopio
<mbruzek> elopio: I am interested in charming some container stuff, such as kubernetes
<eldarkg> hello guys. How to exchange copy plugin with dump: "files: ./*: usr/share/kicad/modules/" ?
<elopio> lazyPower: hello mbruzek: hello
<elopio> mbruzek: we have been playing with related stuff in the playpen. mbruzek: do you think it would make sense to share your work in progress there?
<lazyPower> elopio - we only have the client binary packed as a snap, and its using the dump plugin
<lazyPower> the build env for kubernetes wont "just work" using hte golang plugin
<lazyPower> we need support to invoke make targets along with exports
<mbruzek> elopio: Is there the ability to run a script.
<eldarkg> elopio: How to exchange copy plugin with dump. Now with copy plugin "files: ./*: usr/share/kicad/modules/" ?
<elopio> mbruzek: lazyPower: you'll find this one interesting: https://github.com/ubuntu/snappy-playpen/pull/223/files
<mup> PR ubuntu/snappy-playpen#223: Add the etcd snap, in devmode <Created by elopio> <https://github.com/ubuntu/snappy-playpen/pull/223>
<lazyPower> interesting, this is more complex than the etcd snap i came up with
<lazyPower> but it doesn't run the daemon either
<sergiusens> stokachu hey, where is your snapcraft.yaml for conjure-up?
<elopio> our idea is that people should use a custom plugin, instead of just executing a script. That causes some issues, so there's an open bug and a couple of PRs we are discussing.
<elopio> eldarkg: hello. I'm not too sure, I would have to play with it but I'm testing snapd atm.
<elopio> sergiusens: we need a guide to migrate from copy to dump. It's not easy.
<eldarkg> elopio: ok )
<sergiusens> elopio ok
<elopio> lazyPower: ah, I have that question. Most of the guides tell you to launch the binary, instead of using an autostart daemon.
<eldarkg> sergiusens: Hi. How to exchange copy plugin with dump. Now with copy plugin "files: ./*: usr/share/kicad/modules/" ?
<sergiusens> elopio it should be if people had been using organize/snap/stage/filesets more, but copy got the need for that out
<lazyPower> well, its like this elopio
<elopio> we could easily add daemon: simple, but I didn't know if that was the right thing to do.
<lazyPower> if you start etcd, and hten make a cluster configuration change, and you have a dirty data dir, you're going to have a bad time
<lazyPower> once raft takes over, its slightly easier, but its still not a stellar process
<elopio> I love that you people are here ^_^ I just had toy examples, now we can make it really useful and find better blocker bugs.
<elopio> lazyPower: mbruzek: so, how can I help? Should we start with one project and make it awesome?
<mup> PR snapd#1770 opened: overlord/assertstate,asserts/snapasserts: give snap assertions helpers a package, introduce ReconstructSideInfo <Created by pedronis> <https://github.com/snapcore/snapd/pull/1770>
<lazyPower> elopio - well.... we're currently blocked on a missing docker snap (or instructions on how to bin pack the docker daemon *and* get it running in the k8s snap)
<eldarkg> sergiusens: Have you answer? I try organize but it doesn't understand './*'
<mbruzek> elopio I running the kubernetes build in a snap.
<lazyPower> while i dont want to just willy nilly spin up engine instances, if we could conglomerate pack the daemon in the k8s snap, that works for us for now and we can get unblocked
<lazyPower> we're stuck on that portion in the mean time, as its a baseline dependency for k8s
<elopio> lazyPower: well, starting with kubernetes might not be the best idea. It's too hard. I would suggest to start with simpler services that it will consume, like etcd,
<lazyPower> "its too hard" - neverrrr
<elopio> I have seen lool and jdstrand comenting about docker. They probably know about the timeline.
<lazyPower> oh i'm looped in on some of those discussions and we're a ways out from having anything ready for us to consume
<lazyPower> re; etcd - thats fine by me, but we also need to talk about how thats going to function in reality
<lazyPower> clustering etcd manually is painful
<eldarkg> elopio: Is it possible to have access to media storage like USB flash card?
<lazyPower> we've had a lot of success clustering with juju
<eldarkg> elopio: from snap app
<elopio> eldarkg: it will be: https://bugs.launchpad.net/snappy/+bug/1604885
<mup> Bug #1604885: Access to mounted USB drives <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1604885>
<eldarkg> elopio: thanks. sorry for noise
<elopio> lazyPower: but that's where the charm comes into play, right? I don't much about either, so please be patient with the stupid questions.
<lazyPower> elopio - no worries, and yeah
<lazyPower> thing is
<lazyPower> 1 sec
<elopio> as I see it, we will have the snap. Juju will install it in many machines, and then configure them to talk to each other.
<elopio> eldarkg: hey, no worry, you are not noise. Is it your first time here?
<smoser> sergiusens, elopio https://github.com/snapcore/snapcraft/pull/762 if you're interested.
<mup> PR snapcraft#762: node plugin: run build in pull phase to download dependencies <Created by smoser> <https://github.com/snapcore/snapcraft/pull/762>
<eldarkg> elopio: yes
<lazyPower> elopio - https://github.com/juju-solutions/layer-etcd/issues/31  -- comment halfway down by neiljerram. If its not coming from the archive, they aren't trusting it, and they are a real consumer of the etcd charm
<lazyPower> so i dont know how keen they are giong to be moving from archive to a snap, as resources had the same property
<mup> PR snapcraft#762 opened: node plugin: run build in pull phase to download dependencies <Created by smoser> <https://github.com/snapcore/snapcraft/pull/762>
<elopio> smoser: oh, that could be a mess, but it's just what sergiusens was suggesting. Call build twice.
<elopio> however, I didn't imagine pull calling build. Hum...
<smoser> i'm not certain that is what you were looking for, but the things i've added (--cache-min=Infinity) is required. and i've tested that the idea works.
<elopio> eldarkg: welcome!
<smoser> http://paste.ubuntu.com/23094486/ <--
<eldarkg> elopio: thank you :)
<smoser> there, do a 'npm install' with internet, and then take away internet and do it again.
<elopio> sorry people, I have a meeting. BBS.
<eldarkg> elopio: bye
<eldarkg> who can to answer what status of https://bugs.launchpad.net/snappy/+bug/1611063
<mup> Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611063>
<eldarkg> sergiusens: can you tell anything about this bug https://bugs.launchpad.net/snapcraft/+bug/1617002 ?
<mup> Bug #1617002: LP build: "/usr/bin/ld: cannot find -llibrary" <build> <lp> <Snapcraft:New> <https://launchpad.net/bugs/1617002>
<jdstrand> roadmr: hi! can you pull r719 of the review tools. not an emergency
<jdstrand> roadmr: oh, actually, hold off on that (the commits are fine, I forgot I wanted to add a few more checks)
<mup> PR snapd#1771 opened: store: refresh expired device sessions <Created by matiasb> <https://github.com/snapcore/snapd/pull/1771>
<kyrofa> jdstrand, what is happening here? http://pastebin.ubuntu.com/23094551/
<kyrofa> jdstrand, how is that possible without the snapd-control interface?
<kyrofa> (FYI, this is the released snapd, not my PR)
<jdstrand> kyrofa: that's curious (cc tyhicks)
<kyrofa> jdstrand, I've verified, the only place /run/snapd.socket is present is the snapd-confine interface apparmor snippet
<kyrofa> And since I can't ls /run or /run/*, there isn't something else covering that
<jdstrand> kyrofa: so, /run is not allowed by the policy so ls /run doesn't work. /run/snapd.socket is also not allowed by the policy-- you can cat /run/snapd.socket. but what is curious is that you can ls -l /run/snapd.socket even though '/run/ r,' is not allowed
<kyrofa> Indeed
<jdstrand> kyrofa: s/you can cat /run/snapd.socket/you can cat /run/snapd.socket to verify/
<kyrofa> jdstrand, indeed, and I can't dial it or anything either
<elopio> lazyPower: that's a good question. It would be great to let people choose the source, either deb from the archive, deb from a ppa, snap, or download a tar.
<kyrofa> But the ls... and os.Stat I tried to do...
<kyrofa> Which I figured would fail. Doesn't!
<elopio> but that sounds like the problem is now 4 times harder.
<tyhicks> yikes, that's not right
<jdstrand> tyhicks: I think kyrofa discovered a bug
<jdstrand> tyhicks: the access to the file is not allowed. but ls /foo/bar is allowed when there is no '/foo/ r,' rule
<tyhicks> yeah, I'm going to narrow down if it specific to socket files or regular files
<tyhicks> and compare to older ubuntu releases to see if it is a regression
<jdstrand> thanks
<jdstrand> kyrofa: thanks for bringing that up
<kyrofa> jdstrand, of course, thanks for looking into it tyhicks!
<tyhicks> np
<stokachu> sergiusens: http://github.com/conjure-up/conjure-up
<jdstrand> tyhicks: do you need me to do anything? one thing I thought that might have an impact is that /run is bind mounted on classic
<tyhicks> jdstrand: not right now
<tyhicks> jdstrand: that's a good though
<jdstrand> kyrofa: did you see this on classic?
<tyhicks> s/though/thought/
<kyrofa> jdstrand, indeed
<jdstrand> kyrofa: 16.04?
<kyrofa> jdstrand, yessir
<jdstrand> k
<jdstrand> tyhicks: ^
<tyhicks> thanks
<jdstrand> tyhicks: thanks! :)
<eldarkg> kyrofa: hi. can you tell anything about this bug https://bugs.launchpad.net/snapcraft/+bug/1617002 ?
<mup> Bug #1617002: LP build: "/usr/bin/ld: cannot find -llibrary" <build> <lp> <Snapcraft:New> <https://launchpad.net/bugs/1617002>
<kyrofa> eldarkg, you're probably missing a build-package
<kyrofa> That you have installed on your build machine, but isn't available by default
<eldarkg> kyrofa: what pkg?
<eldarkg> kyrofa: I build ngspice from src in this snapcraft.yaml
<kyrofa> eldarkg, oh, I missed that :)
<ahoneybun> anyone know what's up with travis?
<eldarkg> kyrofa: ok)
<nacc> eldarkg: i'm guessing that you need to tell kicad's build where to find the staged ngspice
<nacc> *libngspice
<ahoneybun> trying to put otter-browser in the playpen
<ahoneybun> https://github.com/ubuntu/snappy-playpen/pull/221
<mup> PR ubuntu/snappy-playpen#221: Added otter-browser <Created by ahoneybun> <https://github.com/ubuntu/snappy-playpen/pull/221>
<eldarkg> nacc: why in local machine this is not need?
<nacc> eldarkg: on your local machine are you running `snapcraft build`? and do you have a system libngspice installed?
<eldarkg> eldarkg: on local machine I use `snapcraft prime`. Yes installed
<kyrofa> eldarkg, is there a reason you're building that lib from source instead of using one from the archive?
<kyrofa> Ah, maybe there isn't one
<nacc> eldarkg: right, i think you could start with just using stage-packages: libngprime (or what the package is called)?
<nacc> if it's packaged, that is
<eldarkg> kyrofa: yes)
<eldarkg> nacc: libngspice
<nacc> eldarkg: err, yes, sorry!
<eldarkg> nacc: isn't in ubuntu repo. It builds from src
<nacc> eldarkg: ah i see
<roadmr> jdstrand: oops... sure, just let me know which revno you need
<eldarkg> nacc: I think running of `snapcraft snap` on local and on LP should be identical shouldn't to use system libs.
<jdstrand> roadmr: well, you could queue up r719
<jdstrand> roadmr: but I have another couple things to add
<jdstrand> (unrelated to what's in there)
<nacc> kyrofa: you probably know better the details than I, but I think that means eldarkg'd need to pass perhaps a configure-like flag which tells kicad to use the staged libngspice?
<jdstrand> ratliff: so just trying to save you time
<jdstrand> roadmr: ^
<jdstrand> ratliff: nm
<roadmr> jdstrand: ok, will do
<kyrofa> nacc, yeah probably, eldarkg happy to help in just a sec, trying to schedule the all-important internet installation
<eldarkg> kyrofa: ok. I waiting
<tyhicks> jdstrand, kyrofa: quick update - this is not a regression in behavior
<eldarkg> nacc: but how kicad build found other build-packages like libboost?
<tyhicks> jdstrand, kyrofa: I've tested on all LTS releases all the way back to 12.04
<kyrofa> tyhicks, yikes
<tyhicks> jdstrand, kyrofa: https://paste.ubuntu.com/23094631/
<sergiusens> smoser looks interesting, aesthetically though I'd prefe to not call self.build from pull, better factor out the common things in build :-)
<tyhicks> I'll glance at the code and see if I can spot something
<nacc> eldarkg: you specificed 'libboost-all-dev' in build-packages
<smoser> sergiusens, i did that at first
<smoser> but then the diff looked bigger.
<jdstrand> tyhicks: that's interesting
<eldarkg> nacc: yes. but I don't set to kicad where it should find libboost
<smoser> sergiusens, i have no strong feeling at all on it.
<nacc> eldarkg: yes, but you told it to install it in the snap build environment
<nacc> eldarkg: and so it's installed int he 'system' level view, whichis probably the default for kicad's build
<elopio> <- lunch.
<nacc> eldarkg: whereas your part for ngspice maybe is not
<eldarkg> nacc: how to install library compiled from source to snap build env?
<nacc> eldarkg: let's let kyrofa help, i'm mostly just conjecturing based upon my own experience. I'm still pretty new to snaps myself :)
<kyrofa> Some people go out to lunch. But when elopio wants to eat, lunch comes to him
<eldarkg> nacc: ok. thanks to help
<eldarkg> what about this bug https://bugs.launchpad.net/snappy/+bug/1611063 ?
<mup> Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611063>
<elopio> -> lunch. I have to cook today.
<kyrofa> Hahaha
<eldarkg> kyrofa: you don't forgot about me ? :)
<kyrofa> eldarkg, still on the phone, sorry
<kyrofa> eldarkg, I can talk, but can't think ;)
<mup> Bug #1581167 changed: package snap (not installed) failed to install/upgrade: a tentar sobre-escrever '/usr/share/man/man1/snap.1.gz', que tambÃ©m estÃ¡ no pacote snapd 2.0.2 <amd64> <apport-package> <xenial> <One Hundred Papercuts:Confirmed> <Snappy:Confirmed> <snap (Ubuntu):Confirmed> <snapd
<mup> (Ubuntu):Confirmed> <https://launchpad.net/bugs/1581167>
<eldarkg> kyrofa:  ahh OK :)
<mup> Bug #1605080 changed: package snap (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snapd 2.0.10 <amd64> <apport-package> <package-conflict> <xenial> <One Hundred Papercuts:Confirmed> <Snappy:Confirmed> <snap
<mup> (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1605080>
<bull_> mup,
<bull_> nick/ bulldog
<kyrofa> Alright eldarkg, off now
<eldarkg> kyrofa: ok
<kyrofa> Let me take a look here
<kyrofa> I suspect nacc was right, though
<eldarkg> kyrofa: I listen you
<bulldog> good night guys :(
<nacc> i'm not sure if this is the best way to test, but one way i've debugged issues like this one eldarkg is to temporarily comment out the broken part, build the rest and then `unsquashfs -l` the resutling .snap to see where things are in the snap's environment. I'm sure there is a better way to do that, but it wasn't obvious to met yet
<nacc> *me
<eldarkg> nacc: to find libngspice?
<kyrofa> nacc, you don't need to squash and then unsquash, just look in the prime/ directory
<nacc> kyrofa: ah true, except i do everything via cleanbuild :)
<kyrofa> nacc, ah, then you're a bit stuck
<nacc> i guess i could flip it and start a container that is my building env
<nacc> and then what you suggest woudl work
<nacc> i'll retool my brain :)
<kyrofa> nacc, that's what I do-- I fire up an ephemeral container every time someone asks me to debug something (like now)
<bulldog> OerHeks, haha yyou here too ?
<nacc> kyrofa: yep, makes sense -- i almost wish that was what cleanbuild did
<nacc> kyrofa: then i could drop to that container's shell on failure
<kyrofa> nacc, actually, we're working on just that
<kyrofa> In fact, it may have landed already
<nacc> kyrofa: awesome!
<kyrofa> sergiusens can give you more info
<nacc> kyrofa: great, thanks!
<sergiusens> nacc use master and do snapcraft cleanbuild --debug
<kyrofa> nacc, that'll be in the next release
<nacc> sergiusens: cool, will try that
<nacc> kyrofa: ah great, that was going to be my next question :)
<kyrofa> nacc, we release weekly
<nacc> yep
<eldarkg> who know status of https://bugs.launchpad.net/snappy/+bug/1611063 ?
<mup> Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611063>
<kyrofa> eldarkg, I'm working on building this, but my internet is dreadful, this will take a bit
<eldarkg> kyrofa: how many?
<kyrofa> It says 37 minutes
<kyrofa> But it jumps to 50-something too
<eldarkg> kyrofa: ouuu. what time in your country ? my 22:56 :) I want to sleep :)
<kyrofa> eldarkg, 1300, haha. Go to bed, come back Monday and ping me
<eldarkg> kyrofa: ok :))
<kyrofa> Or if I figure something out, I'll put it on the bug
<eldarkg> kyrofa: ok
<eldarkg> kyrofa: you know something about https://bugs.launchpad.net/snappy/+bug/1611063 ?
<mup> Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611063>
<kyrofa> eldarkg, yeah I do
<eldarkg> kyrofa: what?
<kyrofa> zyga, are you still around? I think the latest snap-confine SRU fixes that bug, right? ^^
<kyrofa> eldarkg, anyway, that was caused by a lack of communication between two tools, snapd and snap-confine
<kyrofa> One thought the other tool was creating it, so neither did :P
<kyrofa> If it's not fixed already it'll be fixed in the next release
<eldarkg> kyrofa: ok.
<eldarkg> kyrofa: good bye. I'll ping you on Monday
<kyrofa> eldarkg, sounds good, talk to you then
<slangasek> sergiusens: hi, I've been granted store perms on the pc snap, but I get a strange error from 'snapcraft push'; can you help me decipher this?:
<slangasek> Received 403: '{"error_list": [{"message": "Developer profile is missing short namespace.", "code": "user-not-ready"}]}'
<slangasek> command was 'snapcraft push pc_16.04-0.5_all.snap', snapcraft help output doesn't give any clues
<sergiusens> slangasek yeah, talk to ev ;)
<ev> le sigh
<sergiusens> slangasek you basically need to go to the store (myapps... and create that)
<slangasek> hmm
<sergiusens> ev well you need to fix it faster :-)
<slangasek> ok, set
<sergiusens> slangasek nice to se the error list stuff is working! I will implement a nicer error for that now ;-)
<ev> I know, believe me - Iâve been moaning about the short namespace ever being a thing for snaps. But we have frankly more important things to deal with first
<slangasek> yeah, I was managing to work my way through the error message to do what it was asking me, was just confused about why this would be related to my upload - I guess it's understood to be a bug ;)
<slangasek> There has been a problem while analyzing the snap, check the snap and try to push again.
<slangasek> ...
<ev> sergiusens: we should check for the short namespace on snapcraft login
<sergiusens> ev how? as in with what api? or are you talking server side
<sergiusens> slangasek if there was a problem, check your inbox
<sergiusens> slangasek or click-review it
<slangasek> "found binaries for architecture 'all': ... ok then
<slangasek> sergiusens: one of the rejects was because 'gadget requires manual review', so if I click that button and somebody manually reviews it, is the architecture mismatch ignorable?
<ev> sergiusens: right, weâd need an API for it
<slangasek> ogra_: btw why is there a 16.04-0.5 in the store that's not in bzr?
<ev> but even with SSO usernames weâre going to have this problem
<ev> unless thereâs some magic way of making them required for anyone who already has an account
<wililupy> Is there a handy list of what the different $SNAP variables are? like $SNAP and $SNAP_APP. What else is there? I am specifically looking for the writable space for my snap.
<slangasek> sergiusens: "check my inbox"> never received any email about this fwiw
<qengho> wililupy: "snap install hello-world; hello-world.env |grep SNAP"
<hatch> is the lack of support in an lxd a snappy or lxd issue?
<hatch> (for running snaps, not building them)
<slangasek> jdstrand, ev: who can 'manually review' a gadget snap that I've uploaded?
<jdstrand> slangasek: I can
<jdstrand> slangasek: what is the store url?
<slangasek> jdstrand: cool, https://myapps.developer.ubuntu.com/dev/click-apps/5508/rev/5/
<jdstrand> slangasek: curious, do that use all the nifty new gadget yaml?
<jdstrand> does*
<slangasek> jdstrand: yes
<jdstrand> cool
<jdstrand> slangasek: approved btw
<ahoneybun> mhall119: make a snap tut video or talk about it at the release party
<slangasek> jdstrand: thanks :)
<slangasek> jdstrand: it's passed local boot tests for both UEFI and BIOS boot, so now we can give people something compatible with ubuntu-image that they can play with :)
<wililupy> qengho: exactly what I was looking for! Thanks!
<mhall119> ahoneybun: if the venue is good for it, I can give a presentation
<jdstrand> slangasek: nice! :)
<ogra_> slangasek, i dont think so
<ogra_> (but i also dont really touch the x86 side in teh tree)
<slangasek> ogra_: you don't think so> you don't think why there's a version in the store that's not in bzr?
<slangasek> :)
<slangasek> fwiw I checked the contents and they were no changes except the version
<slangasek> so I ignore it
<cjwatson> smoser: environment> easy enough to see from http://bazaar.launchpad.net/+branch/launchpad-buildd/view/head:/buildsnap, which is short enough
<cjwatson> (it is not otherwise documented I'm afraid)
<wililupy> hmm. For some reason, when I build an image with ubuntu-device-flash and a custom kernel, it doesn't show any snaps installed.
#snappy 2016-08-27
<mup> PR snapd#1749 closed: many: split public snapd REST API into separate socket <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1749>
<mup> Bug #1617508 opened: snap find returns bad request error when using a long query <Snappy:New> <https://launchpad.net/bugs/1617508>
<mup> Bug #1617509 opened: Nothing happens when the connection goes down in the middle of an install <Snappy:New> <https://launchpad.net/bugs/1617509>
<ahoneybun> https://github.com/keshavbhatt/snapcraft-gui
<ahoneybun> mhall119: ^
<WebDrake> Hello all -- hoping someone can advise/help with a small issue I'm encountering creating a snap that contains 2 apps (& hence 2 commands)
<dave_uy> I am using the ffmpeg part but my application cannot find ffprobe which should be included with ffmpeg part. Can I explore the environment the app sees somehow?
<dave_uy> So far I have just been putting in print statements. I now I'm thinking I should package up a bash prompt so I can take a look around.
<tvoss> o/
#snappy 2016-08-28
<bulldog>  irc test from hermes client
<Son_Goku> evening folks
<mup> Bug #1617770 opened: Snap cannot exec tput <Snappy:New> <https://launchpad.net/bugs/1617770>
<dave_uy> I'm trying to build a part using the maven plugin. The part requires libopenjfx-java to build, but I'm getting errors to indicate that libopenjfx-java isn't being found. Any suggestions on what to do?
#snappy 2017-08-21
<Justin`> Hi team, trying to build a snap, is this the best place to get some on the spot support?
<nacc> Justin`: i think the forum is even more active (see /topic)
<Justin`> OK thanks.
<zyga-suse> good morning
 * zyga-suse goes to get some breakfast
<zyga-suse> mvo: how are you doing?
<zyga-suse> it is finally not hot around here, actually the reverse; from 35+ to 16 :-~)
<Son_Goku> zyga-suse: hey
<zyga-suse> Hey1
<Son_Goku> mvo, zyga-suse: snapd 2.27.2 has rolled out to stable updates
<zyga-suse> Son_Goku: I got F25 and F26 installed, I was totally offline during weekend
<zyga-suse> Son_Goku: oh, no .3?
<Son_Goku> what's the point?
<Son_Goku> .3 only has AppArmor fixes
<zyga-suse> Son_Goku: there was a regression in containers and I thought he's doing .3 to fix it
<zyga-suse> but in any case, I'm now online again and I can test and review fedora updates
<Son_Goku> so 2.27.3 is this: https://github.com/snapcore/snapd/commit/cfc44fa948cbd42ff636d2763099446768946e71
<Son_Goku> but snapd isn't going to run on lxd in Fedora anytime soon
<zyga-suse> right
<zyga-suse> ah, I see
<Son_Goku> unless you want to take charge and get lxd into Fedora so that it works, that's not going to be a thing
<Son_Goku> I mean, I'd totally love it to be in Fedora
<Son_Goku> (considering it's needed for snapcraft cleanbuild to work)
<zyga-suse> Son_Goku: see you in 30 minutes, I've stated to pull updates
<zyga-suse> my network is workable but slow
<zyga-suse> kids murderred my data plan
<Son_Goku> davidcalle: you can merge the snappy-docs PR now
<davidcalle> Good morning Son_Goku, I will, thanks for the heads up
<Son_Goku> good night
<Son_Goku> must sleep
<Son_Goku> it's 3am
<zyga-suse> re :)
<zyga-suse> good night!
<zyga-suse> mvo: hey, any plans to make the .3 tarball?
<zyga-suse> mvo: I was thinking, if you could commit the tarball maker script
<zyga-suse> mvo: we could modify it to include the version as gustavo requested last week
<mvo> zyga-suse: tarfile is available
<zyga-suse> oh, I searched my history for the wget command and just did .3 instead of .2 and found 404
 * zyga-suse looks
<mvo> zyga-suse: re version> yes, no time for that yet, but will happen soon, reparis are the priority right now
<zyga-suse> ok
<zyga-suse> wget https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+files/snapd_2.27.3.tar.xz
<zyga-suse> mvo: shall I look at github instead?
<mvo> zyga-suse: yeah, please check gh
<mvo> zyga-suse: usually I upload to the image ppa too, but not this time as we do not need a new core
<mvo> zyga-suse: so your wget is right in 99% of the cases :)
<mvo> zyga-suse: but gh should be the place
<zyga-suse> yep, and I also corrected the spec file to contain .vendor suffix
<mup> PR snapd#3769 closed: many: sanitize NewStoreStack signature, have shared default store test private keys <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3769>
<zyga-suse> mvo: I see the layout of the tarball has changed again :D
<zyga-suse> mvo: may I just commit _a_ script and let you add the parts you care about later? (changelogs perhaps)
<mvo> zyga-suse: isn't the format of the tar what we want? snapd-$ver/... ?
<mvo> zyga-suse: or what am I missing?
<zyga-suse> mvo: it oscilates between snappy.upstream and snapd-$version
<mvo> zyga-suse: it should not, everytime its snappy.upstream in GH that is a bug
<zyga-suse> mvo: I'd honestly prefer the name-version
<mvo> zyga-suse: it is currently .upstream for the dpkg-buipdackage generated tarfiles, which is a bit of a problem with dpkg-buildpackage. I want to check if I can make gbp to generate nice dirs
<mvo> zyga-suse: name-version is what we want and what is in GH
<zyga-suse> mvo: aha
<zyga-suse> mvo: ok, so as long as it _stays_ this way then I'm very happy
<mvo> zyga-suse: its just not (yet) in lp because of dpkg-buildpackage
<mvo> zyga-suse: yeah, you can smack me everytime something is on GH where its not like this
 * zyga-suse sits outside at 15C
<zyga-suse> mvo: I'll hug you for each release, no less
<zyga-suse> :D
<zyga-suse> hey pstolowski!
<pstolowski> zyga-suse, hi!
<mup> PR snapd#3765 closed: vendor: explode and make more precise our golang.go/x/crypto deps, use same version as Debian unstable <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3765>
<mup> PR snapd#3773 opened: snap-repair: execute the repair and capture logs/status <Created by mvo5> <https://github.com/snapcore/snapd/pull/3773>
<morphis> mvo, zyga-suse: seeing snapd failing to boot inside LXD atm, https://paste.ubuntu.com/25361363/
<morphis> that is 2.6.10
<morphis> sorry, 2.26.10 which is currently in xenial
<pedronis> mvo: hi, should we reenable Fedora tests:  snapd#3755
<mup> PR snapd#3755: try to reenable fedora spread tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/3755>
<zyga-suse> morphis: this is fixed in 2.27.3
<morphis> zyga-suse: question is then, when will it be in xenail?
<zyga-suse> morphis: via re-exec it should be very soon, not sure
<zyga-suse> morphis: directly, no idea, that's a question for mvo
<morphis> zyga-suse: isn't this coming from the Nice= value being set in the .service file?
<zyga-suse> morphis: indeed
<zyga-suse> morphis: please diff 2.27.2 and 2.27.3
<morphis> how can that then be fixed via re-exec?
<zyga-suse> oohhh
<zyga-suse> sorry
<zyga-suse> indeed, good point
<morphis> :-)
<zyga-suse> I think we need a real .deb release for htis
<zyga-suse> *this
<morphis> jepp
 * zyga-suse is freezing-ish at 15C outside
<zyga-suse> I'll get indoors and make some warm tea
<morphis> zyga-suse: but yeah, already fixed with https://github.com/snapcore/snapd/commit/afcf731aac5333edd444071a8f2a41f033be0edd
<morphis> thanks
 * mwhudson waves
<mwhudson> what gyrations do i need to go through to be able to seed snaps that do not have store assertions?
<pedronis> mwhudson: seed as in ubuntu-image?
<mwhudson> i guess i need an account with a key and to sign both the model and the snaps' assertions ?
<mwhudson> pedronis: yes ish, this is for subiquity
<pedronis> mwhudson: there's no signing your own snap assertions atm
<pedronis> they just go in as --dangerous
<mwhudson> pedronis: hmm, so i can just list any old snaps in seed.yaml?
<pedronis> atm yes, but they need to be flagged unasserted: true
<mwhudson> ah ok
<mwhudson> that's fine
<mwhudson> atm? is this going to change?
<pedronis> mwhudson: maybe not this, but in general we might move not to allow any snap that was not listed as required in the model assertion
<mwhudson> pedronis: so the context is subiquity, the server installer
<mwhudson> for a "real" image we install subiquity from the store, fine
<pedronis> mwhudson: well to do seeding you need a model assertion
<mwhudson> but i want to make test images out of subiquity branches
<mwhudson> yes, we have a self signed model assertion currently
<pedronis> ok, you'll want a real one at some point but you probably need to feed us your requirment because I see a tension here in terms of model assertion
<pedronis> vs list of snaps
<pedronis> mwhudson: anyway what I said should be ok for tests
<mwhudson> i have no problem with everything in the test images being signed with a bogus, non-store, non-widely trusted key
<mwhudson> it would probably even be better for that to be the case
<mwhudson> but for now, unasserted: true will do :)
<pedronis> mwhudson: as I said there's not plan to allow for signing the snaps on your own
<pedronis> there's snap-build but is not the full story
<mwhudson> pedronis: works, thanks
<pedronis> mvo: zyga-suse: can we do something about merging snapd#3753
<mup> PR snapd#3753: Make updateKeyValueStream reject unsupported options <Created by mvo5> <https://github.com/snapcore/snapd/pull/3753>
<zyga-suse> let me look
<zyga-suse> yes, I wish this was fixed too
<zyga-suse> mvo: can I just correct it ^ ?
 * zyga-suse does that
<mvo> zyga-suse: if you are on it already I leave it to you, otherwise I can fix it too
<mvo> (sorry)
<zyga-suse> I'm on it
<mvo> ta
<zyga-suse> done
<zyga-suse> mvo: when will 2.27.2 hit stable?
<mwhudson> is the code for mup available somewhere?
<mwhudson> i don't believe https://launchpad.net/mup is the right one any more
<mwhudson> ah https://github.com/go-mup/mup/tree/master
<zyga-suse> I don't know, I think this is something ogra restarted recently, maybe he knows?
<ogra_> ??
 * ogra_ has never touched mup
<zyga-suse> ah, sorry, I recalled you restarted it or something
<pedronis> mvo:  snapd#3757  can be merged I think
<mup> PR snapd#3757: snapstate: undo a daemon restart on classic if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/3757>
<mvo> pedronis: yes, I think so too, I can tweak the message still if you want
<mup> PR snapd#3758 closed: spread: add mtr logs to diagnose linode issues <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3758>
<mup> PR snapd#3725 closed: osutil: honor SNAPD_UNSAFE_IO for testing <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3725>
<mup> PR snapd#3766 closed: cmd/snap-repair: test that redirects works during fetching <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3766>
<mup> PR snapd#3774 opened: spread: opt into unsafe IO during spread tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3774>
<zyga-suse> mvo: lots of errors on https://github.com/snapcore/snapd/pull/3753
<mup> PR snapd#3753: Make updateKeyValueStream reject unsupported options <Created by mvo5> <https://github.com/snapcore/snapd/pull/3753>
<zyga-suse> I think your revert broke it more
<mvo> zyga-suse: meh, ok
<zyga-suse> maybe we can land one then the other will become landable
<mvo> zyga-suse: I'll fix it
<mvo> zyga-suse: 3754 fixes it implicitely
<mvo> zyga-suse: but I canupdate 3753 too
<ogra_> zyga-suse, i only used to block mup spam on IRC by quietening the mup user in the channel
<ogra_> (only IRC stuff ... )
 * zyga-suse -> lunch
<zyga-suse> re
<ogra_> popey, i'm starting to get desparate with the nanopi-air ... i literally spent my whole weekend on it but i cant reproduce any of your errors, nor can i make wlan0 show up at all ... i tried all possible firmware combos and devicetree changes ... funnily the armbian kernel just works
<ogra_> (but indeed lacks any snap support)
<popey> ogra_: thats a bummer!
<ogra_> popey, well, not giving up yet ... after all there is a functioning kernel somewhere ... but it means patch by patch comparison (and armbian is full of them)
<pedronis> mmh, github is timing out for me atm
<ogra_> GH in general works here
<ogra_> hmm, or not
 * ogra_ takes that back
<popey> https://status.github.com/
<popey> it ded
<ogra_> yeah, the app-server availability curve is funny
<noise][> i feel bad for the SREs that are going to have to be fixing that instead of eclipse viewing
<Son_Goku> damn it
<Son_Goku> the world is exploding :(
<ogra_> noise][, thats still a few hours out, isnt it ?
<ogra_> so it depends how fast they are :)
<noise][> yeah, they have 2 hrs, best get crackin'!
<noise][> errâ¦3.5 hrs
<noise][> well, depends where you are, i guess 2 hrs until west-coast contact
<ogra_> popey, ooooh ! actually armbian works ! i can actually install snapd and it seems to kind of work (hello world works)
<ogra_> popey, https://www.armbian.com/nanopi-neo-air/ with that image (mainline kernel)
<popey> so can you do the diff and figure out what you need from it?
<ogra_> ogra@nanopiair:~$ snap list
<ogra_> Name   Version     Rev   Developer  Notes
<ogra_> core   16-2.26.14  2466  canonical  -
<ogra_> hello  2.10        24    canonical  -
<ogra_> ogra@nanopiair:~$ hello
<ogra_> Hello, world!
<ogra_> and ...
<ogra_> ogra@nanopiair:~$ snap version
<ogra_> snap    2.26.14
<ogra_> snapd   2.26.14
<ogra_> series  16
<ogra_> ubuntu  16.04
<ogra_> kernel  4.11.7-sun8i
 * ogra_ checks syslog for denials
<ogra_> ah, runs completely unconfined it seems
<ogra_> :/
<ogra_> (teh htop snap shows all processes even without connected interfaces)
<ogra_> (and no complaints in syslog)
<ogra_> popey, i surely can, but will need to actually build an armbina image i guess ... to get the patched kernel tree ... (this is assembled from different trees during build)
 * ogra_ installls the lxd snap on the nanopi for laughs
<ogra_> heh, not working
<ogra_> ah, installing the squashfuse deb helps
<pedronis> mvo: niemeyer:  we wrote this in London:  copy snap-repair to local disk, replace only when necessary after it reports one successful run   but IÂ don't remember if we changed our mind on that or is it's a for later
<niemeyer> pedronis: On a call, but will be with you shortly
<pedronis> mvo: I did the copying out of the points from London:  https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/40
<mvo> pedronis: great, I have a look in a little bit, pushing first round of review feedback, will look at the timeout for repairs next
<jdstrand> davidcalle: hey, date corrected, reassigned to you
<pedronis> mvo: couple more small comments, looking good otherwise
<mup> PR snapcraft#1498 opened: lxd: pass original CLI arguments down to container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1498>
<mvo> pedronis: great, I check it out now
<niemeyer> pedronis: I think that was the latest agreement indeed
<mvo> pedronis: excellent comments, thank you! I address them now
<niemeyer> pedronis: We decided to not rebuild the binary every time, which removed most of the complexity in keeping things safe
<niemeyer> pedronis: And then made the replacement simpler, by just saying "If you can run it successfully, the binary (and disk) is not corrupted"
<niemeyer> pedronis: So it's sort of the typical atomic write, with the exception that we run the .tmp before the mv just to be sure it looks good
<niemeyer> pedronis: It doesn't look like a blocker to get the primary functionality in place, though
<niemeyer> pedronis: The fact we're not rebuilding the binary every time is the safest net we have
<mup> PR snapd#3775 opened: [IGNORE FOR NOW] make sure fakestore is running <Created by pedronis> <https://github.com/snapcore/snapd/pull/3775>
<ryebot> Are there any reported bugs related to snap causing a soft cpu lockup? We're seeing this: http://i.imgur.com/jRYfjzz.png
<ryebot> It takes down our whole machine because it locks up all the cores.
<zyga-suse_> thunderstorm here, networking super super slow
<ryebot> To get things started, I'd just like to know a) if there's an issue for this being tracked somewhere, and b) what information you guys would like to see in order to start working towards a resolution
<zyga-suse_> ryebot: hey, I think starting a forum post about this is best as then more people will see it (timezones!)
<zyga-suse_> ryebot: provide "snap version" information
<zyga-suse_> ryebot: as well as other basic things, hardware, snap etc
<pedronis> don't think we heard of soft lock ups
<ryebot> zyga-suse_: ack, will do
<far-blue> hi all :) Is there an interface I can connect to the docker snap to allow it access to a locally mounted filesystem?
<mup> PR snapd#3775 closed: [IGNORE FOR NOW] make sure fakestore is running <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3775>
<Soren_> Hi Guys, apologies for asking for help in the developer channel.. But I'm looking for someone who can guide me through packaging our python project including dependency libraries like TensorFlow and OpenCV which has to be build from source to be CPU/GPU optimized. Anyone who got experience with this type of project?
<pedronis> mvo: zyga-suse: I tweaked sergio's PR
<zyga-suse> pedronis: thank you!
<zyga-suse> Soren_: no, sorry, can you please start a forum thread about this, I bet you will get more feedback this way
<zyga-suse> Soren_: just go to forum.snapcraft.io and create a new thread
 * zyga-suse -> supper
<mup> PR snapd#3772 closed: tests: wait until the port is listening after start the fake store <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3772>
<mup> PR snapd#3753 closed: Make updateKeyValueStream reject unsupported options <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3753>
<zyga-suse> pedronis: thank you for merging it
<ogra_> GRRRR !
<ogra_> ogra@nanopi-air:~$ sudo TMPDIR=. snap install linux-generic-allwinner_10.snap
<ogra_> error: cannot copy request into temporary file: write
<ogra_>        /tmp/snapd-sideload-pkg-112412374: no space left on device
<ogra_> why the heck doo we use /tmp there
<ogra_> -o
<ogra_> (and why dont we respect TMPDIR at least
<ogra_> )
<zyga-suse> ogra_: note that TMPDIR is not seen by snapd here
<zyga-suse> ogra_: and snap just makes a RPC request
<ogra_> hmm, yeah, i guess i'd need to hack the systemd unit
<ogra_> zyga-suse, in any case i thought we refrained from using /tmp a while ago ... pretty surprising there is still somethig using it
<zyga-suse> we never did
<ogra_> we never did what ? stop isung it ?
<ogra_> *using
<zyga-suse> yes
<zyga-suse> I don't recall any such patches
<ogra_> hmm, i thought that was the fix for the core install issues we had
<zyga-suse> which fix is that?
<zyga-suse> not sure what you are talking about
<zyga-suse> or which issue actually
<ogra_> trying to find it ... there were a bunch of bugs
<ogra_> zyga-suse, hmm, i thought there were at least three of them ... bug 1667865 is the only one i can find right now (and it isnt closed)
<mup> Bug #1667865: Unable to sideload large snap on DragonBoard <Snappy:New> <https://launchpad.net/bugs/1667865>
<ogra_> ah bug 1536864
<mup> Bug #1536864: Signature verification of large packages fails on embedded systems due to limited RAM <Snappy:Fix Released> <https://launchpad.net/bugs/1536864>
<ogra_> so the assertion side was fixed ... the snp side wasnt
<ogra_> *snap
<kyrofa> ogra_, yep, still a problem :)
<mup> Bug #1667865 changed: Unable to sideload large snap on DragonBoard <snapd:Confirmed> <https://launchpad.net/bugs/1667865>
<diddledan> this one caught me today: https://bugzilla.gnome.org/show_bug.cgi?id=786581
<diddledan> great. I can't override the path used by libpeas correctly, so usage in a snap is nogo for now
#snappy 2017-08-22
 * ogra_ curses ... 
<ogra_> popey, i got wlan working on the nanopi-air ... but that now just shows a bug in netplan ... (the same one we had with the pi3)
<ogra_> cyphermox, can we disable unbind/bind for all brcmfmac drivers in netplan ?
<ogra_> (not just for -sdio)
 * ogra_ has console-conf reliably explode (and the wlan device vanish when the config gets applied)
<kyrofa> ogra_, why on _earth_ are you still awake?
<ogra_> kyrofa, battling with my nanopi-air ... my head doesnt stop thinking when i go to bed ... so i can as well just fix it :)
<ogra_> (and i did ... apart from that damned netplan bug)
<kyrofa> Yeah I feel ya on that problem
<mup> PR snapd#3565 closed: cmd/snap-repair: skeleton code around actually running a repair <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3565>
<ogra_> cyphermox, (or mwhudson, not sure who cares for nplan nowadays ...) bug 1712224
<mup> Bug #1712224: netplan should not try to unbind brcmfmac  <nplan (Ubuntu):New> <https://launchpad.net/bugs/1712224>
<mup> PR snapcraft#1499 opened: repo: make errors based on SnapcraftError <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1499>
<mup> PR snapcraft#1500 opened: grammar: move out of pluginhandler <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1500>
<Son_Goku> jjohansen: hey
<mup> PR snapcraft#1501 opened: tests: use assertThat instead of assertEqual <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1501>
<mup> PR snapd#3776 opened: snap-repair: update snap-repair/runner_test.go for API change in makeMockServer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3776>
<zyga-suse> good morning
<mvo> hey zyga-suse_ good morning. how are you?
<mvo> zyga-suse_: if you could have a look a 3776 that would unbreak master
<zyga-suse_> mvo: good morning, doing fine though we could use less rain :)
<zyga-suse_> looking at the PR
<zyga-suse_> mvo: looks good,
<zyga-suse_> mvo: I'll grab breakfast/coffee and be back shortly
<mvo> ta
<zyga-suse_> re
<mup> PR snapd#3776 closed: snap-repair: update snap-repair/runner_test.go for API change in makeMockServer <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3776>
<zyga-suse_> mvo: 2.27.3 is non in stable yet, what are we waiting on?
<mvo> zyga-suse_: I need to catchup with sergio and fgimenez - if QA is ok and CE got green light as well we can promote. but sergio was off yesterday so we couldn't promote then
<mwhudson> ogra_: i think probably cyphermox, but if it's just a case of skipping the replug for another driver that sounds pretty easy
<mwhudson> oh heh you patched it already
<mwhudson> ogra_: give cyphermox a chance to look today if not, ping me and i'll merge it tomorrow?
<fgimenez> hey mvo, afaik CE results are good so far (i've just forwarded you the last message in the 2.27.2 validation thread), not sure if they have finished though
<mvo> fgimenez: thanks, that sounds promising
<cjwatson> ogra_: The revision field of LP snap builds dates from May.  The difference you point out isn't mysterious: one of those snaps builds from bzr and the other from git.
<cjwatson> ogra_: (The revision is the source VCS revision that the snap was built from, not the revision in the store.)
<ogra_> cjwatson, oh, how confusing... but that explains it, thanks :)
<mup> PR snapd#3777 opened: snap-repair: implement basic `snap-repair list` (with --verbose) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3777>
<popey> ogra_: oooh!
<popey> ogra_: looking forward to playing with it :)
<ogra_> popey, i'll have an image ready soon
<mup> Bug #1708703 changed: "enable" does not apply connected slot security policy <snapd:New for zyga> <https://launchpad.net/bugs/1708703>
<mup> Bug #1711847 changed: "snap run" doesn't support not installed packages <snapd:New> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1711847>
<popey> ogra_: super news :)
 * ogra_ sits here waiting for "please press enter" already ....
<ogra_> popey, note that you need an antenna ... the wifi wont find anything without one
<popey> yeah, i have one
<ogra_> bah, and i messed up
 * ogra_ starts over
<mup> PR snapd#3774 closed: spread: opt into unsafe IO during spread tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3774>
<ogra_> (accidentially removing the SD when attaching the antenna on the running board isnt helpful ...)
<zyga-suse> mvo: hey, I've assigned  https://bugs.launchpad.net/snapd/+bug/1709536 to you, since you worked on it recently and know the status better than I do
<mup> Bug #1709536: snapd 2.26.14 on ubuntu-core won't start in containers anymore <lxd> <snapd:New for mvo> <systemd (Ubuntu):Fix Released by xnox> <systemd (Ubuntu Xenial):Confirmed for xnox> <systemd (Ubuntu Artful):Fix Released by xnox> <https://launchpad.net/bugs/1709536>
<zyga-suse> mvo: can you please update the bug? I believe this is fixed but I wanted to be sure
<zyga-suse> woot
<zyga-suse> with the unsafe-io flag tests ran in sub 30 minutes :)
<zyga-suse> it's a net win for all PRs
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name                     Version       Rev   Developer  Notes
<ogra_> core                     16-2.27.2     2715  canonical  core
<ogra_> linux-generic-allwinner  4.11.0-13.19  16    ogra       kernel
<ogra_> nanopi-air               16-0.1        x1               gadget
<ogra_> ogra@localhost:~$
<ogra_> popey, ^^^^
<popey> is that good? :)
<ogra_> (uploading an image for you noow)
<ogra_> i'm ssh'ed in, yes, thats good ;)
<popey> ok, now I need to find my nano pi!
<popey> they're so small I lost it
<ogra_> i lost one of my antennas on the weeked ... they're even smaller and the plug on the board isnt really fitting 100% here
<ogra_> popey, http://people.canonical.com/~ogra/snappy/nanopi-air.img.xz (once you found it)
<popey> ta
<pedronis> mvo: could you try to merge master into snapd#3757
<mup> PR snapd#3757: snapstate: undo a daemon restart on classic if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/3757>
<zyga-suse> please don't merge 3778
<mup> PR snapd#3778 opened: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <https://github.com/snapcore/snapd/pull/3778>
<mup> PR snapd#3778 closed: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3778>
<mvo> pedronis: sure, I have a look now
 * zyga-suse reboots
<ogra_> OH!
<ogra_> thats cool
<ogra_> popey, seems the image work just as fine if you dd it to the internal mmc, so you only need the SD to dd it to /dev/mmcblk1
<ogra_> *works
<popey> there's internal mmc?
<ogra_> yeah :D
<popey> huh, that's handy
<popey> so boot from it, then copy image to it then dd that to internal mmc?
<ogra_> right
<popey> thats amazing
<ogra_> well, its a bit more tricky since you need to get nanopi-air.img.xz onto the SD ...
<ogra_> and you indeed need to configure twice
<popey> right, but that part is known
<ogra_> but yeah, the board can run completely standalone, no SD needed
<mup> PR snapd#3779 opened: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
<ogra_> i might produce an image with hacked initrd and the img file pre-loaded on the SD ;)
<ogra_> so that you get an option to directly write to mmc ... (just an initrd UI to dd)
<mvo> pedronis: just to clarify for 3777 - we need to look at both state *and* disk because one might be corrupted (or both :)
<pedronis> mvo: well, my point was not about corrupted, more that state has only the last runs
<pedronis> per seq
<pedronis> mvo: for each sequence num we could have multiple revisions and for each revision we could have multiple runs
<zyga-suse> mvo: did you push https://github.com/snapcore/snapd/pull/3779 earlier? I recall seeing the same diff
<mup> PR snapd#3779: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779>
<mvo> pedronis: aha, indeed, let me fix that
<mvo> zyga-suse: no, but its similar to 3502 which you reviwed 6 days ago
<zyga-suse> aha, thank you
<ogra_> mvo, FYI, i added the debdiff from https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1712224 to our netplan package in the image PPA
<mup> Bug #1712224: netplan should not try to unbind brcmfmac (like brcmfmac-sdio) <patch> <nplan (Ubuntu):New> <https://launchpad.net/bugs/1712224>
<mvo> ogra_: thank you
<mvo> pedronis: I will rework it to ignore the state, sounds reasonable?
<mvo> zyga-suse: fwiw, I addressed your comments on 3502
<mvo> zyga-suse: it has a +1 from jamie, so an extra +1 would help :)
<zyga-suse> aha, thank you, I'll check that out
 * zyga-suse needs a break
<zyga-suse> it's finally less cloudy/rainy, I'm stuck indoors for too long
<pedronis> mvo: you will still need the state for skip
<pedronis> mvo: I mean some stuff will be skip immediately and then there's no files on disk (at least atm)
<mvo> pedronis: aha, what condition currently skips them?
<pedronis> mvo: not matching model,  arch etc
<mvo> pedronis: ok
<pedronis> mvo: anyway probably non verbose mode shouldn't list skipped stuff that didn't run anything
<pedronis> (there might be a lot of those for a given device)
<mvo> pedronis: ok, I added a FIXME for myself and will look once the other bits are in place
<mvo> pedronis: will work on the on-disk thing after lunch
<pedronis> mvo: I'm waiting for green to merge one of my repair PRs
<mvo> pedronis: how do you feel about renaming "scipt.r0" to "r0.script" for consistency with the other file prefixes (output and stamp)?
<popey> ogra_:
<popey> popey@localhost:~$ uname -a
<popey> Linux localhost.localdomain 4.11.0-13-generic #19 SMP Sun Aug 20 16:36:37 CEST 2017 armv7l armv7l armv7l GNU/Linux
<popey> popey@localhost:~$ snap list
<popey> Name                     Version       Rev   Developer  Notes
<popey> core                     16-2.27.2     2715  canonical  core
<popey> linux-generic-allwinner  4.11.0-13.19  16    ogra       kernel
<popey> nanopi-air               16-0.1        x1               gadget
<popey> \o/
<popey> thank you!
<ogra_> wohooo !!!!
 * ogra_ pushes the gadget to the store
<popey> so mmcblk0 is the sd card and mccblk1 is the internal mmc, but I guess the internal one will be 0 once i reboot without the sd card?
<ogra_> nope, it stays 1
<ogra_> but you dont need to care anyway, core operates based on filesystem labels
<popey> how big is it?
<popey> wonder how many snaps I can install before it blows up
<popey> oh, 8GB
<ogra_> /dev/mmcblk1p2  7.1G  400M  6.3G   6% /writable
<popey> that's enough
<ogra_> yeah
<popey> sweeet!
<popey> interesting, there is already two partitions on the internal device here
<ogra_> i wonder how long it will take to empty my USB powerbank
<popey> it has a filesystem on it already
<ogra_> yeah, there are some hardcoded "boot" partitions ... thats a kernel thing
<ogra_> oh ?
<ogra_> mine didnt have any filesystems i think
<popey> DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
<ogra_> ah
<ogra_> that their hacked up deboostrap thingie that they advertise as Ubuntu Core
<popey> ah okay
<popey> will dd over it
<popey> yay, booting off internal mmc, nice work ogra_ ! I smell a forum post :)
<ogra_> gimme a bit ... i need to get the gadget snap past jdstrand in the store first and want to build a proper image :)
<popey> super, I won't steal your thunder :)
<ogra_> just imagine how cool it will be once you dont need a serial cable anymore (thats my next task with that kernel)
<ogra_> jdstrand, https://dashboard.snapcraft.io/dev/snaps/8227/rev/1/ for you :)
<mup> Bug #1712312 opened: Cannot add secondary group to user <Snappy:New> <https://launchpad.net/bugs/1712312>
<mup> PR snapd#3780 opened: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
<pedronis> mvo: I'm thinking about that, I'm not a fan of "r1..." tbh,  also because (though I'm not checking) revision can only increase, so we could use one counter across all revisions, and have revision later in the name
<pedronis> mvo: we have also "repair.r#"  for the assertion atm
<mup> PR snapd#3571 closed: cmd/snap-repair: recover brand/model from /var/lib/snapd/seed/assertions checking signatures and brand account <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3571>
<pedronis> mvo: do you know when we are goin to cut 2.28 ?  there's some ongoing discussion that might need to changes to things that landed before it goes out
<ogra_> pedronis, we dont even have 2.27.3 out
<ogra_> (unless mvo decided to drop it and move the fix to 2.28)
<mup> PR snapcraft#1486 closed: core: improve source caching logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1486>
<zyga-suse> re
 * zyga-suse feels better now
<jdstrand> ogra_: yep, I saw. approved
 * ogra_ hugs jdstrand 
<jdstrand> ogra_: also updated the review tools, but need a store sync of course
 * jdstrand hugs ogra_ :)
<popey> ogra_: what would you use to get the air on a new wifi network?
<popey> like, over serial console, when at a meetup, connecting to their wifi
<ogra_> either console-conf or edit the netplan config and call netplan apply
<popey> is this documented somewhere?
<ogra_> not sure ... /etc/netplan/00-snapd-config.yaml is the file to edit
<popey> ta
<ogra_> i guess cyphermox would know
<popey> kk
<ogra_> ah, wait ... i think it is "edit file", then "netplan generate" and then "netplan apply""
<zyga-suse_> hey jdstrand
<zyga-suse_> how are you doing
<diddledan> would the LD_PRELOAD hack help with libpeas looking for libpythonloader.so in /usr/lib/libpeas-1.0/loaders/libpythonloader.so without $SNAP prefix?
<zyga-suse> diddledan: maybe, maybe not, depending on some factors
<diddledan> specifically I am referring to this preload hack: https://github.com/sergiusens/snapcraft-preload
<mvo> pedronis: aha, so the dir also contains "repair.r#"? I will update my mocks
<ogra_> diddledan, will that prevent peas from walking its buildin search path ?
<diddledan> it looks like the thing does hook dlopen, so I'll give it a go
<mvo> pedronis: I want to talk to cachio about the release, hopefully we can release today
<ogra_> diddledan, alternatively https://developer.gnome.org/libpeas/stable/PeasEngine.html#peas-engine-add-search-path ...
<pedronis> mvo: no, that is in a different set of dirs
<ogra_> but i guess thats something you'd have to patch ...
<ogra_> (and use getenv() to give it a env var with the $SNAP search path)
<mvo> pedronis: aha, ok. what do you mean with " we have also "repair.r#"  for the assertion atm"?
<diddledan> ogra_: afaict it doesn't do any "searching" it seems to memoize the prefix at build time and then use that when building paths - the libpythonloader is found by literally "libdir" + "loaders" + "libpythonloader.so"
<ogra_> diddledan, well, it has that function above
<ogra_> (also prepend_search_path() as well)
<pedronis> mvo:  /var/lib/snapd/repair/assertions/{$BRAND_ID}/${REPAIR_ID}  vs /var/lib/snapd/repair/run/{$BRAND_ID}/${REPAIR_ID}
<ogra_> so it allows it ... just not OOTB
<diddledan> but we don't want to be hacking stuff to make it work in snappy - that is a sure WONTFIX when pushing upstream
<ogra_> asking them to ccep an env var for more flexibility ? not sure
<pedronis> mvo:  we have a hierarchy for the assertions and a different one for the run artifacts
<ogra_> *accept
<mvo> pedronis:yes
<diddledan> I tried that: https://bugzilla.gnome.org/show_bug.cgi?id=786581
<diddledan> NOTABUG
<pedronis> mvo: just saying repair.r# exists but is not under */run/*
<diddledan> I even gave them a patch
<mvo> pedronis: aha, ok. now I see what you mean
<ogra_> booo
<diddledan> maybe I should reword my bug report and try again
<mvo> pedronis: quick brainstorm on your idea about just using the counter as the prefix? http://pad.ubuntu.com/c3Ku7ZRkGk has that what you have in mind?
<pedronis> mvo: anyway maybe it's ok to turn them all aorund to be "r#..."
<ogra_> yeah, talk about flexibility and advantages ;)
<ogra_> (make it sound like a positive thing they want :) )
<popey> ogra_: in snap changes, I'm seeing a bunch of errors when doing Initialize device
<popey> Error   2017-08-22T11:57:13Z  2017-08-22T11:57:18Z  Request device serial
<ogra_> popey, about get a serial" ?
<popey> ya
<pedronis> mvo: yes,  but as I said now, not sure it's a good idea
<ogra_> popey, yeah, thats pointless ... pedronis once promised me it would stop doing that over time (but it isnt ... at least for me)
<ogra_> :)
<pedronis> mvo: anymore
<mvo> pedronis: ok, let me do the alternative in the pad
<ogra_> popey, it wont ever get a serial since it isnt an official canonical image, but that doesnt do any harm apart from spamming the log
<mvo> pedronis: maybe its a gustavo question, I'm sure he has an opinion, I don't mind either way much as long as its somewhat consistent
<pedronis> ogra_: no, it's my fault it back offs but per reboot, so if you reboot often it spams a bit anyway
<popey> ogra_: ok
<mvo> pedronis: which means I will write/update the forum post I guess
<ogra_> pedronis, heh, well, an edge image reboots daily for the daily core ... thats it then (i only use edge everywhere)
<pedronis> mvo: anyway my point   is that r1.repair is probably more consistent to what we usually do thatn repair.r1 and then it goes from there
<pedronis> mvo: other those are more than the repair, they are streams
<mup> PR snapd#3781 opened: cmd/snap-repair: track and use a lower bound for the time for TLSÂ checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/3781>
<mvo> pedronis: right
<mup> PR snapd#3757 closed: snapstate: undo a daemon restart on classic if needed <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3757>
<mup> Issue snapcraft#1502 opened: Support :target suffix for build-packages <designed> <Created by kalikiana> <https://github.com/snapcore/snapcraft/issue/1502>
<mup> Issue snapcraft#1477 closed: multi-arch build packages <design-required> <Created by sergiusens> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1477>
<mup> PR snapcraft#1346 closed: repo: multi-arch build deps <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1346>
<mup> PR snapd#3782 opened: client: fix go vet 1.7 errors <Created by mvo5> <https://github.com/snapcore/snapd/pull/3782>
<Son_Goku> who manages mup?
<Son_Goku> the syntax of issue URLs is wrong
<zyga-suse> Son_Goku: we were wondering ourselves recently
<zyga-suse> not sure, maybe niemeyer?
<cachio> mvo, hey, is it sru validation ready to start?
<mvo> cachio: yes
<cachio> mvo, starting with it
<mvo> ta
<jdstrand> hey zyga-arch :)
<mup> PR snapd#3783 opened: tests: make 17.04 shellcheck clean <Created by mvo5> <https://github.com/snapcore/snapd/pull/3783>
<kenvandine> nessita, remember we talked about collaborators will remain when we change the publisher of a snap?  Is that only active shares or will the pending go along as well?
<kenvandine> nessita, i'm trying to decide how persistently i nag the collaborators I invited :)
<nessita> kenvandine, hum I'm not 100% sure and I'm otp, I can check after this call I'm in
<kenvandine> nessita, no rush :)
<diddledan> the desktop-gnome-platform has a minor bug (this is a PR fixing it): https://github.com/ubuntu/snapcraft-desktop-helpers/pull/70
<mup> PR ubuntu/snapcraft-desktop-helpers#70: update init to fix cases where the helper exits <Created by diddledan> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/70>
<zyga-suse> diddledan: looking
<zyga-suse> diddledan: not sure what I think about it, I'd have to look at what the code is doing there elsewhere
<zyga-suse> diddledan: I'll let others review
<diddledan> ok
<diddledan> the line I removed is duplicated currently in mark-and-exec: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/mark-and-exec#L5
<diddledan> so it's just removing the early setting of the .last_revision
<didrocks> diddledan: this was a missing git add -p a long time ago
<didrocks> was supposed to be in
<didrocks> (when I added the mark-and-exec statement)
<diddledan> aha
<diddledan> :-)
<didrocks> so yeah, completly my fault, thanks for spotting it! :)
<diddledan> no problem .. glad to help :-)
<didrocks> merged, thanks again
<zyga-suse> obviously after adding measurements I cannot reproduce this failure
<zyga-suse> but running tests over and over I see failures all over the tree
<ogra_> popey, here you go https://forum.snapcraft.io/t/new-nanopi-neo-air-ubuntu-core-developer-image/1814
<diddledan> sergiusens: the snappy-preload rewriting shared memory. have you tried it against an application that uses pulseaudio?
<diddledan> specifically I'm getting [pid 21683] open("/dev/shm/snap.liferea.pulse-shm-908736786", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<diddledan> I'm wondering if the pulse-shm is not meant to be rewritten
<diddledan> ref: https://github.com/sergiusens/snapcraft-preload
<popey> ogra_: yay
<zyga-arch> mvo: so...
<zyga-arch> https://paste.gnome.org/pmlk7zgjb
<zyga-arch> mvo: I added this patch in the build: https://paste.gnome.org/pkepaslix
<zyga-arch> and came out with this https://paste.gnome.org/p8akyvrfy
<zyga-arch> I'm totally puzzled now
<zyga-arch> shall I leave it on memcheck for the evening?
<zyga-arch> (the host)
<zyga-arch> did we run into any golang bugs recently?
<zyga-arch> niemeyer: ^
<niemeyer> zyga-arch: AFAIK only the one about fork/exec concurrency, which arguably is a kernel bug
<zyga-arch> https://paste.gnome.org/p1hsubmo4
<zyga-arch> pedronis: ^ any ideas/
<pedronis> in daemon?
<pedronis> zyga-arch: our tests don't always use the lock correctly for convenience, it also means though that a test failure can turn into such a panic
<zyga-arch> aha, I see
<zyga-arch> this is not the error I'm researching but I wanted to share it in case it is more serious
<pedronis> so something else is failing but you get this insteaad
<pedronis> some printing around in the test exploding should reveal what's happening
<zyga-arch> it's not easily reproducible, it feels like each time I run it some part explodes but not the same part
<mup> PR snapd#3741 closed: tests: remove TestInterfacesHelp as it breaks when go-flags changes <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3741>
<mup> PR snapd#3783 closed: tests: make 17.04 shellcheck clean <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3783>
<niemeyer> Stepping out into the non-eclipsed sun for a while
<pedronis> niemeyer: added this to the topic with a question that we didn't consider:  https://forum.snapcraft.io/t/lazy-fallback-serial-registration-for-classic/1232/8
<pedronis> niemeyer: I also I have an errand tomorrow that will not allow me to make the standup IÂ think
<jdstrand> roadmr: hi! can you sync r913? this isn't urgent, but note there are a number of code changes
<roadmr> jdstrand: oh boy.. sure
<roadmr> jdstrand: as long as you're fairly confident it won't start rejecting snaps or crashing, we should be ok :)
<roadmr> jdstrand: I do a basic smoke check before proposing the merge, and then we can test on staging a bit
<jdstrand> roadmr: I have a bunch of tests to test things. they aren't crazy changes
<jdstrand> err, bunch of snaps
<roadmr> nice :)
<jdstrand> and a lot of testsuite changes
<jdstrand> so I am confident it'll be fine, but I watch the queue every day so I'll pay the price if things get rejected
<niemeyer> pedronis: Thanks for the topic, and thanks for the note
<jdstrand> roadmr: more seriously, it's mostly data changes. then there is a safety check for verifying there is enough disk space to uncompress, and then another check for executable stacks, which is rarely used by anything
<jdstrand> roadmr: and then a few things to help the tools when run as a snap
<roadmr> which we're not using yet :/ but can't hurt
<jdstrand> roadmr: I use it regularly and I run it through all the same tests
<jdstrand> roadmr: but I discovered an issue that would've caused you problems: the snap was defaulting to using python3's default for gettemptdir(), which is /tmp, which in snappy is a memory backed tmpfs, which means that the size of reviewable snaps would've been smaller (eg, out of space if the snap didn't fit in half the ram on the review system)
<jdstrand> roadmr: the change was to use SNAP_USER_COMMON, but then because we didn't get cleanup of that directory for free, I implemented some stale review dir reaping code
<jdstrand> I'm particularly happy that the snap no longer needs to 'plugs: [ network ]'
<roadmr> \o/
<mup> PR snapcraft#1488 closed: lxd: always remove existing device for project folder <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1488>
<mup> PR snapcraft#1495 closed: cli: don't raise from excepthook <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1495>
<mup> PR snapcraft#1499 closed: repo: make errors based on SnapcraftError <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1499>
<mup> Issue snapcraft#1454 closed: python plugin recording <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1454>
<mup> PR snapcraft#1487 closed: python plugin: record manifest <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1487>
<mup> PR snapcraft#1503 opened: ci: speedup the CLA check <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1503>
#snappy 2017-08-23
<mup> PR snapd#3782 closed: client: fix go vet 1.7 errors <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3782>
<mvo> jamesh: hey, I added some small comments for 3581, very excited that this can land
<jamesh> mvo: okay.  I was just writing a reply to niemeyer's last comment.
<mvo> jamesh: great!
<mvo> pedronis: how are things looking from your side for 2.28 - did we need to make the tweaks you mentioned yesterday?
<Chipaca> Buon giorno, principesse e principi!
<zyga-suse> good morning
<zyga-suse> hey Chipaca, good to see you
<zyga-suse> how were your holidays?
<Chipaca> tiring :-)
<Chipaca> how were things?
<zyga-suse> I think mostly okay
<pedronis> mvo: hi, not we didn't  yet
<zyga-suse> tests are greener than earlier
<Chipaca> anything igneous that shouldn't be?
<zyga-suse> Chipaca: haha, yes, mystery of my VM with high error rate
<zyga-suse> Chipaca: I have a VM that when I run tests on, things massively fail, randomly
<zyga-suse> Chipaca: (in unit tests)
<pedronis> mvo: IÂ need to prepare a PR with a change this morning
<mvo> pedronis: ok, please tag with 2.28 then
<Chipaca> zyga-suse: is it accidentally a Win10 vm?
<zyga-suse> Chipaca: haha, no, it's my Arch VM
<mvo> pedronis: I went over the open ones to see what we want for 2.28 and milestoned a bunch
<zyga-suse> Chipaca: tests failures are pretty odd, like "cannot parse this constant yaml string"
<zyga-suse> Chipaca: the host has good memory (tested)
<Chipaca> zyga-suse: how big is the vm image?
<zyga-suse> Chipaca: let me look
<zyga-suse> 14GB
<zyga-suse> Chipaca: note that it fails randomly but mostly so when I unpack the release tarball again
<zyga-suse> so feels like something gets corrupted randomly
<zyga-suse> Chipaca: the releast tarball md5sum checks out (weak but useful)
<pedronis> Chipaca: buon giorno
<Chipaca> zyga-suse: and it's a regular VM thing like kvm?
<zyga-suse> yes
<Chipaca> zyga-suse: you're not emulating ryzen or something
<zyga-suse> Chipaca: no, on a 3rd gen core i5
<zyga-suse> and this machine has loads of other VMs with nothing failing anywhere
<zyga-suse> Chipaca: the kernel there is fresh, I forgot how fresh
<zyga-suse> Chipaca: the golang bits are 1.8.3
<zyga-suse> Chipaca: if you want I can show you
<Chipaca> zyga-suse: can you build a fresh arch vm of the same version and compare checksums?
<zyga-suse> Chipaca: checksums of all the files on disk?
<Chipaca> yes
<zyga-suse> Chipaca: arch is hand made (early parts) so I bet things will turn out different
<Chipaca> well, not _all_, but say /lib
<zyga-suse> Chipaca: I could reinstall all packages
<zyga-suse> Chipaca: one thing I did
<zyga-suse> Chipaca: that is interesting
<mvo> pstolowski: 3569 is ready, right? test look a bit unhappy right now, but I can baby sit, I think we wan tthis for 2.28 :)
<zyga-suse> Chipaca: is to save yaml to /tmp/FAILING.yaml whenever I cannot parse it
<zyga-suse> Chipaca: and I got the string ` - : `or something like that
<zyga-suse> o_O
<zyga-suse> I should do incremental files to see what other strings may fail
<zyga-suse> and note that it is not random at all
<zyga-suse> er
<zyga-suse> it **is** random
<mvo> zyga-suse: do you always get the same yaml? hexdump -C on the file would be great
<zyga-suse> mvo: so far yes but as I said, I only save one file
<zyga-suse> mvo: so I could get the same one because it's the first/last
<mvo> zyga-suse: but that file is always the same?
<zyga-suse> yes
<zyga-suse> each time I saw it (~10
<mvo> zyga-suse: thats a good start
<jamesh> mvo: I've pushed some changes based on your review comments.  Assuming CI is happy with it, can you merge it?
<zyga-suse> and note that since I built the package so I managed to run everything at least once without any failures
<Chipaca> zyga-suse: ` - :` probably is bad yaml tho
<Chipaca> :-p
<zyga-suse> speaking of which, I wanted to upload that package
<zyga-suse> Chipaca: I figure :)
<mvo> pstolowski: does 3526 needs a review from gustavo? or just a second review?
<zyga-suse> let me get more facts
<zyga-suse> I find it annoying and curious at the same time
<mvo> jamesh: \o/ thank you
<mvo> jamesh: I have a look and if CI is green I will merge it, really nice to see this sorted, this is a huge win for usability
<pstolowski> mvo, hey, yes 3569 is ready but has been failing tests for random reasons unrelated to the PR itself, i restarted it a couple of times in the last few days
<mvo> zyga-suse: you sure its ` - :` and not `( - :` ;) ?
<zyga-suse> mvo: hahahaha
<jamesh> mvo: I've got more I'd like to do w.r.t. polkit support: this was just a minimal change to get the foot in the door.
<mvo> pstolowski: yeah, I pushed master, maybe today is a good day
<zyga-suse> mvo: yaml-smiley-virus-2017
<pstolowski> mvo, and yes, 3526 needs a review from Gustavo
<zyga-suse> mvo: replaces random in-memory yaml with a non-parsing smile
<zyga-suse> :D
<mvo> jamesh: anything that is ready or almost ready that we want for 2.28 (which we plan to tag in the next few days)?
<pstolowski> mvo, :) yes let's hope today is THE DAY ;)
<mvo> pstolowski: I added gustavo for 3526, lets poke him in the standup :)
<pstolowski> mvo, thanks@
<jamesh> mvo: It's probably best not to wait.  I'd like to add polkit auth for a few more APIs, but I understand that is somewhat controversial
<jamesh> mvo: less controversial is having the snap client support the textmode polkit agent and indicate whether it is interactive
<mvo> jamesh: ok, sounds good! what is needed for the textmode polkit agent? I assumed this is transparent for the API user, no?
<mvo> morphis_: want me to have a look at the open comments for 3260? it seems its almost there
<jamesh> mvo: essentially just have it fork "pkttyagent --fallback", like systemctl does
<zyga-arch> re
<zyga-arch> Chipaca: have a look
<jamesh> mvo: this would let you run privileged operations without sudo, having pkttyagent prompt if needed
<zyga-arch> https://paste.gnome.org/pecbkpb4e
<morphis_> mvo: if you have spare cycles for that, that would awesome
<zyga-arch> this is from
<zyga-arch> https://paste.gnome.org/prw9lmfbx
<mvo> jamesh: aha, nice!
<morphis_> mvo: but more in general I still waiting for niemeyer to approve this from an architectural point
<zyga-arch> Chipaca: ideas appreciated, I can patch and rebuild easily
<mvo> jamesh: if this PR is there before 2.28 is taged I will milestone it so that it gets at least priority reviews :)
<jamesh> mvo: okay
<mvo> morphis_: I can raise it in the standup, I was uner the impression he is happy with it now but I have not talked with him in detail
<morphis_> mvo: that was my guess too, but he still has his denial on the PR
<morphis_> mvo: otherwise let me try to get through zyga-arch's comments this afternoon
<mvo> morphis_: I tagged it for 2.28, lets see if that helps speeding it along. I also check the open question and will push changes
<morphis_> :-)
<Chipaca> zyga-arch: and which test is it that fails with this?
<mvo> morphis_: lets make a deal, I look at things now and what is left you can have in the afternoon :)
<morphis_> sounds good :-)
<zyga-arch> Chipaca: *any* tests that touches yaml, I saw it fail all over the source code
<Chipaca> zyga-arch: an example?
<zyga-arch> essentially any that calls snap.InfoFromSnapYaml for insatance FirstBootTestSuite.TestPopulateFromSeedHappyMultiAssertsFiles
<zyga-arch> (note that this is a first that I saw this particular test failing)
<zyga-arch> mvo: question, did you upgrade your laptop to >> xenial?
<zyga-arch> (hence the spellchcek and govet changes)
<zyga-arch> Chipaca: I just patched it to collect each failure, let's see what we get
<zyga-arch> https://paste.gnome.org/pjiw7rerp
<zyga-arch> more interesting failure log
<Chipaca> zyga-arch: what filesystem is this on?
 * Chipaca thinks "lardfs"
<zyga-arch> Chipaca: ext4
<zyga-arch> as boring as it gets, right?
<zyga-arch> Linux archlinux 4.12.8-2-ARCH #1 SMP PREEMPT Fri Aug 18 14:08:02 UTC 2017 x86_64 GNU/Linux
<zyga-arch> the kernel is fresh though
<Chipaca> zyga-suse: can you try with a kernel that isn't newer than the host's? (not that it should matter)
<zyga-arch> Chipaca: not sure, I don't know how to get old arch kernels
<Chipaca> zyga-arch: snap install linux-2.0.43
<Chipaca> no?
<Chipaca> aw :-(
<zyga-arch> heh, not yet
<zyga-arch> I improved logging to save the failing yaml and the error message
<zyga-arch> maybe some of those are genuine errors from the test suite
<Chipaca> âsnap set core locales en_GB.UTF-8â, WTDT?
<Chipaca> WDYT*
<ogra_> Chipaca, wont work
<Chipaca> ogra_: wy?
<ogra_> because there is no locale-gen
<Chipaca> ogra_: not _yet_ :-)
<ogra_> Chipaca, i wont add 20MB (or what was the locales stuff)
 * ogra_ forgot the exact size but it wasnt small iirc
<Chipaca> ogra_: oooh, we can discuss this like civilized people, or we can fight!
 * Chipaca gets his gloves
<zyga-arch> *ding* FIGHT
<zyga-arch> and you konw
 * Chipaca runs the fastest
<zyga-arch> the finishing move will be called LOCALITY!
 * Chipaca makes chicken noises and waves his elbows while running
 * ogra_ throws a de_DE.UTF-8 ... in a perl variant !
 * Chipaca is in a perl hackers list somewhere on the internet still
 * Chipaca mutates the glob behind the variant and throws it back
<zyga-arch> Chipaca: on the interenet nobody knows you are a perl interpreter
<ogra_> Chipaca, i'll trade though ... find something that compensates enough for the added stuff and we can talk ;)
<Chipaca> ogra_: but, serioulsy, if it's 20MB i'd agree, but i think what we want is the locale-gen, not the locales themselves
<ogra_> there is definitely still other stuff we can drop
<zyga-arch> ogra_: here's $0.01 for the flash cost ;)
<zyga-arch> Chipaca: here's another interesting failure
<zyga-arch> ----------------------------------------------------------------------
<zyga-arch> PANIC: firstboot_test.go:445: FirstBootTestSuite.TestPopulateFromSeedMissingBootloader
<zyga-arch> ... Panic: cmd: "mksquashfs . /tmp/check-717607699634245797/61/snapsrc/core_1.0_all.snap -noappend -comp xz -no-xattrs" failed: exit status 1 ("Parallel mksquashfs: Using 4 processors\nCreating 4.0 filesystem on /tmp/check-717607699634245797/61/snapsrc/core_1.0_all.snap, block size 131072.\n\r[===================================================================|] 1/1 100%writer: Lseek on destination failed because Bad file descri
<zyga-arch> ptor, offset=0x60\nFATAL ERROR:Probably out of space on output filesystem\n\n\nExportable Squashfs 4.0 filesystem, xz compressed, data block size 131072\n\tcompressed data, compressed metadata, compressed fragments, no xattrs\n\tduplicates are removed\nFilesystem size 0.35 Kbytes (0.00 Mbytes)\n\t101.72% of uncompressed filesystem size (0.34 Kbytes)\nInode table size 98 bytes (0.10 Kbytes)\n\t100.00% of uncompressed inode table
<zyga-arch> size (98 bytes)\nDirectory table size 55 bytes (0.05 Kbytes)\n\t100.00% of uncompressed directory table size (55 bytes)\nNumber of duplicate files found 0\nNumber of inodes 3\nNumber of files 1\nNumber of fragments 1\nNumber of symbolic links  0\nNumber of device nodes 0\nNumber of fifo nodes 0\nNumber of socket nodes 0\nNumber of directories 2\nNumber of ids (unique uids + gids) 1\nNumber of uids 1\n\tzyga (1000)\nNumber of gid
<zyga-arch> s 1\n") (PC=0x458E88)
<zyga-arch>  /dev/sda2        20G  9,5G  9,1G  52% /
<Chipaca> hmmmm
<Chipaca> zyga-arch: how
<Chipaca> 's space doing?
<zyga-arch> tmpfs           1,5G  2,1M  1,5G   1% /tmp
<Chipaca> ah
<zyga-arch> not bad
<Chipaca> zyga-arch: what does dmesg say?
<zyga-arch> really weird, right?
<ogra_> did you add locales back ?
<ogra_> :P
<zyga-arch> nothing at all
<zyga-arch> https://paste.gnome.org/psa6vgmnj
<zyga-arch> the last timestamp is old there
<mvo> zyga-arch: yeah, I run on zesty
<zyga-arch> mvo: I'm tempted to update my xenial x250
<mup> PR snapd#3569 closed: snapd,snapctl: decode json using Number <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3569>
<zyga-arch> any issues?
<mvo> zyga-arch: its doing fine on my x250
<Chipaca> zyga-arch: i'll move this weirdness to the backburner for a bit
<Chipaca> let see if something percolates
<zyga-arch> Chipaca: yeah, me too; thank you for the time!
<Chipaca> is it my machiine, or are the travis logs so slow they're almost unusable?
<zyga-arch> my network is shitty enough not to handle 2 IRC connections (and music streaming :P)
<pstolowski> yay! thanks mvo :)
<mvo> pstolowski: thank you :)
<zyga-arch> janisozaur: hey, around?
<janisozaur> o/
<zyga-arch> hey :)
<zyga-arch> do you have a moment to help me out?
<janisozaur> with?
<morphis> zyga-arch: I am seeing https://paste.ubuntu.com/25375579/ right now on my production system
<zyga-arch> janisozaur: I'd like you to build a package for me a few times
<zyga-arch> I'm seeing random bugs that feel like kernel memory corruption or something similar
<zyga-arch> and I need 2nd opinions
<janisozaur> on Arch?
<zyga-arch> yes
<zyga-arch> morphis: oh that's a new thing, feels I dind't patch the apparmor profile
<zyga-arch> morphis: where are you seeing this?
<morphis> zyga-arch: Ubuntu 16.04
<janisozaur> I don't have access to my system right now, maybe in the evening?
<morphis> I think with proposed enabled
<zyga-arch> janisozaur: that's ok, thank you!
<zyga-arch> morphis: I think we need to fix this, mvo ^^^
<zyga-arch> mvo: we may need to patch 2.27.x
<zyga-arch> let me check though
<morphis> 2.27.3 is the version of the snapd deb
<janisozaur> zyga-arch: that's on fully updated system, right?
<zyga-arch> yes
<zyga-arch> morphis: can you look at your apparmor profile
<zyga-arch> morphis: look for     mount options=(rw bind) @SNAP_MOUNT_DIR@/{,ubuntu-}core/*/etc/nsswitch.conf -> /tmp/snap.rootfs_*/etc/nsswitch.conf,
<zyga-arch> morphis: this should be in /etc/apparmor.d/
<morphis> yeah, it's there
<zyga-arch> morphis: can you check that it is present for the core snap version as well
<morphis> zyga-arch: hm, an apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real fixed it
<zyga-arch> morphis: !!!
<morphis> zyga-arch: the core snap is at 16-2.26.14
<zyga-arch> morphis: can you please open a forum topic
<zyga-arch> I think we've seen it before
<zyga-arch> but now it's a smoking-gun-bug
<zyga-arch> morphis: and please save your journal
<morphis> sure, but can't share that in the public
<zyga-arch> as there are log entries for each time the profiles are loaded
<zyga-arch> jdstrand: ^
<zyga-arch> mvo: ^ (possible bug in our packaging or in dh_apparmor in general)
<morphis> zyga-arch: mvo: https://forum.snapcraft.io/t/apparmor-profile-for-snapd-confine-not-reloaded-on-deb-update/1820
<morphis> zyga-arch: if I remember right I've rebooted in between
<mvo> zyga-suse: ok, we need to figure out if its a regression, fortunately its not too late yet to do another 2.27
<zyga-arch> mvo: I don't think so, we've seen this randomly a few times
<mvo> morphis: what is the timeline, i.e. did you apt upgrade and after that the snapd services did stop working?
<zyga-arch> mvo: but it is serious, it means we are running on a broken configuration
<mvo> zyga-arch: or did a reboot happen in between?
<zyga-arch> mvo: I don't know, it's morphis that is affected
<mvo> zyga-arch: yeah, definitely serious
<morphis> mvo: if I remember right, I did a manual apt upgrade
<morphis> did a reboot and then after some time wondered why specific services coming from a snap were not running
 * zyga-arch wonders where to upload the binary release for Arch
<zyga-arch> :/
<mvo> morphis: can you please add the info that there was a reboot in between? that might be useful to know
<morphis> done
<mvo> morphis, zyga-*: I think we want the input from jdstrand on https://forum.snapcraft.io/t/apparmor-profile-for-snapd-confine-not-reloaded-on-deb-update/1820
<janisozaur> zyga-arch: github releases?
<zyga-arch> janisozaur: oh, good idea
<zyga-arch> mvo: can I add a file to our 2.27.3 github release page?
<mvo> zyga-arch: I bet its apparmor cache related
<zyga-arch> mvo: I checked that the debhelper scripts uses an option to skip the cache
<mvo> morphis: silly question, but another reboot will not bring the problem back, right? I assume apparmor_parser -r will update all caches
<mvo> zyga-arch: oh? woah
<morphis> mvo: didn't tried yet
<zyga-arch> mvo: not sure, caches are writen to explicitly
<mvo> zyga-arch: so the file on disk is correct but the wrong profile is loaded even after reboot?
<zyga-arch> I think the early startup script that loads profiles
<zyga-arch> mvo: not sure how it uses or not uses caches
<mvo> zyga-arch: re file for release> what file exactly?
<zyga-arch> mvo: binary build for arch
<zyga-arch> and a source package for arch
<mvo> zyga-arch: sure
<zyga-arch> thank you
<mvo> zyga-arch, morphis: so just to double check - the apparmor profile on disk is correct, the reboot has happend and yet the kernel has an incorrect profile loaded?
<morphis> mvo: yes, that is what happened
<morphis> can it be a problem that the core snap was still at 2.26?
<zyga-arch> morphis: next time, don't reload the profile
<zyga-arch> morphis: please collect the loaded profile from sysfs
<mvo> morphis: would you mind also putting this as a TL;DR in the forum post :) ?
<zyga-arch> morphis: no, each profile is distinct
<zyga-arch> it applies to a specific binary via path
<mvo> morphis: this makes it also sound as alarming as it should sound :)
<zyga-arch> morphis: profiles can be extracted from memory
<zyga-arch> morphis: via /sys/kernel/apparmor/profiles/
<zyga-arch> morphis: but you need to copy the raw policy
<mvo> zyga-arch: 3260 is ready for a re-review
<zyga-arch> morphis: you cannot tarball the directory
<zyga-arch> (or you may need to give tar a smart option to ignore size)
<zyga-arch> mvo: noted, I'll open it now
<mup> PR snapd#3581 closed: daemon: add polkit support to /v2/login <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3581>
 * mvo hugs jamesh
<jamesh> mvo: thanks!
<morphis> mvo, zyga-arch: btw. shouldn't I better file a bug report on launchpad for this?
<zyga-arch> morphis: I prefer the forum really
<zyga-arch> morphis: people look there x10 more often
<morphis> zyga-arch: so is that were you now track bugs?
<zyga-arch> morphis: track TODOs really, bugs and other
<zyga-arch> morphis: a bug is fine as well but my point is that exposure there is low
 * zyga-arch spends $ETERNITY to upload the release
<morphis> just wondering what the actual policy is
<zyga-arch> morphis: no idea
<morphis> :-D
<zyga-arch> morphis: forum >> bug for sure but bugs are used too
<zyga-arch> I'll focus on the review from mvo/morphis now, ping me for attention
<mup> PR snapd#3784 opened: cmd/snap: in "snap info', don't print a newline between tracks <Created by chipaca> <https://github.com/snapcore/snapd/pull/3784>
<mvo> morphis: quick question - there is code in cmd_userd.go that looks like you created unittests, there is no cmd_userd_test.go on your hdd that is not git added ;)
<Chipaca> mvo: the bigger question is, how can you see morphis' hdd
<mup> PR snapd#3785 opened: asserts,overlord/devicestate: accept generic serials only if the model has generic-serials: true <Created by pedronis> <https://github.com/snapcore/snapd/pull/3785>
<pedronis> mvo:  this is the PR ^ ,  marked for 2.28  and needs Gustavo to look at it
<morphis> mvo: need to check but I guess I never ported them over from the former implementation when it was snapd --user
<morphis> mvo, zyga-arch: there seems to be another problem, I am now seeing seccomp enabled for my devmode snaps with 2.27.3
<zyga-arch> morphis: can you please collect as much stuff as you can
<morphis> sure
<zyga-arch> morphis: can you look at the bpf profile
<morphis> zyga-arch: how do I see if a process is running with seccomp attached?
<zyga-arch> morphis: and at the legacy profiles that we don't remove
<zyga-arch> morphis: let me check, I don't know
<zyga-arch> mvo: devmode snaps get an ALLOW bpf, right?
<zyga-arch> mvo: or nothing at all?
<morphis> hm, the profile has @complain
<zyga-arch> morphis: which specific file has this?
<zyga-arch> morphis: note that we have new profile location now so you may be looking at the old palce
<morphis> zyga-arch: the profile for my snap app
<zyga-arch> place
<zyga-arch> morphis: right, _which_ file? :-)
<morphis>  /var/lib/snapd/seccomp/profiles/snap.anbox.container-manager
<zyga-arch> that's the old file
<zyga-arch> it's not used anymore
<zyga-arch> and not removed either
<zyga-arch> morphis: look at seccomp/bpf
<zyga-arch> there are two files per profile
<zyga-arch> binary and source
<zyga-arch> those are compiled with snap-seccomp
<morphis> hm, /var/lib/snapd/seccomp/bpf/snap.anbox.container-manager.src has @complain too
<zyga-arch> okay so _so far_ so good
<zyga-arch> mvo: is the person to talk as he wrote that part
<morphis> but I see a lot denials in dmesg: https://paste.ubuntu.com/25375999/
<zyga-arch> I'll return to your code review
<zyga-arch> mq_timedreceive ?
<zyga-arch> or is this an i386 binary?
<morphis> it's x86_64
<zyga-arch> so this is mq_timedreceive, weird
<zyga-arch> I'll leave that to mvo for now
<zyga-arch> but feels like another forum topic to open
<morphis> zyga-arch: can I reliable switch back to the older snapd or will that break things even more?
<zyga-arch> you should be
<zyga-arch> (able to)
<morphis> ok, but lets wait for mvo before I do that
<pedronis> seems there are still issues with the fakestore sometimes
<pedronis> we probably want to print the logs there
<zyga-suse> morphis: I commented on the 3260 PR about one aspect of the spread test
<zyga-suse> morphis: can you look please
<zyga-suse> I'm looking at the rest
<morphis> zyga-suse: when I get to it today, I will for sure :-)
<morphis> zyga-suse: thanks
<mvo> zyga-suse, morphis: seccomp is allow all mode
<zyga-suse> mvo: aha, then something wonky is going on
<mvo> morphis: strange, @complain should be fine and should not kill anything, the generated bpf file ".bpf" would be nice, could you mail that to me?
<mvo> zyga-suse, morphis: I can look at the test issue in 3260, I'm keen to land that, will also look at the cmd_userd.go bits and see if I can come up with a test
<pedronis> mvo: Chipaca: as I told Gustavo yesterday IÂ have errands today that overlap with the standup so IÂ won't be there
<mvo> pedronis: ok, thank you
<morphis> mvo: sure
<morphis> mvo: sent
<morphis> mvo: so these messages in dmesg are no denials?
<zyga-suse> morphis: those are hard denials
<zyga-suse> (SIGKILL)
<zyga-suse> there's no complain mode for seccomp being used yet
<morphis> good, that is what I thought
<mvo> morphis: bpf disassembled looks ok, what architecutre is this? amd64?
<morphis> yes, amd64
<morphis> mvo: installed with snap install --devmode --edge anbox
<mvo> morphis: ok, let me try that
<mvo> morphis: I just did a snap install --devmode --edge anbox and systemctl status snap.anbox.container-manager is happy
<mvo> morphis: what should I see?
<ogra_> ppisati, ".config:9871:warning: override: reassigning to symbol ARCH_MEDIATEK" what does that mean ?
<ogra_> (building a patched arm64 mediatek kernel here, is the above fatal in any way ? i have never seen it before)
<jdstrand> morphis: fyi, syscall 243 is mq_timedreceive and that isn't included in any interfaces. the denial indicates you are not actually in complain mode
<jdstrand> mvo, zyga-arch: ^
<jdstrand> also, I commented in the forum topic
<jdstrand> morphis: ^ questions for you there
<zyga-arch> jdstrand: looking
<jdstrand> mvo: based on morphis' denial, it seems clear that seccomp.NewFilter(seccomp.ActAllow) isn't being run
<jdstrand> mvo: that should be a very small bpf based on lines 616-624 (as you know)
<jdstrand> morphis: can you paste the entirety of /var/lib/snapd/seccomp/bpf/snap.anbox.container-manager.src?
<mvo> jdstrand: morphis mailed me the bpf and it looks like this http://paste.ubuntu.com/25376337/
<zyga-suse> I get a change after running get-deps.sh
<mvo> jdstrand: so it looks like the normal allow bpf
<zyga-suse> golang.org/x/sys/unix changes checksum
<mup> PR snapd#3786 opened: vendor: update vendor.json after (presumed) manual edits <Created by zyga> <https://github.com/snapcore/snapd/pull/3786>
<zyga-suse> mvo: ^
<jdstrand> mvo: that's interesting. seems that the old non-bpf profile is being preferred, which suggests a problem with the reexec code
<mvo> jdstrand: oh, that is interessting
<mvo> morphis: what do you get with `snap version` on the system that has the anbox problem?
<zyga-suse> jdstrand: yes, I was thinking the same thing
<zyga-suse> jdstrand: the old profile gets used because the old snap-confine runs
<jdstrand> zyga-suse: based on the forum topic, it looks like morphis has the stable core installed (16-2.26.14) and upgraded to 2.27.3. I tried that exact upgrade path and couldn't reproduce the apparmor bits
<jdstrand> (upgraded t 2.27.3 deb)
<zyga-suse> jdstrand: I haven't been able to reproduce that
<zyga-suse> jdstrand: but I've seen it happen once in front of my eyes
<morphis> mvo, jdstrand: back now, let me read through the messages
<morphis> mvo: snap version output is on the forum thread
<jdstrand> zyga-suse: based on the forum topic alone, it looks like the system (not the reexec'd) snap-confine is used
<zyga-suse> yes, I agree
<jdstrand> zyga-suse: I wonder if it is a race between the snapd restart and the deb packaging
<zyga-suse> mmmm
<zyga-suse> re-execing snap (as in snap run) will always use the new snap-confine
<jdstrand> zyga-suse: but in this case, new is the deb (2.27 deb vs 2.26 snap)
<zyga-suse> riiiight
<zyga-suse> so there's no reexec
<zyga-suse> so there should be stuf from the distro
<zyga-suse> aha
<zyga-suse> I see
<jdstrand> so re-exec should not be in effect (indeed, the denial clears shows /usr/lib/snapd/snap-confine has the denial, not /snap/core/.../snap-confine
<zyga-suse> so half-way unpacked snap-confine binary?
<jdstrand> clearly*
<zyga-suse> yes, I noticed that
<jdstrand> I'm trying to think through that. let me look at the postinst again
<morphis> jdstrand: mvo: added requrested details to the forum post
<jdstrand> zyga-suse: so, looking at postinst, snapd looks to be started *before* the dh_apparmor hooks
<zyga-suse> oh,
<zyga-suse> in the maintainer script
<jdstrand> zyga-suse: line 125: deb-systemd-invoke start snapd.service >/dev/null || true
<jdstrand> zyga-suse: line 160:  apparmor_parser -r -T -W "$APP_PROFILE" || true
<mvo> morphis: the `snap version` output of the anbox issue
<mvo> morphis: that is the bit I care most about
<mvo> jdstrand: ohhhh, ok. will you do a PR or shall I?
<jdstrand> zyga-suse: now, the new profile should be on disk so, technically, snapd would load the new profile and it shouldn't matter. *but* if there was a problem there with snapd using the wrong profile and updating the cache, by the time apparmor_parser dh postinst is run, it wouldn't update the cache, so on reboot, it would be out of date
<jdstrand> zyga-suse: *if* the start won the race that is
<jdstrand> since we are seeing some reexec issues with seccomp, I'm not sure we can say for sure that snapd is doing the right thing here, so perhaps the postinst ordering exposes something
<jdstrand> morphis, zyga-suse: it does seem most correct to have the dh bits for apparmor before the dh bits for systemd, but I don't know if it will fix this issue
<zyga-suse> I'll read your conversation with focus in a moment (on a call)
<morphis> mvo: it's on the thread
<morphis> mvo: within the first post: https://forum.snapcraft.io/t/apparmor-profile-for-snapd-confine-not-reloaded-on-deb-update/1820?u=morphis
<mvo> morphis: I mean, you mentioned an "anbox" problem and seccomp not being in @complain mode but in enforce mode. that was a different issue, no?
<morphis> mvo: ah, I have both issues I've reported today (apparmor + seccomp) on the same system after the deb upgrade to 2.27.3
<morphis> so snap version output is the same for both
<mup> PR snapd#3784 closed: cmd/snap: in `snap info`, don't print a newline between tracks <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3784>
<mup> PR snapd#3787 opened: cmd/snap-repair: filter also on models and architecture <Created by pedronis> <https://github.com/snapcore/snapd/pull/3787>
<zyga-suse> + curl -sS -o - https://codeload.github.com/snapcore/snapd/tar.gz/2.27
<zyga-suse> gzip: stdin: not in gzip format
<zyga-suse> unhappy github?
<zyga-suse> only half of spread tests finished
<zyga-suse> in https://travis-ci.org/snapcore/snapd/builds/267571170?utm_source=github_status&utm_medium=notification
<Chipaca> zyga-suse: i got that one too for a lil' bit
<Chipaca> seems to be better now
<Chipaca> i'm assuming network hiccup
<zyga-suse> https://plus.google.com/114015603831160344127/posts/MdNjzwKvknX
<zyga-suse> jdstrand: ^ perhaps something to keep an eye out for
<zyga-suse> jdstrand: specifically https://bugs.freedesktop.org/show_bug.cgi?id=101354
<mup> PR snapd#3788 opened: cmd/snap-repair: ignore superseded revisions like the rest of the assertion infra <Created by pedronis> <https://github.com/snapcore/snapd/pull/3788>
<jdstrand> zyga-suse: thanks
<zyga-suse> jdstrand: were you familiar with those efforts?
<mvo> zyga-suse: 3260 should now address all questions/suggestions
<mvo> zyga-suse: why the question about artful?
<zyga-suse> mvo: run xdg-open on artful
<zyga-suse> last time I looked it was a broken shell script
<zyga-suse> (that didn't work)
<zyga-suse> recommending to switch to gio-open or something like it
<zyga-suse> it feels like an upstream change that will go our way sooner or later
<mvo> zyga-suse: looks ok to me (xdg-utils 1.1.1-1ubuntu2) - what system did you try this on?
<zyga-suse> mvo: maybe it was fixed
<zyga-suse> mvo: what happens when you run it? (note: artful, not zesty)
<zyga-suse> mvo: does it print any advice?
<mvo> zyga-suse: I only tested it in a chroot so far but it look like the normal xdg-open. version is the same as the zesty version
<zyga-suse> mvo: is it a shell script?
<mvo> zyga-suse: yes
<mvo> zyga-suse: it always was one
<ogra_> are oyu surte you are not looking at snapd-xdg-open ?
<mvo> (afaik)
<ogra_> *you sure
<zyga-suse> ogra_: no
<ogra_> (awful shell script talking about being replaced sounds exactly like it)
<zyga-suse> ogra_: no, that was a 4 line script
<zyga-suse> ogra_: that had a typo that made it broken
<zyga-suse> ogra_: maybe this update was pulled from artful since, I saw it on my desktop at home
<zyga-suse> (I cannot check that now)
<mvo> zyga-suse: xdg-open prints helpful advice in my cloudvm as well
<zyga-suse> it printed a message and ran something else
<zyga-suse> mvo: if it works and will stay working then fine
<mvo> zyga-suse: we can always tweak further, but if xdg-open is broken we have a bigger problem in artful
<zyga-suse> mvo: I was worried since it felt like it is going away
<hallyn> ...  say, the snappy vagrant box, is there a default username/pwd? vagrant wants those to get in to setup authkey
<mvo> zyga-suse: lots of 3rd party things use it
<zyga-suse> I see it even supports flatpak now
<jdstrand> zyga-suse: I wasn't, no. Simon, the submitter, is active with apparmor so I'm hopeful it won't conflict with anything. I haven't looked at any of this yet (I created a card)
<zyga-suse> thank you jdstrand
 * zyga-suse experiences dial-up speeds :/
<ogra_> use LTE !
<Chipaca> ogra_: i agree! Liquid Tension Experiment makes everything better. Evidence: https://www.youtube.com/watch?v=edqH0ofRQrM
<Chipaca> of course, zyga can't watch that because he's on GPRS
<Chipaca> zyga-suse: it could be worse: you could be tethered over bluetooth to an GPRS nokia. rfcomm still haunts me.
<mup> PR snapd#3786 closed: vendor: update vendor.json after (presumed) manual edits <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3786>
<zyga-suse> Chipaca: and the nokia might be wrapped in plastic and connected to usb power pack
<zyga-suse> Chipaca: out there glued to a tree
<zyga-suse> Chipaca: in the rain
<zyga-suse> Chipaca: to get the signal
<zyga-suse> Chipaca: that's close to how I'm connected
<Chipaca> zyga-suse: outside? you'd get several kbps more from that!
<Chipaca> like, 20% more! or 3kbps
<zyga-suse> haha
<zyga-suse> my network is so slow
<zyga-suse> that I see a merged branch (3786) in the list of open PRs
<zyga-suse> and that list has just loaded :D
<ogra_> lol
<jdstrand> morphis (cc mvo and zyga-suse): https://forum.snapcraft.io/t/apparmor-profile-for-snapd-confine-not-reloaded-on-deb-update/1820/8
 * zyga-suse looks
<morphis> jdstrand: just read it, interesting
<jdstrand> morphis: if you wanted to propose a PR, I'd be happy to review it
<jdstrand> morphis: maybe mvo or zyga-suse would want to propose that...
<morphis> jdstrand: sadly not enough time to do that
<mvo> jdstrand, morphis I can look at this in a bit
<zyga-suse> I can look
<jdstrand> ok, thanks guys
<zyga-suse> wow, git push takes noticeable time
<morphis> mvo: jdstrand: the other issue is seccomp being in enforce mode for devmode snaps
<mvo> zyga-suse: I take a break now, so feel free
<morphis> mvo: you found anything in the profiles I've sent you?
<mvo> morphis: its using the wrong profile, that seems to be the issue, does reloading the unit fixes the issue?
<mup> PR snapd#3789 opened: cmd/snap-confine: genearlize apparmor profile for various lib layout <Created by zyga> <https://github.com/snapcore/snapd/pull/3789>
<mvo> morphis: the profile looks correct, its the normal allow profile
<morphis> mvo: you mean restarting the systemd unit?
<mvo> morphis: I suspect what happens is that the old profile is loaded or was loaded
<zyga-suse> jdstrand: I'll propose a small PR with the order of calls in the maintainer script changed
<mvo> morphis: yeah, the systemd unit for the failing service
<morphis> mvo: nope, that doesn't help
<morphis> let me try to remove and install the snap again
<jdstrand> mvo: keep in mind seccomp doesn't work like apparmor-- snap-confine loads what is on disk into the kernel on each invocation (ie, there is no binary attachment or anything). either an old snap-confine that doesn't know bpf is parsing the profiles/* file, or the new snap-confine is preferring profiles/8 over bpf/*.bin for some reason
<zyga-suse> hmm, this debian packaging change will require some more surgery it seems
<jdstrand> mvo: the only other possibility would be *if* bpf/* on disk at the time snap-confine ran was strict mode, then updated after the fact for devmode
<zyga-suse> jdstrand, mvo: it seems that all of the magic is in #DEBHELPER# expanding, I wonder how we can fix that
<pedronis> zyga-suse: what's the status of snapd#3617, wasn't it split in a lot of smaller PRs ? or is still wip ?
<mup> PR snapd#3617: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3617>
<zyga-suse> pedronis: it's good for review I think, all the small PRs were merged and integrated there now
<zyga-suse> pedronis: I haven't checked where things go
<zyga-suse> (as in what needs doing there)
<jdstrand> zyga-suse: so, if you put dh_apparmor before dh-installinit, it still ends up after?
<zyga-suse> jdstrand: no, I mean that there is no explicit dh_apparmor there, it's all done at build time
<jdstrand> zyga-suse: ie, all in override_dh_installint
<zyga-suse> jdstrand: quickly looking at that file shows that it is post-processed during the build to contain the actual "meta"
<zyga-suse> "meat"
<jdstrand> zyga-suse: ?? I'm looking at debian/rules from xenial-- line 188 has dh_apparmor
<zyga-suse> I was looking at .postinst in packaging/ubuntu*/
<jdstrand> zyga-suse: if you are talking about packaging/*...
<jdstrand> zyga-suse: you have to look at packaging/ubuntu*/rules
<zyga-suse> ok, I have that open
<jdstrand> zyga-suse: you can change things in there to affect #DEBHELPER# in postinst
<zyga-suse> I see, I'm not familiar with that, let me experiment
<jdstrand> zyga-suse: alternatively, you can just drop dh_apparmor, then modify snapd.postinst directly to put what dh_apparmor would put in #DEBHELPER# before #DEBHELPER#
<jdstrand> zyga-suse: looking at that file, you just need to make it so dh_apparmor happens before dh_systemd_start -psnapd data/systemd/snapd.service
<jdstrand> cause it is deb packaging, you have lots of choices :)
<zyga-suse> yes :-)
 * jdstrand notes that the xenial Uuntu archive packaging does not seem to be derived from packaging/ubuntu*
<jdstrand> Ubuntu*
<zyga-suse> if that's the case we should fix that for 2.28
<jdstrand> I don't know what is used where, so to fix this in SRU, just make sure things are updated everywhere it needs to be
<jdstrand> zyga-suse: that might violate the SRU process. I'm not familiar with the agreements there. please discuss with mvo before transitioning 2.28 in the Ubuntu archive to packaging/ubuntu*
<zyga-suse> ah, indeed... man this stuff is so hairy
<zyga-suse> mvo:  I thought that each upload to xenial proposed was using this packaging
<zyga-suse> are you maintaining a separate package somewhere for xenial?
<jdstrand> oh, maybe it is
<Pharaoh_Atem> mvo is using packaging/ubuntu*
<jdstrand> I looked at the one from -updates rather than -proposed
<Pharaoh_Atem> that's why he's got the weird symlink for gbp
<jdstrand> the one from -proposed looks like packaging/ubuntu*
<jdstrand> zyga-suse: ^
<zyga-suse> aha
<jdstrand> zyga-suse: ie, I think you are good with updating packcaging/ubuntu*
<zyga-suse> well, that's nice then
<jdstrand> yeah, sorry for the brief noise
<zyga-suse> jdstrand: can you look at https://github.com/snapcore/snapd/pull/3789 while I'm fiddling with debian please?
<mup> PR snapd#3789: cmd/snap-confine: genearlize apparmor profile for various lib layout <Created by zyga> <https://github.com/snapcore/snapd/pull/3789>
<jdstrand> zyga-suse: so, you can move 'dh_apparmor --profile-name=usr.lib.snapd.snap-confine.real -psnapd' from override_dh_installdeb to the top of override_dh_systemd_start, *or* modify postinst to put what dh_appamor would do up above #DEBHELPER# in snapd.postinst
<jdstrand> the former is probably best, since you will benefit from bug fixes to dh_apparmor
<jdstrand> zyga-suse: yes, I can do that
<jdstrand> zyga-suse: you dropped a rule (libdl is specified in one but not the other)
<zyga-suse> oh, ineede
<zyga-suse> corrected
<zyga-suse> I just pasted your earlier rules from solus PRs
<zyga-suse> good catch!
<jdstrand> zyga-suse: yes, but you pasted only one of the comments :) there were two comments, one for each section :)
<jdstrand> zyga-suse: approved
<zyga-suse> thank you
<zyga-suse> I see, I will recheck that comment then
<zyga-suse> jdstrand: can you please look at the topmost three patches in https://github.com/zyga/snapd/commits/tweak/opensuse-snap-confine-aa-profile
<zyga-suse> I think the deeper two are okay
<zyga-suse> but the topmost one is surely not landable
<zyga-suse> ideas welcome
<zyga-suse> I will post them later today (I need to break now)
<mup> PR snapd#3790 opened: cmd/snap-confine: allow reading /proc/filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/3790>
<pedronis> niemeyer: both me and noise][ added some comments on the 'generic'/generic-serials topic,  I made the PRÂ but IÂ marked it blocked because it's a bit unclear whether is really what we want atm
<niemeyer> pedronis: Thanks, will follow up there
 * zyga-suse -> off for supper/break
<pedronis> mvo: I reviewed a couple fo small 2.28 PRs,  as I said mine is blocked atm,  I also created some small repair PRs, OTOH snapd#3616 is the next important unreviewed one
<mup> PR snapd#3616: cmd/snap-repair: implement Runner.Verify and use it to check signatures of repairs from Next <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616>
<Chipaca> zyga-suse: how do i fix the âcannot update snap namespace: cannot switch mount namespace: invalid argumentâ again?
<mvo> pedronis: does 3616 needs a normal review or a gustavo reivew?
<mvo> morphis, jdstrand: I'm very confused about the seccomp issue, what does "SNAPD_DEBUG=1 snap run anbox" show? this should print some re-exec related debug
<mup> PR snapd#3756 closed: corecfg: deal with system.power-key-action="" correctly <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3756>
<mup> PR snapd#3754 closed: corecfg: fix proxy.* writing and add integration test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3754>
<Chipaca> niemeyer: why does âN** become âwrite: (N-1)â and not âwrite: Nâ?
<Chipaca> the forum takeover of ^F stopping from doing actual useful in-page search is annoying
<niemeyer> Chipaca: Re. forum, sometimes it indeed feels awkward, but the thinking is probably that things both load and unload dynamically on the page, so CTRL-F is not super useful as it is either
<niemeyer> Chipaca: About the **, I suggest seeing the video on the first message
<Chipaca> i know -- still annoying :-)
<niemeyer> It is
<morphis> mvo: 2017/08/23 18:37:15.673897 cmd.go:103: DEBUG: core snap (at "/snap/core/current") is older ("2.26.14") than distribution package ("2.27.3")
<niemeyer> Chipaca: It explains in detail what it's supposed to do and why it's sort of a unique case
<niemeyer> Chipaca: I'd guess it's about half-way through the video
<Chipaca> fair 'nuf (i thought i knew, but Â¯\_(ã)_/Â¯)
<niemeyer> Chipaca: CTRL-F won't help on the video either, unfortunately :P
<Chipaca> niemeyer: but âplay at 2Ã speedâ does :-)
<niemeyer> Chipaca: Yeah, love it as well
<Chipaca> niemeyer: also love âplay at 0.75Ãâ when learning music
<niemeyer> Chipaca: Recently I also used /2 for the first time
<Chipaca> niemeyer: also: mplayer -af scaletempo=scale=1.0 -speed 0.75
<niemeyer> Chipaca: It was a super dense topic, and the speaker felt like speaking at 3x naturally
<niemeyer> Chipaca: I actually doubted he was able to speak with so much precision about so many things so fast, and thought the video was sped up.. but looking at other hints the video, no.. the guy was just inhuman..
<niemeyer> Chipaca: Nice, I didn't know about scaletempo
<pedronis> mvo: both
<Chipaca> niemeyer: the order of -af and -speed is important in that (if you set the speed before doing the scale, it's does the opposite and you need to specify speed=pitch
<niemeyer> Aha, makes sense
<niemeyer> Chipaca: This is the one if you're curious: https://www.youtube.com/watch?v=j-A0mwsJRmk
<pedronis> mvo: it has zero reviews atm
<Chipaca> niemeyer: yeah, as i understand it 1** meant âreads 0 and 1, writes 0 and/or 1â
<niemeyer> Chipaca: Yeah, I'm trying to avoid [0, 1], but so far no good ideas have shown up
<niemeyer> Perhaps we don't need to avoid it.. this is really an extremely atypical case and I expect a handful of snaps to use it
<Chipaca> niemeyer: âand/orâ is perhaps too handwavy to codify though
<Chipaca> niemeyer: is there a resason read is an ordered array instead of two endpoints?
<niemeyer> Chipaca: Yeah, the thinking will need to change from write N to write compatible with N
<Chipaca> do we really want to support a snap reading 1, 2 and 4 but not 3/
<Chipaca> to me an epoch/read_{min,max} and epoch/write, epoch/compat, would cover how it's in my head
<niemeyer> Chipaca: We went from a simplistic view of the world to one that respects its craziness while keeping a way to represent it simplistically.. we should probably not give up on acking that the world is crazy :)
<niemeyer> Chipaca: e.g.
<niemeyer> Chipaca: epoch 1 is a stable, epoch 2 was an alpha revision that broke the format, epoch 3 is the new stable
<niemeyer> Chipaca: It's quite plausible to have a 3 that can handle read 1 but not 2
<Chipaca> niemeyer: true dat
<Chipaca> niemeyer: wrt crazy, thinking about people that actually want a version of âmaster@87da2fcf1d0925f489985323303531507b5ed537â
<mvo> morphis: do you get output or is anabox immediately killed when you run the above command?
<niemeyer> Chipaca: I don't think we should allow those
<Chipaca> niemeyer: i agree -- we want them human readable
<niemeyer> Yeah, this is clearly oriented for a machine to read
<mvo> morphis: fwiw, this debug output looks sane SNAP_CONFINE_DEBUG=1 snap run anabox
<niemeyer> and will corrupt the output of everybody else if shown entirely
<morphis> mvo: https://paste.ubuntu.com/25377571/
<morphis> mvo: no, the process doesn't get killed
<morphis> the process will spawn an LXC container
<morphis> and processes inside that will get killed later on
<Chipaca> mvo: is test-snapd-dbus-service yours?
<mvo> Chipaca: I think so
<Chipaca> mvo: i was going to ask you to build it for i386, but i changed my test instead
<Chipaca> mvo: because i'm lazy _and_ impatient
<mvo> morphis: oh, that is interessting, so it does not get killed but the daemon part of it is?
<mvo> Chipaca: heh, ok
<mvo> Chipaca: I think we just need to upload it to LP to make it build there
<mup> PR snapcraft#1501 closed: tests: use assertThat instead of assertEqual <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1501>
<mvo> morphis: I think we need to continue to debug this tomorrow morning, I will ping you if thats ok
<niemeyer> morphis, mvo: Provided some feedback on the userd PR..
<niemeyer> Some simple recommended changes and one issue to think through
<zyga-suse> re
<zyga-suse> Chipaca: hmmmm, not sure, is this on 14.04?
 * zyga-suse gives up on backlog
<zyga-suse> Chipaca: did you resolve that issue?
<kyrofa> roadmr, any idea what's happening here? https://pasteboard.co/GH176X7.png
<mup> PR snapd#3789 closed: cmd/snap-confine: genearlize apparmor profile for various lib layout <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3789>
<mup> PR snapd#3791 opened: cmd/snap-confine: allow using additional libraries required by openSUSE <Created by zyga> <https://github.com/snapcore/snapd/pull/3791>
<zyga-suse> jdstrand: ^ a small PR with extra libraries for snap-confine
<kyrofa> roadmr, I can't upload that snap again, but I should not have to request manual review
<zyga-suse> jdstrand: thank you for the review
<zyga-suse> jdstrand: last of the trivial PRs that' s likely to go in is https://github.com/snapcore/snapd/pull/3790
<mup> PR snapd#3790: cmd/snap-confine: allow reading /proc/filesystems <Created by zyga> <https://github.com/snapcore/snapd/pull/3790>
<zyga-suse> jdstrand: this is the RFC branch that I don't expect to land https://github.com/snapcore/snapd/pull/3792
<mup> PR snapd#3792: cmd/snap-confine: allow running snap-exec without confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/3792>
 * zyga-suse gets back to layout
<mup> PR snapd#3792 opened: cmd/snap-confine: allow running snap-exec without confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/3792>
<jdstrand> roadmr: can you sync r919? (fix for 1712476, unrelated to my previous request to you)
<zyga-suse> I just found a huge downside of using snaps :-(
<zyga-suse> when you are working on snap-confine and other lower parts
<zyga-suse> and you tweak things
<zyga-suse> and your music player or video player breaks
<zyga-suse> man that is annoying
<zyga-suse> (those apps are snaps)
<roadmr> jdstrand: sure, I'll put it in the queue
<roadmr> kyrofa: let me see
<jdstrand> zyga-suse: done
<jdstrand> zyga-suse: you should use a vm :)
<zyga-suse> jdstrand: thank you again
<zyga-suse> jdstrand: I have plenty but I also like to work natively
<roadmr> kyrofa: which snap is this?
<kyrofa> roadmr, revisions 2692, 2678, and 2684 of nextcloud
<jdstrand> zyga-suse: play music from your vm :P
<jdstrand> roadmr: thanks!
<zyga-suse> man, did you try that? it's terrible
<zyga-suse> choppy and no video acceleration that works
<roadmr> jdstrand: btw the latest update (913, right?) was deployed earlier today \o/
<mup> PR snapd#3790 closed: cmd/snap-confine: allow reading /proc/filesystems <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3790>
<jdstrand> roadmr: awesome, thanks! :)
<jdstrand> zyga-suse: I was joking :)
<jdstrand> I've gotten to where I don't do any dev work on my system except for the occasional live policy updates
<Chipaca> zyga-suse: no, i just used a different snap to test
<jdstrand> everything is vm
<jdstrand> s
<zyga-suse> Chipaca: I'd appreciate if you could run that again
<zyga-suse> Chipaca: with SNAP_CONFINE_DEBUG=1
<Chipaca> sure, 1 sec
<Chipaca> zyga-suse: SNAP_CONFINE_DEBUG=1 doesn't seem to have changed anything
<Chipaca> zyga-suse: what a i looking for?
<zyga-suse> Chipaca: what's the last few things
<Chipaca> zyga-suse: where
<zyga-suse> and did you get any denials/messages logged?
<zyga-suse> like nothing at all?
<zyga-suse> SNAP_CONFINE_DEBUG=yes hello
<zyga-suse> or whatever that snap was
<Chipaca> zyga-suse: "hello"?
<Chipaca> i mean
<Chipaca> the snap is not installed
<Chipaca> zyga-suse: http://pastebin.ubuntu.com/25378106/
<zyga-suse> Chipaca: any snap that you ran this with before that failed with EINVAL
<zyga-suse> I see
<zyga-suse> hmm hmm hmm
<zyga-suse> I see
<Chipaca> (as per usual, this might be me needing to install the right thing)
 * zyga-suse assumed something else
<Chipaca> (but i thought we'd fixed that)
<zyga-suse> is this a make-hack experience?
<Chipaca> it is
<zyga-suse> I think it was a different case before
<zyga-suse> wait
<Chipaca> zyga-suse: you want me to see if doing this with stock snapd works?
<zyga-suse> unless it's one of the versions
<zyga-suse> just install snap-update-ns in distro location
<zyga-suse> and see if that fixes it
<Chipaca> 1 sec
<roadmr> jdstrand: ironic :) "Store upload scan failed for review-tools [...] Unexpected output from click-review.
<roadmr> jdstrand: (which btw looks very similar to what kyrofa reported)
<kyrofa> roadmr, jdstrand yeah I just got several more emails about it as well. Something is busted
<Chipaca> lel
<roadmr> kyrofa: indeed
<Chipaca> zyga-suse: yes that fixed it
 * zyga-suse wants that release to go out one day
<Chipaca> zyga-suse: i thought we'd changed 'make hack' to copy that one as well?
 * Chipaca makes a note to push a PR for this
<zyga-suse> no, I don't think we did
<zyga-suse> we should
<zyga-suse> thanks!
<Chipaca> ok, i'll do it
<Chipaca> but after dinner and dogwalk
<jdstrand> roadmr: that is probably the cleanup code. it will output stuff if there are lingering things to clean
<roadmr> jdstrand: aha. Is that in r913?
<roadmr> jdstrand: it happened in your snap and kyrofa's but not on mine, which is a trivial minimal snap... which kinda makes sense
<jdstrand> roadmr: yes, 913 (also 919)
<jdstrand> roadmr, kyrofa: r2698 passed review
<roadmr> yep, that's slightly suspicious - why some and not others?
<jdstrand> roadmr: you have more than one review machine?
<Chipaca> zyga-suse: how do i rebuild the makefile?
<roadmr> jdstrand: yes, reviews run on app servers and there are 4 of them
<Chipaca> just ./autogen.sh?
<zyga-suse> Chipaca: automake
<zyga-suse> Chipaca: I _may_ have a nicer  build system on the horizon
<jdstrand> roadmr: right, so the one that tried the libreoffice snap will have a directory that didn't get cleaned
<zyga-suse> Chipaca: but for now you just need automake
<jdstrand> roadmr: (the bug r919 fixes)
<roadmr> click-review returned unexpected output for package /tmp/tmplOHGz7/nextcloud.nextcloud_master-2017-08-23_i386.click: ERROR: Could not find '/tmp/review-tools-p1e8wr9d' Removing old review '/tmp/review-tools-skxfgd28'
<Chipaca> in my experience "nicer build system" just means "build system that is more naive about the twisted ways of the world"
<roadmr> jdstrand: that's for kyrofa's package, this is for yours: click-review returned unexpected output for package /tmp/tmpwU84wp/review-tools.jdstrand_0.47+git_i386.click: ERROR: Could not find '/tmp/review-tools-skxfgd28'
<jdstrand> roadmr: so it will try to clean it. until r919 is rolled out, it will fail eith PermissionError. when r919 hits, a msg() to stdout will state it is being cleaned
<zyga-suse> no, just it doesn't have a 5000 line shell crap in case you are on that broken release of AIX on this 36 bit processor using that non-ascii encoding
<jdstrand> roadmr: I don't understand the review-tools one... that is suggesting the directory went away
<roadmr> jdstrand: interestingly, note that both log messages mention /tmp/review-tools-skxfgd28
<roadmr> hm, but that doesn't seem to be it. This is another nextcloud one:   click-review returned unexpected output for package /tmp/tmpF5KzHz/nextcloud.nextcloud_11-2017-08-23_i386.click: ERROR: Could not find '/tmp/review-tools-7p_jt1us'
<roadmr> click-review returned unexpected output for package /tmp/tmpbFMjHa/zeronet-js.mkg20001_0.0.1-alpha17_armhf.click: ERROR: Could not find '/tmp/review-tools-vuwvtkw3' ??
<jdstrand> roadmr: do multiple reviews happen concurrently on these servers?
<roadmr> jdstrand: hm, potentially, yes
<roadmr> are they racing each other? :(
<jdstrand> roadmr: ok, r919 fixes that
<roadmr> jdstrand: yay :) well it's already in the pipeline, if so, the fastest way is to just stay the course until I can roll out r919
 * roadmr checks for clean runway and so on
<jdstrand> roadmr: I'll get rid of that msg() too and turn it into debug() for r920
<roadmr> thanks... ugh I hope it doesn't continue to output spurious stuff which confuses sca :(
<jdstrand> roadmr: that is what r920 will address. r919 fixed a short-circuit value for 'maxage' in the reaping code. it should've been 'only reap if the stale review dir is older than 3 hours'
<jdstrand> roadmr: I can up that to anything. I figured a review that was 3 hours old was clearly hung
<roadmr> yes, I agree
<roadmr> jdstrand: so is it that two concurrent reviews are trying to reap the same temporary dir?
<jdstrand> roadmr: in r913, yes
<jdstrand> roadmr: in r919, no. but, please hold off r913 for a moment
<jdstrand> I'll have an r920 in just a moment
<roadmr> oh you meant "hold off r919" :)
<jdstrand> roadmr: yes. want to test the use of debug()
<roadmr> ok
<Chipaca> zyga-suse: comme Ã§i? https://github.com/snapcore/snapd/compare/master...chipaca:make-hack-update-ns
<zyga-suse> mmm
<zyga-suse> nice use of $(or)
<zyga-suse> you want to use $(wildcard *.go) I think
<zyga-suse> same for others
<zyga-suse> I don't think *.go does what you want
<zyga-suse> and I think you want to use 755
<zyga-suse> not 644 :D
<roadmr> jdstrand: merges are kinda fire-and-forget, I did my best to try and stop r919 from landing so we don't waste time testing/building that. Not sure I succeeded :)
<zyga-suse> other than that I think it looks ok
<jdstrand> roadmr: no big deal. that will fix the concurrency issue (sorry about that)
<Chipaca> zyga-suse: lel
<Chipaca> zyga-suse: about the 755
<Chipaca> zyga-suse: about *.foo AIUI it works in prereq's
<jdstrand> roadmr: r920 is now committed. it will fix the output to not confuse SCA and should properly cleanup the bad libreoffice snap review directory
<zyga-suse> I somewhat dobut that (in automake many things are weridly broken)
<zyga-suse> though... let mecheck
<roadmr> jdstrand: woohoo, I'll propose the r920 merge
<zyga-suse> Chipaca: ah, you are corret
<zyga-suse> *correct
<zyga-suse> Chipaca: globs work when used directly
<Chipaca> yup
<zyga-suse> Chipaca: don't work when using variables, hence the function $(wildcard)
<Chipaca> zyga-suse: if i'm editing a makefile, i have 'info make' open :-)
<zyga-suse> haha, guess what I did
<Chipaca> because otherwise i've got to _remember_ this stuff
<zyga-suse> I love make though
<zyga-suse> even if it sucks
<roadmr> haha
 * Chipaca is not arguing
<kyrofa> roadmr, can you let me know when it's deployed? I don't know which snap goes into which channel, so I'll need to re-spin all my builds
<jdstrand> roadmr: it is weird that the bum libreoffice snap happened at the same time as the r913 rollout, but it is good that it did-- it made it clear what was happening there
<roadmr> kyrofa: sure thing. Sorry about that :( it'll be about 2 hours but I'll ping here
<kyrofa> Thank you
<roadmr> jdstrand: I saw that error in a bunch of units (I think all of them actually) - so unless libreoffice built e.g. 4 snaps and they all hit different units, I think it was more about the race condition (the "unexpected output" thing, I mean)
<roadmr> at least I do get visibility on that unexpected output via kibana
<jdstrand> roadmr: yes, there were two issues. one was concurrent, one was the lo snap
<roadmr> jdstrand: when it rains it pours eh? :) (and 2 drops constitute a downpour haha)
<mup> PR snapd#3793 opened: cmd: "make hack" now also installs snap-update-ns <Created by chipaca> <https://github.com/snapcore/snapd/pull/3793>
<jdstrand> but both would've given unexpected output
<Chipaca> zyga-suse: ^
<jdstrand> anyway, r920 should fix that
<roadmr> great :)
<zyga-suse> thank you
<Chipaca> now let's go walk that hound
 * roadmr barks in approval
<Chipaca> roadmr: I only have the short lead for you i'm afraid
<Chipaca> also, i'm not picking up your poo
<Chipaca> just FYI
 * roadmr wags tail
<roadmr> haha
<mup> PR snapd#3794 opened: asserts,overlord/devicestate: revert allowing 'generic'-signed serials <Created by pedronis> <https://github.com/snapcore/snapd/pull/3794>
<mup> PR snapd#3526 closed: hooks: support for refresh hook <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3526>
<janisozaur> zyga-arch: sorry, can't help today
<zyga-suse> ikey: hey, offtopic, how to debug solus getting no keyboard input when installed in gnome-boxes?
<zyga-suse> ikey: could it be related to my locale (pl)?
<mup> PR snapcraft#1504 opened: project loader: refactor into package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1504>
<roadmr> kyrofa: that rollout you're waiting for is in progress, should be about 10-15 mins. I'll confirm when it's done
<kyrofa> Great, thanks roadmr
<roadmr> kyrofa: ok, done - let it rip.
<roadmr> jdstrand: ^^ same
<jdstrand> roadmr: thanks!
<jdstrand> roadmr: fyi, there is r922 which is not urgent. It makes it so any error during the reap results in a syslog entry (instead of a traceback)
<roadmr> nice!
<roadmr> I'll make a note to put in a merge for that tomorrow; I'm almost EOD and don't want to leave it dangling today :(
<jdstrand> roadmr: r921 has a new yaml check (ie, standard stuff)
<jdstrand> roadmr: sure, np at all. thanks for doing it! :)
<jdstrand> stgraber: fyi ^
<stgraber> jdstrand: sounds good
#snappy 2017-08-24
<morphis> mvo: hey!
<mvo> hey morphis
<mvo> morphis: soâ¦ anbox still failing?
<morphis> mvo: I am sorry, didn't had much time yesterday evening to debug the seccomp issue further
<morphis> mvo: jepp, still get seccomp denials
<morphis> https://paste.ubuntu.com/25381201/
<morphis> mvo: did a reboot this morning
<morphis> DEBUG: raising privileges to load seccomp profile
<mvo> morphis: this DEBUG: read 48 bytes from /var/lib/snapd/seccomp/bpf//snap.anbox.container-manager.bin looks right, 48byte is the allow profile
<morphis> sounds like somethign which shouldn't happen for a devmode snap, or I am wwrong with that assumption?
<morphis> ah
<mvo> morphis: it should not happen, we need to figure out why it is happening now :)
<mvo> morphis: can you pastebin the dmesg denials again please?
<morphis> sure
<morphis> https://paste.ubuntu.com/25381213/
<morphis> a few
<mvo> morphis: and those are the result of "sudo SNAP_CONFINE_DEBUG=1 snap run anbox.container-manager      " and this command gets killed right away?
<morphis> nope, anbox.container-manager doesn't get killed
<morphis> that is the tricky thing here
<morphis> anbox.container-manager uses LXC to start a container
<mvo> morphis: aha, I think I get it - the arch=40000003 is the problem :/
<morphis> and processes inside that container are getting killed
<morphis> mvo: why that?
<mvo> morphis: what arch is that? someting android special? or is there some usermode cpu emulation or something going on?
<morphis> no cpu emulation, let me check
<mvo> morphis: when you do a "seccomp.NewFilter(default=Allow)" this will still filter on architecture :(
<mvo> morphis: and this arch is none not amd64 nor i386
<mvo> morphis: hm, or maybe it is just in a different notation, let me dig into it
<morphis> it should be either amd64 or i386
<morphis> mvo: https://paste.ubuntu.com/25381228/
<mvo> morphis: aha! thanks, so *maybe* multi-arch releated
<morphis> mvo: yeah that makes sense
<morphis> but everything inside the Android container should be either 64 or 32 bit x86
<morphis> there is no ARM stuff
<morphis> mvo: the new filtering came in with 2.27?
<mvo> morphis: and indeed, the arch is 386
<mvo> morphis: correct
<morphis> ok, then smells like we're not filtering correct
<mvo> morphis: actually  it came in with 2.26.x :/
<morphis> hm
<morphis> did we release a 2.26 deb package?
<mvo> morphis: yes, it was availabe in -proposed
<mvo> morphis: it should still be in -updates, so you should be able to downgrrade
<morphis> if I am not wrong I was using 2.26 here either through re-exec or via the deb package
<morphis> mvo: do you need anymore debugging from my side on this?
<mvo> morphis: maybe, let me try to reproduce again with your steps
<morphis> mvo: then let me keep this for a moment
<mvo> morphis: ok, this is all very strange - I snap install anbox, run the same command as you in the pastebin, get exactly the same .bin file, get exactly the same debug output but no errors, the thing just runs. can you pastebin the output of "snap version" please?
<morphis> https://paste.ubuntu.com/25381266/
<morphis> mvo: ah, you need to do a bit more to trigger the errors
<morphis> $ sudo systemctl stop snap.anbox.container-manager.service
<morphis> sudo SNAP_CONFINE_DEBUG=1 snap run anbox.container-manager
<morphis> $ ANBOX_LOG_LEVEL=debug anbox session-manager
<morphis> the last one will trigger the boot of the container and then you should see the denials
<mvo> morphis: I get "failed to start as either binder or ashmem kernel drivers are not loaded", I guess I need to do an insmod somehere?
<mvo> morphis: this is using lxc, right? I wonder if it is related to that, iirc it also has some seccomp bits
<mvo> morphis: but first, let me try to reproduce :) any suggestion for the binder/ashmem?
<morphis> mvo: ah right, you need https://launchpad.net/~morphis/+archive/ubuntu/anbox-support
<morphis> then apt install anbox-modules-dkms
<morphis> that will build and load the binder/ashmem kernel drivers
<morphis> mvo: or if you take the right way: $ snap install --classic anbox-installer && anbox-installer
<morphis> that will do these things for you
<mvo> morphis: hrm, hrm, I modprobe binder_linux, its showing up in lsmod but I get the same error message :(
<morphis> modprobe ashmem_linux
<morphis> you need both
<mvo> ta
<mvo> morphis: *cough* still no denial :(
<mvo> morphis: [Renderer.cpp:248@initialize] successfully initialized EGL
<morphis> hm, stop the session-manager and start it with $ anbox session-manager --single-window
<morphis> that should give you a Android screen after a while
<morphis> mvo: which kernel are you on?
<morphis> I am running the 4.10 HWE kernel here
<mvo> morphis: the zesty default kernel 4.10.0-32-generic
<morphis> ok
<morphis> so same as me
<mvo> morphis: single-window does it for me, loads of syscall denials
<morphis> good!
<mvo> morphis: thank you, I dig a bit
<morphis> np, thanks for getting into this :-)
<mvo> morphis: just to confirm, no issues with 2.26.14
<morphis> mvo: let me revert back to that and verify
<mvo> morphis: its fine,I think I can take it from here
<mvo> morphis: again, thanks a lot for reporting this!
<morphis> mvo: jepp, verified now, 2.26.14 is working fine
<morphis> mvo: np
<mvo> morphis: I think I have a fix, its indeed a multi-arch related regression, building an update now
<morphis> mvo: nice!
<mup> PR snapd#3795 opened: Polkit interactive flag <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3795>
<jamesh> mvo: ^^ the above is a fairly simple improvement to my polkit-support branch you merged yesterday: let the client decide whether to allow interaction
<mvo> jamesh: thanks, checking
<Chipaca> good morning peeps
<Chipaca> electrician is here and my power will be going off by about 20 minutes at some point soon
<zyga-suse> good morning
 * zyga-suse waits forever until PRs show up :/
<mvo> zyga-suse: just fyi, 2.27.4 just got uploaded, morphis helped me to track down the seccomp regression, it was a missing cherry pick related to multi-arch. I think we don't have a spread test for this case yet, I will add one
<zyga-suse> mvo: understood, thank you, I wil help with updated packages
<zyga-suse> mvo: I remember that fix but didn't you make it for 2.26.x?
<zyga-suse> mvo: was it just not merged back to 2.27 after the release?
<zyga-suse> (after the 2.26.x release was merged back to master)
<mvo> zyga-suse: yeah, that was exactly the problem
<zyga-suse> mvo: as a sanity check, can you look at merging release/2.26 into release/2.27 please?
<zyga-suse> and we could use this as a standard process
<zyga-suse> to ensure that no point release fixes are missing in new release
 * zyga-suse rolls up his packaging sleeves
<zyga-suse> and throws a coin to see if the tarball layout is the same ;-)
<Chipaca> morphis: if you happen to be editing snapd-user-instance again sometime, could you s/'%s'/%q/?
<zyga-suse> Chipaca: I left comments for that
<morphis> Chipaca: I am trying to get to that point, will include that
<Chipaca> morphis: i was going to comment on the PR but couldn't find a way to properly say "don't do this unless you happen to be here" and have you believe me
<Chipaca> zyga-suse: ah! you did? missed it
<zyga-suse> Chipaca: perhaps a new instance of that was added
<Chipaca> zyga-suse: yeah, not seeing your comment :-)
<mvo> zyga-suse: *pff* - yeah, I did a sanity check and things look good, some delta mostly because we did some things slightly differently in 2.26 and fixed that in 2.27
 * zyga-suse_ is fed up with shitty network
<mcphail> zyga-suse_: welcome to my world :)
<zyga-suse_> mcphail: where do you connect from?
<mcphail> zyga-suse_: I work away from home in the north of scotland. I'm often on 2G mobile connections, but even broadband in the "city" of Inverness is painfully slow
<mup> PR snapd#3796 opened: release: new 2.27.4 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3796>
<zyga-suse_> I'm technically on LTE but I ran over (ahem, kids did) my data plan so I get to see why they show number of bits per second :/
<mcphail> heh. buy another sim for the rest of the month?
<mcphail> if you need a decent connection, it has to be worth the money
<mcphail> Claim it back from canonical as a work expense :)
<zyga-suse_> mcphail: it's not easy, only one network is here, I'm in the woods with no car (no way to go out until my wife comes back for weekend) and normal data plans strongly favor contract over pre-paid (one month) thing (from this telco only, others are better but don't have any coverage here)
<zyga-suse_> it's just for this week, normally I have two mobile connections that work OK
<zyga-suse_> (in the capital)
<mcphail> aah well. Enjoy the solitude :)
<mcphail> zyga-suse_: https://chris.bolin.co/offline/
<mup> PR snapd#3796 closed: release: new 2.27.4 release <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3796>
<mup> PR snapd#3797 opened: daemon: allow polkit authorisation to install/remove snaps <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3797>
<zyga-suse_> why did you close the PR?
<jamesh> mvo: ^^ and here's the other branch.  This one would definitely need niemeyer's signoff based on previous conversations
<mup> PR snapd#3788 closed: cmd/snap-repair: ignore superseded revisions like the rest of the assertion infra <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3788>
<mup> PR snapd#3798 opened: release: 2.27.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3798>
<Chipaca> ooh, nice, bug
<mvo> jamesh: thank you
<mvo> Chipaca: what bug?
<Chipaca> mvo: snap's completion of service names does not filter
<pedronis> hello
<pedronis> there was some confusion with my small PRs, IÂ need a quick review of snapd#3787 , which now is just adding some test cases
<mup> PR snapd#3787: cmd/snap-repair: more test coverage of filtering <Created by pedronis> <https://github.com/snapcore/snapd/pull/3787>
 * zyga-suse_ looks
<Chipaca> 2017-08-24 09:58:00 Cannot allocate linode:ubuntu-16.04-32: cannot create Linode disk with ubuntu-16.04-32: you do not have enough unallocated storage to create this Disk (872 requested, but only 0 available)
<Chipaca> :-(
<zyga-suse> we require more megabytes
<zyga-suse> (spoken with starcraft zerg voice)
 * zyga-suse waits _eternity_ for package downloads :/
<zyga-suse> ah, finally cached!
<mup> PR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
<mwhudson> oh so i should upload 2.27.4 to debian ?
<zyga-suse> mwhudson: yes, unless we disabled seccomp in debian
<mwhudson> oh i think we did
<zyga-suse> but I think uploading it is ok in general since pepole will feel it is in sync
<mwhudson> ifeq ($(shell dpkg-vendor --query Vendor),Debian)
<mwhudson>     VENDOR_ARGS=--disable-apparmor --disable-seccomp --enable-static-libcap
<mwhudson> someone said something about taking that out but apparently i didn't...
<zyga-suse> I think we might enable seccomp on debian nowadays
<mwhudson> mvo: did you actually tag 2.27.4?
<zyga-suse> and not do static libcap (we don't need to)
<mvo> mwhudson: there is a tag, is there not?
 * zyga-suse uploads new suse build
<mwhudson> mvo: ah yes, got confused about which remote was which in this repo :)
<mvo> :)
<mwhudson> zyga-suse: i can make those changes, how do i tell if they've broken something?
<ogra_> mvo, hmm ... did you explisictly pick beta when building core ? (edge stil has the old builds)
<zyga-suse> mwhudson: run snaps
<mwhudson> zyga-suse: ok :)
<mvo> ogra_: sort of, I changed edge back right after pushing to beta
<ogra_> ah, fine then
<mvo> ogra_: so that it refelects master
<ogra_> yep
<zyga-suse> mwhudson: there's a PR that has several most downloaded/important snaps
<zyga-suse> mwhudson: just trying a few I think (or one of each class) is sufficiently good as smoke test IMO
<zyga-suse> suse is now up-to-date
<zyga-suse> man, this is too easy
 * zyga-suse looks at arch
<pedronis> mvo: snapd#3798  seems to have broken cmd/snap-repair tests on it, not sure how/why
<mup> PR snapd#3798: release: 2.27.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3798>
<mvo> pedronis: how stange, let me lok
<mvo> look
<mwhudson> debian@debian:~$ hello.universe
<mwhudson> /usr/lib/snapd/snap-confine: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
<mwhudson> how did i do that
<mvo> mwhudson: uh, is that apparmor denials for libcap.so.2 ?
<mwhudson> oh yes
 * mwhudson puts that bit back
<pedronis> Chipaca: it's cannot allocate disks land?
<Chipaca> yuh
<pedronis> :/
 * zyga-suse needs a faster HDD
<zyga-suse> mwhudson: you confined snap-confine
<zyga-suse> mwhudson: take this patch:
<mwhudson> i did
<zyga-suse> https://github.com/snapcore/snapd/pull/3791/files
<mup> PR snapd#3791: cmd/snap-confine: allow using additional libraries required by openSUSE <Created by zyga> <https://github.com/snapcore/snapd/pull/3791>
<zyga-suse> mwhudson: also look at master, cherry pick one more patch before this one affecting the same file
<zyga-suse> mwhudson: this should fix it for you
<zyga-suse> travis/spread is unhappy today
<zyga-suse> my hdd is unhappy
<zyga-suse> my 300GB old HDD is unhappy to be precse
<mwhudson> mvo: https://github.com/snapcore/go-gettext/pull/1
<mup> PR go-gettext#1: update import path to new location <Created by mwhudson> <https://github.com/snapcore/go-gettext/pull/1>
<mwhudson> :)
<mwhudson> zyga-suse: did you see https://github.com/snapcore/snapd/pull/3760
<mup> PR snapd#3760: Allow snap-confine to be confined even with --disable-apparmor <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3760>
<zyga-suse> I probably did, let me review it
<mwhudson> mmm tests failed i wonder why
<zyga-suse> mwhudson: I sent a RFC PR and got detailed feedback from jdstrand yesterday
<pedronis> mwhudson: we have infrastructure problems atm , all tests are failing
<mwhudson> pedronis: these tests ran a few days ago
<zyga-suse> as in https://github.com/snapcore/snapd/pull/3792
<mup> PR snapd#3792: cmd/snap-confine: allow running snap-exec without confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/3792>
<pedronis> ah ok
<zyga-suse> mwhudson: I think we want to solve the same problem
<zyga-suse> mwhudson: check out what jamie wrote about it
<mwhudson> zyga-suse: ah yes
<mwhudson> zyga-suse: i thought there was another way of doing this, which was to generate a super loose apparmor policy when in forced devmode state
<mwhudson> rather than generating no policy at all
<mwhudson> zyga-suse: but do what jamie says, i guess :)
 * zyga-suse -> coffee
<zyga-suse> I'll wait 20 minutes for various pulls/pushes/builds anyway
<zyga-suse> sigh
<mup> PR snapcraft#1505 opened: errors: introduce ContainerError <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1505>
<pedronis> mvo: IÂ marked this upcomign for you:  https://forum.snapcraft.io/t/snapd-not-restarting-on-revert/1679  IÂ think you merged a fix
<mvo> pedronis: thank you
<zyga-suse> mvo: I made a small tweak/fix to tests related to LANG
<zyga-suse> mvo: https://github.com/snapcore/snapd/pull/3799
<mup> PR snapd#3799: snap/squashfs: use LANG=C.UTF-8 <Created by zyga> <https://github.com/snapcore/snapd/pull/3799>
<zyga-suse> mvo: I suspect we may need a few more as new translations show up
<mup> PR snapd#3799 opened: snap/squashfs: use LANG=C.UTF-8 <Created by zyga> <https://github.com/snapcore/snapd/pull/3799>
<zyga-suse> mvo: this lets me go test without fiddling with language
<mvo> ok
<mvo> zyga-suse: can you pastebin the failure you are seeing (that lead to this change) ?
<zyga-suse> sure
<zyga-suse> mvo: https://paste.gnome.org/pjmwzmgo2
<mvo> zyga-suse: ta
<zyga-suse> mvo: are you running your system with english or german locale?
<mvo> zyga-suse: does http://paste.ubuntu.com/25382296/ help?
<mvo> zyga-suse: I use en
<zyga-suse> mvo: that explains it, looking
<zyga-suse> setenv is evil
<zyga-suse> I wonder how golang can have a broken function like that
<zyga-suse> I honestly prefer my approach as it limits the env change to the started process
<zyga-suse> and not to golang process
<mvo> zyga-suse: I will reply in the pR
<zyga-suse> mvo: I replied
<zyga-suse> mvo: looking at it from i18n angle
<zyga-suse> mvo: what would be the right solution if both the invoked program and the snapd code itself was localized
<zyga-suse> mvo: the test would have to have synchronized localization
<mvo> zyga-suse: the paste was not the final solution, just checking that this is enough to fix the issue. I still think from a i18n pov its preferable that the child runs with the native locale, it might have to tell the user something
<zyga-suse> yes, that I agree with
<mvo> zyga-suse: anyway, this is slightly crufty code (pretty old) I have a look if there is a way to remove some of this oddness
<zyga-suse> we could just patch the test for now
<mvo> zyga-suse: yeah
<zyga-suse> .* vs the english error
<mvo> zyga-suse: I think runCommand is really not needed with testutil.MockCommand() etc
<zyga-suse> aha, good point too
<mvo> zyga-suse: I have a look, but feel free to do the change you suggested
<zyga-suse> ok
<zyga-suse> I'll check in a moment, just wrapping up arch builds
<mvo> zyga-suse: no worries and no rush
<mvo> zyga-suse: *cough* I think the problem goes away entirely
<mvo> zyga-suse: hm, maybe, maybe not, looking harder
<zyga-suse> hmm?
<zyga-suse> can you explain
<mvo> zyga-suse: just wait for my PR, its kind of funny
<mup> PR snapd#3800 opened: squashfs: remove runCommand/runCommandWithOutput as we do not need it <Created by mvo5> <https://github.com/snapcore/snapd/pull/3800>
<mvo> zyga-suse: -^
<mvo> zyga-suse: thanks again for finding this! I get some lunch now, let me know your thoughts
<zyga-suse> enojy
<mvo> zyga-suse: you mentioned the problem is not solved, afaict the error happens in testcode that I removed, so what is left to do?
<zyga-suse> mvo: I mean we removed the test so the problem is not going to show up
<zyga-suse> but we need to figure out how to test i18n eventually
<zyga-suse> that's what I wanted to convey
 * zyga-suse has is usual food poisoning woes after moving to a new location
<zyga-suse> how I hate my body in days like this
<mup> PR snapcraft#1503 closed: ci: speedup the CLA check <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1503>
<zyga-suse> what's wrong with travis today?
<pedronis> no spread run can get disks afaict
<zyga-suse> good day to feel sick and work locally then
 * zyga-suse notices that British pound is awfully cheap lately
<mup> PR snapcraft#1504 closed: project loader: refactor into package <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1504>
<ogra_> ppisati, is the 3.10 branch of the sample-kernel tree up to date ? (i need to port to a board that only has 3.10 sources)
<ppisati> ogra_: it's in line xenial, so yeah, go ahead
<ppisati> *on par
<mvo> zyga-suse: right, well, the test and the offending code is gone, but yes, at some point we will need to look at i18n in tests
 * zyga-suse nods
<ogra_> ppisati, thanks !
<zyga-suse> popey: hey
<zyga-suse> popey: isn't martin an arch TU?
<zyga-suse> can we ask him for help?
<mup> PR snapd#3799 closed: snap/squashfs: use LANG=C.UTF-8 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3799>
<zyga-suse> jdstrand: what am I doing wrong here: https://paste.gnome.org/pwb7cargz
<zyga-suse> jdstrand: note that I added just this
<zyga-suse> +#include </var/lib/snapd/apparmor/snap-confine.d>
<zyga-suse> jdstrand: ah, I see now
<Chipaca> niemeyer: would you agree that people in other teams working on snapd would benefit from joining the standup if they're struggling with process?
<Chipaca> e.g. if they're bashing their heads on the wall of OMG 50+ PRs
<pedronis> I *am* bashing my head against 50+Â PRs
<Chipaca> pedronis: you should join the standup!
<jdstrand> zyga-suse: when including a directory the directory must exist
<Chipaca> wait
<zyga-suse> right, it did exist, the problem was " " vs < >
<jdstrand> zyga-suse: so the packaging is going to need to create it
<jdstrand> oh right, I think I told you wrong wrt " vs <>
<pedronis> Chipaca: it might help or not,  50+Â PRs is a bit bad anyway
<jdstrand> (sorry)
<pedronis> Chipaca: for anybody
<zyga-suse> taking gustavo's advice about email we should close them all
<Chipaca> i tried that
<Chipaca> people got upset
<zyga-suse> jdstrand: no worries, I found the jump to apparmor docs interesting
<pedronis> well I think we are close to a point in which we should just stop adding them until they are below one page
<Chipaca> pedronis: +1.33
<Chipaca> and i say that as somebody with a branch ready to be a pr
<mup> PR snapd#3372 closed: tests: add basic lxd test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3372>
<zyga-suse> struct { PRs [50]PR } snapd;
<zyga-suse> or something
<pedronis> Chipaca: anyway even just,  you, zyga, me and mvo, if each of us has 10 open PRs, it makes 40
<zyga-suse> back when poland was under soviet rule we had "stamps" for food and other basic things
<zyga-suse> we could bring "PR stamps"
<zyga-suse> you get 3 a week
<zyga-suse> and you have to make it
 * zyga-suse cannot wait to see the economy of stamp trading
<Chipaca> zyga-suse: but then we'd have a solidarnosc team handing out counterfeit stamps
<zyga-suse> it might also end with the round table talks and free elections ;)
<ogra_> will we have to hand over snapcore to walesa ?
<Chipaca> zyga-suse: the longer-term economic impact of your suggestion dissuades me
<popey> zyga-suse: he used to be one, but gave it up when he moved to work on ubuntu
<zyga-suse> popey: not according to the TU page
<popey> yeah, he still has limited access in places
<jdstrand> are you suggesting that if an individual has more than N open PRs, stop proposing PRs and start reviewing?
<jdstrand> Chipaca: ^
<popey> flexiondotorg: ^
<pedronis> jdstrand: something something, sadly some PRs have more complicated constraints
<jdstrand> yes
<jdstrand> I was going to mention that
<pedronis> also it's clear that the forum has eaten into reviewing time
<jdstrand> it is a hard problem
<zyga-suse> yes
<zyga-suse> forum is more fun than reviews
<jdstrand> oh gosh, the forum has eaten into all time
<zyga-suse> that's a problem
<Chipaca> we should nationalise the trains
<jdstrand> well, fun
<zyga-suse> heh
<Chipaca> everything leads on from there
<jdstrand> I mean, we are told to be responsive to the forum (with good reason)
<zyga-suse> yes
<zyga-suse> and releases
<flexiondotorg> I used to be an Arch TU.
<flexiondotorg> I stood down about 8 months ago.
<flexiondotorg> Looks like that page didn't get updated.
<flexiondotorg> So I have considered re-applying, just to maintain snapd etc.
<pedronis> yes, just saying that PR creation seems to be one of the few things we can control
<jdstrand> that's technically true, but it won't fly when people say 'the forum has too much traffic, so people couldn't do reviews, so I stopped proposing PRs"
<zyga-suse> flexiondotorg: I could work with you, I can prepare each release technically
<jdstrand> it's a difficult problem
<Chipaca> jdstrand: i'm saying _we_ should stop pushing PRs until the queue is under control
<zyga-suse> flexiondotorg: I just need to have someone sponsor it (in arch-specific way)
<zyga-suse> Chipaca: "you should stop eating until we have more food"
<zyga-suse> ish
<zyga-suse> I agree but it's not a simple solution
<jdstrand> Chipaca: as a temporary action, sure
<jdstrand> that makes a ton of sense
<jdstrand> I was thinking bigger picture
<Chipaca> we're going to have to have something in place permanently, as clearly we aren't self-governing without _something_
<zyga-suse> standup time
<zyga-suse> Chipaca: vote
<Chipaca> omw
<jdstrand> but maybe temporary halting PRs and review queue focus isn't bad in the short term
<jdstrand> while people think about how to do it better long term
<zyga-suse> +1
 * zyga-suse goes for the token
<zyga-suse> sigh
<zyga-suse> why does chrome always log me out
<flexiondotorg> zyga-suse OK, I'm not sure how well an application to re-apply will go down. More so given the agenda.
<flexiondotorg> But I can try.
<zyga-suse> let's try
<jdstrand> Chipaca, zyga-suse: one thing we experimented with on the security team was heuristics. you give everything a point value based on priority. different attributes add to the heuristic. for example, critical vs high vs medium vs low priority feature, customer facing bug, regular bug, contribution from community, how old the PR is, etc (whatever makes sense). then you give a score for each
<jdstrand> Chipaca: if you end up with a PR review with a higher score than a feature's score, you do the review
<mup> PR snapd#3456 closed: many: add interfaces.SystemKey() helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3456>
<jdstrand> Chipaca: this isn't perfect, because you can't squeeze blood from a stone. an understaffed team will end up  with a big queue, but at least the most important items are being worked on
<jdstrand> Chipaca: importantly, age of PR review could get extra points. eg, 0 extra of < 1 week, 10 extra if 2 weeks old, 50 if 3
<zyga-suse> jdstrand: right, I think there are many ways to solve this, we just have to agree on something and be consistent
<mup> PR snapd#3585 closed: many: configure store from state, reconfigure store at runtime <Created by atomatt> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3585>
<jdstrand> if the team is severely understaffed, you end in a particularly bad state where you are only reviewing things that are old. you therefore seem unresponsive (cause you are!) and you aren't getting features done
<Chipaca> jdstrand: yeah. I think we're not that bad, but we risk seeming so if we don't stay on top of it
<ogra_> you could have a comment-bot that adds "we'll be processing yoour PR shortly, please hold the line" once a week
<ogra_> :)
<zyga-suse> there are ... 3512 days remaining
<jdstrand> lol
<Chipaca> zyga-suse: ðð ð¦ð£ ð·ðð¶ðð¸ð½ is ð¿ð®ð»ð ð¦ðªð­ð¬ð¯ð±ðð«ð± ðð ðð.
<zyga-suse> "all the operators are busy though"
<zyga-suse> I wonder how your message shows up in text mode programs
<zyga-suse> how did you do it?
<zyga-suse> I just went to amazon.com and got a "are you a robot" page
<zyga-suse> woah
<ogra_> and ?
<ogra_> are you ?
<zyga-suse> well, it's somewhat intrusive change,
<zyga-suse> I wonder why they introduced it
<zyga-suse> screen-scraping bots?
<ogra_> yeah, likely
<ogra_> though if people use screen scapers they can as well just use pixel correct click generation ... as long as the layout doesnt change and the checkbox is always in the same place at least
<zyga-suse> it's a captcha
<ogra_> ah, not the "I'm not aa robot" checkbox thing then
<ogra_> (which is kind of a cut down capcha ...)
<pedronis> niemeyer: IÂ don't think IÂ fully parsed how we should tag things you should review? you said "BLOCKED" that means more it cannot go in yet to me (probably because it breaks something or is incompatible with something or some new choice)
<niemeyer> pedronis: Sorry, I used the word in a loose way instead of actually suggesting using that as a tag
<pedronis> niemeyer: IÂ mean IÂ have now a couple of things that are marked blocked and some need your review, but they are blocked because we changed our minded or are not fully updated to some other change, not because they need your review
<niemeyer> pedronis: Trying to come up with a good term for that
<pedronis> niemeyer: ok
<pedronis> not urgent but do let us know
<niemeyer> pedronis: There's actually a real mechanism in GH to ask someone to review it
<niemeyer> pedronis: I wonder if there's a filter on it
<niemeyer> That would be the best
<pedronis> I use it
<pedronis> but I haven't found a filter fo rit
<pedronis> it would be strange if there isn't though
<pedronis> niemeyer:  https://github.com/pulls/review-requested
<pedronis> ?
<niemeyer> pedronis: Brilliant.. review-requested:<username>
<niemeyer> pedronis: So we don't need to invent anything else
<Chipaca> zyga-suse: https://github.com/chipaca/bin/blob/master/unifonter
<pedronis> niemeyer: I think IÂ marked the ones I'm aware of correctly
<pedronis> niemeyer: though snap#3573 it's in a messy state atm, IÂ need travis back to work so IÂ can land the revert of 'generic'-signed allowing to put it into shape
<niemeyer> pedronis: I'm cleaning it
<niemeyer> I'm actually implementing a feature in spread to do it for me, as there are too many machines to do that by hand without it feeling absurd
<pedronis> mvo: zyga-suse: Chipaca: that's what is marked for Gustavo:  https://github.com/snapcore/snapd/pulls/review-requested/niemeyer don't know if you have any other thing
 * zyga-suse looks
<zyga-suse> oh, nice
<zyga-suse> I don't have any other things yet, after my hangout review I know what to do
<Chipaca> pedronis: i'll tag him in one of the ones about the store work
<pedronis> Chipaca: yes, IÂ need to review those too but they are quite serialized
<Chipaca> yeah, but no point him reviewing them as a series
<Chipaca> i think
<Chipaca> e.g. the storestate one is pretty clear, clean, and straightofrward imo
<Chipaca> pedronis: that is snapd#3780 fwiw
<mup> PR snapd#3780: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
<Chipaca> which i'm reviewing now
<Chipaca> (so it might turn out to be terrible! :-) )
<pedronis> probably james henstridge ones need his input?
<Chipaca> pedronis: wasn't he already done with those?
<pedronis> there are new ones
<Chipaca> pesky people, making forward progress and stuff
<pedronis> Chipaca: there's a bit of an open question in #3780  which is , it does nothing about the urls in auth.go
<Chipaca> pedronis: well... those aren't in Config
<Chipaca> pedronis: by which i mean: i think moving them into config would be alright, but separate from this pr
<Chipaca> but let's see what the pr authors say
<pedronis> Chipaca: yes, would be good to understand the plan forward though
<sergiusens> jdstrand: how can I see that a slot is effectively setup or way it failed to do so?
<sergiusens> this is what I get when trying to connect: "error: snap "gnome-3-24" has no slot named "gnome-3-24-platform""
<zyga-suse> sergiusens: try new snap interface (singular)
<zyga-suse> though we need snap connections
<sergiusens> zyga-suse: says I don't have that command
<zyga-suse> ah, !released :/
<davidcalle> ikey: welcome to the frontpage of snapcraft.io
<zyga-suse> 2.28
<sergiusens> zyga-suse: any lower level way to verify this?
<zyga-suse> sergiusens: try snap interfaces (plural)
<zyga-suse> and pastebin
<sergiusens> zyga-suse: only one entry
<zyga-suse> only one? that's odd
<sergiusens> this feels like https://forum.snapcraft.io/t/vanishing-plugs/1823?u=sergiusens
<sergiusens> I'll continue there
<zyga-suse> harry potter and the vanishing plugs
 * ogra_ hands sergiusens a drill to make more plugs
<mup> PR snapd#3632 closed: asserts,overlord/assertstate: auto refresh account-keys <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3632>
<sergiusens> just posted an update zyga-suse on there, change 128 is interesting
<zyga-suse> lookinb
<zyga-suse> sergiusens: what's the smoking gun?
<zyga-suse> everything looks fine there
 * sergiusens curses at the forum at its force of quoting on text selection
<ogra_> well
<ogra_> 124  Error   2017-08-24T07:01:10Z  2017-08-24T07:11:54Z  Auto-refresh snap "lxd"
<ogra_> 125  Error   2017-08-24T12:26:10Z  2017-08-24T12:36:58Z  Auto-refresh snap "lxd"
<sergiusens> zyga-suse: 128 is "Connect gnome-twitch:gnome-3-24-platform to gnome-3-24:gnome-3-24-platform" and yet it failed
<ogra_> that happened right beofre
<ogra_> *before
<zyga-suse> ah, I see
<sergiusens> ogra_: you say the transaction breaks as it is not an isolated task?
<sergiusens> this could explain the previous failure too
<zyga-suse> sergiusens: can you collect the state file
<ogra_> sergiusens, i have no idea, i just noticed that you have a bunch of erroring updates of lxd there as well
<sergiusens> fwiw, lxd cannot update due to a profile switch error, it has been discussed on the forum
<zyga-suse> though we don't store plugs/slots in the state
<zyga-suse> is this in a container?
<zyga-suse> what is snap version
<sergiusens> zyga-suse: where do you store it? snapd things its good from a state PoV it seems, but not really
<sergiusens> zyga-suse: no, my real system
<zyga-suse> just in memory
<sergiusens> 2.27.3+17.10
<zyga-suse> interesting
<zyga-suse> I'll think about what might cause this behavior
<zyga-suse> just to make sure
<zyga-suse> snap interfaces
<zyga-suse> that shows nothing ?
<sergiusens> zyga-suse: I added a call to that with a grep on the post
<sergiusens> it doesn't
<sergiusens> I bet that if I reinstall it will work
<zyga-suse> yes
<zyga-suse> reinstall adds/removes interfaces from a given snap
<zyga-suse> can you just pastebin full "snap interfaces" please
<sergiusens> zyga-suse: http://paste.ubuntu.com/25383368/
<zyga-suse> sergiusens: can you keep the system as is
<zyga-suse> and let me think for a moment
<sergiusens> zyga-suse: well I reinstalled the snap, sorry
<sergiusens> my work machine
<zyga-suse> and the output is before or after?
<sergiusens> I bet if you installed many snaps for use you'd run into this ;-)
<zyga-suse> sergiusens: I had 15 before I were testing purge logic
<sergiusens> zyga-suse: before... I like just did it 15" ago
<zyga-suse> seyeongkim: I have 7 now
<zyga-suse> ok
<zyga-suse> sergiusens: ^
<sergiusens> zyga-suse: gnome-twitch still doesn't run unfortunately "cannot change profile for the next exec call: No such file or directory"
<sergiusens> so I still have a weird problem with interfaces ;-)
<zyga-suse> sergiusens: that seems to say that you have no apparmor profile
<zyga-suse> sergiusens: are you on a !ubuntu kernel?
<zyga-suse> I'm working on something that will make that work soon
<sergiusens> zyga-suse: yeah, non ubuntu, well ubuntu with things on top
<zyga-suse> sergiusens: can you run ls -l in /sys/kernel/security/apparmor/features
<ogra_> and apparmor dropped :P
<sergiusens> http://paste.ubuntu.com/25383394/
<ogra_> thats a short list :)
<zyga-suse> sergiusens: right, you need more for snapd to enable apparmor
<sergiusens> aa-status does say I have apparmor though http://paste.ubuntu.com/25383400/
<zyga-suse> sergiusens: as a quick workaround rebuild snapd
<zyga-suse> sergiusens: and pass --disable-apparmor to configure
<zyga-suse> yes, but not all the features
<ogra_> ogra@nanopi-air:~$ ls /sys/kernel/security/apparmor/features
<ogra_> capability  caps  dbus  domain  file  mount  namespaces  network  policy  ptrace  query  rlimit  signal
<ogra_> thats the subdirs you want
<sergiusens> got it
<zyga-suse> alternatively copy all of security/apparmor to your kernel and rebuild that
<zyga-suse> jdstrand: https://github.com/zyga/snapd/commit/ef40971ea1da4110fa6474ccff634802236aebdd
 * zyga-suse -> break / walk
 * Chipaca -> break walkers' legs
<jdstrand> zyga-suse: this feels like it should be coordinated with mvo's https://github.com/snapcore/snapd/pull/3456
<mup> PR snapd#3456: many: add interfaces.SystemKey() helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3456>
<zyga-suse> jdstrand: perhaps but for now it is a small improvement over what we have in release.go
<zyga-suse> jdstrand: I only intend to make it "enough" to implement the permissive confinement
<zyga-suse> jdstrand: when we pick up the system key branch again we can tie that into it easily
<jdstrand> ok, I'm sure mvo will comment when it goes up for review. I'll look at this as is
<zyga-suse> thank you!
<sergiusens> zyga-suse: ogra_ ok I am back, I rebooted into an ubuntu kernel, installed, and now back and it all works
<sergiusens> so with the profiles created with the kernel that has all the features I get a working snap on a kernel without all the features ;-)
<zyga-suse> yes, we'll soon have a feature that will make it work on a partially supported kernel
<zyga-suse> (with just some apparmor features around)
<zyga-suse> it will still be devmode but at least it will not fail
<sergiusens> zyga-suse: if I install the way I just mentioned, I don't get devmode though
<zyga-suse> that's an interesting bug in itself
<zyga-suse> something that jamie just spoke about is related to it
<sergiusens> zyga-suse: and I get loaded profiles
<zyga-suse> right
<zyga-suse> just because the apparmor backend was not loaded at all
<zyga-suse> my patches address that partially already
<zyga-suse> so it will work regardless
<zyga-suse> but not by accident
<sergiusens> jamesh: hey, can you please take a final look at https://github.com/snapcore/snapcraft/pull/1298 ?
<mup> PR snapcraft#1298: jhbuild plugin: new plugin <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1298>
<zyga-suse> jdstrand: thank you for the review, I added rlimit, I'll work on subsequent parts of this
<mup> PR snapd#3800 closed: squashfs: remove runCommand/runCommandWithOutput as we do not need it <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3800>
<Chipaca> mvo: dunno if you saw but snapd#3693 is properly sad
<mup> PR snapd#3693: snapstate: improve the error message when classic confinement is not supported <Created by mvo5> <https://github.com/snapcore/snapd/pull/3693>
<mvo> Chipaca: everything was sad the entire day, let me see if there is different sadness this time. thanks for the heads up
<Chipaca> mvo: no, this one is on you
<Chipaca> mvo: "classic confinement requires snaps under /snap or symlink from /snap to %!s(MISSING)"
<mvo> Chipaca: autsch
<mvo> Chipaca: let me fix that
<Chipaca> IKR
<zyga-suse> m-i-s-s-i-n-g
<zyga-suse> I wonder why golang doesn't make that a compile time error
<Chipaca> ruh roh
<Chipaca> dreamhost dead?
<zyga-suse> even C does nowadays
<zyga-suse> what's on dreamhost?
<Chipaca> chipaca.com :-)
<Chipaca> well, r.chipaca.com
<Chipaca> which is where the fun is
<zyga-suse> aha
<zyga-suse> dreamhost is sleeping?
 * zyga-suse should take a break
<Chipaca> dns seemed to have hiccuped
<Chipaca> it's back now
<Chipaca> zyga-suse: agreed
<zyga-suse> https://paste.gnome.org/pddn5v3pp
 * zyga-suse is grumpy 
<zyga-suse> well
<Chipaca> zyga-suse: here: https://www.youtube.com/watch?v=u5XDnaeGbLk
<Chipaca> that one cheers me up :-)
<mup> PR snapd#3586 closed: client, daemon: rest api to reconfigure snapd with a custom store <Created by atomatt> <Closed by atomatt> <https://github.com/snapcore/snapd/pull/3586>
<mup> PR snapd#3590 closed: cmd/snap: snap cli to set or revert the custom store <Created by atomatt> <Closed by atomatt> <https://github.com/snapcore/snapd/pull/3590>
<jdstrand> zyga-suse: unfortunately the reviews for commits doesn't let me group them altogether, so they are coming in piecemeal, but I'm done now
<kyrofa> I just updated snapd in my lxd container to 2.26.10, and it's no longer starting up
<kyrofa> I'm getting this: "snapd.service: Failed at step NICE spawning /usr/lib/snapd/snapd: Permission denied"
<zyga-suse> jdstrand: that's fine, I get notified on each in a separate section
<Chipaca> kyrofa: i think there's a bug about that
<Chipaca> kyrofa: look for Nice=-5 in snapd.service and nuke it
<Chipaca> kyrofa: and shake your fist at systemd, or at the universe in general
<kyrofa> Chipaca, I suppose we still have no spread tests running on lxd, then?
<Chipaca> kyrofa: and then systemctl daemon-reload, and maybe restart snapd
<ogra_> i think we do, but the fix (dropping NICE=) actually landed in 2.27.3
<Chipaca> kyrofa: it broke after we'd released (the nice has been there for a while)
<Chipaca> kyrofa: the universe has very good integration tests
<Chipaca> kyrofa: but they run on production
<pedronis> kyrofa: mvo started some but it there were issues
<kyrofa> pedronis, what issues?
<pedronis> kyrofa:  https://github.com/snapcore/snapd/pull/3372
<kyrofa> Chipaca, thanks for the Nice hint, I'm back up and running. Teach me to update my production instance
<mup> PR snapd#3372: tests: add basic lxd test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3372>
<kyrofa> Thanks pedronis
<ogra_> do we re-exec in lxd ? then you could just switch to the core in beta
<ogra_> hmm ... or not since the systemd unit probably still comes from the outside
<pedronis> this is about the .service files so reexec doesn't help
<ogra_> yeah, just struck me
<mup> PR snapd#3801 opened: tests: add test to ensure amd64 can run i386 syscall binaries <Created by mvo5> <https://github.com/snapcore/snapd/pull/3801>
<kyrofa> There are numerous other issues in lxd as well. Particularly the garbage collection one
<mvo> kyrofa: https://github.com/snapcore/snapd/pull/3372 has some code but I couldn't make it reliable (I get the irony)
<mup> PR snapd#3372: tests: add basic lxd test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3372>
<kyrofa> mvo yeah, bad sign eh? :P
<zyga-suse> lxd
<mup> PR snapd#3794 closed: asserts,overlord/devicestate: revert allowing 'generic'-signed serials <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3794>
<zyga-suse> well
<zyga-suse> I really want to break now
<zyga-suse> jdstrand: I pushed more patches there but I failed to use dirs (cycles)
<Chipaca> zyga-suse: snapd#3692 is blocked on you
<mup> PR snapd#3692: tests: install most important snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3692>
<zyga-suse> Chipaca: approved
<mup> PR snapd#3785 closed: asserts,overlord/devicestate: accept generic serials only if the model has generic-serials: true <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3785>
<Chipaca> zyga-suse: snapd#3635 has some changes requested by cachio, a week ago
<mup> PR snapd#3635: tests: add out-of-the-box test suite <Created by zyga> <https://github.com/snapcore/snapd/pull/3635>
<zyga-suse> I should close that PR
<zyga-suse> it doesn't work well with rest of spread suites
<niemeyer> Alright
<niemeyer> I've made a change in Spread, and from now on it should be cleaning systems even in those bad situations
<niemeyer> It cannot prevent the space errors since this can be caused simply by interrupting forcefully previous processes in a bad moment, but it will clean up those machines and the error will be gone
<niemeyer> I can already see the effect.. just from the last few PRs run, systems are all clean already
<niemeyer> So hopefully this is the last thing that required manual care
<superjonotron> is there a way to mount a usb drive as writable on ubuntu core?  read only file system changes mount permissions to root and read only so i can't copy anything off of the system onto a usb device
<pedronis> cachio: we are still getting    fakestore service not started properly
<pedronis> + exit 1  sometimes
<pedronis> cachio: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170824_094354_789aa@/log.gz
<pedronis> we probably need to log some more there
<cachio> pedronis, yes
<cachio> pedronis, we should need to see the state of the port at least
<pedronis> and the systemd log of the unit
<pedronis> we make a unit IÂ think for it, I had forgotten about it
<cachio> pedronis, yet, i'll create a branch to add debug information
<mup> PR snapd#3787 closed: cmd/snap-repair: more test coverage of filtering <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3787>
<pedronis> mvo: I think I asked before, should we reenable the fedora tests? or things are still to unstable to add more potential instability?
<pedronis> s/to unstable/too unstable/
<cachio> pedronis, the problem is tht I'll need to add debug info to all the tests using the fake store
<cachio> pedronis, is it ok?
<pedronis> cachio: ?
<pedronis> just in setup_fake_store
<pedronis> or however is called
<cachio> ok,
<pedronis> before it does exit 1
<jdstrand> cachio: hey, when you get a chance, can you re-review https://github.com/snapcore/snapd/pull/3759
<mup> PR snapd#3759: add spread test for wayland <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3759>
<cachio> jdstrand, sure
<jdstrand> cachio: thanks! :)
<mup> PR snapd#3802 opened: tests: adding debug info fakestore when it does not start properly <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3802>
<pedronis> cachio: seems there's an addition of tests/main/install-snaps/task.yaml  that doesn't belong there
<pedronis> I thought you had a different branch with that in it
<cachio> jdstrand, minor comment inline
<cachio> pedronis, repearing it
<mup> PR snapd#3802 closed: tests: adding debug info fakestore when it does not start properly <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3802>
<mup> PR snapd#3803 opened: tests: adding extra info for fakestore when fails to start <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3803>
<cachio> pedronis, yes I created a branch based on another one and not from master
<cachio> my fault
<cachio> pedronis, PR 3803 now
<willdeberry> if someone has a moment, what am i missing here? https://forum.snapcraft.io/t/accessdenied-when-running-my-packaged-bluetooth-app/1724/15
<superjonotron> mount usb as writable on snappy, anybody know how to accomplish?
<jdstrand> cachio: thanks, fixed
<Chipaca> willdeberry: maybe https://github.com/chipaca/bin/blob/master/run-snapd-srv helps
<Chipaca> willdeberry: but at a glance i think SNAP_REEXEC=0 is the one you're missing
<Chipaca> good luck
<superjonotron> is it possible to run a snap command from within a snap command for a different snap?
<kyrofa> superjonotron, no, at least not currently
<superjonotron> back to the drawing board it is then
<Pharaoh_Atem> aww
<Pharaoh_Atem> I'm sad
<Pharaoh_Atem> davidcalle's new design for the front page doesn't have Fedora in the center anymore :(
<Pharaoh_Atem> it has.. Debian (meh)
<Pharaoh_Atem> davidcalle: I'm hurt... after all that time spent actually keeping stuff up to date :P
<niemeyer> Hadn't seen the new design.. looks nice
<davidcalle> niemeyer: just landed
<niemeyer> davidcalle: Nice!
<niemeyer> Let me change the forum icon so it looks the same size
<davidcalle> Pharaoh_Atem, if it can be of any consolation, there is someone, somewhere, browsing the site on a tablet in portrait mode and seeing Fedora in the center https://usercontent.irccloud-cdn.com/file/0C2RMUS3/Screenshot%20from%202017-08-24%2020-46-51.png
<niemeyer> davidcalle++
 * zyga-suse hug, Pharaoh_Atem
<ogra_> davidcalle, hmm, in my browser the distro icons on the site look rather awful ...
<davidcalle> ogra_: can you grab a screenshot, what's your browser ?
<ogra_> davidcalle, http://people.canonical.com/~ogra/snapcraft-io-logos.png
<ogra_> kind of off-center and a tad to large for the boxes
<davidcalle> Oh wow, that's rather funky, refresh maybe ? Could be some CSS caching gone wrong
<ogra_> dang ... doesnt change if i refresh the screenshot madly in the browser :P
<ogra_> davidcalle, yeah, that fixed it ...
<davidcalle> Hah, interesting, you are the second person to report something like that, ty
<ogra_> properly centered and scaled after a refresh
<mup> PR snapcraft#1500 closed: grammar: move into project_loader <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1500>
<sergiusens> davidcalle: is the tour gone from all documentation instances?
<sergiusens> if so, I'd be happy to remove it from snapcraft itself as it is somewhat a maintenance burden
<mup> PR snapd#3692 closed: tests: install most important snaps <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3692>
<zyga-suse> mwhudson: hey? around?
<zyga-suse> mwhudson: I was wondering if I could do a point release of snapd for debian one day, just prepare it and get you to ack it
<zyga-suse> mwhudson: I'd like to deprecate snap-confine (the package)
<zyga-suse> mwhudson: I really think we should get rid of it from sid
<zyga-suse> mwhudson: and send it the way of ubuntu-app-launcher
<mup> PR snapd#3804 opened: cmd/snap-seccomp: support parsing 'u:' and 'g:' for username and groups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3804>
<mup> PR snapd#3803 closed: tests: adding extra info for fakestore when fails to start <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3803>
<mup> PR snapd#3801 closed: tests: add test to ensure amd64 can run i386 syscall binaries <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3801>
<mup> PR snapd#3805 opened: interfaces/default,account-control: don't hardcode uid and gid. Use username and group instead <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3805>
<zyga-suse> jdstrand: interesting
<zyga-suse> jdstrand: why the unsafe/C handling vs golang's user module?
<jdstrand> zyga-suse: there is a comment in there
 * zyga-suse looks closer
<jdstrand> zyga-suse: LookupGroup is not implemented
<jdstrand> zyga-suse: so I stole it from upstream master
<zyga-suse> ah, drat
<zyga-suse> makes sense
<jdstrand> I very much wanted to use the user module :)
<janisozaur> zyga-suse: I'm here now. Do you still need something tested on Arch?
<zyga-suse> hey
<zyga-suse> janisozaur: you can try this
<zyga-suse> https://github.com/snapcore/snapd/releases/download/2.27.4/snapd-2.27.4-1-x86_64.pkg.tar.xz
<zyga-suse> this is the latest release
<janisozaur> try how?
<zyga-suse> janisozaur: we are also looking to resolve a problem with the package maintainer
<zyga-suse> janisozaur: install it :) this is the arch package
<zyga-suse> if you prefer to rebuild: https://github.com/snapcore/snapd/releases/download/2.27.4/snapd-2.27.4-1-arch-srcpkg.tar.gz
<janisozaur> yes, but what next?
<zyga-suse> janisozaur: just install it and see if things work for you
<zyga-suse> it contains several fixes since 2.27
<zyga-suse> there are two forum threads
<zyga-suse> https://forum.snapcraft.io/t/issue-with-discord-snap-in-arch/1811
<janisozaur> i imagine opengl is not one of them?
<zyga-suse> and https://forum.snapcraft.io/t/updates-to-snapd-package-on-arch/1467
<mup> PR snapd#3798 closed: release: 2.27.4 <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3798>
<zyga-suse> janisozaur: no change in that area yet :/
 * zyga-suse EODs
<janisozaur> scummvm appears to work with that package
<mwhudson> zyga-suse: o/
<zyga-suse> o/
 * zyga-suse is really almost sleeping
<mwhudson> heh
<mwhudson> zyga-suse: well that makes sense
<mwhudson> i guess ~everyone who has snap-confine installed has snapd too
<mwhudson> so if you change snapd to replaces: snap-confine people upgrading to buster will get snap-confine removed which is what we want?
<mwhudson> zyga-suse: just push a branch to alioth when you want me to look at it?
<zyga-suse> I think this is also what we did in ubuntu
<zyga-suse> ok, I need to brush up my debian skills,
<zyga-suse> I'll experiment and push
<mwhudson> either push to debian or a new branch depending on confidence level :)
<Pharaoh_Atem> zyga-suse: woohoo!
<Pharaoh_Atem> DNF is now in Factory!
<Pharaoh_Atem> or rather, it will be in the next few minutes
<Pharaoh_Atem> it passed legal-auto a few minutes ago
<kyrofa> zyga-suse, if I need to log a bug against snap-confine, do I log against snapd these days?
<kyrofa> jdstrand, perhaps you're a better person for that question this time of day
<Pharaoh_Atem> kyrofa: they go against snapd now
<kyrofa> Thanks Pharaoh_Atem :)
<kyrofa> Does that mean the bugs at https://bugs.launchpad.net/snap-confine should be reassigned?
<stgraber> kyrofa: that was quick :)
<kyrofa> stgraber, dude, you're a life-saver
<kyrofa> stgraber, I've been hitting that for weeks now
<kyrofa> stgraber, I have three containers in production, each of which requires me to SSH into it and convince them to update whenever new snaps come out
<kyrofa> I had no clue what was happening
<mup> Issue snapcraft#1506 opened: Inconsistent formatting when opening vs. closing channels <Created by Roadmaster> <https://github.com/snapcore/snapcraft/issue/1506>
#snappy 2017-08-25
<willdeberry> any around around by chance?
<willdeberry> anyone*
<mup> PR snapd#3806 opened: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3806>
<mup> PR snapd#3693 closed: snapstate: improve the error message when classic confinement is not supported <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3693>
<mup> PR snapd#3806 closed: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3806>
<pedronis> ++ dnf -q -y --refresh install 'pkgconfig(systemd)'
<pedronis> Error: Failed to synchronize cache for repo 'updates'
<zyga-suse> kyrofa: re
<zyga-suse> kyrofa: not sure about bug tracking, I think keeping it all in snapd is easier though
<zyga-suse> good morning everyone :-)
<mvo> zyga-suse_: hey, I think I addressed your points in 3260, let me know. I will ponder a bit more over the cmd_userd_test.go in the meantime
<zyga-suse_> hey
<zyga-suse_> thank you, let me look
<zyga-suse_> I'm working on a blanket in the grass
<zyga-suse_> I wonder if people will wonder what I do here ^_^
<zyga-suse_> mvo: poor network connection, are you reading this?
<mvo> zyga-suse_: yes
<zyga-suse_> odd, I can chat on IRC but I cannot load any website
<zyga-suse_> loaded
<zyga-suse_> mvo: replied on the Ping comment
<zyga-suse_> mvo: that's the only part I really cared about
<zyga-suse_> let me read the diff
<zyga-suse_> mvo: reviewed
<zyga-suse_> mvo: I'm sorry about being strict about that ping method there, let me know if that works in the end
<mvo> zyga-suse_: we are not implementing Ping() currently
<mvo> zyga-suse_: we are not implementing the Dbus.Peer interface at all
<zyga-suse_> mvo: go dbus doesn't do it for free?
<zyga-suse_> it's typically implemented by libraries
<mvo> zyga-suse_: unfortunately not
<zyga-suse_> aww, bummer
<zyga-suse_> that's not good
<mvo> zyga-suse_: at least not as far as I can tell
<mvo> zyga-suse_: d-feet is what i use
<zyga-suse_> does it show up in introspection?
<zyga-suse_> aha
<mvo> zyga-suse_: yes, introspection shows up
<zyga-suse_> I mean, does Peer show up?
<mvo> zyga-suse_: no, peer does not show up at all, it does show up for the old safe launcher though (because dbus-gio)
<zyga-suse_> right
<Chipaca> good morning all! happy "all versions of go shipped in ubuntu are obsolete" day!
<Chipaca> (1.9 is out)
<zyga-suse_> oh, nice
<zyga-suse_> anything shiny?
<zyga-suse_> are generics in yet?
<Chipaca> zyga-suse_: type aliases are a thing
<Chipaca> zyga-suse_: and monotonic time
<zyga-suse_> whee
<zyga-suse_> so 2001 of us
<mvo> zyga-suse_: I look into it, maybe we are just holding^Wusing it wrong
<zyga-suse_> mvo: maybe we could just implement Peer
<zyga-suse_> it's no-op Ping
<zyga-suse_> and get machine id
<Chipaca> zyga-suse_: the nicest change that would impact my work is that ./... no longer looks in vendor
<zyga-suse_> yes, I saw that one
<zyga-suse_> that's a nice change
<Chipaca> so go test ./... would finally dtrt
<mvo> zyga-suse_: yeah, otoh, if we can call OpenURL and get a reply like "cannot use ping-ping-ping:" we know the interface is up as well. but yeah, ping is nicer, I have a look
<zyga-suse_> Chipaca: I'm still holding out for generics
<zyga-suse_> mvo: agreed
<zyga-suse_> mvo: if you want +1, just move to libexecdir
<zyga-suse_> mvo: I may look at Ping over weekend
<mvo> zyga-suse_: we are actually using the normal "snap" command for the userd subcommand, so it will be the regular bindir (unless I miss something)
<zyga-suse_> mvo: ahh, sorry
<zyga-suse_> I must have misread the diff
<mvo> zyga-suse_: no worries
<zyga-suse_> I assumed it would be a new binary
<zyga-suse_> ok, I have two tests to fix
<zyga-suse_> and a lot of goodies will be ready
<zyga-suse_> but first
<zyga-suse_> coffee!!!
<mvo> zyga-suse_: heh, fun! if I export the ping interface things work
<mvo> zyga-suse_: oh well, I will update things
<Chipaca> zyga-suse_: did you see the guy that had generics implemented via unicode and generators?
<pedronis> mvo: there was no joy with the fedora tests btw, still failed in prepare in strange ways, are we tuning ip6 on fedora as well?
<zyga-suse_> mvo: things work?
<zyga-suse_> Chipaca: I think I don't actually want to know anymore :D
<zyga-suse_> pedronis: probably not, it's behind ubuntu spread test flag
<pedronis> anyway something is off and makes those even more unstable than usual
<Chipaca> zyga-suse_: bottom line: it looked like âtype ImmutableTreeListá¸ElementTá³ struct {â
<pedronis> or the fedora infra itself is flakier, no clue
<mvo> pedronis: I have not looked at the details for fedora unfortunately
<mvo> zyga-suse_: yeah, ping works once the interface is exported via xml, no code needed, I will update in a bit (working on tests right now)
<zyga-suse_> woot!
<zyga-suse_> nice :)
<zyga-suse_> ah
<zyga-suse_> right
<zyga-suse_> because introspection is how dfeet knows about it
<zyga-suse_> though odd that this is not done by gdbus itself
<mup> PR snapd#2837 closed: interfaces/apparmor: allow reading from ecryptfs <Blocked> <Decaying> <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2837>
<zyga-suse_> thank you :'-(
<zyga-suse_> though we _may_ have a way to solve that with what I'm working on
<mup> PR snapd#3346 closed: [WIP] allow access to nm-dispatcher scripts <Decaying> <Created by felicianotech> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3346>
<Chipaca> hmm, i've got to test stuff that involves rebooting. I'll be pestering you with in/out messages soon :-)
<zyga-suse_> Chipaca: VMs/
<Chipaca> zyga-suse_: i'm too close to my memory limit :-(
<Chipaca> (this is a test that needs a full desktop)
<Chipaca> brb
<zyga-suse_> aww
 * zyga-suse_ has apparmor on opensuse :)
<zyga-suse_> and we can now probably also enable reexec
<zyga-suse_> there's still a few things missing but I think it's very very closenow
<zyga-suse_> mvo: is the PR ban still in effect?
<Chipaca> morphis_: zyga-suse_: so it looks like moving /etc/X11/Xsession.d/65snappy to e.g. /etc/profile.d/snappy.sh will DTRT in both X and Wayland (might need some tweaks, but basically it'll work)
<Chipaca> morphis_: zyga-suse_: I know RH/fedora are slightly different wrt profile.d, but afaik it boils down to it getting loaded more, not less; can you confirm?
<zyga-suse_> Chipaca: if you test it, +1
<zyga-suse_> Chipaca: I think we want to dedupe those files
<Chipaca> this is me looking at snapd#3398
<mup> PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>
<zyga-suse_> Chipaca: there's one in every distro packaging
<zyga-suse_> Chipaca: and then we want to call it sanely, say snapd.sh
<zyga-suse_> Chipaca: and keep it in data/
<Chipaca> zyga-suse_: i tested it on ubuntu, but as i said i don't have the space to test it on other things
<zyga-suse_> Chipaca: I see
<Chipaca> bah. i might be able to get this fedora running
<Chipaca> should work with 1G, right?
<zyga-suse_> Chipaca: I can test on all of them but I'd prefer to do that in the afternoon with less sharp mind
<Chipaca> yeah no probs
<zyga-suse_> Chipaca: nah
<zyga-suse_> try 2G
<Chipaca> sigh, ok
<zyga-suse_> how much ram do you have?
<Chipaca> lots of swapping ahead for me :-)
<zyga-suse_> I have a _physical_ fedora box with 2GB and it's a pain
<zyga-suse_> I added 1GB stick to make it work
<Chipaca> zyga-suse_: free right now? 1G
<zyga-suse_> OMG
<zyga-suse_> and in general?
<Chipaca> zyga-suse_: 4G total
<zyga-suse_> darn
<zyga-suse_> no way to expand?
<Chipaca> i had 8 but one of the sticks died
<Chipaca> and the whole box is starting to die
<Chipaca> so i'm just letting it
<zyga-suse_> aha
<zyga-suse_> thinkpad?
<Chipaca> while saving up for its replacement
<zyga-suse_> man, buy t430 for the price of a good meal
<Chipaca> zyga-suse_: latitude e series
<zyga-suse_> they are indestructible
<zyga-suse_> and cost peanuts
<Chipaca> it's ~8 years old
<Chipaca> if i were to buy the same thing, it'd cost peanuts too
<zyga-suse_> what are you saving for?
<Chipaca> but these old cpus suck 45W when angry, i'll gladly pay to worry about that less
<zyga-suse_> so what if you can get a battery with 11hrs of life?
<Chipaca> zyga-suse_: probably a latitude e series :-)
<zyga-suse_> and still buy three for the price of one new box
<Chipaca> zyga-suse_: 15
<Chipaca> zyga-suse_: this box had 15 hours battery life when it and the batteries were new
 * zyga-suse_ chooses not to buy new laptops again
<Chipaca> zyga-suse_: ah, it'd not be new, it'd be refurb
<zyga-suse_> ah
<zyga-suse_> +100 on that
<zyga-suse_> it's worse than with used cars
<Chipaca> i can't in good conscience justify the price nor environmental cost of new
<zyga-suse_> you open the door and 30% is gone
<zyga-suse_> yep
<zyga-suse_> especially when new CPUs suck so badly lately
<zyga-suse_> with less and less reliablity and features
<zyga-suse_> I wonder when amd will show their mobile ryzen/threadripper units
 * zyga-suse_ sees ants crawling over his keys
<zyga-suse_> not ogod
<ogra_> they probably just want to help
 * zyga-suse_ plays bug squashing
<zyga-suse_> Chipaca: buy this and run !ubuntu distro on it http://www.ebay.es/itm/Lenovo-ThinkPad-T530-i5-3210M-2x2-5GHz-8GB-128GB-SSD-UMTS-NVS5400-Webcam-WIN10-/253112700548?hash=item3aeeb14e84:g:KsAAAOSw01dZnrBX
<zyga-suse_> Chipaca: and work on it 2/5 days a week
<zyga-suse_> snapd must feel great everywhere
<ogra_> well, if you want low-end, get a beaglebone :P
<zyga-suse_> ogra_: ahem
<zyga-suse_> ogra_: that's way more than sufficient for work
<zyga-suse_> ogra_: and it has twice the RAM that Chipaca has now
<zyga-suse_> it would be good if we had someone running centos
<zyga-suse_> or if feeling less bold, just run opensuse or fedora where there's very good support already
<zyga-suse_> ogra_: what are you using daily?
<zyga-suse_> (h/w wise)
<ogra_> well, depends where i sit
<ogra_> in my office i have a "Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz" with 32G, 3TB raid, 500G SSD, triple head nvidia 970
<ogra_> (+3x 22" LG HD monitors )
<ogra_> in my living room my first gen XPS13
<ogra_> (some early i7, i forgot which and 8GB)
<Chipaca> zyga-suse_: http://www.morgancomputers.co.uk/c/512/IBM-Lenovo/
<zyga-suse_> nice desktop setup!
<Chipaca> OTOH i coould set up my bbb
<Chipaca> i'd need bluetooth and wifi to be working on it though
<zyga-suse_> punch-card speed IO
<ogra_> hmm, then a pi3 rather ...
<Chipaca> i thought io on the pi3 was slower than the bbb
<ogra_> (though thats pretty powerful for an arm board)
<zyga-suse_> no, nothing is slower than bbb
<ogra_> well, pi3 is quad core 1.2GHz ...
<zyga-suse_> Chipaca: pi3 when using HDD is very much usable
<ogra_> bbb is single 800MHz
<zyga-suse_> Chipaca: just get that fancy Pi drive and boot away
<zyga-suse_> no SD cards needed
<ogra_> as long as you dont use any other USB devices on it, yeah
<zyga-suse_> (or any HDD with a usb cable)
<zyga-suse_> it's good enough for coding IMO
<ogra_> wired anetwork and HDD at the same time can already get nasty
<ogra_> the USB hub gets saturated easily
<zyga-suse_> it's limited but for the price it's really good
<ogra_> well ... for the price, yeah
<zyga-suse_> mvo: trivia PR pre-reviewed by jdstrand https://github.com/snapcore/snapd/pull/3807
<mup> PR snapd#3807: cmd/snap-confine,packaging: import snapd-generated policy <Created by zyga> <https://github.com/snapcore/snapd/pull/3807>
<zyga-suse_> I stated doing internal reviews with jamie so that we can start with a +1 and land things faster
<mup> PR snapd#3807 opened: cmd/snap-confine,packaging: import snapd-generated policy <Created by zyga> <https://github.com/snapcore/snapd/pull/3807>
<ogra_> hmm ...
<mup> PR snapd#3791 closed: cmd/snap-confine: allow using additional libraries required by openSUSE <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3791>
<mup> PR snapd#3792 closed: cmd/snap-confine: allow running snap-exec without confinement <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3792>
<ogra_> why is my daily edge image installing core 2466 on first boot ?
<zyga-suse_> 2466 feels 1000 builds too old
<ogra_> yes
<ogra_> especially for an edge build
<ogra_> 2739 is the current core in armhf edge
<ogra_> this smells like firstboot didnt set up the system properly
<ogra_> :/
<zyga-suse_> what's in /var/lib/snapd/snaps ?
<ogra_> ogra@pi2:~$ snap list
<ogra_> No snaps are installed yet. Try "snap install hello-world".
<ogra_> ogra@pi2:~$
<ogra_> grmpf
<ogra_> ogra@pi2:~$ ls /var/lib/snapd/snaps/
<ogra_> core_2466.snap  core_2739.snap  pi2-kernel_39.snap
<ogra_> ogra@pi2:~$
<ogra_> no gadget
 * ogra_ starts over with a fresh flash to capture the log of the first boto
<ogra_> *boot
<zyga-suse_> Chipaca: did you see the new "dep" tool?
<zyga-suse_> ogra_: super odd
<Chipaca> zyga-suse_: in go?
<zyga-suse_> ogra_: how did youget 2466? from ubuntu-image?
<zyga-suse_> Chipaca: yes
<ogra_> zyga-suse_, i didnt ..
<ogra_> zyga-suse_, core_2739.snap
<zyga-suse_> sure but 2466 is present there as well
<ogra_> u-image did the right thing ... but the initial setup failed ... i usually install avahi as first thing after setting the hostname when testing ... that pulled core from stable
<zyga-suse_> aha
<ogra_> and this time it takes actually longer to get to "please press enter" ... last round this casme up immediately which indicates the key generation didnt take place
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name        Version                   Rev   Developer  Notes
<ogra_> core        16-2.27.4+git331.b672daf  2739  canonical  core
<ogra_> pi2         16.04-0.18                39    canonical  gadget
<ogra_> pi2-kernel  4.4.0.1070.70             39    canonical  kernel
<ogra_> ogra@localhost:~$
<ogra_> hrm ... so there was a race in the first run ... which is gone now :/
<ogra_> i'm always surprised how different the memory usage between the different arm boards is
<ogra_> on the nanopi-air htop shows 48.7MB used ... the pi2 with the same set of snaps installed and running uses 70.3MB
<mup> PR snapd#3808 opened: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <https://github.com/snapcore/snapd/pull/3808>
<zyga-suse_> mvo: another small branch pre-approved with jdstrand
<ogra_> (both armhf, both using the same core )
<mvo> zyga-suse_: ok, looking
<zyga-suse_> mvo: I have a tiny branch on top that will let debian and suse to enable apparmor
<zyga-suse_> mvo: and that will let us enable reexec on suse :)
<zyga-suse_> mvo: the last holdout of reexec will be distro layout (fixed with layouts) and /snap location (not covered by layouts yet)
<ogra_> fgimenez, ppisati, any idea why all our stable kernels are like 6 revisions behind ?
 * zyga-suse_ -> small break
<zyga-suse_> everyone: please request my reviews on things you want me to look at
<fgimenez> ogra_: nope, i don't know
<pedronis> mvo: so the problem test seems a quirk of task without undo handlers, their change is ready "sooner", don't think it should block your branch, but IÂ would like to explore not needed Overlord.Loop there
<mvo> pedronis: aha, I see! I can add an undo handler for now as a workaround until we have time to explore further. thanks a lot for looking into this
<Chipaca> mvo: if what's now /etc/profile.d/apps-bin-path.sh suddenly becomes /etc/profile.d/snapd.sh, does apt/dpkg/something freak out?
<mup> PR snapd#3809 opened: tests: copy files with less verbosity <Created by zyga> <https://github.com/snapcore/snapd/pull/3809>
<zyga-suse_> mvo: trivial for my modem woes ^
<zyga-suse_> Chipaca: yes
<zyga-suse_> you need to rm conffile
<zyga-suse_> Chipaca: or in other words, you want to ship your computer to the arctic, move north and herd sheep
<Chipaca> zyga-suse_: the name just strikes me as odd, especially now that it'll have XDG stuff in it :-)
<Chipaca> but they are technically both paths
<Chipaca> so Â¯\_(ã)_/Â¯
<zyga-suse_> Chipaca: yeah, the name is bad
<zyga-suse_> Chipaca: I'd like to have just "snapd.sh", period
<Chipaca> that's what i was proposing above
<zyga-suse_> Chipaca: new systemd (we cannot assume it though) has nicer way to do this
<Chipaca> zyga-suse_: it does?
<zyga-suse_> one sec
<Chipaca> anyway, time for me to go run
 * Chipaca waits
<zyga-suse_> let me pull the discussion with systemd devs
<mup> PR snapd#3810 opened: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
<zyga-suse_> from my blog ...
<zyga-suse_> https://new.zygoon.pl/post/case-study-snapd-on-centos/
<zyga-suse_> Chipaca: have a look there
<zyga-suse_> there are links to a PR that has since landed in systemd: https://github.com/systemd/systemd/pull/5131
<mup> PR systemd/systemd#5131: Environment generators <pid1> <Created by keszybz> <Merged by poettering> <https://github.com/systemd/systemd/pull/5131>
<zyga-suse_> and while looking there, enjoy 102 open PRs for systemd
<zyga-suse_> (we are not doing bad)
<ogra_> well
<zyga-suse_> though 806 contributors is x10 more than we have
<ogra_> from our downstram POV thats not acgtually much different
<ogra_> (environment.d vs profile.d ... )
<ogra_> you still need to ship the snippet that assembles the variable
<ogra_> just in another place
<Son_Goku> environment.d happens earlier than profile.d
<ogra_> sure sure
<Son_Goku> though I hate putting things in either, really
<ogra_> just saying that iit doesnt matter much regarding the naming of the fil ;)
<ogra_> *fiile
<ogra_> sigh ...
<Son_Goku> that's okay, one day you'll get it :)
<ogra_> my laptop keyboard slowly gives up
<Son_Goku> zyga-suse_, we'll probably not have anywhere close to that number of contributors
<zyga-suse_> Son_Goku: as I said, x10 less
<zyga-suse_> Son_Goku: good to see you
<zyga-suse_> Son_Goku: did you see my reply on the forum there?
<Son_Goku> that would require rejiggering the project in a way that currently isn't possible :(
<Son_Goku> the forum makes me angry, so I haven't looked since I posted yesterday
 * zyga-suse_ hugs Son_Goku again
 * Son_Goku sighs
<mcphail> kyrofa: thanks for the 11.0.4 nextcloud update. Is 12.x on the roadmap? (I'm not complaing, btw. I don't even know what version 12 brings. Just curious!)
<zyga-suse_> ogra_: what does it take to add /var/lib/snapd/apparmor/snap-confine.d to the core snap?
<ogra_> two lines ?
<ogra_> (assuming you want it writable, else one line)
<zyga-suse_> yes, two lines
<zyga-suse_> er
<zyga-suse_> yes writable
<zyga-suse_> where?
<ogra_> heh
<zyga-suse_> note that it's under /var/lib/snapd/apparmor which was writable before
<zyga-suse_> does it need any work?
<zyga-suse_> or do I just need to fix CI prep to mkdir that too
<ogra_> zyga-suse_, https://github.com/snapcore/core/blob/master/live-build/hooks/20-extra-files.chroot for the mkdir -p ...
<zyga-suse_> why there's no /var/lib/snapd/apparmor there/
<ogra_> zyga-suse_, https://github.com/snapcore/core-build/blob/master/config/etc/system-image/writable-paths to make it writable
<zyga-suse_> -> /var/lib/snapd auto persistent transition none
<zyga-suse_> that's already present, so I think I'm good
<ogra_> well, you want a mkdir somewhere ... if snap-confine creates it on startup or package install that should be sufficient
<ogra_> else you need it in some of the build scripts like above
<zyga-suse_> ogra_: the snapd package has that directory
<ogra_> ok
<zyga-suse_> ogra_: it's made and packaged in the deb
<mup> PR snapd#3809 closed: tests: copy files with less verbosity <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3809>
<zyga-suse_> mvo: thank you
<zyga-suse_> mvo: please help me out with one thing
<zyga-suse_> mvo: when I want to add a new directory under /var/lib/snapd/ (specifically /var/lib/snapd/apparmor/snap-confine.d) should I do anything more than just update packaging?
<zyga-suse_> mvo: tests are failing and I assume it is because of this
<zyga-suse_> mvo: I have a patch that looks like :
<zyga-suse_> https://paste.gnome.org/pkhbjpoju
<zyga-suse_> mvo: but I'm unsure if that will really hide the problem until release
<ogra_> hmm
<mvo> zyga-suse_: lets get to the bottom of this, the dir in the package should be enough, let me try to reproduce via spread
<ogra_> you might have a problem if you need it on non-new systems ...
<ogra_> since /var/lib/snapd is "transition" not synced
<zyga-suse_> can you explain?
<ogra_> transition only copies the dirs on the first run ...
<ogra_> from core to writable
<zyga-suse_> "transition"?
<zyga-suse_> aha
<zyga-suse_> I see
<ogra_> so an upgraded ubuntu-image install wont simply add it
<zyga-suse_> well
<zyga-suse_> suggestions?
<ogra_> systemd job ... or switch to "synced" but i'm not 100% sure about the latter
<ogra_> (have to check the code)
<willdeberry> when making a change to an interface, is building snapd cmd sufficient to pick up the changes? `go build -o /tmp/snapd github.com/snapcore/snapd/cmd/snapd`
<zyga-suse_> ugh
<zyga-suse_> willdeberry: yes, you need to re-start it though
<zyga-suse_> willcooke: which backends are you changing
<zyga-suse_> willdeberry: some things are not refreshed on startup
<zyga-suse_> willcooke: (sorry, bad tab completion)
<ogra_> zyga-suse_, for refrence http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html
<zyga-suse_> ogra_: I just need an empty directory
<zyga-suse_> but it _must_ be there
<zyga-suse_> ogra_: and it may need to be there very early
<zyga-suse_> ogra_: before apparmor profiles are loaded
<zyga-suse_> and I think those are done before regular systemd units start
<ogra_> well, given apparmor itself relies on writable-paths, that should be a given
<ogra_> the issue is transition vs synced
<ogra_>      WARNING:  This is a one-off operation which requires that the
<ogra_>                  source  directory  on  the  writable  partition   not   exist
<ogra_>                  initially: if this condition is satisfied, the directory will
<ogra_>                  then be created and the data moved on  first  boot.  Although
<ogra_>                  the  mountpoint  will be writable, note that subsequent boots
<ogra_>                  will ignore any new files appearing or  disappearing  in  the
<ogra_>                  original  read-only  rootfs  location  unless  you  perform a
<ogra_>                  factory reset.
<ogra_> (thats "transition" )
<ogra_> note that subsequent boots
<ogra_>                  will ignore any new files appearing
<ogra_> that one specifically
 * zyga-suse_ feels like not wanting to fight this fight on friday
<willdeberry> zyga-suse_: still fighting on adding bluez interface to classic OS
<zyga-suse_> but this is something he needs :/
<zyga-suse_> willdeberry: which backends are you using in that interface?
<ogra_> we might need to switch /var/lib/snapd to be "synced" to make your dir appear ... i'm just not sure what happens with existing files in the target dir
<ogra_> alternatively a systemd unit that runs mkdir ...
<zyga-suse_> yeah, I don't like that really :/
<ogra_> which is surely the uglier option
<willdeberry> zyga-suse_: i am not sure i am following. I am just needing to expose bluez as an interface on classic so my snap can connect to bluez as a plug
<zyga-suse_> willdeberry: the bluez interface won't work as-is on classic
<zyga-suse_> willdeberry: can you pastebin your diff from master please
<willdeberry> https://github.com/willdeberry/snapd/commit/11001ff172e7ddc96f6109a0c8ff9b3e63595ad4
<ogra_> zyga-suse_, why wouldnt bluez work as-iis on classic ? the files, devices and services it needs to access should be the same
<zyga-suse_> ogra_: look at the diff
<zyga-suse_> willdeberry: the diff look ok actually
<zyga-suse_> willdeberry: can you please test both variants in each backend, ensuring that we don't get unexpected things?
<zyga-suse_> ogra_: the confinement is very specific
<ogra_> zyga-suse_, yeah, i meant more the interface itself ... not the conditions that make it available
<zyga-suse_> ogra_: down to the point where peer is confined with a specific label
<zyga-suse_> ogra_: and on classic that would be "unconfined"
<ogra_> ah
<zyga-suse_> ogra_: but the patch handles that so it looks correct
<ogra_> yeah
<willdeberry> zyga-suse_: right now, the bluez tests pass. the only tests i haven't fixed yet are the basedefinition tests which run when building the deb
<zyga-suse_> willdeberry: they are in ../policy
<zyga-suse_> just run them
<willdeberry> k
<zyga-suse_> (and fix)
<ogra_> zyga-suse_, btw, do we have any mechanism for interfaces to check that the backend they allow access to is actually working/existing ?
<zyga-suse_> ogra_: yes, implicitly
<ogra_> imho bluez should be hidden on classic server installs that dont have BT installed/enabled
<zyga-suse_> ogra_: interface methods specific to a backend are not used if the backend is not loaded
<ogra_> ok
<willdeberry> backend meaning the bluez service in regards to classic right?
<zyga-suse_> ogra_: we don't do that distinction yet, I think it falls under hotplug a little, we should do it but it's fine to just have it, even if unsupplied
<zyga-suse_> willdeberry: no, backend meaning one of the security backends in snapd
<willdeberry> gotcha
<ogra_> yeah, i meant the service backend actually
<willdeberry> trying to map terminiology in my brain :)
 * zyga-suse_ feels grumpy now
<zyga-suse> pstolowski: review on 3810
<pstolowski> zyga-suse, thanks
<zyga-suse> pstolowski: if you want we can discuss the design here
<zyga-suse> pstolowski: (standup may be hard with my data)
<pstolowski> zyga-suse, I'll answer to comments on the PR first
<zyga-suse> sure, thank you
<zyga-suse> jdstrand: reviewed https://github.com/snapcore/snapd/pull/3805
<mup> PR snapd#3805: interfaces/default,account-control: don't hardcode uid and gid. Use username and group instead <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3805>
<zyga-suse> er. make that 3804
<willdeberry> zyga-suse: just an fyi, this is what is currently failing and I will address before reach back out https://pastebin.com/8BdemMUD
<zyga-suse> jdstrand: reviewed both now, I think we have a major problem to solve before this can land
<zyga-suse> willdeberry: yeah, just adjust those tests
<pstolowski> zyga-suse, replied. take a look at one of the interfaces in #3120 to see how this is used (best to look at an interface that uses some attributes)
<pstolowski> zyga-suse, i'll be avail in ~10 minutes if you want to discuss in HO
<zyga-suse> pstolowski: not sure if my data plan will allow it :)
<zyga-suse> pstolowski: replied
<zyga-suse> I'll brew some fresh coffee and I'll return to my woes
 * genii 's ears perk up for a moment at the mention of coffee
<Chipaca> ogra_: do we support this guy? http://beagleboard.org/black-wireless
<zyga-suse> mvo: interesting https://paste.gnome.org/pu8sxtwdg
<mup> PR snapd#3761 closed: Disable reexec on debian <Created by mwhudson> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3761>
<ogra_> Chipaca, well, the bbb image should boot and run but no idea about the changed network bits
<zyga-suse> saw that when 2017-08-25 11:51:20 Error executing autopkgtest:ubuntu-17.10-amd64:tests/main/config-versions :  failed
<zyga-suse> mwhudson: ^ maybe interested in this
<zyga-suse> runtime: address space conflict: map(0xc420100000) = 0x7f377c677000
<zyga-suse> fatal error: runtime: address space conflict
<jdstrand> zyga-suse: thanks, I've commented in both 3804 and 3805
<zyga-suse> jdstrand: thank you
<zyga-suse> jdstrand: offtopic, the /var/lib/snapd/apparmor/snap-confine.d is harder than anticiapted
<zyga-suse> jdstrand: is there a way for apparmor-parser to ignore missing directories somehow?
<jdstrand> zyga-suse: not without code changes. I doubt they would be upstreamable
<ogra_> Chipaca, i see we have /boot/uboot/linux-generic-bbb*/dtbs/am335x-boneblack-wireless.dtb  .... so might need an adjusted own gadget
<ogra_> so yes, we can easily support it :)
<jdstrand> zyga-suse: why is it difficult? I saw something about core. we create directories in core all the time...
<Chipaca> ogra_: maybe i should get one and use it as my laptop at the sprint
<zyga-suse> jdstrand: replied
<zyga-suse> jdstrand: apparently not all the time
<zyga-suse> jdstrand: I need to think but merely adding the directory to snapd.deb is not enough
<zyga-suse> jdstrand: (replied https://github.com/snapcore/snapd/pull/3805#discussion_r135248529 in case you want to see)
<mup> PR snapd#3805: interfaces/default,account-control: don't hardcode uid and gid. Use username and group instead <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3805>
<jdstrand> zyga-suse: going back to 3805> in a strict or devmode snap on core, the shadow gid matches (fine). on classic, /etc is one of the directories we bind mount from the host into the mount namespace. *not* /etc from core. therefore, the /etc/shadow in the mount namespace is /etc/shadow from the host
<jdstrand> zyga-suse: are you saying something changed in this regard?
<zyga-suse> jdstrand: ah, you are right
<zyga-suse> jdstrand: but files from core snap will be owned by 42, not by 15
<zyga-suse> jdstrand: this is a separate issue
<jdstrand> zyga-suse: so?
<zyga-suse> jdstrand: but still true
<jdstrand> the snap never sees them
<zyga-suse> jdstrand: shadow is maybe not the best example, I bet there are users/groups that _can_ be seen that don't match host's /etc/
<jdstrand> the snap with account-control plugged will only modify the host. it can't get to the core snap
<jdstrand> zyga-suse: no
<jdstrand> zyga-suse: the have the same databases
<jdstrand> they*
<jdstrand> because we intentionally bind mount so it is that way
<zyga-suse> jdstrand: my point is that the core snap has hardcoded values for each file
<zyga-suse> jdstrand: right in the squashfs
<jdstrand> zyga-suse: again, so?
<jdstrand> we bind mount over them
<zyga-suse> jdstrand: and any disagreements with the host will be confusing
<jdstrand> it doesn't matter
<jdstrand> this is precisely why we bind mount
<zyga-suse> jdstrand: are all non-root files in the core hidden?
<jdstrand> so they are the same. no disagreements
<jdstrand> zyga-suse: of course not, but that is a different issue
<zyga-suse> ok
<jdstrand> zyga-suse: we aren't expsoing those files to the classic snap
<zyga-suse> I agree about your reasoning on snap-seccomp now
<jdstrand> certainly not for chown
<jdstrand> since those files are readonly anyway
<ikey> snaps are swiftly becoming a pain in my ass, just wanted to share that.
<ikey> https://dev.solus-project.com/T4390
 * zyga-suse looks
<jdstrand> zyga-suse: this functionality isn't about weird esoteric permissions in the core snap vs classic. this is about 2 users and groups that are defined by the LSB to exist everywhere (root and daemon (daemon in a followup PR)) and shadow, which in practice exists everywhere (but we could adjust as needed (if NonCompliantDistro ; use othershadow)
<zyga-suse> ikey: more classic snaps :/
<jdstrand> zyga-suse: after that it is all about snapd-managed users
<ikey> "Yay"
<zyga-suse> ikey: we need a way to pester snap makers and improve snapcraft
<jdstrand> I'll mention that in 3804
<ikey> ya because id been down this ABI path with Ubuntu before
<ikey> it's called Steam.
<ikey> and frankly it aint worth it
<jdstrand> actually, there is the calling user too
<zyga-suse> jdstrand: calling user?
<jdstrand> sudo foo, we may want to allow dropping to 1000
<jdstrand> I need to think about that one
<jdstrand> may not allow that. again, I'll think about it
<jdstrand> that might be a straight snap-confine (not snap-seccomp) change
 * zyga-suse really breaks now and goes to make that coffee
<jdstrand> oh, we don't need Lookup and LookupGroup for that anyway
 * genii hears something about coffee again, goes and gets one
<ogra_> ikey, "snap run --shell atom" ... then grep LD_LIBRARY_PATH from the env ... i bet it doesnt prefix it correctly with the in-snap lib paths
<zyga-suse> ogra_: that's not sufficient to test
<zyga-suse> ogra_: the wrapper may set that
<zyga-suse> ogra_: and --shell will not run it
<ogra_> zyga-suse, and thats fine
<ogra_> oh
<ogra_> i didnt know that
<zyga-suse> ogra_: it's still a bug in the snap
<ogra_> yes
<ogra_> well
<ogra_> https://forum.snapcraft.io/t/libraries-not-found-in-classic-snaps/1033
<ogra_> zyga-suse, i consider is a snapd/snap-confine bug TBH
<zyga-suse> ogra_: I don't
<zyga-suse> ogra_: I gave my reasoning why this cannot be set in snap-confine
<ogra_> the env should be properly prefixed without needing a wrapper
<ogra_> ikey, so close that bug and make them complain to the snap creator ;)
<ogra_> flexiondotorg, /snap/atom/current/bin/electron-launch is missing paths for $SNAP/lib and $SNAP/lib/$TRIPLET ...
<ogra_> (iirc atom was your snap)
<ogra_> ikey, ^^^
<ogra_> (it only defines $SNAP/usr/lib ... )
<jdstrand> zyga-suse: fyi, https://github.com/snapcore/snapd/pull/3804#discussion_r135254236
<mup> PR snapd#3804: cmd/snap-seccomp: support parsing 'u:' and 'g:' for username and groups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3804>
<Son_Goku> zyga-suse, I think at some point we need a way to deal with the lack of extrausers outside of Ubuntu
<zyga-suse> Son_Goku: aha, is that breaking in the field somehow?
<zyga-suse> I thought that was used in the core only
<jdstrand> mvo: regarding 'restore' in the wayland spread test, that is what I initially tried (see the comment in the test: "# If this is in 'restore', it hangs the test")
<Son_Goku> well, weird things are happening already because snaps like docker snap don't work right without bounding back and forth
<ogra_> flexiondotorg, https://github.com/snapcrafters/atom/pull/3 for you
<mup> PR snapcrafters/atom#3: add $SNAP/lib, $SNAP/lib/$TRIPLET to library path <Created by ogra1> <https://github.com/snapcrafters/atom/pull/3>
<zyga-suse> snapcraft should offer easy-to-use knobs for snaps using classic confinement *and* binary packages and don't expect to run host programs
<zyga-suse> and should set LD_LIBRARY_PATH
<zyga-suse> sergiusens: ^^
<jdstrand> mvo: I think this has to do with backgrounding the daemon with '&'. execute would never return and the test would have to timeout before getting to restore
<sergiusens> zyga-suse: no, the correct path is to compile
<zyga-suse> I know
<zyga-suse> but people shoot themselves in the foot repeatedly
<zyga-suse> so let's add some aribags
<sergiusens> if we set LD_LIBARARY_PATH we taint the environment by default
<zyga-suse> *airbags
<zyga-suse> I wouldn't set it by default
<zyga-suse> but I would add a knob for classic confinement snaps
<zyga-suse> and warn people if they didn't make any decision about it
<sergiusens> if you do classic, you need to compile your runtime, period
<jdstrand> mvo: now, I can try to use something like start-stop-daemon, but I didn't go that route because it isn't going to exist outside of Debian derived distros
<jdstrand> mvo: granted, the test itself is only running on Ubuntu, but figured for futureproofing, did it this way
<zyga-suse> sergiusens: should store reject snaps that dont?
<jdstrand> mvo: but, what I could do is also have it in restore
<sergiusens> zyga-suse: we shouldn't block people that know what they are doing
<zyga-suse> sergiusens: yes but apparently people don't know
<jdstrand> mvo: ok, let me do that
<jdstrand> mvo: thanks for the chat :)
<sergiusens> setting LD_LIBRARY_PATH is valid for some snaps that would never shell out
<sergiusens> look at all the trouble I went through to get snapcraft to be classic. It is a lot more work, there are beneifts, but all these apps need to use a compiled electron and not the default build
<zyga-suse> jdstrand: can you please look at and +1 https://github.com/snapcore/snapd/pull/3808 (you looked at the patches already)
<mup> PR snapd#3808: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <https://github.com/snapcore/snapd/pull/3808>
<ogra_> sergiusens, how does compiled vs non-compiled have any effect here ?
<ogra_> sergiusens, $SNAP/lib is simply not in LD_LIBRARY_PATH so shipped libs are not found ... that has nothing to do with the electron binary at all
<mvo> jdstrand: hey, sorry, was in the standup
<mvo> jdstrand: but it seems like you solved everything :)
<sergiusens> ogra_: RPATH would be set for the binary
<sergiusens> the whole concept of classic confined snaps is that you fix the linker and what libraries can load (and disabling LD_LIBRARY_PATH)
<ogra_> is it ? ... it doesnt compllain about missing $SNAP/usr/lib
<ogra_> (about files from there)
<sergiusens> huh?
<ogra_> only about the lib path that is missig from the launch wrapper
 * sergiusens needs more words to make sense of that sentence
<ogra_> sergiusens, https://github.com/snapcrafters/atom/pull/3
<mup> PR snapcrafters/atom#3: add $SNAP/lib, $SNAP/lib/$TRIPLET to library path <Created by ogra1> <https://github.com/snapcrafters/atom/pull/3>
<sergiusens> when we introduced classic we said it was supposed to be used by people who compile from source; we never made a promise about anything else
<jdstrand> zyga-suse: sure
<ogra_> sergiusens, starting the snap on a non-16.04 system simply fails because it doesnt find libs from $SNAP/lib
<sergiusens> because atom (through electron) is not compiled in snapcraft
<ogra_> sergiusens, nothing complains about any libs from $SNAP/usr/lib (which is inn LD_LIBRARY_PATH already
<sergiusens> yes there are workarounds
<ogra_> right
<sergiusens> like LD_LIBRARY_PATH
<ogra_> so we should have a "classic-wrapper" part ...
<sergiusens> but, if you shell out, you get those libs picked first intead of those on the host
<ogra_> that simply ships such a wrapper
<ogra_> yes, thats what you want
<sergiusens> no, no wrappers for classic was what we discussed in the forum months ago
<ogra_> you never want to ever use any libs from the host
<sergiusens> yes you do!
<sergiusens> e.g.; asciinema
<ogra_> then hell breaks loose
<ogra_> you want to be able to **fall back* to them
<sergiusens> e.g.; integrated shell in vscode (you want to use the python and pip on the system)
<ogra_> but if you ship any lib in your snap you want that one to be used and preferred
<sergiusens> test runner tools
<sergiusens> anything useful, you want from the host
<ogra_> yes, you want to carefully pick what you ship inside
<sergiusens> for the application, yes, but not for what you invoke outside of the system
<ogra_> but still
<sergiusens> the only sane thing here is rpath
<sergiusens> everything else is broken
<ogra_> *if* you ship it it needs to be the preferred lib
<sergiusens> and you are on your own should you choose to go down that path
<ogra_> else classic will never function anywhere but 16.04
<sergiusens> ogra_: compile and it works
 * sergiusens is not discussing this anymore, seems to come back every two months
<ogra_> well, wrap and it works too :P
<sergiusens> half works
<sergiusens> just wrappers and it doesn't work on trusty, try the asciinema in the store there and try to run something python and subsequently upload the video ;-)
 * sergiusens reboots
<ogra_> Chipaca, " ps eww of the toplevel process" ... is that Xorg ? gdm/lightdm ? systemd --user ? or bash ?
 * ogra_ bets on the latter
 * zyga-suse breaks for an hour
<mvo> does anyone know if there is a way to skip an entire suite with gopkg.in/check.v1 ?
<mvo> I mean, in SetupSuite(c *C) skip everything if e.g. a required binary is not available
<pedronis> mvo: I think c.Skip in the SetUpSuite does that
<pedronis> we even use it already IÂ think
<pedronis> mvo: see for example  asserts/gpgkeypairmgr_test.g
<pedronis> o
<mvo> pedronis: aha, it will still run teardownsuite, this is what confused me
<mvo> pedronis: thanks!
<Chipaca> ogra_: not bash
<Chipaca> ogra_: ps fx, look for the topmost thing in the session (here it's upstart)
<Chipaca> ogra_: for jwm it was jwm itself
<jdstrand> mvo: ok, comments addressed in https://github.com/snapcore/snapd/pull/3759
<mup> PR snapd#3759: add spread test for wayland <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3759>
<Chipaca> ogra_: any ideas on how to find a case where it doesn't work?
<ogra_> Chipaca, to exec ps you need a shell ... and even /dash reads profile
<Chipaca> ogra_: yes, but i'm looking at the environment of a different process
<ogra_> Chipaca, dunno if there is some gtk test app that prints the env ... i guess that'd be a question for the desktop team ...
<mvo> jdstrand: thanks! approved, but one more nitpick/question related to the source of test-snapd-wayland
<ogra_> flexiondotorg, seems the build badge markdown in README.md for atom points to https://build.snapcraft.io/user/snapcrafters/discord ... i guess you want to fix that to point to https://build.snapcraft.io/user/snapcrafters/atom
<flexiondotorg> ogra_ ty Mr. popey is on it.
<ogra_> heh, ok
<ogra_> bah, it is odd that a change to README.md causes a rebuild of the snap ...
<ogra_> we should have something like .snapbuild-ignore so that build.snapcraft.io doesnt pick up such changes
<Chipaca> ogra_: well... if I were to build stuff using snapcraft in a repo, I'd use chunks of my README in the snap's description
<ogra_> Chipaca, yeah, if you do that you want README changes to be used ...
<ogra_> https://forum.snapcraft.io/t/build-snapcraft-io-should-not-always-rebuild/1850/1 ...
<ogra_> but a .snapignore file could make that flexible
<Chipaca> man, my xbill snap doesn't have a .desktop file
<ogra_> heh
<Chipaca> i need to fix this post haste
<ogra_> complain at microsoft :P
<Chipaca> worse, i don't know where i built it
<ogra_> ikey, if you feel like you can tell your users to "snap refresh atom --edge" to test the fix ;) (and to show off how quick snaps can be fixed ;) )
 * ogra_ hugs ikey ... the IRC-> bugtracker bot :)
<ikey> lol
<kyrofa> mcphail, oh definitely, v12 is quite simply not a good experience in the snap right now, which is why we haven't updated stable. Take a look at https://github.com/nextcloud/nextcloud-snap/pull/334
<mup> PR nextcloud/nextcloud-snap#334: nextcloud: update to v12.0.1 <Created by pachulo> <https://github.com/nextcloud/nextcloud-snap/pull/334>
<ogra_> pfft ... icons ... who needs them anyway :P
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/3759#discussion_r135275936
<mup> PR snapd#3759: add spread test for wayland <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3759>
<mcphail> kyrofa: thanks!
<mvo> zyga-suse: some ideas for 3808, sorry that its a bit long, happy to discuss more if you want
<kyrofa> zyga-suse, this is for you: https://bugs.launchpad.net/snapd/+bug/1712930
<mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:New> <https://launchpad.net/bugs/1712930>
<ogra_> just hold it upside down
<mvo> pstolowski: the error in 3642 looks real, there is a unit test failure in transaction_test.go:168 - could you please have a look?
<niemeyer> o/
<pstolowski> mvo, sure
<niemeyer> Will get a quick lunch and be here shortly
 * Pharaoh_Atem sighs
<Chipaca> xbill-xaw now has a desktop file, and it works and is light enough i can ask people to test stuff with it :-D
 * Chipaca tries in his fedora with wayland, first
 * Chipaca braces for thrashing
<zyga-suse> re
<zyga-suse> mvo: thank you, will look at 3808
<mvo> jdstrand: 3759 looks ready, I will merge when tests are green
<zyga-suse> kyrofa: looking, interesting from the title alone
<Chipaca> ogra_: hah! dang, i just wasted some time. the rest of the world is _already_ doing this stuff from profile.d
<jdstrand> mvo: thanks! :)
<zyga-suse> mvo: nice, I'll iterate after dinner
<zyga-suse> kyrofa: hey, have you tried 2.27?
<zyga-suse> kyrofa: I'm pretty sure we handle / which isn't MS_SHARED up front
<zyga-suse> kyrofa: reading the rest of the analysis now
<kyrofa> zyga-suse, no, just latest stable. Happy to try though-- which channel?
<zyga-suse> kyrofa: not sure if channels work now
<zyga-suse> kyrofa: our release-breaks-edge process
<zyga-suse> kyrofa: maybe proposed 2.27.4 would be nice
<zyga-suse> but maybe not
<zyga-suse> let me finish reading stgraber's analysis
<zyga-suse> hmm, forum logged me out
<zyga-suse> and ff doesn't know my password, what?
<zyga-suse> ah
<zyga-suse> this is not forum.snapcraft.io
<ogra_> Chipaca, well, debian and ubuntu arent unless that changed recently
<Chipaca> ogra_: correct
<Chipaca> ogra_: but, it works
<ogra_> well, good then :)
 * ogra_ is afk for a bit
<mup> PR snapd#3372 opened: tests: add basic lxd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3372>
 * zyga-suse was a the sauna
<zyga-suse> I should have been doing that all this week
<zyga-suse> sergiusens_: saunas are fun
<mvo> fgimenez: do you happen to know if the "nightly" suite of snapd is run currently? if so, is that part of spread-cron?
<fgimenez> mvo: yes, according to https://travis-ci.org/snapcore/spread-cron/branches it was executed last night (the branch is called "snapd-nightly-suite")
<fgimenez> mvo: this is the job executed currently https://github.com/snapcore/spread-cron/blob/snapd-nightly-suite/run-checks
<mvo> fgimenez: great, thank you!
 * Chipaca ~> walk
<fgimenez> mvo: np :) i see that the unity test is still around, maybe better removing it completely and execute the whole nightly suite, that way it would be easier to add new tests there
<Chipaca> jdstrand: we don't yet support running ia32 binaries on amd64, right?
<mvo> pedronis: is the night extra-snap-assertions your baby? it looks its unhappy currently https://travis-ci.org/snapcore/spread-cron/builds/268207725#L715
<mvo> fgimenez: +1 for removing that
<pedronis> mvo: I don't even know what it is
<mvo> fgimenez: I'm mostly interessted in this because of lxd, docker which are a bit heavy for the normal runs
<mvo> pedronis: no worries, I have a look
<zyga-suse> Chipaca: we do
<Chipaca> ah! good :-D
<Chipaca> now yes, /me -> walk
<pedronis> mvo: doesn't mean IÂ wasn't involved but Â I don't remember
<fgimenez> mvo: pedronis i added it, it checks for the feature of using extra-snaps with assertions to ubuntu-image
<mvo> pedronis: your name does not come up in git blame, so I guess your memory is fine
<pedronis> ConfigManager is weird, is not actually a StateManager :/
<zyga-suse> I think it's only that because it handled hooks
<jdstrand> roadmr: I noticed r922 is live. thanks!
<jdstrand> stgraber: fyi, feel free to use reload-command
<roadmr> jdstrand: oh yay! true, there was a deploy this morning
<stgraber> jdstrand: yay!
<sergiusens> zyga-suse: they are indeed
<zyga-suse> sergiusens: your mainline kernel will soon-ish work
<jdstrand> Chipaca: ia32 on amd64, do you mean i386 on amd64/x86 on x86_64? if so, snapd supports this. snapcraft (I don't think yet) makes that easy
<zyga-suse> kyrofa: interesting, I'll need to ponder on this some more
<zyga-suse> jdstrand: interesting bug there btw,
 * jdstrand wanted to make sure you weren't talking about x32
<jdstrand> I phrased the snapcraft bit weird. I don't think snapcraft helps at all there
<mup> PR snapd#3793 closed: cmd: "make hack" now also installs snap-update-ns <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3793>
<jdstrand> but I did this work a long time ago (now) for popey's use case of wine on amd64 being able to run 32 bit binaries
<niemeyer> Hellos
<jdstrand> and all that carried forward into recent snap-seccomp, etc
<jdstrand> hey niemeyer :)
<niemeyer> How're things going today?  Anything urgent to look after, or can I jump into the review board and reviews?
<jdstrand> niemeyer: I've not seen anything scary in backscroll, but I'll defer to others
<jdstrand> Chipaca: sudo snap install test-seccomp-compat --edge
<jdstrand> Chipaca: test-seccomp-compat.true32
<jdstrand> Chipaca: test-seccomp-compat.true64
<jdstrand> Chipaca: oh, I forgot, cmd/snap-confine/spread-tests/main/test-seccomp-compat/task.yaml :)
<zyga-suse> niemeyer: hey
<zyga-suse> niemeyer: how are you doing?
<zyga-suse> niemeyer: I think we're good
<zyga-suse> jdstrand: nice snap!!!
<niemeyer> jdstrand, zyga-suse: Sweet
<jdstrand> zyga-suse: thanks :)
<jdstrand> zyga-suse: the bug you mentioned earlier-- you meant snapcraft making it easy for compat archs?
<zyga-suse> no, I mean the bug where snap-confine and / and MS_RSHARED and containers blow up
<zyga-suse> https://bugs.launchpad.net/snapd/+bug/1712930
<mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:In Progress by zyga> <https://launchpad.net/bugs/1712930>
<zyga-suse> real stuff is on https://discuss.linuxcontainers.org/t/snapd-cant-remove-old-revisions-when-running-inside-lxd/452/3
<jdstrand> ah, I didn't see that one yet
 * zyga-suse loves this moment of the day
<zyga-suse> sun is visible because it is below clouds
<zyga-suse> and shines through moving trees
<jdstrand> zyga-suse: sounds nice :)
<jdstrand> we're looking forward to a bunch of thunderstorms this evening
<zyga-suse> https://twitter.com/zygoon/status/901119350870036481
<mup> PR snapd#3811 opened: interfaces/i2c: adjust sysfs rule for alternate paths <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3811>
<jdstrand> zyga-suse: pretty :)
<mup> PR snapcraft#1507 opened: many: simplify plugin loading <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1507>
<niemeyer> mvo: snapd#3260 seems good to go for next week
<mup> PR snapd#3260: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <https://github.com/snapcore/snapd/pull/3260>
<willdeberry> finally got it showing! :) `:bluez`
<willdeberry> thanks zyga-suse
<Pharaoh_Atem> zyga-suse: I wish it was good day here
<Pharaoh_Atem> I'm stuck inside an office working on backporting crap to old stuff :(
<Pharaoh_Atem> I can't even see the sun from where I am :(
<jdstrand> willdeberry: nice!
<Chipaca> niemeyer: how can I edit somebody else's post in the forum?
<Chipaca> wanting to indent a chunk of stuff so it'll be formatted properly
 * Chipaca hugs Pharaoh_Atem 
<Chipaca> Pharaoh_Atem: not long to go now
 * Chipaca wonders why he's doing tech support in the forum
 * Chipaca realises the distance between "snapd doesn't work" and "my system doesn't work" is invisible to users \o/
<Pharaoh_Atem> FINALLY
<Pharaoh_Atem> we're going to have the xdg-open replacement?
<willdeberry> jdstrand: :) . I will be cleaning up and then sending over a PR sometime today for it
<willdeberry> i did have to resort to build the deb and installing. doesn't seem like building snapd was enough
<niemeyer> Chipaca: Hm
<niemeyer> Chipaca: Not sure if you can while being a moderator
<Chipaca> eh, never mind
<niemeyer> Chipaca: ?
<Chipaca> niemeyer: if it was easy and obvious, sure, but it's not important
<niemeyer> If moderators can, then it's easy and obvious to give you that flag
<Chipaca> ah!
<Chipaca> niemeyer: i misread your "not sure if you can while being a moderator" as "afaik being a moderator you can't"
<niemeyer> Ah, sorry.. it was more like "AFAIK I have no idea"
<niemeyer> Chipaca: See if you can now
<Chipaca> I do have a pencil now
<niemeyer> Bingo
<niemeyer> Chipaca: Be careful when tagging now.. you won't be constrained to our standard targs
<niemeyer> targs is great
<niemeyer> Wow.. it's even nicer than I expected.. "Targ or TARG may refer to: The Anti-Gravity Room"
<Chipaca> mbuahaha
 * Chipaca tags all the things
<Chipaca> niemeyer: if you want you can bump me down again :-)
<jdstrand> willdeberry: re building the deb-- that's definitely going to be more robust. glad that worked for you
<niemeyer> Chipaca: Will keep you up.. hopefully you can actually help on the moderation :)
<Chipaca> niemeyer: with great power come great tee shirts, right?
<niemeyer> (unlike zyga, which after a few days had half a dozen random tags, posts painted yellow, etc /o\)
<niemeyer> :P
<niemeyer> jdstrand: Do you have a moment to quickly cover the desktop interface PR?
<jdstrand> niemeyer: yeah
<niemeyer> jdstrand: Ok.. so the thing I'm trying to figure after the extensive conversation we had there is whether we're still solving a problem worth solving for the price of the added complexity
<niemeyer> jdstrand: I miss some technical pieces, so would like to talk live about it.. can we have a quick hangout?
<jdstrand> ok
<jdstrand> niemeyer: where?
<Pharaoh_Atem> mvo: it feels weird to see mvo@ubuntu.com in the fedora changelogs: https://koji.fedoraproject.org/koji/buildinfo?buildID=956399 :D
<niemeyer> jdstrand: hangouts.google.com/hangouts/_/canonical.com/desktop-interface?authuser=0
<Pharaoh_Atem> mvo: but it seems people appreciate the fuller changelogs, so we'll keep rolling with it
<jdstrand> sigh, the camera stopped
<jdstrand> gimma a sec
<Dee__> Hey all! Dee here, New to using Snaps
<kyrofa> Hey Dee__, welcome
<niemeyer> Bye Dee :)
<genii> heh
<kyrofa> I guess I wasn't the person to whom Dee wanted to talk
<mvo> Pharaoh_Atem: heh, I can offer more addresses if you want :)
<mvo> niemeyer: re 3260> yeah, I'm quite happy with it now after the last refactor and added tests
<mvo> Pharaoh_Atem: I will also fix your point in 3260
<mvo> Pharaoh_Atem: I reverted the snapd.spec file changes as you requested, will check tomorrow if tests are still happy. thanks for the review!
<willdeberry> one last thing i am still dealing with is the randomness of error: `/snap/bjarkan/52/usr/bin/python3: 1: /snap/bjarkan/52/usr/bin/python3: Syntax error: word unexpected (expecting ")")`
<willdeberry> i can rebuild on snapcraft.io and the next build will not have any issues
<willdeberry> not sure what is causing this
<willdeberry> makes me wonder if there is a bug in the python plugin for building
<kyrofa> Hey niemeyer, can we get your thoughts on this? https://bugs.launchpad.net/snapcraft/+bug/1712061
<mup> Bug #1712061: snapcraft restricts version field too much <Snapcraft:New> <https://launchpad.net/bugs/1712061>
<mup> PR snapcraft#1508 opened: schema: version should have a max length of 32 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1508>
<niemeyer> kyrofa: Sure, will look in a moment
<mup> PR snapcraft#1507 closed: many: simplify plugin loading <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1507>
<mup> PR snapcraft#1509 opened: project_loader: process stage package grammar <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1509>
<niemeyer> kyrofa: Done
<kyrofa> Thanks niemeyer. Why are you still here?!
<niemeyer> kyrofa: My day started a bit late today.. kid was a bit under the weather last night and I went to sleep when I supposed to be waking up.. so it all shifted forward a bit
<kyrofa> Ah, poor kid. We just finished a round of the stomach flu, I know how you feel
<niemeyer> Yeah.. wonders of being in a school with other children
<niemeyer> I guess that's how they improve their immune system
<niemeyer> (and ours :P)_
<kyrofa> No kidding
#snappy 2017-08-26
<mup> PR snapcraft#1510 opened: ci: disable the travis deploy stage for docs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1510>
<mup> PR snapcraft#1511 opened: project_loader: support grammar on build-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1511>
<mup> PR snapd#3812 opened: Expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
<jhadida> Hello
<jhadida> Idk if I'm in the right place, but I followed the recommendations from this post (https://askubuntu.com/a/796981/135465) for an issue with AppArmor and a snap application (Hugo)
<jhadida> I reported the issue here (https://discourse.gohugo.io/t/where-does-hugo-put-sites-with-absolute-path/8107) and I think I have narrowed it down to one configuration file (/var/lib/snapd/apparmor/profiles/snap.hugo.hugo), which I pasted here (https://pastebin.com/KchkwNRL)
<jhadida> Of particular relevance in this file (imo) are the lines 392-404, which give write access to a range of subfolders from the user's home
<jhadida> I think this is missing write access to mounted drives the user can write to (eg /media/$USER/*), and to the temporary folder (/tmp/*)
<jhadida> But I am not sure how to modify this file, or whether I should report a bug instead, and if so to whom?
<zyga-suse> o/
<zyga-suse> anyone around for a trivial review: https://github.com/snapcore/snapd/pull/3813
<mup> PR snapd#3813: interfaces/apparmor: add missing call to dirs.SetRootDir <Created by zyga> <https://github.com/snapcore/snapd/pull/3813>
<mup> PR snapd#3813 opened: interfaces/apparmor: add missing call to dirs.SetRootDir <Created by zyga> <https://github.com/snapcore/snapd/pull/3813>
 * zyga-suse wonders if any core developers are here to review
 * zyga-suse reboots
<ogra_> zyga-suse, done
<zyga-suse> thank you ogra_
 * zyga-suse preps for 2.28
<mup> PR snapd#3813 closed: interfaces/apparmor: add missing call to dirs.SetRootDir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3813>
<zyga-suse> ogra_: would you be interested in looking at https://github.com/snapcore/snapd/pull/3808 as well
<mup> PR snapd#3808: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <https://github.com/snapcore/snapd/pull/3808>
<zyga-suse> ogra_: make sure to read the comment from mvo: https://github.com/snapcore/snapd/pull/3808#discussion_r135280022
<zyga-suse> ogra_: as my commit later on was to address that
<zyga-suse> ogra_: specifically this one https://github.com/snapcore/snapd/pull/3808/commits/6fc7559580e89f60f8055f00371153d64d67d111
<ogra_> popey, flexiondotorg https://github.com/snapcrafters/atom/pull/4 ...
<mup> PR snapcrafters/atom#4: do not replace but prefix LD_LIBRARY_PATH <Created by ogra1> <https://github.com/snapcrafters/atom/pull/4>
<zyga-suse> ogra_: oh, nice
<ogra_> zyga-suse, sorry, i have to go afk again (i'm actually renovating one of the bathrooms in our house and just took a break), perhaps later in the evening
<zyga-suse> ogra_: no worries, thank you!~
<zyga-suse> ogra_: core snap in edge has version 2.27.4, is it because our release process is broken and edge is old
<zyga-suse> ogra_: (I would have expected 2.28~git12312)
<ogra_> ogra@styx:~/nanopi/brcm$ snap info core|grep edge
<ogra_>   edge:      16-2.27.4+git336.deee544 (2744) 87MB -
<ogra_> zyga-suse, where did you see 2.27.4 in edge ?
<zyga-suse> snap version
<zyga-suse> I mean in the core snap's version
<zyga-suse> I see the same version as you
 * ogra_ refreshes to edge
<ogra_> ogra@styx:~/nanopi/brcm$ snap version
<ogra_> snap    2.27.4+git336.deee544~ubuntu16.04.1
<ogra_> snapd   2.27.4+git336.deee544~ubuntu16.04.1
<ogra_> series  16
<ogra_> ubuntu  16.04
<ogra_> kernel  4.4.0-91-generic
<zyga-suse> yep
<zyga-suse> same here
<ogra_> looks all fine
 * zyga-suse updates to zesty
<zyga-suse> I think my assumptions are different
<zyga-suse> it's okay
<zyga-suse> I would have preferred 2.28~
<ogra_> well
<zyga-suse> >> 2.27
<ogra_> the edge version is always "latest release + git commit on top"
<ogra_> and since there was no .28 yet yu see the last .27 version
<ogra_> *you
<zyga-suse> right
<ogra_> (you have a perfect timing to hit my break time btw :) )
<zyga-suse> I'm reading a book
<zyga-suse> sprinkled my ankle
<zyga-suse> not very mobile ATM
<ogra_> wll, your ping popped exactly up when i sat down with coffee and cigarette for the next break :)
<zyga-suse> ogra_: try pijul snap
<zyga-suse> https://pijul.org/
<ogra_> is it as good as bzr ? :P
 * ogra_ still misses it ... even though i get along with git nowadays i still find it very user-unfriedly 
<ogra_> heh
 * ogra_ goes back to paint a bathroom ceiling
<ogra_> uh oh
<ogra_> zyga-suse,
<ogra_> ogra@styx:~/nanopi/brcm$ sudo snap refresh core --beta
<ogra_> 2017-08-26T15:32:16+02:00 INFO Waiting for restart...
<ogra_> error: cannot perform the following tasks:
<ogra_> - Run refresh hook of "core" snap if present (internal error: no registered handlers for hook "refresh")
<ogra_> can you go back from edge to beta ?
<ogra_> i seemingly cant
<ogra_> anyway ...
 * ogra_ -> painting
<zyga-suse> oooo
<zyga-suse> something for pawel to handle
<zyga-suse> I think we have a bug
<zyga-suse> when edge creates a refresh task
<zyga-suse> *change
<zyga-suse> this will include hook logic that's absent earlier
<mup> PR # closed: snapd#2807, snapd#3120, snapd#3260, snapd#3372, snapd#3398, snapd#3484, snapd#3502, snapd#3556, snapd#3573, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3635, snapd#3642, snapd#3697, snapd#3719, snapd#3720, snapd#3727, snapd#3734, snapd#3748, snapd#3750, snapd#3755,
<mup> snapd#3759, snapd#3760, snapd#3773, snapd#3777, snapd#3779, snapd#3780, snapd#3781, snapd#3795, snapd#3797, snapd#3804, snapd#3805, snapd#3807, snapd#3808, snapd#3810, snapd#3811, snapd#3812
<mup> PR # opened: snapd#2807, snapd#3120, snapd#3260, snapd#3372, snapd#3398, snapd#3484, snapd#3502, snapd#3556, snapd#3573, snapd#3616, snapd#3617, snapd#3621, snapd#3625, snapd#3635, snapd#3642, snapd#3697, snapd#3719, snapd#3720, snapd#3727, snapd#3734, snapd#3748, snapd#3750, snapd#3755,
<mup> snapd#3759, snapd#3760, snapd#3773, snapd#3777, snapd#3779, snapd#3780, snapd#3781, snapd#3795, snapd#3797, snapd#3804, snapd#3805, snapd#3807, snapd#3808, snapd#3810, snapd#3811, snapd#3812
<zyga-suse> oh, hey mup
<zyga-suse> nice to see you connected
<ikey> yknow github has irc bots right? :P
<ikey> #justsayin
<Son_Goku> hey ikey
<ikey> hai
<willdeberry> anyone around to help me understand why this one check failed on the PR I made? https://github.com/snapcore/snapd/pull/3812
<mup> PR snapd#3812: Expose bluez interface on classic OS <Created by willdeberry> <https://github.com/snapcore/snapd/pull/3812>
<mup> PR snapd#3811 closed: interfaces/i2c: adjust sysfs rule for alternate paths <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3811>
<mup> PR snapd#3808 closed: apparmor,release: add better apparmor detection/mocking code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3808>
#snappy 2017-08-27
<ia_> Hello. Just to clarify - is this >[ https://web.archive.org/web/20160428030021/http://developer.ubuntu.com:80/en/snappy/guides/porting/ ] exact concept is dead for embedded devices? Yes, I know that I still can use and devel snap packages, but what about storage-based chromeos-like approach for a whole system? I mean system-a/system-b, switch between them, etc. And now looks like that rollbacks are implemented via simple copying >[ https://snapcraft.io/docs/core/updat
<ia_> es ] instead of switching whole partition. Thanks in advance.
<ogra_> ia_, the newer ubuntu core images use a single writable partition and snap packages on top ...  the rollback is done by switching between versions of the snaps not by switching partitions
<ogra_> ia_, there is a core snap (the rootfs), a kernel snap and a gadget snap (the bootloader and basic system configs) ... to roll back you can just switch to a different core or kernel snap
<ia_> ogra_, just like I thought - thank you for clarification.
<ogra_> on the low level thats way less complex and on the top level way more reliable that way
<ogra_> the former partition setup was a pain and very limited
<Chipaca> zyga-suse: o/
#snappy 2018-08-20
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> hey mborzecki - good morning
<mborzecki> mvo: do you plan to release 2.35 today?
<mvo> mborzecki: yes
<mborzecki> ack
<mvo> mborzecki: reviews for 2.35 prs would be great, iirc its not that many left
<mvo> mborzecki: and 5583 can be ignored and 5340 as well, those will go to 2.36
<mvo> mborzecki: oh, I see there are reviews :) yay
<mborzecki> mvo: yeah, tried to go through 2.35 ones first
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> *yawn* :-)
<zyga> I should make a double espresso
<mvo> zyga: heh, yeah, I make a cup of tea as well
<zyga> :-)
<mborzecki> zyga: quick question, can you take a look at https://paste.ubuntu.com/p/xgQDvNqmtb/ ? i haven't updated apparmor profile yet, so it's expected to fail, the thing i'm a bit suprised is that failure in snap-update-ns does not make the whole thing exit with non-0 status
<zyga> Yes that is expectedâ
<zyga> Only layout failures are âloudâ
<zyga> It is an old decision we took
<mborzecki> zyga: ok, so i guess i should make those changes be of 'layout' origin
<mborzecki> pstolowski: hey
<pstolowski> heyas
<zyga> Or change the default
<zyga> mborzecki: I mean, the decision was made because we only had the content interface using it
<zyga> mborzecki: I would argue that we could reverse the decision now
 * zyga goes to find 2fa tokens
<Chipaca> moin moin
<zyga> hey Chipaca :)
<mborzecki> Chipaca: hey
<Chipaca> mborzecki: is 2.34 really *that* old, or is something weird going on there?
<mborzecki> Chipaca: hm?
<zyga> mborzecki: btw, I prepared 2.35 for opensuse
<Chipaca> mborzecki: this arch bug on the forum
<zyga> but then my opensuse box removed grub
<zyga> so I need to recover it but the packaging is ready
<zyga> I tested it for about a day
<mborzecki> Chipaca: i think it's something odd
<mvo> Chipaca: once 5678 has a second review I can release 2.35 for real ;)
<mvo> Chipaca: hm, and 5677 it seems
<mvo> Chipaca: meh, the later one can go in
<Chipaca> mvo: how any +1s do you want on it?
 * mvo does that now
<Chipaca> mvo: 5678 has a +1 from samuele from 3 days ago and one from maciej from 2 hours ago
<mvo> Chipaca: aha, sorry then!
<mvo> Chipaca: I was trying to debug this grub xz failure, I think that messed with my brain :(
<Chipaca> mvo: good thing the week is nearly over
<Chipaca> mvo: the comment about the error message is on point though (but fine for a follow-up imo)
<Chipaca> niemeyer: dunno if you saw my question about the limitation in spread about not mixing absolute and relative 'systems' statements
<mborzecki> Chipaca: yeah, that forum user has a messed up snapd install from before antergos fixes imo
<Chipaca> niemeyer: I'd like to relax it so that you can mix them as long as the absolute come before the relative
<niemeyer> Mornings!
<mborzecki> Chipaca: at that time we'd just default to /snap instead of /var/lib/snapd/snap and after an update to proper version things go sideways
<Chipaca> niemeyer: that way one can say: systems: [ubuntu-*, -ubuntu-14*]
<niemeyer> Chipaca: Sounds reasonable
<Chipaca> niemeyer: PR coming your way in a bit
<niemeyer> Thanks!
<Chipaca> niemeyer: 'go test' is failing with errors in humbox, am i holding it wrong?
<niemeyer> Chipaca: No, I see them as well, sorry.. humbox is not yet properly finished.. the other end of it, the spread backend itself, still sits on my tree
<Chipaca> niemeyer: no worries
<niemeyer> Chipaca: Just to make sure, the errors you see are from vet, right?
<Chipaca> niemeyer: yes, about printf
<niemeyer> Chipaca: COol.. let me fix those quickly
<niemeyer> Chipaca: Done
<Chipaca> niemeyer: mucho bettero
<mborzecki> zyga: hm asking for user.Current() to work in snap-update-ns is probably too much right?
<zyga> yes, it will run inside the mount namespace and it will not necessarily see the right /etc
<zyga> brb
<zyga> re
<zyga> pstolowski: I'm going over all of the hot plug branches
<pstolowski> zyga: great, thank you! btw, last friday we're discussing the need for a helper such as SystemSnapInfo(), i need to talk yo you about that
<zyga> pstolowski: tell me more, what would that do
<pstolowski> zyga: can we have a quick HO?
<pstolowski> it's related to hotplug
<zyga> yes
<zyga> sure
<zyga> standup?
<pstolowski> ok, coming
<zyga> eh
<zyga> why is google so moronic
<zyga> I personally cannot wait until we move off google services :/
<niemeyer> I'm particularly frustrated with the new interface of Meet.. it now feels like we're speaking to one or two people, even if there are 10 on the call
<mborzecki> zyga: https://paste.ubuntu.com/p/F2hNNVx8HJ/
<mborzecki> zyga: it's still a bit ugly on the inside as I need to guess the user's home dir while not beign able to use user.Current() https://paste.ubuntu.com/p/h8RPVFm4RH/
<zyga> one sec, in a call
<niemeyer> pedronis: Commented on the store scope doc
<pedronis> niemeyer: I'm a bit confused by some of the comments
<zyga> mborzecki: looking
<zyga> mborzecki: hmm, curious
<zyga> mborzecki: since we do user mounts, we have to know the user id at least, and presumably more, in a robust way
<zyga> mborzecki: how does snap-confine get that today?
<zyga> mborzecki: is it a bit of environment that we trust?
<mborzecki> zyga: uid is known, but the paths are from snap run (?)
<zyga> aha
<mborzecki> zyga: s/paths/env vars/
<zyga> right
<zyga> mborzecki: well, we could do one more thing
<zyga> since this is a profile written by snapd
<zyga> we can just ask snapd to tell us
<zyga> that is, we can bake the variables into the per-user profile
<mborzecki> zyga: per user profile?
<zyga> yeah
<zyga> I mean per user mount profile
<zyga> ah
<zyga> I'm dumb, sorry
<zyga> no we cannot :P
<zyga> drat :)
<mborzecki> zyga: but you don't know the user at this point
<zyga> yeah
<zyga> ...
<zyga> we could have snapd write authoritative user data per-user
<zyga> but ...
<mborzecki> bit of chicken and egg :)
<zyga> not sure if sensible
<zyga> I mean something like /var/lib/snapd/users/zyga
<zyga> with authoritative data
<zyga> and it would be true inside mount namespaces and what not
<zyga> so no need to rely on /etc
<mborzecki> zyga: you'd need to know the users upfront
<zyga> well, snapd already needs to know
<zyga> but yeah, more sprawling complexity there
<photex> moin moin! Looking into using snap as an internal app format. Is it possible to run a private snap repo/service?
<zyga> photex: hey, you can send private snaps to the store that only you can download, you can also copy a snap and just install it from a file as well; we don't support running a private repository just yet but for bigger deployments you can redirect your device to a private store (which is a commercial offering I believe) where you can locally host snaps that are private to your organisation (locally) and also filter access to the
<zyga> main store
<photex> Thanks for the info zyga
<photex> And can snaps contain services?
<zyga> yes
<photex> we're specifically looking at snaps as an alternative to deb
<photex> which I'd assume you may have guessed :D
<mborzecki> zyga: so the spread test that runs snaps, writes some data to SNAP_{DATA,COMMON,USER_DATA,USER_COMMON} works now
<zyga> mborzecki: that's great :-)
<mborzecki> zyga: obviously non ubuntu host :P now i have to update autogenerated apparmor profile whihc will be a bit of fun i presume
<zyga> mborzecki: yeah, it should be doable :-)
<mborzecki> is mup quiet again?
<mborzecki> https://github.com/snapcore/snapd/pull/5684
<zyga> pstolowski: hey, I put hotplug reviews on hold for now, I will fix my PRs so that they land; once I do another pass we should be closer to the key decision wrt system snap
<zyga> mvo: we should discuss the system snap concept again
<zyga> mvo: I have a feeling that pawel's work needs to solve that
<pstolowski> zyga: sure & thanks
<mvo> zyga: yeah, I have free cycles one 2.35 is out
<mvo> simple review: 5685
<mvo> (but important for core18)
<zyga> mvo: done
<zyga> and back to hacking
<mvo> zyga: thank you!
<mvo> ogra: I think the latest (edge) snapd fixes the reboot hang, kudos to pedronis
<ogra> mvo, will try !
<ogra> (VM is running but it might take a while until it refreshes)
<ogra> pedronis, mvo, seems to have helped, thanks (havent seen any timeouts this time)
 * Chipaca ~> lunch
<mborzecki> what part is actually skipped when doing spread -reuse ?
<zyga> I think chunks of prepare are skipped
<zyga> but also allocation (obviously)
<mborzecki> hm got a case when s-c was not being rebuilt when using -reuse
<zyga> that's prepare that I mentioned
<mborzecki> i'd guess that package is rebuilt but well, maybe not then
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/5687 your turf
<zyga> hmmm
<zyga> will this work if we disable reexecution
<zyga> that is
<zyga> if future snapd sets SNAP_NAME and SNAP_INSTANCE_NAME
<zyga> and somehow old snap-confine is ran
<zyga> I know that the answer is "it doesn't work"
<zyga> but I wonder how to guard against that
<zyga> or if it will happen in practice
<mborzecki> zyga: i remember talking to mvo that snap/s-c go in sync
<mborzecki> so you either reexec both or none
<zyga> anyway, I will think and review
<mborzecki> zyga: thanks!
<Chipaca> mvo: did we have a problem with x/sys/unix? something about powerpc?
<mvo> Chipaca: we had a problem there in 2.35. do we have a new one=
<mvo> Chipaca: ?
<mvo> Chipaca: do you have more details? 2.35 should be happy everywhere now
<Chipaca> mvo: I'm asking because I was wondering whether I could use it or not
<mvo> Chipaca: let me try
<Chipaca> why did I add the 'or not' there
 * Chipaca grabs the dunce hat
<mvo> Chipaca: did I mention that my brain got a bit damaged by grub?
<mvo> Chipaca: anyway, let me try to login into a ppc machine to test this
<Chipaca> we use syscall all over the place :-/
<mvo> Chipaca: which package? "syscall"? or "x/sys/unix"?
<Chipaca> mvo: x/sys/unix is the one I'd like to use
<mvo> Chipaca: hm, there is a bugreport that x/sys/unix is broken with go1.6
<Chipaca> mvo: link?
<mvo> Chipaca: https://github.com/golang/go/issues/26576
<mvo> Chipaca: on powerpc I have proxy issues right now, looking into it
<Chipaca> :-(
<zyga> mvo: it's interesting because of how that snap (classic) works;
<zyga> mvo: should we keep all the variant deltas (core18, core16) inside?
<zyga> should those be separate snaps (classic/18)
<zyga> etc
<mvo> zyga: good questions
<zyga> mvo: and to take the question further, what about fedora29 is that is a boot base and you install classic, then what
<zyga> mvo: perhaps classic should be a special snap, that can talk to snapd (snapd-control) figure out where it is (which boot base, which environment (classic or core)) and DTRT
<zyga> (e.g. download the delta or do something similar)
<zyga> mvo: but being executable in the classic snap itself feels like a good idea, then we could do the right thing without having all that logic in snapd
 * zyga goes to make coffee while spread runs
<mborzecki> Chipaca: could you take a look at https://github.com/snapcore/snapd/pull/5670 later on?
<Chipaca> mborzecki: yep
<mborzecki> Chipaca: thanks!
<zyga> dh_clean fails in spread? https://www.irccloud.com/pastebin/Sp1cvxRD/
<mvo> zyga: I have not seen this yet
 * zyga -> afk
<mborzecki> zyga: when you're back, please take a look at https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/parallel-install-snap-namespace-mapping just to do a sanity check of the changes
<alexlarsson> jamesh: I'm updating the flatpak PPA to 1.0, which includes the xdg-desktop-portal 1.0 release
<alexlarsson> I'm not sure if updating it for bionic is a good idea though
<alexlarsson> Do you want to do that update eventually?
<mborzecki> zyga: this works on ubuntu 18.04 running from spread, i've pushed it to the integration branch as well so we'll know if other releases are good too
<zyga> Looking
<zyga> Mborzecki: there may be one issue there
<zyga> Mborzecki is envp big enough? I doubt it is
<Chipaca> mvo: can i show you something funny?
<Chipaca> mvo: funny but not urgent :-) so no worries if you'd rather be ignorant for a bit longer
<sergiusens> Chipaca: is funny the thing we are talking about? ð
<Chipaca> sergiusens: yes
<mvo> Chipaca: sure
<Chipaca> mvo: try "snap install --channel=latest/stable bofh" (or any snap) (or refresh instead of install)
<mvo> Chipaca: heh, it tells me this channel is closed
<Chipaca> mvo: :-)
<Chipaca> i'll look into fixing it later
<mvo> Chipaca: thank you
<Chipaca> as soon as this uname thing is green :-)
<Chipaca> thanks to sergiusens fwiw
 * mvo hugs sergiusens 
<Chipaca> refreshing between stable and latest/stable is also fun
<Chipaca> we need a "normalize channel name" thing before comparing them
<mvo> Chipaca: I think we have something like this
<mvo> Chipaca: iirc Channel.Clean() will do that
<sergiusens> Chipaca: I have normalizing logic in snapcraft for build snaps because the api does not normalize them for me ;-)
<sergiusens> Chipaca: LP: #1787967
<Chipaca> sergiusens: ta
 * Chipaca pokes mup
<Chipaca> niemeyer: ^
<niemeyer> Chipaca: Thanks, must have reconnected .. I still haven't managed to fix the nickserv behavior properly
<ogra> the spam wave seems to be over though ... perhaps we could remove +r again
<niemeyer> mup: Ok now?
<mup> niemeyer: Roses are red, violets are blue, and I don't understand what you just said.
<niemeyer> Chipaca: ^
<Chipaca> mup: <3
<niemeyer> ogra: Worth trying, otherwise I'll need to spend some time this week actually fixing that
<ogra> niemeyer, actually, looks like someone did that already
<ogra> seeems to only be +cnt ... i see no +r
<Chipaca> ogra: what does the global +R do?
<Chipaca> (block messages from unidentified users)
<ogra> Chipaca, +r means registered channel +R means you also need to use an registered nick ... but neither seems to be set here anymore
<ogra> so it should be fine for mup for the moment
<ogra> Chipaca, for details https://freenode.net/kb/answer/channelmodes
<Chipaca> #1787967
<mup> PR snapd#5689 opened: many: move Uname to osutil, for more DRY and easier porting <Created by chipaca> <https://github.com/snapcore/snapd/pull/5689>
<mup> Bug #1787967: installing from latest/stable tells you latest/stable is closed and tracking stable <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1787967>
<Chipaca> k
<kyrofa> Hey Chipaca, any chance you could take a look at https://github.com/snapcore/snapd/pull/5655 ?
<mup> PR #5655: snap,snap-exec: support command-chain for hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5655>
<jdstrand> roadmr: hi! would you mind pulling r1115 of the review-tools? it's all overrides
<roadmr> jdstrand: ohai! sure thing, coming up
<jdstrand> roadmr: thanks!
<Chipaca> kyrofa: tomorrow, i'm afraid
<kyrofa> Chipaca, no problem, thanks!
<smoser> hey all. someone suggeseted i enable the 'removable-media' plug. is there any reason to not do that?
<smoser>  https://github.com/smoser/pdftk/issues/1
<zyga> smoser: no, just go ahead and do it
<popey> ogra: finally tried wmx, but it doesn't start. https://paste.ubuntu.com/p/PjHX72f2Bx/
<jdstrand> roadmr, nessita: hey, I've had two LP generated uploads fail. Eg: https://launchpad.net/~myapps-reviewers/+snap/review-tools/+build/316386
<jdstrand> "Store upload failed: Piston/0.2.4 (Django 1.11.13) crash report: Method signature does not match. Resource does not expect any parameters. "
<jdstrand> I looked on status.snapcraft.io and...
<jdstrand> oh, there it is "
<jdstrand> We are experiencing some problems with the Snapstore hosting infrastructure, and are investigating."
<nessita> jdstrand, is all the rebootarama on every server
<jdstrand> I see, ok
<nessita> jdstrand, but I'm not sure your error is related
<jdstrand> it is a weird error
<roadmr> \o/
<roadmr> it's piston, it's all weird
<nessita> jdstrand, if you click retry, does it fail consistently?
<jdstrand> nessita: I did one retry and it failed. let me try again
<jdstrand> nessita: it failed again
<nessita> jdstrand, hum, I will try to dig logs
 * zyga fixed a very stupid network bug that was driving him crazy
<zyga> I had network sharing on one machine and two conflicting dhcp servers
<zyga> stuff _sometimes_ worked, depending on luck and off/on status of the other box
<zyga> man that was silly and hard to track down
<roadmr> Heads up folks - snap store is having some trouble with some operations like some snap pushes, releases, addition of developer accounts. We're looking into it.
<popey> ogra: seems if I reboot, wmx is running and I see a mouse pointer, but nothing more.
<roadmr> jdstrand: see my latest. Some stuff is broken indeed :( we're looking into it
<nessita> jdstrand, hey, can you please retry the review-tools?
<nessita> jdstrand, or I can click on the button (I see it, at least :-))
 * nessita clicks
<nessita> jdstrand, issue fixed
<ogra> popey, a left click should bring up a one-entry-menu ... "New" ...
<ogra> clicking it starts an xterm
<ogra> (and makes that xterm show up in that menu)
<popey> no, it's a blank desktop
<popey> like, doesn't even look like a desktop is running.
<ogra> and nothing if you click ?
<popey> nope
<ogra> weird
<ogra> you did install in devmode ?
<popey> yes
<ogra> and connected the wayland-socket-dir and and x11-plug interfaces
<popey> yes
<ogra> very weird
<ogra> whcih snap did you use ?
<ogra> (it runs fine here in my qemu instance and on a pi)
<ogra> i uploaded the one i'm running to the store but the review is stuck atm
<roadmr> ogra: stuck or waiting for manual review?
<popey> i used the one you linked to
<roadmr> ogra: stuck I can help with, waiting for manual, I probably can't :(
<popey> https://paste.ubuntu.com/p/XKJfG99Cxr/  ogra
<ogra> roadmr, the latter ... the snap uses a llopback x11 plug/scket setup ...
<popey> i see no snap called wmx in the store
<ogra> the review tools arent happy with that
<popey> https://dashboard.snapcraft.io/snaps/wmx/
<popey> that shows 404
<ogra> popey, no, it is called wmx-kiosk-session
<popey> oh
<jdstrand> nessita: thanks! sorry, someone was at the door
<popey> ok, well it doesn't work here. I have a mouse cursor and that's it
<popey> in fact, if i touch the mouse, the cursor disappears
<ogra> thats ok ... thats a mir bug
<ogra> but you should also get a menu
<popey> ooh!
<popey> now I do
<roadmr> ogra: oh then :( sorry :( would need to wait for someone who knows what they're doing to review it
<ogra> \o/
<ogra> roadmr, yeah, i know jamie knows how to deal with that ... but it isnt that urgent that i want to push it :)
<popey> ogra: is there some graphical thing I should be able to run?
<popey> like a desktop snap?
<ogra> i havent tried desktop apps ... but htop definitely works
<ogra> so should irssi and friends
<popey> hm, i have to "snap run" things
<ogra> i'm not really sure what happens with desktop apps ... you'd likely need to connect them somehow to the x11 slot
<ogra> su popey
<ogra> ;)
<ogra> switch to the actual user
<ogra> that should give you the needed path entry (root doesnt have /snap7bin in path)
<popeycore> :)
<ogra> ha !
<popey> https://usercontent.irccloud-cdn.com/file/PQV1cfQk/IMG_20180820_214251.jpg
<ogra> yeah ...
<popey> Nice one, thanks ogra :)
<ogra> with another "New" you can open mre terminals
<ogra> *more
<ogra> to run more apps :)
<Chipaca> sergiusens: how do I tell mypy to chill?
<sergiusens> chipaca: # type: ignore
<Chipaca> sergiusens: and, where should I put a yaml module, if I were to write it?
<sergiusens> chipaca I think kyrofa might take over your PR
<Chipaca> sergiusens: that's fair
<sergiusens> chipaca if that speeds up a review for his he might be happier too :-)
<Chipaca> sergiusens: that sounds efficient
<Chipaca> OTOH, i've checked out of go, and was only looking at mypy because I was curious :-D
<sergiusens> oh, add the proper type check then :-)
<zyga> jdstrand: re
<Chipaca> sergiusens: it looks  like I'll dive into mypy over my staycation
<Chipaca> bah
<Chipaca> a friend is getting married, also
<zyga> jdstrand: not sure if you remember the interface for sharing /mnt, I just updated the PR for that with a simpler approach that just reuses the removable-media; added some more tests and replied / applied all feedback.
<Chipaca> so there might be a lot of alcohol involved
<jdstrand> zyga: I do and I saw and it is already on my TODO to review
<jdstrand> :)
<zyga> thank you
<zyga> https://twitter.com/zygoon/status/1031646427611578370 :-)
 * zyga tries to switch to vim hjkl for navigation
<Chipaca> g'night y'all
<jdstrand> zyga: nice :) and hjkl is worth it I think (I switched a year or so ago)
<zyga> jdstrand: it's nicer in real life, my phone camera doesn't capture the contrast
<zyga> plus most keys leave ghosting trail as I type
<zyga> it's pure bling but it looks great :D
<jdstrand> hehe
<zyga> brb, shower time
<jdstrand> nessita: fyi, snapcraft release had the same issue as before: bad-request: Piston/0.2.4 (Django 1.11.13) crash report:
<jdstrand> Method signature does not match.
<jdstrand> Resource does not expect any parameters.
<jdstrand> nessita: different from before, retries seemed to help. I am not blocked
<roadmr> jdstrand: yes, we just noticed we missed restarting some processes :)
 * jdstrand nods
<roadmr> jdstrand: done, hopefully solved now but we'll keep an eye on things
<sergiusens> jdstrand: zyga hjkl on vi(m) or something else?
<sergiusens> I only ever used that, but am on vscode now... contemplating switching back just for navigational purposes
<roadmr> I was going to say hjkl sucks for me because I'm left-handed, but the arrow keys which I use just fine *are* on the right side :/ so I guess it's just never getting used to using letters if there are perfectly fine, pointy arrows for that purpose
<jdstrand> sergiusens: I was assuming vim
<jdstrand> roadmr: hehe :)
<cjwatson> ogra: I think I set +q $~a here rather than +r
<cjwatson> which is slightly gentler
#snappy 2018-08-21
<mup> Bug #1760252 changed: starting slack crashes xwayland on 18.04 <bionic> <xorg-server (Ubuntu):New> <https://launchpad.net/bugs/1760252>
<mup> PR snapd#5690 opened: Add an error code for Polkit auth cancels <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/5690>
<mborzecki> morning
<mborzecki> mvo: hey
<mborzecki> mvo: easy win https://github.com/snapcore/snapd/pull/5687
<mup> PR #5687: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5687>
<mborzecki> mvo: hey, you probably missed that, https://github.com/snapcore/snapd/pull/5687 is an easy win, same as https://github.com/snapcore/snapd/pull/5684
<mup> PR #5687: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5687>
<mup> PR #5684: cmd/snap: create snap user directory when running parallel installed snaps <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5684>
<mvo> mborzecki: yeah, missed that, looking. thank you
<zyga> good morning!
 * zyga tries to shift to 6AM wake-ups
<zyga> not there yet
<zyga> but slowly :)
<mvo> zyga: good morning
<zyga> I'll make coffee and join you guys shortly
<mborzecki> zyga: hey
<mborzecki> zyga: you're still 2h behind the schedule :P
<mup> PR snapd#5687 closed: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME <Parallel installs> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5687>
<mvo> mborzecki: 5684 waits for john, no?
<mborzecki> mvo: yay, thanks
<mborzecki> mvo: yes, i pinged him and pawel yday
<mborzecki> feels good to be back at the proper screen
<zyga> :-)
<zyga> Yeah but Iâm shifting
<zyga> When I woke up today I felt like itâs autumn ready
<zyga> Is it OK to say I already miss the summer?
<zyga> My plan for today is to talk with PaweÅ about the system snap
<zyga> And to finish off the two remaining PR I have open
<zyga> And then work and user mounts
<zyga> mvo: When do you plan to release the next point release?
<mborzecki> zyga: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/parallel-install-snap-namespace-mapping i'd love to hear your thoughts
<mborzecki> zyga: also need to look info why /snap/foo is mounted rw
<zyga> Iâll check it out very soon but just as an observation snap foo cannot be a mount point, because thereâs nothing out there is just a directory
<mborzecki> zyga: rbind & ro are a no go (you added that comment?), guess it's not much of a problem for /snao/foo_bar -> /snap/foo
<zyga> re
<zyga> mborzecki: looking
<pstolowski> mornings
<mvo> zyga: I have no plans yet for a point release. what do we need in it?
<zyga> some things are tagged with 2.35
<mvo> zyga: we can do in a week after the real release
<zyga> and 2.35.0 is in the release page
<mvo> zyga: aha, let me check
<zyga> so I assumed you would do another one
<zyga> is 2.35 out?
<zyga> or am I just mistaken about the assumption
<mvo> zyga: I thought I had moved them to .36
<mvo> zyga: its in beta now
<zyga> ah, that must be it then
<mvo> zyga: https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.35
<mvo> zyga: but we can do a point release i fneeded
<zyga> ah, ok
<zyga> :)
<mborzecki> zyga: mount profiles for test-snapd-layout{,_foo} https://paste.ubuntu.com/p/JvmWd88tKp/ unfortunately the _foo one explodes on startup https://paste.ubuntu.com/p/8ZYtzf7sgG/
<zyga> https://www.irccloud.com/pastebin/d39eugoc/
<zyga> mborzecki: that's "expected", aka known issue
<zyga> mborzecki: rm the symlink on your host to fix it
<zyga> mborzecki: that's the "trespassing" bug that I was trying to fix for many months now
<zyga> mborzecki: it manifests itself as dangling symlinks and empty files in /etc
<mborzecki> zyga: ok, removing files made it go away
<mup> PR snapcraft#2220 opened: schema: allow license field <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2220>
<alexlarsson> zyga: hey, do you know if there is any work going on to backport the new xdg-desktop-portal releases (in particular, 1.0) to bionic?
<alexlarsson> zyga: I'm considering whether to add it to the bionic flatpak ppa
<mup> PR snapd#5691 opened: spdx: allow Other-Open-Source <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5691>
<seb128> jamesh, ^ you might know?
<jamesh> alexlarsson: we want to backport xdg-desktop-portal to xenial.  I think it might make that backport 1.0, and push it to bionic, assuming there aren't compat issues
<alexlarsson> jamesh: Should be no compat issues
<alexlarsson> I have x-d-p 1.0 for xenial in the flatpak ppa, but historically i didn't add it to bionic, because it had 0.11 already
<zyga> whee, thank you alexlarsson and jamesh :)
<jamesh> alexlarsson: I'll talk about it with Ken
<mborzecki> zyga: parallel installs + layouts spread test running now
<zyga> cool
<alexlarsson> jamesh: cool
<zyga> mborzecki: any luck?
<mborzecki> zyga: heh, stopped at the trespassing thing, fixed the test to cleanup /etc/demo* stuff and retrying now
<zyga> kk
<zyga> once it passes (if it does) look around, as I said it's more about just ensuring the outcome makes sense than looking at the boolean pass/fail value
<mup> Bug #1533899 changed: Add support for proxies <canonical-is> <proxy> <webdm> <cloud-init:New> <Snap Layer:Fix Released by stub> <Snapcraft:Invalid> <Snappy:Fix Released> <snapweb:Invalid> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1533899>
<mborzecki> zyga: yeah, modified it a bit to write different content to locations and added some steps to verify if the things look ok from the outside
<mborzecki> zyga: once https://github.com/snapcore/snapd/pull/5670 i'll be able to open a PR with mapping changes along with a spread test
<mup> PR #5670: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5670>
<mborzecki> hm actually most of the spread tests, there's one that depends on https://github.com/snapcore/snapd/pull/5614
<mup> PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614>
<Chipaca> zyga: next time you're feeling smug about your mac, have you looked at the uname implementation for darwin vs the one for linux
<zyga> mmm, nope/
<zyga> what's the difference?
<Chipaca> zyga: https://github.com/golang/sys/blob/master/unix/syscall_darwin.go#L368 vs https://github.com/golang/sys/blob/master/unix/zsyscall_linux_amd64.go#L1378
<Chipaca> zyga: the darwin one is five syscalls and a loop
<zyga> interesting, I knew apple did some unusual things with their sys call layers
<zyga> notably for compatibility at the extreme
<zyga> and also flexibility
<zyga> some system calls don't have numbers
<zyga> only names
<zyga> and to call them you literally have to pass the string to the kernel
<zyga> then again apple sys calls are executed differently due to (last time I looked at 32bit systems) 4/4 split
<zyga> where the whole address space flips (except for a tiny page that has the flip code and arg buffers)
<zyga> Chipaca: but yeah, cool stuff :)
<zyga> and apparently it doesn't matter (marketshare :)
<Chipaca> zyga: :-)
<Chipaca> what does userd use SIGUSR1 for?
<Chipaca> morphis: do you remember?
<mup> PR core#93 opened: hooks: unwind /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/93>
<mborzecki> zyga: that's the test currently https://paste.ubuntu.com/p/KfNJC6tJV2/
<zyga> mborzecki: looking
<zyga> mborzecki: what I would look for in this test is something that verifies that both instances don't step on each other's data
<mborzecki> zyga: that's towards the end
<zyga> mmm, I don't see that
<mborzecki> zyga: lines 85+, unless you have something else in mind
<zyga> mborzecki: I mean that one snap should say "snap-a" and the instance snap should say "snap-b"
<zyga> they should both write
<zyga> and only after that we should verify the data seen by both
<zyga> so that it's not "snap-a" in all the places (or snap-b in all the places)
<mborzecki> zyga: that's exactly what's there
<zyga> hmm?
<zyga> but you write foo-1, 2, 3 for _both_
<zyga> so how can you check that
<mborzecki> zyga: $name foo-1 ..
<zyga> either I don't see it or the pastebin is wrong :D
<zyga> aaah
<zyga> $name :D
<zyga> I didn't notice that at a ll
<zyga> ++
<zyga> it's good :)
<mborzecki> heh :)
<zyga> thank you
<mborzecki> zyga: ok, i'll add it to the tests and integration branches, and deal with that change in mount spec that you suggested layer
<mborzecki> have to deal with UpdateMany() now
<mvo> zyga: do you know what (bind) mounts /var/lib/extrausers in snap-confine - git grep extrausers is very quiet for me
<zyga> let me think
<zyga> I don't think that's us
<zyga> isn't that the test setup?
<zyga> or core boot process?
<zyga> (us as in the cli tools)
<mvo> zyga: snap run --shell test-snapd-tools.echo gives me a valid /var/lib/extrausers inside the mount namespace
<mvo> zyga: so I assume that is us doing it
<zyga> ok, let me look deeper
<zyga> probably my memory is just rusty
<zyga> ah
<zyga> I know
<zyga> just let me check to be 100% sure
<zyga> yep
<zyga> it's the LXD quirk
<zyga> we have a "quirk" system in snap-confine that we only used after a particular release of snap-confine broke lxd
<zyga> we make /var/lib/lxd (which is not in the base snap)
<zyga> and we bind mount the host's version there
<zyga> to do that we construct an (older implementation of) a writable mimic over /var/lib
<zyga> I would like to disable that code but perhaps hard to ensure it's not a backwards incompatible change now
<mvo> zyga: and this runs only if core is the base? not core18 ? or how is that decided?
<zyga> (and we could tie that code to the lxd interface perhaps)
<zyga> it runs on all classic systems for sure
<zyga> let me look
<zyga> yes
<mvo> zyga: aha, ok
<zyga> sc_setup_quirks is called if distro is SC_DISTRO_CLASSIC
<zyga> but I would like to drop that, really
<zyga> it pollutes the mount table with stuff for one snap but runs for all the snaps
<zyga> and it's very very very likely to be unused now
<zyga> and it can move to an interface (for sure)
<mvo> zyga: hm, something else is going on - I see this on !classic, on uc16
<zyga> though all such transitions are non-trivial because we have no mechanism to update in-place the
<zyga> oh
<zyga> maybe there's a bug in core / classic classification on uc16
<mvo> zyga: could be, not super important right now, I was mostly looking why core18 was not displaying a username on core18 devices inside the mount namespace
<zyga> mvo: what's the /etc/os-release file you see?
<mvo> zyga: https://paste.ubuntu.com/p/XkFW7hYYTX/
<zyga> ID=ubuntu-core
<mvo> zyga: silly question - in sc_mount_config what does "normal mode" mean?
<zyga> normal mode is the preferred mode of operation where pivot root happens
<zyga> the exceptional mode is only on core16 when we don't do that
<zyga> (for compatibility reasons)
<zyga> the exceptional mode is called "legacy mode"
<mvo> zyga: do we have two normal modes? on in the struct and one global?
<zyga> nope
<zyga> normal == used on classic, used on core 18 +
<zyga> legacy == used only on core16
<zyga> brb, coffee
<mvo> zyga: thank you
<mvo> zyga: enjoy coffee, I will dig a bit around myself
<mup> PR snapd#5683 opened: overlord/patch: support for sublevel patches <Created by stolowski> <https://github.com/snapcore/snapd/pull/5683>
<zyga> mvo: back
<zyga> I was getting coffee making lessons actually (unexpectedly)
<zyga> mvo: I can spin up a core16 VM and check as well if you want
<mborzecki> need to go to the car shop, will work from there, bbiab
<zyga> kk
<zyga> mvo: you can also get a trace with SNAP_CONFINE_DEBUG=yes
<zyga> perhaps that will shed some light as to what is going on
<mvo> zyga: ok
<zyga> mvo: if you pastebin that I will gladly look
<zyga> mvo: just remember that on 2nd run it will use the persisted namespace
<zyga> so you may want to discard it before collecting the log
<mvo> zyga: https://paste.ubuntu.com/p/mTqsSKSfTz/
<mup> PR snapd#5692 opened: snap-confine: map /var/lib/extrausers into snaps mount-namespace <Created by mvo5> <https://github.com/snapcore/snapd/pull/5692>
<mvo> zyga: oh, what was the command again to discard it?
<mvo> zyga: ^- the PR above is the actual problem I want to fix :)
<mvo> zyga: this is a bit of a side-issue
<zyga> mvo: /usr/lib/snapd/snap-discard-ns $SNAP_NAME
<mvo> zyga: https://paste.ubuntu.com/p/26bb6N4mVQ/
<zyga> mvo: if you use SNAP_DEBUG=1 you will also get snap-update-ns feedback
<zyga> mvo: hmm
<zyga> mvo: so this says nothing happened really pretty much
<mvo> zyga: https://paste.ubuntu.com/p/FtqGCYzTnT/ <- with SNAPD_DEBUG=1
<mwhudson> niemeyer: https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/corecfg.go#L119-L125 <- means that snap set core proxy.http doesn't do anything on non-core, right?
<mvo> mwhudson: correct
<mwhudson> mvo: context https://bugs.launchpad.net/snapcraft/+bug/1533899
<mup> Bug #1533899: Add support for proxies <canonical-is> <proxy> <webdm> <cloud-init:New> <Snap Layer:Fix Released by stub> <Snapcraft:Invalid> <Snappy:Fix Released> <snapweb:Invalid> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Released> <https://launchpad.net/bugs/1533899>
<mvo> mwhudson: aha, I see. this is about respecting it in snapd internally?
<mwhudson> mvo: i don't know
<mvo> mwhudson: yeah, I think thats missing but should be simple, let me have a poke
<Chipaca> mwhudson: proxy on classic can be set via /etc/environment, can't it?
<mwhudson> mvo: there is a tension core-aka-system-config vs core-aka-snapd-config
<mwhudson> mvo: which i guess you are fixing in series 18 :)
<mwhudson> Chipaca: that works about as well or badly as any other way of setting it, yes
<Chipaca> mwhudson: also to keep things interesting, there's http proxying, and there's snap store proxy
<mvo> mwhudson, Chipaca my gut feeling is that on core device we edit /etc/environment and thats fine. on classic we don't but we should still lookup if the config was set and respect it
<zyga> brb
<Chipaca> sparkieg`: the link to documentation from https://forum.snapcraft.io/t/announcing-snap-store-proxy-beta/4666 is broken
<mwhudson> i think snapd.service still says EnvironmentFile=/etc/environment?
<Chipaca> mwhudson: yup
<mwhudson> anyway, i wouldn't want people to think that saying snap set core proxy.http=.. does anything at all on classic now, because it doesn't
<mwhudson> maybe it should but i don't have an opinion on that :)
<Chipaca> mvo: mwhudson: on classic, setting the proxy via unity-control-center edits /etc/environment
<mvo> Chipaca: yeah, thats fine
<Chipaca> I'm lost about what the bug is about tbh
<Chipaca> description just talks about core
<mvo> Chipaca: I was mostly thinking that we should do somehting on classic. either error if you try to set it on classic *or* respect it for snapd only
<mvo> Chipaca: yeah, its not entirely clear to me either but there is confusion and it seems the above (either error or support it) should fix the confusion
<mvo> mwhudson: ^- does this make sense?
<Chipaca> mvo: hold on
<mwhudson> Chipaca: should probably do something to do with environment.d(7) nowadays? don't really care though
<Chipaca> mvo: "snap set system proxy.store=xyzzy" works on classic, doesn't it?
<Chipaca> mwhudson: environment.d wasn't in <18 afaik
<mwhudson> oh wait that's only user sessions?
<mwhudson> yeah all this is fairly new
<niemeyer> mvo: Don't we use the proxy internally?
<mvo> mwhudson: this is not read by pam, right? so things like ssh will not use it(?)
<Chipaca> mwhudson: so yeah nah
<mvo> niemeyer: I think we did not add support for this, I can look into making this happen should be easy but iirc we did not do it yet
<Chipaca> mvo: erroring on the ones we don't support would be good yes
<mvo> mwhudson: I whish pam_env would support it, I looked at this briefly but iirc there were some complications (beside it being pam)
<mwhudson> mvo: something extra fun iirc here is that go's ProxyFromEnvironment looks at the environment *once*
<mvo> Chipaca: yeah, lets see if niemeyer prefers support or error
<mvo> mwhudson: heh, fun indeed :)
<mwhudson> i spent a while trying for subiquity to find a way of providing a proxy to snapd that didn't involve restarting it and failed
<niemeyer> For some reason I assumed we were already using it for internal purposes at least.. just not changing the whole system configuration when !core
<Chipaca> mvo: wait, that onClassic check means we don't support proxy.store on classic either
<mvo> mwhudson: hm, you should talk to use more :)
<niemeyer> Chipaca: Yeah, this is busted
<mwhudson> mvo: probably
<mvo> mwhudson: I mean, we can/should honor it internally
<mvo> Chipaca: is it? this is just used internally, no?
<Chipaca> mvo: which is 'this'?
<mwhudson> i should also not rush to complete features before deadlines i guess
<mvo> Chipaca: let me look at the code before I make more statements :)
<Chipaca> mvo: ok :-)
<mvo> Chipaca: what I mean is that iirc we allow setting proxy.store
<mvo> Chipaca: and it is store in the internal configuration state
<mvo> Chipaca: and we honor it inside our code
<Chipaca> mwhudson: turns out deadlines are really only slightly-upset-lines
<niemeyer> Chipaca: Ah, except we do it seems
<mvo> Chipaca: *but* I have not looked at this
<mvo> Chipaca: I mean, this is just memory
 * Chipaca tries
<Chipaca> hmm, proxy.store does do _something_ (it complains about a missing assertion at least)
<Chipaca> proxy.http does not, though
<mvo> Chipaca: yeah, thats my understanding
<mvo> Chipaca: let me do a quick PR that errors and then I do a not-so-quick PR that honors it internally
<mwhudson> looks like all snap set core proxy.store does is validate the args
<mvo> niemeyer: ^- sounds reasonable?
<mwhudson> on any system
<Chipaca> bah
<Chipaca> i dunno
<Chipaca> validation happens, but handling does not ?
<mwhudson> looks like it
<mvo> Chipaca: we don't need to handle it at this level, do weÃ
<mvo> s/Ã/?/
 * Chipaca gives up
 * mwhudson gets back to ordering groceries (why the laptop is open at 22:40)
 * Chipaca goes shopping
<Chipaca> mwhudson: a solid plan
<mwhudson> ha
<mvo> Chipaca: I mean - for http.proxy we need to modify the filesystem but proxy.store is only used internally and does not need any external actions iirc
<niemeyer> func ProxyStore(st *state.State) (*asserts.Store, error) {
<niemeyer>         tr := config.NewTransaction(st)
<niemeyer>         var proxyStore string
<niemeyer>         err := tr.GetMaybe("core", "proxy.store", &proxyStore)
<niemeyer> The fact we don't do anything at set time but validation doesn't mean it's unused
<mvo> +1
<niemeyer> I assumed the same was being done for proxy, at least for internal purposes
<niemeyer> We just shouldn't fiddle with the whole system when snapd is not on a core system
<niemeyer> But respecting the variable seems reasonable
<niemeyer> I mean, if people don't want snapd to have a proxy, just don't set it
<mvo> niemeyer: yeah, I think we are in agreement, I have a look at this
<niemeyer> mvo: The question is what's the easiest way to make sure all requests are proxied
<niemeyer> mvo: It may well be to take the proxy configuration and set the environment variable
<niemeyer> Both when we start, and when someone changes the conifg
<niemeyer> Otherwise we'll need to tune every single *http.Client
<mvo> niemeyer: yeah, this is straightforward, we need to double check that golang actually reads the env anew every time
<niemeyer> mvo: +1.. I assume it does, but needs confirmation indeed
<mwhudson> er no it doesn't
<mwhudson> that's what i was saying above
<mvo> mwhudson: hm, hm, thats unfortunate
<ogra> just make people stop using that ancient classic thing ;) core for everyone !
<mvo> niemeyer: the good news is that we have httputils:NewHTTPClient so hopefully a single point where we need to inject this
<mwhudson> mvo: hmmm maybe i am wrong, or maybe this has changed in golang now
<mvo> mwhudson: I was just looking at 1.10
<mvo> mwhudson: but then we still build with 1.6 :(
<mwhudson> ah no net/http's ProxyFromEnvironment still has a sync.once
<niemeyer> mvo: Ah, sweet! I didn't realize we had already consolidated that, great
<mvo> niemeyer: its a bit of a layering problem still because we use that in e.g. "snap download" so we need access to the state
<mvo> niemeyer: we could of course cheat and set an (internal) env var snapd_http_proxy etc
<niemeyer> mvo: I think we need to fix snap download to be more typical
<niemeyer> mvo: Meanwhile, we might just ask for the config in the command maybe?
<niemeyer> mvo: I mean, the configuration is readable from the API
<mvo> niemeyer: great idea
<mwhudson> aah ok you can call golang.org/x/net/httpproxy.FromEnvironment() to make a new thing from the current environment
<mwhudson> (thanks to rog, it seems0
<mwhudson> )
<mvo> mwhudson: this will work in 1.6?
<mwhudson> mvo: no idea
<mwhudson> mvo: suspect not :/
<mwhudson> mvo: do you have a plan for getting off 1.6?
<mwhudson> juju-core uploads in xenial build golang first...
<mvo> mwhudson: I hard foundations will support 1.10 in xenial :P
<mvo> mwhudson: yeah, we might need to do the same, I'm not looking forward to it
<mwhudson> mvo: i just do what the security team tells me to do
<mvo> mwhudson: heh, sure I understand the issue(s)
<mwhudson> (which is why juju does what it does!)
<mvo> mwhudson: it makes me wonder (again) if we should make the snapd in the deb just a small shim that downloads the snapd *snap* which we then can build in whatever way we want
 * mwhudson reaches for his boostraps only to find he's already standing on them
<mwhudson> mvo: something about the current setup certainly smells bad
<mwhudson> mvo: something something prepare-image classic something
<mvo> mwhudson: I'm missing something here, what about prepare-image classic ?
 * mvo might be a bit slow due to lack of lunch
<mwhudson> mvo: heh i'm skipping ahead in ways that probably don't make sense
<mwhudson> mvo: we already support including snaps in all the images we make
<mwhudson> or will
<mwhudson> why shouldn't the snapd snap be one of them?
<mvo> mwhudson: \o/ I like that thinking!
<mwhudson> well because it's snapd that processes the seed.yaml
<mvo> mwhudson: sillly bootstraps
<mwhudson> so you need something to at least partly process it at image build time
<mwhudson> --> prepare image for classic
<mvo> mwhudson: yeah, we would just need to extract the snapd binary and when it starts and finds a valid seed env it will DTRT (i.e. seed itself, restart itself, seed the rest)
<mvo> mwhudson: so that is actually pretty simple
<mwhudson> and then you can use the go snap to build snapd :)
<mvo> mwhudson: \\o//
<mvo> mwhudson: I will think about this over lunch
<mwhudson> mvo: i'm at least somewhat procastinating about ordering groceries, please don't let me disturb your day too much
<Chipaca> um, sorry if i got distracted and worked on the same thing you've been working
<Chipaca> without reading all the backlog :-)
<Chipaca> i can confirm proxy.store works on classic
 * Chipaca hates having to set up proxy for a quick check like this
 * Chipaca now wonders if he's stuck with the proxy asserts forever
<mup> PR snapd#5693 opened: overlord/snapstate: verify SnapState name matches instance key <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5693>
 * Chipaca further wonders why he didn't do it in a vm
<zyga> Chipaca: setting proxy on classic blows up fuses in your CPU *forever*
<mborzecki> pedronis: i'm wondering if a change like #5693 would be useful (actually makes my life easier in the tests)
<mup> PR #5693: overlord/snapstate: verify SnapState name matches instance key <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5693>
<Chipaca> zyga: 'proxy' is not  settable, so neener neener
<ogra> jdstrand, already around ?
<Chipaca> mborzecki: which was the pr you asked me to review?
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/5670
<mborzecki> Chipaca: thanks!
<mup> PR #5670: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5670>
<pedronis> mborzecki: it's a bit problematic because some buggy code in a corner doesn't undo the current op, it kills snapd
<pedronis> but making Set return an error is a huge change
<mborzecki> pedronis: yeah, that's what i'm afraid of, either way it's no good :/
<pedronis> mborzecki: otoh I don't think we have a ton of non-test places using Set
<pedronis> you might just do it one level up or have a wrapping helper
<mborzecki> pedronis: the reason i added it is that in the tests it's easy to do .Set(.., "foo_bar", ..) and forget to set InstanceKey in SnapState
<mborzecki> pedronis: MustSet?
<pedronis> I see, for tests
<pedronis> that is a big change too
<mborzecki> pedronis: ok, let me drop it for now
<mup> PR snapd#5693 closed: overlord/snapstate: verify SnapState name matches instance key <Parallel installs> <Simple> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5693>
<pedronis> mborzecki: an approach would be some kind of global flag we set in tests
<mborzecki> pedronis: right, that would work, i saw some test only flags/ifs inside the code, so the precedent is set
<Facu> hi all!
<Facu> may it be that snap is restarting my lxd? I have this in my /var/log/syslog: http://linkode.org/#UkaWdFxuTwqJTFFc3UqLW5
<Facu> in that log, snap is telling that some of my snaps have no update available, but for lxd it doesn't say that, and some seconds later lxd is stopped
<mborzecki> zyga: hah, layout test recovery has to be improved little, it leaves garbage behind, jut had tests/main/layout fail because tests/main/parallel-install-layout left the /etc/* symlinks
<zyga> mborzecki: yeah, that's the (existing) bug I mentioned
<mborzecki> mhm
<mborzecki> zyga: the trespassing thing, something i could help you with?
<zyga> yes, I have a branch that we need to go back to
<zyga> I got stuck on the precise algorithm there (after loads of attempts)
<zyga> we can talk about that today
<mborzecki> zyga: i remember the reviewing some checkers for this
<zyga> yeah, a lot of the preceding helpers landed but the "meat" did not
<mborzecki> sounds familiar :)
<pedronis> mvo: I saw you updated the roadmap, there is still some mistyped "topic"   in the 2.34 bits
<mup> PR snapd#5694 opened: tests/main/layout: cleanup after the test <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5694>
<mborzecki> zyga: ^^
<zyga> yeah, +1
<zyga> odd - we had that before
<zyga> must have been lost in some PR
<zyga> I remember that all of the trespassing PRs (the full blown versions that didn't land) removed that part
<mborzecki> yeah, btw. cachio__ tracking of tests that executed before came in handy :)
<ackk> hi, I'm trynig to implement a configure hook for a snap, but I get "snapctl: not found" when I run "snapctl get <something>" in the hook script
<cachio__> mborzecki, :)
<ackk> do I need special permissions for the snap to do that?
<ogra> Facu, better start a forum thread ... (see channel topic)
<Facu> ogra, ack, thanks
<mup> PR snapd#5684 closed: cmd/snap: create snap user directory when running parallel installed snaps <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5684>
<zyga> mvo: any luck?
<Gargoyle> Hi all. All my snaps have stopped working - is this likely to be related to giving kernel 4.18 a spin (I can't think of anything else I have done). "snap list" shows them all, but none of them work. lxd, discord, postman. It's as though they are just not on the system.
<zyga> Gargoyle: hey, can you provide some more details? what does snap version show?
<mvo> pedronis: thanks, will fix the ypos
<mvo> pedronis: *cough* typos
<pedronis> mvo: not the most important thing but I see them :)
<mvo> zyga: no luck, lunch and tea and then
<zyga> k
<mvo> pedronis: yeah, thanks for noticing!
<mvo> Chipaca: did you work on the http-proxy stuff? or just store proxy?
<Chipaca> mvo: I just set up postgres and the store proxy to get the assertions and see if it actually worked (it did)
<mvo> Chipaca: great
<Chipaca> mvo: I also set http-proxy and confirmed it did not work
<mvo> Chipaca: thanks for doing this!
<mvo> Chipaca: I am looking into making http-proxy actually work
<Gargoyle> zyga: https://paste.ubuntu.com/p/qFcJvTKx5Z/, I've also tried "snap remove postman" and "snap install postman" which seemed to run the installation fine, but can't launch "postman" from gnome or command line.
<Chipaca> mvo: if in classic, and it's set, it overrides environ?
<zyga> Gargoyle: how did you install the 4.18 kernel?
<mvo> Chipaca: I would assume so, going from most generic to most specific
<zyga> perhaps there's an issue with that kernel and snap confinement
<Chipaca> mvo: can I bother you for a +1/-1 on #5689 ?
<Chipaca> mvo: (you already looked at it)
<mup> PR #5689: many: move Uname to osutil, for more DRY and easier porting <Created by chipaca> <https://github.com/snapcore/snapd/pull/5689>
<Gargoyle> zyga: From the .deb files on http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18.3/
<zyga> I see
<mvo> Chipaca: we could also warn
<zyga> Gargoyle: I can give that a spin
<mvo> Chipaca: sure, looking
<Chipaca> mvo: thanks
<mvo> Chipaca: you stole all the comments ;) or it would be approved already
<Chipaca> mvo: I put 'em back :-D
 * mvo stops being silly and looks at the code
<Gargoyle> zyga: Cool. I had nvidia drivers and virtualbox installed, so I removed those first and re-installed later. Everything else seems to be working a-ok.
<zyga> Gargoyle: do you have any apparmor denials?
<zyga> what does snap debug sandbox-features # shows
<zyga> (apparmor denials can be checked with: dmesg | grep DENIED
<Chipaca> mvo: \o/
<mup> PR snapd#5689 closed: many: move Uname to osutil, for more DRY and easier porting <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5689>
<Gargoyle> zyga: https://paste.ubuntu.com/p/z6xX3vwGKT/
<Gargoyle> Snap core denied... that's probably not good!? :/
<mup> PR snapd#5695 opened: osutil/sys: small tweaks to let it build on darwin <Created by chipaca> <https://github.com/snapcore/snapd/pull/5695>
<zyga> mmm
<zyga> Gargoyle: I think I've seen this, it looked like a bug in the latest kernel
<zyga> jdstrand, jjohansen1: ^ do you guys remember if the ptrace(read) issue turned out to be a kernel bug?
<mvo> zyga: hm, we have no notion of "optional" things to mount into a mount namespace right now? i.e. if /var/lib/extrausers exists, mount otherswise no error?
<mvo> zyga: mind if I add it?
<zyga> mvo: we do now (almost, just needs an ack from jdstrand)
<zyga> mvo: look athttps://github.com/snapcore/snapd/pull/5307
<mup> PR #5307: cmd,interfaces,tests: add /mnt to removable-media interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
<zyga> once that lands we can use this feature
 * zyga goes and fixes garbage in that PR
<zyga> brb
<mvo> zyga: cool, I will base my PR on yours then
<mup> PR snapd#5696 opened: interfaces/builtin/opengl.go: add additional cuda bits to opengl <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>
<Gargoyle> brb, reboot (reverting to 4.15)
<morphis> Chipaca: hm, let me have a look
<morphis> Chipaca: no, sure. I don't see any reason for it to use SIGUSR1
<Gargoyle> zyga: All working fine again back on 4.15.
<Chipaca> morphis: ok, thank you
<zyga> Gargoyle: ack
<zyga> mvo: ack
<mborzecki> store hiccup?
<mup> PR snapd#5690 closed: Add an error code for Polkit auth cancels <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5690>
<zyga> mvo: do you know more about the details of the core18 mount issue that cachio mentioned?
<sergiusens> Chipaca: does the latest snapd in beta now default to setting the snaps in /var/lib/snapd/snaps to 600?
<Chipaca> sergiusens: yes
<sergiusens> Chipaca: this unfortunately breaks snap install snapcraft ....; mkdir project; cd project; snapcraft init; /snap/bin/snapcraft cleanbuild
<Chipaca> sergiusens: <3 you're using beta!
<sergiusens> Chipaca: not me... I got burned by beta already :-P
<Chipaca> sergiusens: boo :-(
<sergiusens> not on my main machine at least, I rely on too many snaps to get my work done that if anything breaks I would need to use my cellphone until I bring back my computer from backup
<sergiusens> Chipaca: how many snaps do you rely on for day to day work ;-)
<mborzecki> damn, was looking for bugs in snapstate.refreshCandidate(), found i'm not setting parallel-instances feature flag
<popey> i too have been burned this morning by this
<popey> should I refresh core to stable, or something else?
<Chipaca> sergiusens: ~5 :-)
<sergiusens> Chipaca: my only installed browser and code editor are from snaps :-)
<popey> every application i have open is a snap
<Chipaca> sergiusens: popey: you're awesome
<jdstrand> zyga (cc mvo and Gargoyle): it was a kernel *fix*
<zyga> jdstrand: I see, is it upstream now?
<jdstrand> Gargoyle: if you update to snapd 2.35, it will work
<Gargoyle> ahh. OK. Thanks.
<jdstrand> zyga: is what upstream? the kernel fix? yes, it is in 4.18. there is a fix for this in snapd 2.35 already. there is additional work to only add the trace rule conditionally, but that needs kernel upstreaming (but is not a problem for snapd, it is just hardening)
<zyga> ok
<jdstrand> https://forum.snapcraft.io/t/snaps-are-not-working-with-linux-kernel-v4-18-rc/6708/3
<mborzecki> going to pick up the car, bbl
<Chipaca> https://www.reddit.com/r/Ubuntu/comments/992mcd/help_snaps_are_using_all_my_data/ fwiw
 * Chipaca pushes a "EAT MORE DATA" PR
<pstolowski> so, re system snap name - hotplug needs to know where to attach hotplug slots to; there needs to be one authoritative helper that does return snapinfo for the system i think. what kind of logic do we need for that, should these slots live on "snapd" snap if available?
<Chipaca> sergiusens: so, about files being 0600, what can we do?
<Chipaca> sergiusens: you were there when we decided to do this :-)
<sergiusens> Chipaca: the alternatives are: break everything, wait on the release until we add logic for this or revert the change
<sergiusens> Chipaca: yes, but the when was not decided :-)
<sergiusens> Chipaca: I was also there when we decided on the first version of epochs, it lives in snapcraft to this date ;-)
<Chipaca> sergiusens: it really sounds like you're asking for a waterfall process with deliverables and stuff which ain't gonna happen
<Chipaca> :-)
<Chipaca> sergiusens: hold on
<Chipaca> sergiusens: this came about because, in _some_ situations, files were already 0600
<sergiusens> yes, the ones with x
<Chipaca> sergiusens: so you already have a workaround for those?
<sergiusens> so, snaps with no assertions
<sergiusens> yes, if the revision starts with x, sudo comes into play
<Chipaca> ah
<Chipaca> sergiusens: given the alternatives, we need to involve mvo and niemeyer
<zyga> pstolowski: I'm going for lunch now, sorry; took a break to sync with family
<Chipaca> sergiusens: so, a proposal
<Chipaca> sergiusens: as a temp fix, make it always use sudo for that step (I'd like to see how it uses sudo, just in case)
<Chipaca> sergiusens: then, maybe in 2.36 we can add something that lets you stream the snapfile given some constraints
<Chipaca> sergiusens: how does that sound?
<sergiusens> Chipaca: all the new code is already resilient, it is this old stuff, which everyone uses that will break
<sergiusens> requesting sudo for non corner case will suck though
<Chipaca> sergiusens: what's the code that does this?
<sergiusens> Chipaca: it still begs the question, will you wait until that makes it into general availability?
<Chipaca> sergiusens: I am not the one that decides that
<Chipaca> ah, found the code
<sergiusens> Chipaca: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/lxd/_containerbuild.py#L345
<Chipaca> hmm
<Chipaca> sergiusens: when I run snapcraft from master things just worked
<Chipaca> sergiusens: what's the snap doing differently?
<sergiusens> Chipaca: injection is when running from the snapcraft snap
<Chipaca> ah, i guess that's common.is_snap() == False and the other path
<Chipaca> sergiusens: unrelated question about this code
<Chipaca> sergiusens: I see the watch for auto-refresh, but i don't see the refresh.hold; is that done?
<sergiusens> Chipaca: for the new code
<mborzecki> re
<Chipaca> mborzecki: wb
<sergiusens> Chipaca: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/build_providers/_snap.py#L263
<Chipaca> mborzecki: do you remember if we check metered for the catalog refresh?
<sergiusens> I asked you to look at the PR 2 weeks ago :-)
<mborzecki> Chipaca: we probably don't
<Chipaca> sergiusens: does it still need a look?
<sergiusens> it is already in master, but yeah, a look never hurts
<Chipaca> sergiusens: but the _containerbuild.py does not do/use that/
<Chipaca> ?
<mup> PR snapd#5670 closed: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5670>
<sergiusens> Chipaca: it does not, I can point release that in the future
<cachio> mvo, should I run sru for 2.35 after beta validation?
<Chipaca> mvo: note sergiusens says we might want to hold off on 2.35 until snapcraft is ready for it
<Chipaca> sergiusens: getting back to containerbuild, why would using sudo suck that much?
<mvo> cachio: yeah, that wouldbe great. is it accepted into -proposed yet? if not we need to ask apw to have a look if snapd can go into -proposed
<sergiusens> Chipaca: because it previously was not requested, that's all
<mvo> Chipaca: oh, tell me more please
<sergiusens> Chipaca: I will work on a fix
<Chipaca> mvo: the 0600 snaps means 'snapcraft cleanbuild' fails for snapped snapcraft
<mvo> ok, when does snapcraft plan to push the update?
<Chipaca> mvo: we were still discussing what to do about it
<sergiusens> mvo: we need to write a fix first
<mvo> sergiusens: heh, ok
<Chipaca> mvo: I flagged you and niemeyer above, but it's just been the two of us
<mvo> sergiusens: sorry, i missed that
<mvo> sergiusens: this sounds like its a couple of days away? with qa and pushing a new release and all that?
<Chipaca> mvo: the easy fix sucks for users
<mvo> yeah
<mvo> sudo is not great
<Chipaca> to be clear, it was already using sudo before, just in more cornery-cases (sideloaded files were already 0600)
<sergiusens> mvo: provided that I have been running adt to push a new snapcraft for a week and just did dput I am not so confident
<sergiusens> but yeah, as soon as possible
<Chipaca> mvo: and then the question is, what can snapd do to make it better
<cachio> mvo, sure, I'll try to promote to candidate 2.35 today and then I'll start with thtat
<niemeyer> sergiusens, Chipaca: How about using download?
<mvo> sergiusens: I share the adt pain
<mvo> sergiusens: but yeah, that sounds unfortuante, maybe we need to remove this change on our side and re-add on 2.36
<mvo> cachio: thank you!
<Gargoyle> jdstrand: Will 2.35 be made available via standard packages for 18.04, or do you have to add a ppa to get the latest version?
<sergiusens> niemeyer: I will try download first, it will remove the possibility to inject the currently sideloaded snap (if it existed) but would solve the greater use case
<niemeyer> sergiusens: Not necessarily
<niemeyer> sergiusens: But possibly, at least for now
<niemeyer> sergiusens: I really hope we can stop special casing the "snap download" command.. it's only caused us pain
<niemeyer> sergiusens: When that happens, we can make "snap download" pick up content from the cache.. that's already done for internal operations
<sergiusens> niemeyer: oh, I am not asking for that :-)
<niemeyer> sergiusens: Right, I'm the one suggesting it...
<sergiusens> niemeyer: ð
<sergiusens> I will work on a fix and get a review from Chipaca
<Chipaca> I'll make sure to forget to review it
<zyga> Pharaoh_Atem: hey
<zyga> Pharaoh_Atem: I think we need your help
<mup> PR snapd#5413 closed: tests: purge packages installed by accounts, calendar, and contacts interface tests <Created by jhenstridge> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5413>
<mup> PR snapd#5697 opened: overlord/snapstate: fix UpdateMany() to work with parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5697>
<mborzecki> pedronis: ^^
<pedronis> mborzecki: thanks, I will look at it tomorrow
<mborzecki> pedronis: great, thank you!
<jdstrand> Gargoyle: it will be made available to 18.04, but since you are on Ubuntu, you can simply do: sudo snap refresh core --beta
<zyga> niemeyer: hey, could you please refresh spread the snap to the current release please?
<Chipaca> niemeyer: i'm missing something wrt patch sublevels i'm afraid
<Chipaca> niemeyer: if a user refreshes from pre-sublevels to a revno with sublevels, and then goes back, what makes the sublevel patch run again when they come back back?
<ogra> whee !
<ogra> i actually managed to get my wmx gui session into a confined state !
<pedronis> Chipaca: we need a breaking patch to introduce them? :/
<Chipaca> ogra: does your gui have a red button that says 'exec' on it
<ogra> jdstrand, i'd appreciate if you could unleash wmx-kiosk-session in the snap store ... its another Xwayland snap that uses the loopback x11 setup (similar to xdmcp-client) and got stuck in review
<pedronis> Chipaca: or maybe not breaking, but a release that just reset them on start
<Chipaca> pedronis: we could also edit the patchlevel on exit
<Chipaca> pedronis: i mean, on downgrade, it's  snapd doing the downgrade
<pedronis> but we don't easily know the patchlevel of the old thing
<ogra> Chipaca, https://imgur.com/a/HuXpmJh
<ogra> no red
<Chipaca> ogra: http://okcancel.com/comic/4.html
<ogra> (but i could add some red ... :) )
<ogra> lol ... i love the kill -9 in green :)
<mvo> Chipaca: an early sniff test of https://github.com/snapcore/snapd/compare/master...mvo5:use-proxy-conf?expand=1 would be great, I will expand and add tests, also ideas where the proxy handler should life would be great (maybe the place is ok)
<mvo> Chipaca: hey, disconnected, sorry. did you get my earlier message
<Chipaca> mvo: I got it but I hadn't seen it
<Chipaca> mvo: looking now
<mvo> Chipaca: thanks, no worris
<Chipaca> mvo: that looks nice
<mvo> Chipaca: yeah, I'm not sure where proxyHelper should live but beside that it just needs some polish and should be good to go
<Chipaca> mvo: ttfn! see you tuesday!
<jdstrand> ogra: ok
<niemeyer> chihchun_afk: Reviewed the PR>. not sure if it clarifies your question
<niemeyer> chihchun_afk: Sorry.. wrong nick
<ogra> popey, now confined and shipping all basic x11 apps in the snap https://imgur.com/a/s47MQOw
<ogra> (though you can indeed not use "snap run" anymore with that)
<ogra> (unless you explicitly switch to --devmode)
<Pharaoh_Atem> zyga: wut, what?
<zyga> Pharaoh_Atem: there are some selinux issues with socket activation of services installed from snaps
<zyga> Pharaoh_Atem: do you have some time to look into that?
<Pharaoh_Atem> not right now
<niemeyer> sergiusens: What happened here:
<Pharaoh_Atem> I'm really compressed and I'm trying to squeeze time to update snapd right now
<niemeyer> https://www.irccloud.com/pastebin/dPnQNNkp/output.txt
<Pharaoh_Atem> zyga: I suspect that this is the consequence of not generating policies here
<niemeyer> sergiusens: This snap get command doesn't make much sense...
<Pharaoh_Atem> the socket path used isn't covered in the domain of snappy run applications and services
<niemeyer> sergiusens: This was the snapcraft.yaml I've been using since I started packing spread as a snap
<zyga> Pharaoh_Atem: mmm
<Pharaoh_Atem> because properly packaged lxd works fine
<niemeyer> sergiusens: The plugin can't be much simpler than this:
<Pharaoh_Atem> as the SELinux policy for container runtimes already supports LXD when built and installed normally
<niemeyer> https://www.irccloud.com/pastebin/CltIdxY9/
<niemeyer> Sorry, I mean the part
<Pharaoh_Atem> the fact that no one upstream is interested in bringing LXD to Fedora as a native package is beside the point, though
<zyga> Pharaoh_Atem: is there something that needs to happen in the snapd policy or is this something to correct in the main policy?
<Pharaoh_Atem> zyga: I'm not sure
<Pharaoh_Atem> do we have a strict rule about where sockets are created for snapped services?
<sergiusens> niemeyer: that does indeed look correct, we have not made any changes as of late to any of this.
<Pharaoh_Atem> and the other question, how do we enforce the label being set?
<zyga> Pharaoh_Atem: I don't know
<niemeyer> sergiusens: Weird.. I wonder what's going on.. the command there makes little sense
<Pharaoh_Atem> zyga: without answers to these things, this is going to be very hard
<niemeyer> 2.41 shows the same error
<zyga> mm
<sergiusens> niemeyer: can you point me to the full repo?
<niemeyer> sergiusens: https://github.com/snapcore/spread/
<niemeyer> sergiusens: Woah
<niemeyer> sergiusens: There's apparently a serious bug there.. It seems to be getting the local source instead of checking out the remote package
<sergiusens> niemeyer: paste.ubuntu.com/p/DTK8DxVXZ6/ the problem is related the fact that source is implicit and defaults to "." (I have made it explicit in that diff). It is one of the things I wanted to bring up as a requirement with the move to bases. The next entry is since the source is not in a fully qualified import path,we need a way to know where it lives. If we removed the implicit source, your snapcraft.yaml will work collocated in there
<niemeyer> sergiusens: This snapcraft.yaml worked...
<niemeyer> sergiusens: Which means something changed in a breaking way
<sergiusens> niemeyer: that implicit source has been there for over two years, so the only thing I can think of is that it was collocated with the source just recently
<niemeyer> sergiusens: Well, maybe I'm just crazy then, and it has been doing something other than what I assumed since forever
<niemeyer> Which is a real possibility
<sergiusens> this is on my list of things to fix without breaking the older plugins for a while now
<sergiusens> fwiw, I do not like this behavior of implicit source
<niemeyer> sergiusens: I can see how it's nice when that's what you want, on something simple
<niemeyer> sergiusens: But this particular case makes it error prone because we _seem_ to request a particular URL, but not really
<sergiusens> niemeyer: but it leads to confusing things like this, we have also had the same comment from people using npm and yarn
<niemeyer> Yeah
<sergiusens> niemeyer: I'll write up a proposal on the forum for the behavior and send your way
<niemeyer> sergiusens: Thanks!
<zyga> success! spread works for me again
<zyga> man, I need to figure out why now
<niemeyer> zyga: You got it
<niemeyer> spread, that is
<niemeyer> pstolowski|afk: And you got a review for the patch sublevel PR, but you're rightfully out of here already
<niemeyer> As should I be
<niemeyer> In fact, here I go.. o/
<zyga> niemeyer: thank you! I'll give it a try after this run
<zyga> niemeyer: I was trying to get locally built copy to work
<zyga> mvo: hey, still around\
<zyga> mvo: I just wanted to comment about the extrausers topic
<zyga> mvo: if you are around, I'd love to share that thought that I had during the standup
<mispp> hey all, a question if i may. is it possible to define which g++ and which qt5 version is used when building snaps?
<zyga> mispp: I believe that you can craft a makefile and define CC and CXX and just use that
<zyga> mispp: snaps are not opinionated and snapcraft allows for a lot of flexibility
<mispp> well, i can build snap on my own box with ubuntu 18.04, works perfectly
<zyga> mispp: you just need enough of the dependencies to use that compiler
<mispp> but now i'm trying to set up build.snapcraft.io
<mispp> to pull directly from github
<mispp> and it fails probalby because of the same reason why "snapcraft cleanbuild" fails - too old g++/qt5
<zyga> mispp: because on your 18.04 machine you are using your local tools for building; snapcraft builder uses a virtual machine or a container with ubuntu 16.04 there
<zyga> mispp: as a simple answer you will be able to use core18 instead of core16 (aka core) to use the more recent toolchain
<mispp> alright, googling
<zyga> mispp: please try core18 instead, I personally haven't used snapcraft for building apps against core18 (I use hand-crafted tools because we are building things before the other tools are ready),
<zyga> mispp: try just adding "base: core18"
<zyga> mispp: I don't know if that is supported end-to-end
<zyga> mispp: but that declaration conveys multiple things: that the application will run against a ubuntu 18.04-based runtime
<zyga> and that the application should be _built_ against such environment as well
<mispp> thanks for the concerns, but this is still development what i'm trying
<mispp> so even if it doesnt work, no harm done
<ogra> note though that nothing binds you to any ubuntu release thoug, you can craft a snapcraft.yaml that even builds a toolchain, compiler and Qt from soucre if you want
<mispp> i'm not that skilled that i can pull this off, so i'd rather try core18 if it works
<mispp> where can i find this in docu?
<popey> ogra: nice!
<ogra> (it surely is a lot effort and will massively increase build time, but snapcraft is flexible enough that you can build all bits you want to ship from source)
<zyga> mispp: not sure, sorry, being on the front lines is not doesn't give me the right perspective
<zyga> mispp: just put "base: core18" into your snapcraft yaml and build that
<zyga> I'm going for a bike ride while it's not pitch black
<zyga> bbl
<mvo> zyga: I'm around
<mup> PR snapd#5695 closed: osutil/sys: small tweaks to let it build on darwin <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5695>
<mup> PR snapd#5698 opened: osutil: reorg and stub out things to get it building on darwin <Created by chipaca> <https://github.com/snapcore/snapd/pull/5698>
<mispp> core18 doesnt work, still uses old toolchain
<mispp> also ... error: cannot find app "goat" in "goat"
<mispp> i guess apps part was missing
<mup> PR snapd#5699 opened: overlord,store: support proxy settings internally too <Created by mvo5> <https://github.com/snapcore/snapd/pull/5699>
<mispp> cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
<mispp> what's this about?
<zyga> re
<zyga> mispp: are you on 4.18?
<zyga> mispp: I believe this is one of the bugs that is fixed in mainline / snapd 2.35
<kyrofa> zyga, snapd supports automatically starting snap apps on login, right? Do we have docs for that?
<kyrofa> All I see is https://forum.snapcraft.io/t/how-to-autostart-a-snap-of-a-desktop-application/2449/33, which pretty much tells me nothing
#snappy 2018-08-22
<mborzecki> morning
<mup> PR snapd#5694 closed: tests/main/layout: cleanup after the test <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5694>
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mvo> zyga: can I merge 5307?
<mvo> zyga: I would like to squash it, I would love to cherry pick this to 2.35 to fix core18s extrausers
<mborzecki> mvo: could you take a look at https://github.com/snapcore/snapd/pull/5614 ? tha's a small change to the code + some tests
<mup> PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614>
<mvo> sure
 * mvo looks
<mborzecki> mvo: thanks!
<mvo> mborzecki: added some comments, sorry probably not strictly related to your pr but it seems its a good opportunity to improve this area
<mborzecki> mvo: thanks, looking
<mup> PR snapd#5698 closed: osutil: reorg and stub out things to get it building on darwin <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5698>
<zyga> good morning!
<zyga> mvo: looking
<mvo> zyga: thanks
<zyga> mvo: while jamie did not comment on the final look of the branch he didn't -1 the earlier version that wasn't much different
<zyga> mvo: so I think yeah but the final call is up to you
<zyga> mvo: in case jamie objects after the fact we can always roll out a .1
 * zyga had a small success by waking up the kids two hours earlier than usual
<mborzecki> zyga: hey
<zyga> hey hey
<mvo> zyga: ok, I see. hm,hm
<zyga> jamie mentioned he was going to look at it
<zyga> so it's in his queue
<zyga> while fighting spread yesterday (the unexpected failure I saw over and over) I refreshed all of the images on https://spread.zygoon.pl/images/
<zyga> I'm wondering why they grow so much though, 18.10 is 2.5x bigger than 14.04
<mborzecki> zyga: maybe 1G of it is all 0s
<zyga> the images are qcow2, that would not be needed
<zyga> and indeed they are not zero as they took a while to send there
<mborzecki> zyga: maybe cached packages were left behind?
<zyga> mborzecki: hmm, maybe but I used the same tool for all of those
<zyga> I'll jump into those images if I have some time
<zyga> I was just curious
<mborzecki> zyga: a trick i use to be able to quick revert back to the clean image is to do a clean install, then use that image a backing file for qcow2 images, then you just have the diff images that you can rebase/commit once they are good enough
<zyga> mborzecki: how do you rebase/diff things?
<zyga> I never did that myself
<mborzecki> qemu-img create -f qcow2 -b your-clean-install.img img-with-diff.img; do stuff inside, then qemu-img commit to move the changes back to the original image, or qemu-img rebase if you have an image chain
<mborzecki> zyga: real life saver in case you screw up the os in the image at some point :P
<zyga> interesting, and are the images aware of each other directly or do I need to tell qemu to use a chain somehow?
<mborzecki> zyga: it's recorded in the image file
<zyga> brb
<mborzecki> mvo: pushed the changes to https://github.com/snapcore/snapd/pull/5614
<mup> PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> wonder if i could push the parallel-installs-interfaces spread test to 5614
<zyga> re
<mborzecki> got to go out for a while, back in ~1h or so
<Gargoyle> zyga: jdstrand: Same problem with snap 2.35 and kernel 4.18.3. :-/
<zyga> can you provide the detailed denial please?
<mborzecki> re
<Gargoyle> Just trying to get it to spit one out
<zyga> mvo: review on 5699
<mvo> zyga: thanks, looking
<mvo> zyga: thanks for the review, I will fix the issue(s)
<zyga> did you mean the sleep 1h?
<zyga> that was the most curious thing to me
<mvo> zyga: I replied, no I did not, I hit the wrong key
<mvo> zyga: or maybe a freudian slip, my mind wanted to go to sleep for 1h (at least ;)
<zyga> haha :-)
<mvo> zyga: replied, I will look into alternatives to squid I think, something in a snap
<Gargoyle> zyga: These are the only messages from "dmesg -w" while I ran "snap remove lxd" (which doesn't seem to have worked) and "snap remove postman", "snap install postman" which both seemed to work fine, but postman is not available to run.
<Gargoyle> https://paste.ubuntu.com/p/Z5C742DfZ8/
<zyga> Gargoyle: STATUS messages are just information, they are not a denial yet. What happens when you install and run the "hello-world" snap?
<mborzecki> mvo: pushed a spread test for parallel instances & interfaces to #5614
<mup> PR #5614: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5614>
<Gargoyle> zyga: No errors from snap - seems to have installed fine, but I have no "hello-world" command to run. (Syslog output during the installation: https://paste.ubuntu.com/p/jgDwrkyK4k/)
<zyga> how about snap run hello-world
<mup> PR snapd#5700 opened: tests: significantly reduce execution time for managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5700>
<Gargoyle> zyga: Yup. That works!
<zyga> ok
<zyga> Gargoyle: can you try the snap you wanted to use before
<Gargoyle> "snap run postman" works too.
<Gargoyle> same for discord.
<zyga> so the issue is fixed?
<Gargoyle> Oh. No.
<zyga> so what is the issue?
<Gargoyle> They only work with "snap run discord". I cannot run just "discord" nor do they show in gnome.
<zyga> log out and back in
<Gargoyle> ok
<Gargoyle> No joy. And now not even happy booting back into 4.15 kernel! :/
<zyga> welcome back, so what happened?
<Gargoyle> same situation. "snap run discord" works, but as far as the rest of the system is concerned, discord doesn't exist. Same for postman.
<zyga> so gnome doesn't see the application, right?
<zyga> what does "which discord" tell you?
<Gargoyle> correct
<Gargoyle> "discord not found"
<zyga> and what does "echo $PATH" print?
<Gargoyle> . /home/paul/bin:/home/paul/.composer/vendor/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
<zyga> Gargoyle: interesting, are you setting PATH in your startup scripts anywhere? it seems to be influencing the default value that ought to also include /snap/bin/
<Gargoyle> zyga: Only in .zshrc where I have: "export PATH=$HOME/bin:$HOME/.composer/vendor/bin:/usr/local/bin:$PATH"
<zyga> ah, you are using zsh
<zyga> perhaps that's the reason stuff is not working for you
<Gargoyle> yup
<zyga> mborzecki: once you are back, do you remember if we had a way to inject environment into zsh; I recall a new systemd feature but I don't know if we ended up using it
<mborzecki> zyga: iirc mvo came up with something that was shell agnostic
<mborzecki> Gargoyle: are you using konsole by any chance?
<zyga> Gargoyle: can you please do one more experiment, switch to bash, check of this fixes it; it will helps us scope the issue to just zsh
<zyga> then we can go after that separately from any kernel issues
<mvo> zyga: environment.d
<zyga> mvo: anything I can man search for; I don't remember the details
<mborzecki> updated arch package to 2.35
<Gargoyle> mborzecki: Nope. Default Gnome terminal
<Gargoyle> zyga: yup. One sec
<zyga> Gargoyle: I switched to zsh now, checking what shows up
<mup> PR snapd#5701 opened: image: add type to seed.yaml to allow sorting in firstboot <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5701>
<mborzecki> Gargoyle: are you on ubuntu?
<mvo> pedronis: high level feedback on -^ would be great. if this looks sensible I will continue this path otherwise derive in firstboot
<zyga> hm
<zyga> I switched to zsh and I cannot log in
<Gargoyle> mborzecki: Yup
 * zyga wonders
<mborzecki> Gargoyle: can you post /etc/zsh/zprofile ?
<Gargoyle> No difference in bash.
 * zyga can log in now
<zyga> Gargoyle: I suspect you may need to reboot
<Gargoyle> mborzecki: Nope. It doesn't exist. /etc/zsh/zprofile is just comments, too.
<zyga> depending on how early the profiles are picked up
<zyga> Gargoyle: I confirm that there's no /snap/bin in PATH now
<zyga> and that will also explain why gnome shell doesn't see any snap apps
<mborzecki> zyga: in zsh on ubuntu?
<zyga> I'll reboot my system now and then look at environment.d
<zyga> mborzecki: I switched to zsh yes
<mborzecki> zyga: yeah, so there's a problem that ubuntu's zsh setup does not source /etc/profile files (while it does so on arch for instance)
<mvo> zyga: fwiw, we added /usr/lib/environment.d/990-snapd.conf
<zyga> mvo: I'll rebuild the package and see if it is used
<mborzecki> zyga: iir there's a bug report for this, from ogra maybe?
<zyga> thanks!
<zyga> mvo: yes, that works!
<zyga> I have /snap/bin at the end of path
<zyga> and I see snaps in gnome shell
<zyga> Gargoyle: I'm running 2.35 from package built from master, reexec won't give you all of that yet
<zyga> I'll rebuild the release branch
<mvo> zyga: this is in 2.34.2 already so should be ok
<zyga> I see
<mvo> (sorry, haven't followed the previous discussion so I may miss things)
<zyga> Gargoyle: what's the version of the debian package you have, you can check with "apt-cache policy snapd"
<Gargoyle> brb, rebooting
<zyga> k
<ogra> mborzecki, not mine, but i was active in it ...
<mborzecki> zyga: https://forum.snapcraft.io/t/gnome-3-shell-snaps-integration/2678/12
<ogra> bug #1640514
<mup> Bug #1640514: /snap/bin is not added to the PATH when using zsh <patch> <Snappy:New> <snapd (Ubuntu):Confirmed> <zsh (Ubuntu):Confirmed> <https://launchpad.net/bugs/1640514>
<ogra> and along with that bug #1637220
<mup> Bug #1637220: zsh has no /snap/bin in PATH <snapd (Ubuntu):Triaged> <zsh (Ubuntu):Confirmed> <https://launchpad.net/bugs/1637220>
<zyga> thank you ogra
<zyga> I will update those bugs
<ogra> well, the fix only helps if people actually went to 18.04
<ogra> so leave the 16.04 tasks open
<zyga> ogra: yeah, this does depend on recent enough systemd, right?
<ogra> right
<zyga> how do I add 16.04 task?
<ogra> nominate foir series
<zyga> how do I do that
<zyga> I never did that before, I may not have rights to do that
<ogra> there is a link
<Gargoyle> zyga: https://paste.ubuntu.com/p/jGgcYf8DX5/
<ogra> everyone can nominate
<ogra> approving the nomination is restricted ...
<zyga> what do I need to click on, there's no "nominate" on the page
<zyga> Gargoyle: so that seems ok
<zyga> Gargoyle: I wonder what's different between our installations
<ogra> zyga, done
<zyga> ogra: what did you do :)
<ogra> (the link right underneath the bug tasks with the little clock icon)
<Gargoyle> OK. Purged 4.18 from the system, force re-installed 4.15 and reverted back to "snap core --stable". and my $PATH is back! https://paste.ubuntu.com/p/YSNyg67xP4/
<ogra> next to "Also affects distribution/package"
<zyga> aha
<zyga> ogra: hmmm,
<zyga> ogra: I don't see that icon, I only see it now after you did the nomination
<ogra> weird, thats a common function that everyone should have access to
<ogra> nomination isnt restricted ... only approving the nomination is
<Gargoyle> Only thing I can't do is remove lxd properly (so I can re-install) : https://paste.ubuntu.com/p/Rfr9gnSdQk/
<mup> Bug #1640514 changed: /snap/bin is not added to the PATH when using zsh <patch> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <zsh (Ubuntu):Invalid> <snapd (Ubuntu
<mup> Xenial):Confirmed> <zsh (Ubuntu Xenial):Invalid> <snapd (Ubuntu Bionic):Fix Released> <zsh (Ubuntu Bionic):Invalid> <https://launchpad.net/bugs/1640514>
<zyga> Gargoyle: you may need to stop the containers first but I defer to stgraber
<ogra> zyga, also ... i dont think it is invalid in zsh xenial ... the fact that environment handling got improved doesnt fix the fact that zsh's env handling isnt using standards
<zyga> yeah but for _this_ bug I think it is invalid now
<mborzecki> zyga: hm so i dropped /etc/profile.d/snapd.sh, and have only /usr/lib/environment.d/990-snapd.conf, and I don't see $SNAP_MOUNT_DIR/bin being added to my PATH
<Gargoyle> I've used zsh since day 1, and not had problems.
<zyga> mborzecki: I'm rebuilding 2.35 now from the release branch
<zyga> I'll know soon :)
<mborzecki> zyga: i'm on 2.35 on arch now ;)
<zyga> maybe packaging skew?
<zyga> mborzecki: 2.35 still has /etc/profile.d/apps-bin-path.sh
<zyga> but also has /usr/lib/environment.d/990-snapd.conf
<mborzecki> zyga: yesh, removed that manually here to check if environment.d works
<zyga> mborzecki: interesting, only PATH is set, XDG_DATA_DIRS is not set at all
<mborzecki> zyga: oh, so you do have PATH set in your setup via environment.d?
<zyga> mborzecki: I _suspect_ so because I have empty profiles otherwise, let me reboot to check
<ogra> zyga, well, if you prefer to put the blame on snapd ... :) (people come back to that bug when they hit the issue in 16.04... )
<mborzecki> zyga: can you do systemctl --user show-environment | grep PATH ?
<zyga> mborzecki: sure, one sec
<zyga> fyke% systemctl --user show-environment | grep PATH
<zyga> PATH=/home/zyga/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
<zyga> WINDOWPATH=1
<mborzecki> zyga: heh, you have snap there, I don't :)
<zyga> mborzecki: what do you have in /etc/environment.d
<mborzecki> zyga: nothing, the file goes to /usr/lib/environment.d/ by default
<zyga> ah sorry
<zyga> I meant that one
<zyga> what do you have in /usr/lib/environment.d/990-snapd.conf
<zyga> did you reboot after installing that update?
<mborzecki> zyga: yup
<mup> PR snapd#5701 closed: image: add type to seed.yaml to allow sorting in firstboot <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5701>
<Gargoyle> Any ideas how I can get rid of my "disabled,broken" lxd snap? https://paste.ubuntu.com/p/G2d9XV5Tx5/
<mborzecki> zyga: hmm https://bugs.archlinux.org/task/56716 uhh and https://bugs.archlinux.org/task/56683 and https://bugs.archlinux.org/task/47884 looks like PATH is overwritten on arch in /etc/profile
<zyga> mmm, can you snap install lxd
<zyga> and then remove all the containers
<zyga> and then remove it again?
<Gargoyle> nope. it thinks its already installed. "snap "lxd" is already installed, see 'snap help refresh'"
<zyga> mborzecki: uh
<zyga> Gargoyle: and snap remove lxd?
<zyga> mborzecki: I'm happy systemd helps to clean up this mes
<zyga> mess
<Gargoyle> zyga: That's in that pastebin. Complaining about readonly filesystem
<zyga> Gargoyle: can you reboot again, I suspect some things are mounted there; you can try to unmount them or just reboot (maybe, no promises)
<Gargoyle> I'll give it a whirl, but it;s been broken for the last few reboots already
<zyga> ah
<zyga> then wait
<zyga> check what is mounted
<Gargoyle> Maybe I am not seeing the wood for all the trees:- https://paste.ubuntu.com/p/D2j94chnMd/
<zyga> hmm
<zyga> I don't see anything
<zyga> what is in /var/snap/lxd
<Gargoyle> "common"
<zyga> and inside?
<Gargoyle> it goes all the way along: /var/snap/lxd/common/lxd/storage-pools/default/images/de2ea148defc21d223376e53ab10ff1bccd003d92d5e6c6822398494ad934859 . No sign of a symlink anyhwere
<zyga> and you cannot rm -rf that yourself, right?
<Gargoyle> nope. Not even as root
<zyga> I think you may need to ask stgraber for help
<zyga> maybe it's a zfs pool or something
<zyga> I don't know exactly
<zyga> opk
<zyga> I need to jump into some code
<Gargoyle> Save me, stgraber. You're my only hope! :P
<pedronis> mvo: I commented on #5701, I still think we should do it in firstboot code
<zyga> mborzecki: about environment.d
<zyga> mborzecki: we don't set XDG_DATA_DIRS
<mup> PR #5701: image: add type to seed.yaml to allow sorting in firstboot <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5701>
<mborzecki> zyga: something fishy on arch, by the time it gets to /etc/profile the PATH does not contain any sign of snap
<zyga> mborzecki: I think we should, right/
<mborzecki> zyga: yeah, i think so
<zyga> I'll try to change that
<mvo> pedronis: yeah, I noticed and already closed it. thanks for the quick feedback
<mup> PR snapd#5702 opened: snap: add ByType sorting <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5702>
<mvo> zyga: we need a snapd type, one issue is that we need a patch for it, i.e. if snapd is already installed we need to transition it
<mvo> zyga: maybe we can get away without
<zyga> mvo: reviewed
<mvo> zyga: given that core18 is not stable yet and its not instalable anywhere else
<zyga> mvo:why would we need a patch?
<mvo> zyga: if you have snapd installed already
<zyga> mvo: I mean, it's just snap info that would change
<zyga> ah
<zyga> I see
<zyga> yeah
<zyga> well
<mvo> zyga: but yeah, I would love to add it
<zyga> we could do in memory tweak
<zyga> because it's clear it's special case
<mvo> zyga: aha, nice idea, that would be a nice way out
<zyga> and special casing on name or snap id as in other parts is clearly showing its cost
<zyga> mvo: yeah, would not break rollback
<zyga> so anyway
<zyga> +1 but I wanted to voice that
<mvo> zyga: ok, I will do it
 * zyga hugs mvo 
 * mvo hugs zyga
<zyga> let's add a type in one pr
<zyga> and then tackle the issues like in-memory migration
<zyga> and various uses
<zyga> (so let's land this one as is)
<mvo> zyga: yeah, I agree
<mvo> zyga: I am in the middle of something else (firstboot ordering) but once that is done I will do the cleanup
 * zyga nods
<zyga> I'll jump into something too but please drag me back when you are into it
<mvo> zyga: thanks, will do
<mborzecki> zyga: can you post your /etc/profile?
<zyga> probably vanilla /etc/profile from bionic https://www.irccloud.com/pastebin/cCczVjri/
<zyga> mborzecki: note that we also have /etc/profile.d/
<mborzecki> zyga: can you grep -n systemd-environment /etc/profile.d/* ?
<zyga> empty
<zyga> (I mean, I ran: grep -n systemd-environment /etc/profile.d/*)
<zyga> unless you meant something more
<mborzecki> zyga: no, that's fine, I have no clue how stuff from systemd-environment-d-generator gets to your session then
<zyga> I rebooted
<zyga> I think it's set by systemd when it starts the session proceses
<zyga> is arch using systemd as a session manager?\
<zyga> brb, getting hungry over essentially no breakfast
<mborzecki> zyga: yeah, the manpages are not too helpful either
<pstolowski> https://www.irccloud.com/pastebin/IzURDL3V/
<pstolowski> zyga: ^ i suspect this is known? i've seen it some time ago; now failed on fedora
<pstolowski> zyga: travis log - https://api.travis-ci.org/v3/job/418670092/log.txt
<mup> PR snapd#5702 closed: snap: add ByType sorting <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5702>
<niemeyer> Heyo
<niemeyer> Chipaca: Moin
<Chipaca> niemeyer: hi
<Chipaca> niemeyer: ssh, I'm not here
<niemeyer> Chipaca: Did the notes on the PR make the idea more clear, or do you still think we have an issue in terms of aptch sublevels
<niemeyer> Chipaca: Oh, is that a day off?
<Chipaca> niemeyer: I'm not sure it'll dtrt wrt reverts to a pre-sublevel snapd and back
<mvo> Chipaca: I can't read ssh without reading ssh (but I guess you meant ssssssh) - anyway, enjoy your day off
<Chipaca> mvo: i meant shh
<niemeyer> Chipaca: Ah, I see it is, sorry.. I had understood the holidays were next week on, sorry for the force disturbance.. :)
<Chipaca> niemeyer: no worries, I'm the one in the channel
<pedronis> mvo: I left a comment in 5702 about an open issue
<pedronis> though I saw you closed it
<mvo> pedronis: yeah, I was thinking about zygas comment
<mvo> pedronis: but maybe I just do that in a followup
<niemeyer> Chipaca: Well, I'm always on the channel as well :)  Anyway, the idea is that pre-sublevel patches are just like post sublevel patches.. the sublevel zero is the one that introduces backwards incompatible changes. So when a revert occurs, nothing is applied.. when the revert is undone to a more recent sublevel, the patches are reapplied
<niemeyer> Bye Chipaca :)
<mvo> pedronis: sorry for the flip-flop, I think I will reopen and just do a followup with the snapd type
<niemeyer> Anyway, the point is that I think we're good, unless I'm missing something
<niemeyer> We just need to be careful with non-zero sublevels as they need to be idempotent
<mup> PR snapd#5702 opened: snap: add ByType sorting <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5702>
<pedronis> niemeyer: how do we know we reverted,   sublevel unaware snapds will not touch patch-sublevel
<niemeyer> pedronis: The behavior across levels is still the same
<niemeyer> pedronis: 6 => 5 will blow up still
<mborzecki> zyga: mvo: fwiw the environment.d generator does not seem to have effect on fedora either
<pedronis> niemeyer: yes, but we cannot afford that, wasn't it the point of doing this
<niemeyer> pedronis: As will 7 => 6.X
<niemeyer> pedronis: No.. the point is that we can patch as 6.1, and have 6.0 untouched
<niemeyer> pedronis: Hmm.. I see.. 6.0 won't actually mark it back as 6.0, so we won't see 6.1 reapplied.. hmm
<pedronis> yes
<pedronis> the issue is the preexisting level 6 snapd out there already
<pedronis> (sorry I thought we were at 5 not 6 atm)
<pedronis> current level 6 snapd doesn't  know about sublevels
<niemeyer> Yeah.. that part is sort of okay.. the problem is how to detect when 6.1 is reinstalled that it needs to reapply.. :/
<pedronis> yes
<niemeyer> pedronis: Only choice I see is special casing 6.0
<niemeyer> Well, the whole 6 series really.. we'll never know whether a revert to a 6.0 happened
<niemeyer> Oh.. or will we
<pedronis> or do something like what chipaca suggested detect we are reverting to a pre sublevel core/snapd and reset sublevel before restarting
<pedronis> not super clear how to do the detecting though
<niemeyer> We might be nastier than that and look at the history.. we have it in the state
<niemeyer> Well, that sounds less nasty actually, in terms of proper isolation
<pedronis> you mean look at what was the previous revision?
<niemeyer> Right.. we have some good data available
<niemeyer> We have the history, and we have a refresh timestamp
<niemeyer> If the state level is 6, we can easily tell whether the refresh time was touched since the last restart, and if so whether we've been in a sublevel-blind revision recently
<niemeyer> All of that just looking at the state, which we have at hand
<niemeyer> pstolowski: ^
<niemeyer> The good thing is that we only need to kick that logic when the state level is 6
<pstolowski> reading
<pstolowski> niemeyer: right.. i understand the problem of reverting back to sublevel-blind 6.0... not yet clear on the details of proposed logic, will need to check the code
<pstolowski> btw, thanks for the review
<pstolowski> (i'm on it atm)
<pstolowski> pedronis: can you take a look at https://github.com/snapcore/snapd/pull/5700 when you have a moment?
<mup> PR #5700: tests: significantly reduce execution time for managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5700>
<pedronis> pstolowski: yes, in a bit
<pedronis> mborzecki: I'm not sure I understand  which tests need to switch to sorting by name 5697
<pedronis> mborzecki: I would really like that we switched to use code mvo is working on 5702, so IÂ would like to understand how strongly we need the change
<mborzecki> pedronis: this was just to ensure that tasksets get stable sorting
<pedronis> mborzecki: which tests fail without though?  the one you added, others?
<mborzecki> pedronis: the one i added
<pedronis> it's a bit bizarre because you need to play with the order of udpates anyway there
<pedronis> is that still true?
<mborzecki> pedronis: yes, it's still true, but those snaps are apps, so there have no inter-dependencies, the issue is caused by refreshCandidates and iterating on what snapstate.All() returns, which can have random order
<mborzecki> pedronis: fwiw the list of updated snaps returned by UpdateMany() is also random, but since I can easily tell which is which they are reodered in the test as needed
<pedronis> yes, but that makes the exercise bizarre
<pedronis> this list random, this one is sorted
<pedronis> because of tests
<pedronis> doesn't sound good as an api to me
<pedronis> also is sorted only if some kind of tasks are needed
<niemeyer> pedronis, pstolowski: I've detailed the algorithm in the PR
<Gargoyle> Fixed lxd. It was a btrfs subvolume. manually removed it with btrfs tools, and then re-enabled lxd and re-ran "lxd init". Seems happy now! :)
<Gargoyle> There's only one down-side...
<Gargoyle> Now I have to do some actual work! :P
<mborzecki> pedronis: well, technicaly it's not a regression, right now both updated snaps and tasks sets are randomly ordered, but i get your point
<mborzecki> pedronis: well, tasksets are semi semi randomly ordered, by kind, but then within the same kind it's random
<pedronis> IÂ know, IÂ don't see a problem with that atm
<pedronis> I'm just questioning making the order requirements more strict for a test
<pedronis> (given that it make some coming refactoring a bit harder)
<pedronis> and it doesn't really give a full ordered behavior to the api anyway (because is kind of hard)
<mborzecki> pedronis: is there a way to figure out which snap the taskset corresponds to aside from interrogating task summary of poking its data?
<pedronis> no, but is not so bad,  we poke at the data all over the place
<pedronis> in the tests
<pedronis> they are tests after all
<mborzecki> pedronis: well, maybe i could just expect one tasksets to be of some lengths, if there's other then signal an error, otherwise just use the legths to make the guess about the order
<mborzecki> pedronis: i'll revert that ordering change and 'll try to find another way
<pedronis> thanks
<pstolowski> niemeyer: ty
<pedronis> mborzecki: to be clear I agree that making output deterministic is best when is cheap and clear-cut, I don't think it's clear-cut here
<niemeyer> pstolowski: np, the whole series is unblocked.. we need to have a conversation about the third-level down PR when you get there, about the API of ConnectReload etc
<pedronis> mborzecki: btw adding a helper in snapstate_test that takes a taskset that is an install of some kind and gets the name of the snap is probably cheap and readable
<pstolowski> niemeyer: the algorithm you outlined looks fine, although i wonder if the introduction of snapd snap changes anything. i'm also wondering if the problem can be simplified, but can't  think of anything
<mborzecki> pedronis: will do, i'm looking into some update-ns issues atm
<pstolowski> mvo: applied you suggestion to  #5686
<mup> PR #5686: overlord/ifacestate: introduce connectOpts <Created by stolowski> <https://github.com/snapcore/snapd/pull/5686>
<mvo> pstolowski: thank you!
<mup> PR snapd#5703 opened: firstboot: sort by type when installing the firstboot snaps  <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5703>
<niemeyer> pstolowski: The snapd snap should support sublevels from the get go, so it shouldn't change much
<niemeyer> pstolowski: We do have it out already, but mainly for testing
<niemeyer> pstolowski: By the time this gets widely used, sublevels should be in already
<pstolowski> right
<mup> PR snapd#5704 opened:  snap: add new type "TypeSnapd" and attach to the snapd snap  <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5704>
<cachio> mvo, hey, core 2.35 was promoted to candidate yesterday
<pedronis> mvo:  maybe I'm just super confused, but I don't see the attaching code in #5704
<mup> PR #5704:  snap: add new type "TypeSnapd" and attach to the snapd snap  <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5704>
<mup> PR snapd#5705 opened: testutil: have File* checker produce more useful error output <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5705>
<mborzecki> simple review ^^
<cachio> niemeyer, hey, there is a PR to review on spread https://github.com/snapcore/spread/pull/66
<mup> PR spread#66: Define storage at system level <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/66>
<cachio> niemeyer, please when you have time could you take a look to that?
<pedronis> pstolowski|lunch: I commented on #5700
<mup> PR #5700: tests: significantly reduce execution time for managers test <Created by stolowski> <https://github.com/snapcore/snapd/pull/5700>
<mup> PR snapcraft#2219 closed: Release changelog for 2.43 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2219>
<mvo> pedronis: sorry, a missed git add, pushed for real now
<mvo> cachio: great, thank you
<zyga> hey
<zyga> github.com resolves to 192.30.253.11{2,3} to me and I cannot ssh in anymore
<zyga> is anyone else experiencing this?
<zyga> mvo: reviewed the type PR now
<mvo> zyga: ta
<zyga> mvo: can you pull/push to GitHub?
<mborzecki> zyga: seems to work here
<zyga> hmm hmm hmm
<zyga> odd
<mvo> zyga: yes
<mborzecki> mvo: can we update go-check in our vendor tree?
<mvo> mborzecki: yes
<mborzecki> mvo: the one that we have now has the bug when non empty error message raises an error regardless of Not() being used
<mvo> mborzecki: oh, ok
<mvo> mborzecki: standup?
<mvo> mborzecki: then you can tell me all about it
<mvo> zyga: -^
<mvo> pedronis: -^
<zyga> yeah
<zyga> joining
<zyga> jdstrand: hey, do you remember if we wanted to call the new adb interface "adb-support" or just "adb"?
<niemeyer> zyga: There's a comment in the PR about it, and we are in the standup btw :)
<zyga> niemeyer: you can switch camera later
<zyga> if you join you can just go to the three dots in the lower-right corner
<zyga> then go to settings there
<zyga> and then pick the video / audio interface
<zyga> niemeyer: I must have missed the adb vs adb-support decision, I remember reading that we _thought_ about it; thank you I will re-check
<zyga> I think p2p video conferencing is not there yet
<zyga> and hangouts work because google takes the traffic
<niemeyer> Alright
<niemeyer> That's super buggy unfortunately
<niemeyer> I like the view, but it doesn't seem to work reliably at all
<zyga> I'll break for lunch now
<zyga> ttyl
<niemeyer> I think that was a fail
<niemeyer> The fact we spent most of the time asking whether we could hear each other and reconnecting is probably enough of a show stopper
<mborzecki> it does bring back early skype memories though
<roadmr> I see your skype and raise you ms netmeeting
<roadmr> with those spherical webcams
<roadmr> over a 64k ISDN line
<mborzecki> or webex
<roadmr> tandberg!
<stgraber> Gargoyle: sorry, there's a lot of backlog in there, what can I do for you?
<zyga> stgraber: cannot remove lxd data, some read-only filesystems
<niemeyer> mborzecki: You mean the bad memories? :)
<niemeyer> Zoom apparently needs an app/plugin to be installed, so also a no go..
<mborzecki> niemeyer: more like repressed memories :)
<niemeyer> Man.. it's 2018 and video conferencing still sucks
<mborzecki> wondering if someone came up with an idea of using cctv video feed for conferencing
<zyga> Analog over IP
<mup> PR snapd#5706 opened: snapstate: make InstallPath() return *snap.Info too <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5706>
<roadmr> well clientless videoconferencing sucks, but nobody wants to install a proprietary client :P
<roadmr> https://talky.io/ is not horrible
<Son_Goku> niemeyer, in Mageia, we use jit.si for this stuff
<niemeyer> Son_Goku: We just tried it.. it was crazy buggy :(
<Son_Goku> damn :(
<Son_Goku> how about Jangouts?
<niemeyer> roadmr: talky.io is also pretty buggy.. it was responsible for one of the most hilarious bugs I've seen in a video conferencing application. One participant was only visible to half the participants
<niemeyer> Can you imagine how funny the call was until we figured that out? :)
<niemeyer> Son_Goku: Haven't tried that one
<Son_Goku> https://github.com/jangouts/jangouts
<niemeyer> zyga: Just reviewed #5469
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<niemeyer> zyga: The main comments there are about pre-existing logic.. Alfonso may need a hand.. not sure.
<Son_Goku> niemeyer, Red Hat uses Bluejeans
<zyga> niemeyer: ack, I'll read that
<Son_Goku> the few video calls I've had with teams at Red Hat were over that and it went pretty well
<Son_Goku> https://www.bluejeans.com/
<niemeyer> Son_Goku: Yeah, bluejeans works a few times for me.. it was old fashioned, but worked okay
<Son_Goku> it has an all-web mode too
<niemeyer> Not sure if it works in the browser nowadays, though, or needs an app
<niemeyer> Son_Goku: Ah, nice
<Son_Goku> niemeyer: https://support.bluejeans.com/knowledge/join-from-browser
<Son_Goku> the app is recommended (and really is a nicer experience), but the browser only option works in a pinch
<Son_Goku> it's the principal reason Red Hat uses Bluejeans over other alternatives
<niemeyer> We might even have a company account already.. I recall at least a couple of meetings over it in the past
<roadmr> niemeyer: we (Canonical) do, yes.
<roadmr> a problem with bluejeans is that some functionality on a computer still requires flash
<Son_Goku> nope
<Son_Goku> I don't even have Flash on my computer and pretty much the entire thing works now
<Son_Goku> the only problem with it is that Macs will burn up because the WebRTC implementations on macOS suck
<roadmr> Son_Goku: well some parts of it don't work here (Chromium on Ubuntu)... heh :(
<Son_Goku> really?
<roadmr> Son_Goku: I usually just use the app on my phone to see the video and use the web UI for the chat and QA stuff
<roadmr> yes, really :) why would I pull your leg on this :D
<Son_Goku> odd, I was using Chromium on Fedora for the last Koji Community Meeting and it worked okay
<Son_Goku> but maybe I did something different?
<roadmr> ah, it could also be somethingsomething on Canonical's settings/account.
<roadmr> I've seen that with gotomeeting: unless the presenter enables it, browser access doesn't work and it pesters you to install a client.
 * Son_Goku shrugs
<Son_Goku> that's probably the case
<roadmr> hehe
<niemeyer> roadmr: Thanks for the info, I'll try to find someone that can hand me access to an account
<roadmr> inconsistent experiences!
<Son_Goku> joy of joys, right? :D
<roadmr> Son_Goku: absolutely \o/ (haha)
<mup> PR snapd#5475 closed: WIP: remove unneeded calls to daemon-reload <Blocked> <Created by alfonsosanchezbeato> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5475>
<Son_Goku> bbl g2g to work
<mup> PR snapd#5495 closed: interfaces/builtin: initial version of the anbox-support interface <Created by morphis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5495>
<mup> PR snapd#5530 closed: tests: use file based markers in snap-service-stop-mode <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5530>
<cachio> niemeyer, hey, I need this permission for the image-baker sa on gce https://paste.ubuntu.com/p/xbPwN6qnWd/
<mup> PR snapcraft#2221 opened: spread: stop running catkin tests on 18.10 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2221>
<niemeyer> mvo: #5583 reviewed
<mup> PR #5583: [RFC] many: go into socket activated mode if there are no snaps <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5583>
<niemeyer> cachio: The image baker already has that permission
<niemeyer> cachio: But probably not on eco-emissary.. what the heck is that project? :)
<cachio> niemeyer,  it is running as part of spread-cron project
<cachio> It clones the pread images project and uses a lib to delete the tmp image
<cachio> it is able to create a new image
<niemeyer> cachio: It still doesn't clarify the point above
<niemeyer> cachio: I don't know what that project is, and I have no control over it
<niemeyer> cachio: The fact you cannot delete images on it is probably A Good Thing
<cachio> niemeyer, it runs from travis, it is a spread-cron branch execution
<niemeyer> cachio: That still sounds completely unrelated to the point I just made
<cachio> niemeyer, I don't get the point!
<cachio> if I log in with this sa, should I be able to create/delete images, right?
<cachio> niemeyer, or it depends on another thing too?
<niemeyer> cachio: What is "eco-emissary"?
<niemeyer> cachio: It seems on my end that you haven't read what I said
<cachio> niemeyer, I though it is a project where it can be executed
<niemeyer> cachio: You are trying to delete projects on "eco-emissary".. I have no clue about what that project is, I don't maintain it, and I cannot give you permissions to delete images on it, and that's a good thing
<cachio> niemeyer, perhaps it is not
<niemeyer> cachio: I don't know what "it can be executed" means in this context
<niemeyer> cachio: You are trying to delete images there.. who owns that project, and why are you trying to delete images there?
<niemeyer> cachio: As I also said above, the image baker *already has* the permission to delete images, on our project, the one our images are stored on
<cachio> my spread cron branch, creates a tmp image, it updates it, it tests it and the it clones the tmp image into a final one, then it needs to delete the tmp image
<niemeyer> cachio: Where?
<cachio> this spread-cron branch runs from a travis machine
<cachio> and it is using the image-baker sa
<niemeyer> cachio: You keep repeating that..
<niemeyer> cachio: It's not helping :)
<cachio> niemeyer, agree
<niemeyer> cachio: Let me be more prescriptive: these tools are attempting to delete images a project we don't control and shouldn't be storing images on in the first place.  YOu'll need to find out why.
<mvo> niemeyer: thanks for 5583!
<cachio> niemeyer, ok, I'll try to do something different
<niemeyer> cachio: It would be good to understand the problem first
<cachio> and use spread-images to delete the image using the computeengine project
<niemeyer> cachio: Our tools shouldn't be poking arbitrary projects like that
<mvo> pedronis: when you have some free cycles, 5702 should be ready for a re-review, I applied your feedback
<niemeyer> cachio: Please understand the problem before changing things
<cachio> niemeyer, yes
<mup> PR snapd#5707 opened: image: detect and error if bases are missing <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5707>
<cachio> niemeyer, it is fixed
<cachio> niemeyer, it was really simple
<cachio> niemeyer, In fact was my fault
<cachio> niemeyer, I didn't set the project when I did login with the sa
<cachio> niemeyer, but it didn't fail, it made login to a generic project
<cachio> niemeyer, to this one eco-emissary-99515
<niemeyer> cachio: Glad it's sorted, thanks for looking into it
<cachio> niemeyer, yaw
<mvo> niemeyer: I replied to your question in 5583, I hope this makes sense but I may miss some subtle bits here if so, my appolgies
<niemeyer> mvo: Thanks, looking
<mup> PR snapd#5340 closed: interfaces: add cifs-mount interface <Created by datenhahn> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5340>
<pedronis> mvo: niemeyer: I wrote something there too
<mvo> pedronis: aha, yeah, that makes sense. I will address it
<niemeyer> mvo, pedronis: Yeah, what pedroins said.. I've made an additional comment there. Repeating here, we might prevent it from dying too fast, maybe
<mvo> niemeyer: yeah, that makes sense, thank you
<pedronis> we don't die too fast if there's  a non-idle connection but at that point we will still shut down
<pedronis> which is not quite what we want
<pedronis> if there's an install
<pedronis> mvo:  a naive approach would be do the check, if it seems we should stop,  wait a while, do the check again, if it's still the case ask to stop there
<pedronis> maybe there is something more elegant though
<mvo> pedronis: yeah, I was wondering if we need something like we do for outstanding hooks
<mvo> pedronis: I will think a bit
<pedronis> mvo: notice that code is also ignoring EnsureBefore unlike Settle
<pedronis> put a not in the PR
<pstolowski> mvo: is there a way to find what was the revision of core for given git commit id? the commit is from 17th Oct 2016, looking at the debian changelog the closest release was 2.17 on 2nd Nov 2016 (did we have release branches back then? i would need to check if that commit was really included in 2.17)
<pstolowski> anyway eod.. will repeat the question tomorrow
<zyga> jdstrand: hey
<zyga> jdstrand: I sent some updates to #5170
<mup> PR #5170: interfaces/builtin: add adb-support interface <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<zyga> jdstrand: I'm working on testing but the look and feel of the interface is what I think you asked for
<zyga> jdstrand: I've built a snap with adb inside and I'm trying to get to the point where it works end-to-end
<zyga> jdstrand: as for a smaller request, https://github.com/snapcore/snapd/pull/5307 is ready and just needs your final ack to land
<mup> PR #5307: cmd,interfaces,tests: add /mnt to removable-media interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
<pedronis> pstolowski|afk: what commit is that?
<mvo> pstolowski|afk: sorry for the delay, was at dinner. you can do "git checkout release/2.17" and look at the diff there
<mvo> pstolowski|afk: I mean, look if the commit is part of this branch
 * zyga goes for a bike ride; I will be back with adb tests tonight
<mup> PR snapd#5702 closed: snap: add ByType sorting <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5702>
<mup> PR snapd#5706 closed: snapstate: make InstallPath() return *snap.Info too <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5706>
<G33kDad> So, how resiliant is ubuntu core to power losses? Im thinking of an automotive application.
<mup> PR snapd#5708 opened: snapstate: use new "snap.ByType" sorting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5708>
<mup> PR snapd#5661 closed: tests: normalize tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5661>
<jdstrand> zyga: sorry, meetings and appt. ack on all fronts
<mispp> hey all, anyway to force build.snapcraft.io to use newer toolchain (18.04)?
<zyga> jdstrand: thank you and no worries about the meetings, I just got back from my ride
 * zyga reads about side-channel LSM
<zyga> G33kDad: more resilient than traditional distributions
<zyga> G33kDad: all application code is stored in read-only filesystem images
<zyga> application upgrades are never partial
<zyga> kernel upgrades are never partial
<zyga> OS upgrades are never partial
<zyga> the upgrade system uses transactions
<zyga> the system can revert to earlier revision of the OS and kernel if upgrade fails
<zyga> sudden power off can still affect the writable filesystem but the "damage surface" is smaller
<mvo> zyga: I'm looking into that firstboot failure curently, no idea what is going on there yet
<zyga> mvo: XK
<zyga> ack
<mvo> zyga: I hope we get a review on 5307 soon, can't wait
<zyga> indeed :)
 * zyga -> supper
<mup> PR snapcraft#2222 opened: lxd: support new style snap injection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2222>
<dave_uy> How should I debug my snapcraft build? I am creating a snap for Bisq. I need to put my build artifacts in the right place I think.
<ogra> stgraber, so two days ago three ominous disks showed up in my unity panel ... turn out thats apparently the lxd snap ... what did change in lxd that makes this happen ? (no other snap does that)
<ogra> annoyingly its all three versions ...
<ogra> and it definitely didnt do that before
<stgraber> ogra: can you pastebin /proc/self/mountinfo?
<ogra> (i dont really see anything that could be special in mount or df)
<ogra> one sec
<ogra> http://paste.ubuntu.com/p/VWv9Xsztbj/
<ogra> ogra@acheron:~$ cat /proc/self/mountinfo |grep lxd
<ogra> 960 563 0:3 mnt:[4026532557] /run/snapd/ns/lxd.mnt rw - nsfs nsfs rw
<ogra> 362 29 7:69 / /snap/lxd/8358 ro,nodev,relatime shared:98 - squashfs /dev/loop69 ro
<ogra> 388 29 7:94 / /snap/lxd/8393 ro,nodev,relatime shared:226 - squashfs /dev/loop94 ro
<ogra> 256 29 7:88 / /snap/lxd/8415 ro,nodev,relatime shared:117 - squashfs /dev/loop88 ro
<ogra> here is the filtered variant ... proably easier :)
<ogra> i dont see anything soecial compared to the other gazillion snaps i have
 * ogra notices lxd is the only snap using the lxd-support interface on his system ... probably related ... 
<ogra> did the interface change recently ?
<stgraber> nope, that interface has never changed
<ogra> weird
<stgraber> kinda hard to tell why LXD would show up in unity, clearly nothing that'd explain it in the mount table and without knowing what kind of event that unity launcher reacts to it's hard to tell what might cause it
<ogra> but well ... they are there :) https://imgur.com/a/4PhinGS
<ogra> (the bottom three disks)
<stgraber> LXD does do a ton of special mount namespace setup, some of which in the host mount namespace, but as you can tell, there's nothing from that left behind, so even if the launcher noticed it happening, those entries should have immediately gone away
<ogra> well, i can tell unity to simply hide them in the panel ... but be prepared that you'll get reports from 16.04 users
<ogra> btw, just checked my desktop machine (where i never noticed it) and got the same three disks there
<G33kDad> zyga: thanks for the thoughts!
#snappy 2018-08-23
<stub> I've got a version-script that contains 'python3 setup.py -V' in it, which is failing in Launchpad builds with "ImportError: No module named 'setuptools'"
<stub> Does anyone know what I need to include to get it working so I don't have to trial and error it?
<stub> I've tried adding "build-packages: python3-setuptools" to the part
<mborzecki> morning
<mup> PR snapd#5614 closed: interfaces: parallel instances support, extend unit tests <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5614>
<mvo> mborzecki: did you see the comment from zyga on 5705 ? looks like one govendor add is missing
<mborzecki> mvo: yup, added it alredy, but i'm checking if fedora package builds fine as i had github.com/kr/{pretty,text} to the spec too
<mborzecki> mvo: interestingly govendor also lists golang.org/x/sys/unix as an external dep and it's imported by some of the pacakges https://paste.ubuntu.com/p/bjKD2dJ93C/ but we do not vendor it, any idea why?
<mvo> mborzecki: hm, in the past we used some older revision of things just to avoid the x/sys/unix
<mvo> mborzecki: the x/sys/unix fails on powerpc so we need to avoid it currently
<mborzecki> mvo: interestingly, latest master of kr/pretty has go.mod already :)
<mup> PR snapd#5709 opened: configcore,snapstate: add new core.experimental.snapd-snap option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5709>
<pstolowski> mornings
<zyga> Hello :-)
<pstolowski> o/
<zyga> mborzecki: what is go.mod?
<pstolowski> mvo: hey, is there a way to find what was the revision of core for given git commit id? the commit is from 17th Oct 2016, looking at the debian changelog the closest release was 2.17 on 2nd Nov 2016 (did we have release branches back then? i would need to check if that commit was really included in 2.17)
<mborzecki> zyga: https://github.com/golang/go/wiki/Modules
<mborzecki> zyga: go 1.11 thing
<mborzecki> pstolowski: zyga: and hi :)
<zyga> Ah, interesting
<mvo> pstolowski: hey, did you see my reply from last night? you can "git checkout release/2.17" and then look into that branch if the commit is in there
<mvo> pstolowski: what git are you looking for?
<mvo> pstolowski: i.e. whats the id?
<zyga> I think that the separate commit IDs from the vendorized tree are still a thing though so complexity in looking up snapd version to git hash in the repo is still harder
<pedronis> pstolowski: hi, why do you need such an old revision?  I'm probably missing something
<mborzecki> + snap install test-snapd-tools test-snapd-control-consumer
<mborzecki> error: unable to contact snap store
<mborzecki> hmm again?
<pedronis> mvo: hi, did you see my new comment in #5703 ?
<mup> PR snapd#5710 opened:  cmd: support re-exec into the "snapd" snap  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5710>
<mup> PR #5703: firstboot: sort by type when installing the firstboot snaps  <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5703>
<mvo> pedronis: yes, need to look at this but I thought we already sort snapd->core18->kernel->gadget and add the right waits. if thats not the case I need to re-check this
<pedronis> mvo: the sorting is right but as your comment says you don't sort things that are added manually before the loops
<pedronis> maybe I'm missing something though
<mvo> pedronis: looking, I though thats ok because we already "manually" sort and add the waits but let me double check
<pedronis> mvo: I think the issue shows up only if gadget   has a base !=  model base, which maybe is strange
<pedronis> but we need to do something about it either way
<mvo> pedronis: aha, I get the issue now, yes, thats a problem
<pedronis> either error or fix the order
<mvo> pedronis: +1
<mvo> pedronis: I think I will just error for now
<mvo> pedronis: because its slightly strange to have a gadget base that is not the model base
<mvo> pedronis: we I add a todo that we can reeval this
<mvo> pedronis: sounds sensible?
<pedronis> yes
<mvo> pedronis: cool, thanks again for spotting this :)
<pedronis> mvo: do the new gadgets we made have base: core18 set ?
<mvo> pedronis: they don't have any bases set yet, I think we need to fix this
<pedronis> ok
<pedronis> mvo: probably worth adding a check in image too
 * mvo goes and fixes that as well
<mvo> pedronis: yeah
<pstolowski> pedronis: i wanted to know the range of core revisions that were on patch level 6 (for the patch sublevel PR). on second thought i probably actually only need the current core revision at the time we release the new code
<mvo> pstolowski: what revision is it you are looking for in 2.17?
<pedronis> pstolowski: yes, think so
<mborzecki> zyga: how's your spreadfmt tool coming along?
<pedronis> if I understand what we need
<mup> PR snapd#5711 opened: tests: shellchecks part 8 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5711>
<zyga> mborzecki: it makes small one time difference but otherwise is useful to apply. I havenât spent much time on task.yaml, just spread.yaml has look and feel hints
<zyga> It is a background task so I open it each time I get stuck on something
<mborzecki> zyga: haha, same with shellchecks for me :)
<mborzecki> ok, back to UpdateMany tests
<ogra> hmm ... why do i see /var/lib/snapd/void in my LD_LIBRARY_PATH ?
<zyga> Odd
<zyga> Perhaps something uses current working directory
<pedronis> pstolowski: revision are different per arch,  5145 is the amd64 revision, but there are higher revision in stable because of other archs
<ogra> it actually seems to come from SNAP_LIBRARY_PATH
<pstolowski> pedronis: ah /o\
<pedronis> pstolowski: also not sure if we should use stable or cand or beta for the number
<pstolowski> pedronis: this is going to be a little messy... perhaps we can think of some other way of finding 6.0 level out
<pedronis> pstolowski: worst case we rerun some idempotent patch, no?
<pedronis> IÂ mean by using somethin higher
<pedronis> pstolowski: btw you can see the info for  all archs and channels with this:  curl -s -H "Snap-Device-Series: 16" https://api.snapcraft.io/v2/snaps/info/core|jq '."channel-map"'
<pstolowski> pedronis: yes, worst case we re-run an idempotent patch
<pstolowski> (thanks, that curl hint will be handy)
<zyga> ogra: is it visible with any snap or with a particular one
<zyga> ogra: and what is the working directory where you are trying?
<ogra> zyga, i'm actually in a rather evil setup ;) https://snapcraft.io/wmx-kiosk-session
<ogra> the working dir by default is $SNAP_DATA and i'm root
<ogra> (planning to change that to cd to $HOME, but not there yet ... i'm surprised it would have any influence on the lib path)
<zyga> it may though not sure how
<zyga> I mean
<zyga> we cd /var/lib/snapd/void in _some_ cases
<zyga> so perhaps something is using $(pwd)
<ogra> well, i'm not cd'ed to it ... it is just in SNAP_LIBRARY_PATH
<zyga> I mean snapd does that for you
<zyga> if $(pwd) cannot be represented in a snap
<ogra> the snap starts a daemon app --- which in turn starts a WM on top of mir-kiosk ... and inside that i'm running an xterm
<ogra> (being root obviously)
<ogra> (and on ubuntu core)
<mup> PR snapd#5712 opened: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
<ogra> it doesnt seem to do any harm btw ... i only noticed it shows up un the lib path variables everywhere
<zyga> wow
<zyga> the adb debian package uses runpath!
<zyga> that's so wierd
<zyga> I thought rpath-like things were forbidden
<ogra> adb *is* weird ... why should a debian package with it be any better ? :)
<zyga> ogra: is there something like x86_64-linux-gnu in the form of a variable
<zyga> ogra: my snapcraft.yaml is non-portable because of those
<mborzecki> zyga: #5705 is green now
<mup> PR #5705: testutil: have File* checker produce more useful error output <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5705>
<ogra> zyga, didnt mvo add SNAP_ARCH_TRIPLET ? ... oh, wait, thats runtime ... there is SNAPCRAFT_ARCH_TRIPLET for build-time
<zyga> I don't know, I'll try that
<mborzecki> pedronis: i'll drop the commits that fiddled with ordering in #5697 and push an update to the test on top if you don't mind
<mup> PR #5697: overlord/snapstate: fix UpdateMany() to work with parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5697>
<pedronis> mborzecki: ok
<mvo> ogra: I did not, that PR got rejected
<ogra> boo
<zyga> mborzecki: reviewed
<zyga> mvo: :(
<ogra> zyga, well, then you want some case statement based on SNAP_ARCH in your app wrapper .... one sec, i have a paste
<ogra> (in case you need it at runtime)
<zyga> $SNAPCRAFT_ARCH_TRIPLET works
<zyga> I didn't want to add any wrappers
<ogra> yeah, thats for build time
<ogra> if your app gets along then thats fine
<ogra> (if you need any subdirs in your lib path that snapcrafts command wrapper doesnt cover, you need an extra wrapper with the above though)
<zyga> yeah but it expands at build time
<zyga> so that's fine
<pedronis> mvo: lots of red because of problems get gcloud tokens
<pedronis> getting
<mvo> pedronis: hm,hm,is that a gcloud issue or is it on our side somehow?
<pedronis> mvo: actually is tls handshake might be networking somewhere
<mborzecki> pedronis: and force pushed
<pedronis> mborzecki: ok, will look at it again in a little bit
<mborzecki> pedronis: thanks
<mup> PR snapd#5686 closed: overlord/ifacestate: introduce connectOpts <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5686>
<zyga> ok, little by little :-)
<mup> PR pc-amd64-gadget#9 opened: snapcraft.yaml: add `base: core18` <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/9>
<mup> PR pc-i386-gadget#7 opened: snapcraft.yaml: add `base: core18` <Created by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/7>
<mvo> zyga: thanks for the approvals
<mvo> zyga: there are more for pi2,3,cm3,dragon
<zyga> woot
<mvo> zyga: but mup does not pick those up
<zyga> adb works now
<mvo> zyga: \o/
<zyga> mvo: I'll look now :)
<zyga> I need to tweak my test snap to start adb as a service
<zyga> but I can get it to do the right thing out of the box now :)
<zyga> and the interface is not that scary actually :-)
<zyga> mvo: let me know if there are any I missed please
<mvo> ok
<mvo> ta
<zyga> hmm
<zyga> Aug 23 11:43:18 fyke kernel: adb[54153]: segfault at 5564b3a9e000 ip 00007f449172f885 sp 00007ffd7002edf8 error 6 in libcrypto.so.1.0.0[7f44916ca000+219000]
<zyga> core18 based adb snap
<zyga> it works when I run it as a user command
<zyga> crashes when I run it as a service (type: forking)
<mvo> zyga: crashes with denials?
<zyga> no, just segvfault
<zyga> this is all of journal when I install the package:
<zyga> adb crashes when started as a service https://www.irccloud.com/pastebin/PTPzjlyC/
<mborzecki> anyone using opera snap on ubuntu? does it work?
<zyga> I used it on Fedora
<zyga> it worked but fonts weren't perfect
<zyga> especially "normal" fonts, web fonts were ok
<mborzecki> zyga: can you install it and check if it works still?
<zyga> let me figure out why gnome shell is crashing onw
<zyga> I cannot log in with zsh as my shell
<zyga> hmm
<zyga> I'll reboot
<mborzecki> haha omg :)
<zyga> rebooting fixed it
<zyga> (I switched back to bash)
<zyga> installing opera nonw
<zyga> *now
<mup> PR pc-amd64-gadget#9 closed: snapcraft.yaml: add `base: core18` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/9>
<mup> PR pc-i386-gadget#7 closed: snapcraft.yaml: add `base: core18` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/7>
<zyga> mborzecki: yes, it works
<mborzecki> zyga: can you snap info?
<zyga> snap info opera https://www.irccloud.com/pastebin/qJTN75jk/
<mborzecki> zyga: can you ls -l /snap/opera/7/usr/lib/x86_64-linux-gnu/opera/opera_sandbox ?
<zyga> -rwxr-xr-x 1 root root 212632 Aug 13 23:04 /snap/opera/7/usr/lib/x86_64-linux-gnu/opera/opera_sandbox
<mborzecki> zyga: and unsquashfs -ll /var/lib/snapd/snaps/opera_7.snap |grep opera/opera_sandbox
<zyga> -rwxr-xr-x root/root            212632 2018-08-13 23:04 squashfs-root/usr/lib/x86_64-linux-gnu/opera/opera_sandbox
<mborzecki> zyga: this is what happens on arch https://paste.ubuntu.com/p/BPr6THsF7d/
<zyga> snap run --shell opera
<zyga> cat /etc/os-release
<zyga> I wonder if this is related
<mborzecki> zyga: ubuntu core
<zyga> hmm
<zyga> magic :)
<zyga> no idea then
<mborzecki> zyga: well the file is not seuid root so there's that
<zyga> it cannot be setuid root
<zyga> snaps cannot do that
<mborzecki> zyga: right, but it complains hard about that here but not on ubuntu (?)
<zyga> yeah, that _is_ odd
<zyga> and also not on fedora
<mborzecki> zyga: when have you tried it on fedora? maybe it was some older rev of the snap?
<zyga> I tried it and it worked
<zyga> same rev IIRC
<mborzecki> i'll try chomium from snaps, it also does sandboxing via a helper
<mborzecki> zyga: well, chromium snap works
<mborzecki> anyone using fedora/opensuse?
<zyga> I can boot both
<mborzecki> zyga: do you have desktop installations? i only have cloud images
<zyga> yes
<zyga> I always use desktop versions
<mborzecki> chromium works fine - https://paste.ubuntu.com/p/s2pgFqXNzB/ You are adequately sandboxed.
<zyga> fedora works fine
<zyga> same revision
<zyga> I need to fix my suse installation now but I'll let you know
<pedronis> mvo: so review-tools seems not to accept base on a gadget, there are two ways to address this, one is to change them,  the other is to fix the base of the gadget to be the base of the model (that means double checking all places using Base tough)
<mvo> pedronis: yeah, I just saw the rejects
<zyga> installing most of opensuse desktop packages back
<zyga> I wonder what caused zypper to remove pretty much all the packages that it could
<zyga> I have grub back, installing gnome-shell
<mvo> pedronis: I like option (2), it de-couples the model and the gadget to some extend, i.e. one could use the same pc gadget on core16 and core18
<mvo> pedronis: feels slightly magic but that may not be bad
<mvo> pedronis: also I wonder how much ugliness it adds to the code but hopefully not much, snap run hopefully just needs to learn to handle gadgets specially for hooks
<mvo> pedronis: wdyt?
<ogra> is it actually a code problem ? not just review tools (pushing then through manually should work too, no )
<ogra> *them
<pedronis> mvo: that sound optimistic , as I said any place doing .Base might have to be considered
<mup> PR snapd#5711 closed: tests: shellchecks part 8 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5711>
<pedronis> mvo: we might probably just need to be clever and some central places, but is not a trivial change
<pedronis> s/and some/in some/
<mvo> pedronis: hm,hm,it sounds like something we should talk about during the standup.
<mvo> pedronis: I guess we need to figure out what feels most "correct"
<pedronis> mvo: there also  some subtle questions like given that is "implicit"Â should we show in the api or not etc
 * mvo nods
<pedronis> to be clear  I'm not against
<mvo> pedronis: yeah, I'm sitting on the fence
<pedronis> I just don't think is trivial path to unblock us
<pedronis> it might be correct but needs thinking/some work
<mvo> pedronis: agreed, lets talk during the standup which of the two solutions is best for the users/fits best into the system design and then we go for it :)
 * mvo also lunch
<ogra> mvo, with that base: core18 in the gadgets, how do we upload changes for core 16 ?
<ogra> mvo, dont we need separate source trees/branches for the core 16 and 18 ones then ?
<pedronis> ogra: you would need branches corrresponding to tracks, but as we were discussing that was hasty and might need a rediscussion
<ogra> pedronis, well, i was more concerned about the source trees, but i see mvo actually created a branch ... i just didnt see it at first ... so all is fine
<ogra> master is still core16
<ogra> (i dont really care how the sotre later deals with it ... but i want to be able to still push fixes to core16 if needed)
<zyga> http://paste.ubuntu.com/p/gD7ty4jygC/
 * zyga failed to recover his opensuse installationn
<zyga> grub works but there's no kernel or initrd
<zyga> eh
<ogra> kernels are overrated
<diddledan> write your own ;-p
<ogra> in shell !
<diddledan> !!
<diddledan> I seen someone working on a .NET kernel
<ogra> heh
<diddledan> ref: https://github.com/mosa/MOSA-Project
<zyga> hey, I found my crash
<zyga> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858764
<zyga> adb sucks :/
<ogra> why would you run it in forking mode anyway ?
<zyga> that's how it works
 * ogra has in fact never seen a snap use daemon: forking yet
<zyga> I wanted the service separatio
<zyga> separation*
<ogra> did you at least try with daemon: simple ?
<zyga> it cannot be used this way because adb start-server forks
<cachio> niemeyer, about the config done in the spread-cron project
<cachio> niemeyer, is it possible to see how it is done?
<cachio> niemeyer, because it is forcing us to create a project called "target" and run tests from there
<cachio> but for the update the gce images I have some branches which require to do something different
<cachio> and I can't see where/how this is configured
<mvo> ogra: we have a "18" track for the gadgets already (was that the question?)
<mvo> ogra: and a corresponding code branch but I see you discussed this already
<ogra> mvo, yeah, sorry, i only noticed it after asking
<zyga> ok
<zyga> dab works! :)
<zyga> adb works
<mvo> ogra: no worries
<zyga> mvo: shall I register "adb" and push a snap there? :)
<zyga> popey_: ^
<zyga> I have a working adb snap
<popey> stupid irc
<popey> zyga: does it contain _only_ adb? I know often people will install adb and fastboot and other bits and bobs
<zyga> yes, only adb
<popey> Cool. you gonna maintain it?
<zyga> no but I can hand it over to $someone
<zyga> and it requires future snapd to work
<popey> ahh, worth holding back until you have a maintainer and it works ? :)
<mup> PR snapd#5713 opened: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<mborzecki> zyga: fun fun ^^
<zyga> mmm
<ogra> it uses layouts ... which is currently painful
<ogra> (since it means every commit/build needs manual approval)
<ogra> hmm ... weird
<ogra> $ snap find falkon
<ogra> Name    Version  Publisher  Notes  Summary
<ogra> falkon  3.0.1    kde        -      Web Browser
<ogra> $ snap info falkon
<ogra> error: no snap found for "falkon"
 * ogra pokes the store with a long pointy stick
<ogra> https://snapcraft.io/falkon has it though
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5713/files#r212296528
<mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<niemeyer> cachio: Let's get that fixed later today
<cachio> niemeyer, sure, thanks
<mborzecki> zyga: hahah omg, yeah
<mborzecki> zyga: idk, maybe we could just pass $HOME and drop that silly part mauling SNAP_INSTANCE_USER_DATA, wdyt?
<zyga> can you give me an example of how that would look like?
<zyga> sorry for silly questions
<mborzecki> nah, $HOME is silly
<zyga> mvo: is this TODO done now? I think it is but I wanted to check: https://github.com/snapcore/snapd/pull/5713/files#diff-57dc34ab6f4bf9730b356d0439daa0fdR305
<mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<sergiusens> zyga, popey: I bet the ubports folks wouldn't mind adding it to their installer snap as an implementation detail
<mborzecki> zyga: ok, we could use SNAP_REVISION and SNAP_INSTANCE_NAME, and work with this to get to /home/joe/snap
<mborzecki> zyga: those are set by snap run
<zyga> sergiusens: the interface work I'm doing is specifically for ubuports
<sergiusens> zyga: is this generic hotplug for usb or very specific to adb/fastboot?
<zyga> sergiusens: it's specific to adb/fastboot but it doesn't handle hot plug as you might think (by creating new interfaces), instead it can talk to hot-plugged usb devices corresponding to a built-in list of known vendors
<zyga> oh
<zyga> standup!
<mborzecki> zyga: got this locally: https://paste.ubuntu.com/p/sgdyy3XqwX/
<zyga> ooo
<zyga> the infamous mount error
<zyga> collect anything you can think of
<zyga> and add that to the forum thread
<zyga> man, that's interesting!
<zyga> mvo: reviewed the shorter one
<zyga> mvo: I'll do the next one after eating lunch
<mborzecki> zyga: heh, there's literally nothing to collect, journal has 'protocol' error and nothing more
<zyga> look for two things:
<zyga> dmesg logs IO error - check which loop devices are logged
<mborzecki> zyga: btw. i was installing 2 snaps `snap install hello-world_foo hello-world_bar`, one got installed :P
<zyga> dd the loop devices (all if you have space)
<mborzecki> zyga: yeah, nothing in dmesg either
<pedronis> mvo: about the snapd snap type, maybe the easiest thing is to create a short forum post about the needs for it and point people to that
<zyga> and compare them to reference images
<pedronis> s/people/relevant people/
<zyga> are the loop devices corrupt?
<zyga> mborzecki: I'm starving so I'll go now but please don't unmount, don't reboot
<zyga> dd the loopback devices
<zyga> collect losetup data
<mvo> pedronis: sounds good
<mborzecki> zyga: heh, can reproduce it `while true; do sudo snap install hello-world_foo hello-world_bar hello-world_baz && sudo snap remove hello-world_foo hello-world_bar hello-world_baz || break; done`
<pedronis> mvo: I'm creating it
<mvo> pedronis: thanks for that
<pedronis> mvo: https://forum.snapcraft.io/t/new-snap-type-snapd/7021
<mvo> pedronis: ta
<mborzecki> zyga: heh, i'm stracing systemd, obviously this doesn't happen, the mment i stop strace, boom
<zyga> mborzecki: that's interesting
<zyga> I need to go to the post office to pick up a package
<zyga> I'll break for some time now, then be back
<mup> PR snapcraft#2223 opened: snap: prepare override scripts to allow rebuilding <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2223>
<zyga> re :)
<pedronis> mvo: btw about transitioning to the new snapd type remember that we store it also in "snaps" SnapState
<mup> PR snapd#5705 closed: testutil: have File* checker produce more useful error output <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5705>
 * niemeyer is back, and happy.. all sorted
<mvo> niemeyer: \o/
<zyga> mvo: about 5710, is it already safe to remove ubuntu-core support?
<zyga> While it will be older some of our tests may repackage it
<mvo> zyga: in a meeting right now. I think it is because this is re-exec and I can't think why we ever wanted to re-exec into a *new* ubuntu-core snap
<mvo> zyga: I mean, we don't make new ones of these anymore
<zyga> Right
 * zyga resumes reading
<zyga> mvo: LGTM except a/core/system/ on config access (unless you disagree)
<mvo> zyga: thank you, looking
<cachio> mvo, hey, I see this error in the snapd-vendor branch on spread cron
<cachio> https://paste.ubuntu.com/p/xv5nxPFZKD/
<cachio> any idea if something changes on the launchpad project?
<cjwatson> More likely the ~snappy-m-o user
<cjwatson> https://pastebin.canonical.com/p/P42gjNpybw/
<cjwatson> ~snappy-m-o was suspended yesterday
<cjwatson> See https://rt.admin.canonical.com/Ticket/Display.html?id=108842
<cjwatson> Contact IS
<cjwatson> (And somebody who actually still works for Canonical will need to take over as the bot's owner)
<cjwatson> Though one thing I'd say there ... that repository is public.  What's the point of cloning it over SSH, assuming this is a read-only operation?  You could just do "git clone https://git.launchpad.net/snapd-vendor ..." instead
<cjwatson> (Maybe you need that account for other reasons, I don't know)
<popey> i enabled debug in /etc/environment, and now I have disabled it and restarted snapd, i still get debug output. How to I completely disable the DEBUG lines?
<jdstrand> mvo: hi! it seems that pc-i386-18, pc-amd64-18, dragonboard-18, pi2-18, cm3-18 and pi3-18 all need approvals and updates for the review tools?
<zyga> jdstrand: hey
<zyga> jdstrand: I think so though I think mvo and pedronis came up with some other idea
<zyga> jdstrand: do you think you will have time to look at https://github.com/snapcore/snapd/pull/5307 today?
<mup> PR #5307: cmd,interfaces,tests: add /mnt to removable-media interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
<pedronis> jdstrand: we are not sure we are going to pursue attaching explicitly bases to gadget right now
<pedronis> jdstrand: they can be rejected I think atm, need mvo really
<jdstrand> zyga, pedronis (cc mvo): ok, I just saw the rejections so asked
<jdstrand> zyga: maybe? it is on the list and I hope to burn down it a bit today
<anarcat> hello
<anarcat> after upgrading from debian stretch to debian buster, i'm seeing this error when starting a snap (signal-desktop): snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<zyga> anarcat: hello
<mvo> jdstrand: yeah, please ignore the "base: core18" on the gadgets for now, we will discuss this tomorrow/early next week. sorry for the noise here
<mvo> cachio: uh, hmm
<zyga> anarcat: that's interesting, do you have /etc/apparmor.d/usr.lib.snapd.snap-confine* ?
<mvo> cachio: could you try what colin suggested and just clone using a read-only connection?
<mvo> cachio: oh, nevermind
<mvo> cachio: I think the problem is that it first is cloned and then updated/commited :/
<cachio> mvo, I just saw the cjwatson comments
<cachio> mvo, we need to commit
<cachio> and push
<cachio> cjwatson, sorry for the delay, why it was suspended?
<mvo> cachio: hm,hm,we just need it for the deb building
 * mvo scratches head
<anarcat> zyga: checking
<anarcat> zyga: there is /etc/apparmor.d/usr.lib.snapd.snap-confine.real
<cachio> zyga, I see this denial running a test with uses cifs-mount interface [ 4721.716187] audit: type=1400 audit(1535049578.061:44): apparmor="DENIED" operation="exec" profile="snap.test-snapd-cifs-mount.sh" name="/bin/mount" pid=2417 comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<cachio> zyga, is something else required apart of the plug/slot connection?
<zyga> anarcat: ok, can you check if the profile is loaded, run aa-status
<zyga> (as root)
<zyga> cachio: I don't remember, let me check
<anarcat> 55 profiles are in enforce mode.
<zyga> anarcat: can you look for "snap-confine" there please
<anarcat> [...] /usr/lib/snapd/snap-confine, /usr/lib/snapd/snap-confine//mount-namespace-capture-helper, /usr/lib/snapd/snap-confine//snap_update_ns...
<cachio> zyga, I am running this
<cachio> with the interface connected
<anarcat> zyga: it's under the "enforce mode" line
<zyga> anarcat: that looks okay
<cachio> and get the denial
<cachio> if I run the mount command directly it works
<zyga> anarcat: do you see a profile that looks like "/snap/core/$NUMBER/usr/lib/snapd/snap-confine"?
<anarcat> zyga: a profile? in aa-status?
<zyga> anarcat: yes,
<anarcat> zyga: here's the full list: https://ptpb.pw/TwrM
<zyga> snap-confine has multiple profiles (it's complex)
<anarcat> zyga: and the answer is no, i don't
<zyga> and you may need both, depending on the circumstances
<anarcat> ...
<zyga> ok
<anarcat> well that thing used to just work before buster :)
<zyga> does "snap list | grep core" show that core is installed?
<anarcat> yes, core            16-2.34.3  5145  stable    canonical     core
<zyga> ok
<anarcat> /usr/bin/snap info core
<anarcat> oops, wrong win
<zyga> hmmm
 * zyga thinks
<anarcat> i'm not sure that matters, but i have ~/bin/snap that's my screenshot tool that sometimes override snap depending on the path
<zyga> that should not be a factor
<zyga> so
<anarcat> indeed, renaming it doesn't fix the problem
<zyga> snapd should have compiled a profile for the core snap
<anarcat> okay
<zyga> it manifests itself as a new file in /etc/apparmor.d/
<zyga> that looks like snap.core.$NUMBER.usr.lib.snapd.snap-confine
<anarcat> no such file
<zyga> if that file is missing snapd has probably decided not to enable apparmor for some reason
<zyga> can you run "snap debug snadbox-features"
<anarcat> http://paste.debian.net/1039051/
<zyga> anarcat: interesting, I think there's a bug in snapd
<zyga> anarcat: I need to check
 * anarcat grumbles
<anarcat> okay
<zyga> anarcat: it's late, can you jump in tomorrow
<anarcat> this is snapd 2.30-5+b1 in debian buster
<anarcat> for sure
<anarcat> i can grep around the debian bugtracker as well
<zyga> anarcat: note that the version of the debian package is not that critical
<anarcat> debsums: changed file /usr/share/dbus-1/services/io.snapcraft.Launcher.service (from snapd package)
<zyga> anarcat: as you will see "snap version"
<anarcat> odd
<zyga> shows more recent version
<zyga> the version of the core snap matters more here
<zyga> but it's clearly not working as expected
<anarcat> i guess i could file this as a regression in the snapd package on debian, in any case?
<zyga> can you run "snap version" and paste hat
<zyga> that
<zyga> so that I can cross ref that tomorrow and not forget
<zyga> I have installations of various debian versions and I should be able to reproduce this
<anarcat> http://paste.debian.net/1039052/
<zyga> thank you
 * zyga updates 
 * cachio afk
<sergiusens> plars, joc:  just in case https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/7024
<anarcat> zyga: could this be because snap-confine is suid root?
<zyga> no
<zyga> it's a security feature we've built in
<anarcat> okay
<mup> PR snapcraft#2221 closed: spread: stop running catkin tests on 18.10 <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2221>
<cjwatson> cachio: I explained why it was suspended in the lines immediately following where I said that it had been suspended ...
<cjwatson> 18:19 <cjwatson> See https://rt.admin.canonical.com/Ticket/Display.html?id=108842
<cjwatson> 18:19 <cjwatson> Contact IS
<cjwatson> 18:19 <cjwatson> (And somebody who actually still works for Canonical will need to take over as the bot's owner)
<cjwatson> We can't have bot accounts lying around with no human owner who can be responsible for them
<cjwatson> So this is the LP account equivalent of pulling the plug to see who complains and who thus might make a good new owner :-)
<plars> sergiusens: thanks, our tests already detected it and ran about 2 hours ago. Everything looked good for us
<cachio> cjwatson, ok, I'll discuss tomorrow about who should be reponsible for that
<cachio> cjwatson, thanks for the explanation
<zyga> anarcat: I updated my installation, trying to reproduce now
<zyga> anarcat: I am on 4.17.0-3-amd64 kernel but otherwise the same
<zyga> anarcat: I have /etc/apparmor.d/snap.core.5145.usr.lib.snapd.snap-confine
<zyga> anarcat: can you please provide me with snapd logs, "sudo journalctl -u snapd.service" should be it
<sergiusens> plars: nice, if you haven't already and do not mind, a comment on the forum post would be nice
<plars> sergiusens: sure
<anarcat> zyga: sure, hold on
<zyga> thank you
<anarcat> zyga: http://paste.debian.net/1039060/
<zyga> ha
<zyga> aoÃ» 22 15:28:06 curie snapd[1189]: 2018/08/22 15:28:06.844606 backend.go:303: cannot create host snap-confine apparmor configuration: cannot synchronize snap-confine apparmor profile: open /var/lib/snapd/apparmor/profiles/snap-confine.core.5145.dDP25MCqBC0L~: no such file or directory
<zyga> that's the bug
<zyga> can you ls /var/lib/snapd/apparmor/profiles/
<anarcat> zyga: http://paste.debian.net/1039061/
<zyga> hmm hmm
<zyga> ok, can you try this please
<zyga> sudo systemctl stop snapd.{socket, service}
<zyga> sudo /usr/lib/snapd/snapd
<zyga> (this will run snapd in the foreground)
<anarcat> done
<zyga> did it print the same error?:
<zyga> about "cannot synchronise snap-confine apparmor profile"
<anarcat> signal-desktop fails the same way
<anarcat> snapd output: http://paste.debian.net/1039062/
<anarcat> no error from sudo snapd
<zyga> ok, ctrl-c to have it exit
<zyga> sudo rm /var/lib/snapd/system-key
<zyga> and re-start snapd in the foregground
<zyga> system-key is a cache of input factors that affect security profiles
<zyga> removing it just makes snapd re-generate those
<zyga> (system-key contains kernel version, snapd version, etc)
<zyga> s/version/features/
<anarcat> 2018/08/23 16:23:31.104021 helpers.go:119: error trying to compare the snap system key: system-key missing on disk
<zyga> right, that's ok
<anarcat> signal-desktop starts
<zyga> (that's expected)
<anarcat> at least it's trying
<zyga> can you check if /etc/apparmor.d now contains that other profile (snap.core.$number.usr.lib.snapd.snap-confine*)
<zyga> I think we fixed it for you but the origin of the error is unclear
<anarcat> it of course needs to load a N'th copy of a gigantic virtual machine that masquerades as a web browser (aka Electron AKA Chrome)
<anarcat> /etc/apparmor.d does n't have snap.core.$number.usr.lib.snapd.snap-confine*
<zyga> you can probably ctrl-c snapd and restart the socket and the service (sudo systemctl start snapd.{socket,service})
<zyga> oh
<zyga> but ...
<zyga> but snap applications now work?
<anarcat> yeeep
<zyga> hmmm!
<zyga> any output from journald?
<anarcat> not bad eh?
<zyga> any errors?
<zyga> it's actually still bad
<anarcat> nothing peculiar
<zyga> we should have got /etc/apparmod.d/snap.core.5145.usr.lib.snapd.snap-confine
<zyga> er
<zyga> I meant /etc/apparmor.d/
<anarcat> maybe there's a different search path on debian?
<zyga> can you check using sudo aa-status if the profile is loaded
<zyga> no, it's exactly the same AFAIR
<zyga> I mean
<anarcat> yes, it's loaded
<zyga> I see it on my Sid installation
<anarcat> http://paste.debian.net/1039064/
<zyga> so it's loaded but it's not in /etc/apparmor.d?
<zyga> can you check if /etc/apparmor.d has some odd permissions?
<zyga> hmm, that's correct
<zyga> ah
<zyga> sorry :D
<zyga> it's all good
<zyga> you are right
<zyga> please look at /var/lib/snapd/apparmor/profiles
<zyga> you should see snap-confine.core.5145
<zyga> we moved it!
<zyga> and we didn't clean up the old spot
<zyga> so I have it because I updated (and it worked for me for some reason)
<zyga> and on your system you didn't have it but the profile was loaded non the less :)
<zyga> because it is stored in other place
<zyga> ok, that's good
<zyga> as a final check you could try to reboot
<zyga> and re-check with sudo aa-status
<zyga> to ensure it's still loaded
<anarcat> ugh, reboot
<zyga> if not we can inspect the loading logic
<zyga> to see if it is buggy
<zyga> perhaps it was there all along
<zyga> but was not loaded
<anarcat> this exists now /var/lib/snapd/apparmor/profiles/snap-confine.core.5145
<zyga> and just got loaded by snapd when we removed the system-key from your machine
<zyga> anarcat: ok, please stay in touch if this persists as an issue
<zyga> anarcat: and thank you for using snaps :)
<anarcat> of course!
<anarcat> i promise to reboot soon, but i have some work to complete first
<anarcat> thank you very much for your help!
<anarcat> should this be filed as a bug somewhere?
<zyga> anarcat: if you want please write a new thread about this on the forum
<zyga> anarcat: especially include the error message you pasted
<zyga> anarcat: and that you upgraded
<zyga> anarcat: perhaps something in the upgrade process is broken
<zyga> or our assumptions about system key were insufficient
<zyga> (system-key is meant to fix issues like this)
<zyga> anarcat: the forum is on forum.snapcraft.io, we prefer it instead of bug reports as it is more encouraging to engage than traditional bug trackers for some people
 * anarcat shrugs
<anarcat> okay
<zyga> thank you :)
<anarcat> commented there before, in https://forum.snapcraft.io/t/snapped-firefox-unable-to-use-smart-card/5719/5?u=anarcat
<anarcat> but thanks to the upgrade, i don't need a snap for firefox anymore :)
<anarcat> well at least not on this machine, on the buggy machine i still do :/
<anarcat> https://forum.snapcraft.io/t/apparmor-error-after-debian-buster-upgrade/7026
<zyga> thank you :)
<anarcat> np
<mup> PR snapd#5714 opened: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
#snappy 2018-08-24
<mojibake> Can someone help me with a problem. On 16.04(Unity). I like to lock apps to the launcher. However I have noticed for snaps everytime a snap (such as firefox) updates, I lose it off the launcher and my muscle memory is disrupted. Any workarounds, or known issue?
<mborzecki> morning
<mup> PR snapd#5697 closed: overlord/snapstate: fix UpdateMany() to work with parallel instances <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5697>
<mvo> zyga: you have (good) feedback on 5307
<mborzecki> mvo: hey, left a small suggestion in 5704
<mvo> mborzecki: ta, looking
<mup> PR snapd#5708 closed: snapstate: use new "snap.ByType" sorting <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5708>
<mborzecki> uh and obviously forgot to +1 : )
<mvo> mborzecki: ta, I like your suggestion a lot, pushed. lets hope tests are less unhappy than yesterday
<mborzecki> mvo: yeah, i think it was better towards the evening
<mup> PR snapd#5673 closed: ifstate: extra common code into checkAutoConflicts() <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5673>
<zyga> good morning :)\
<mborzecki> zyga: hey
<zyga> jdstrand: thank you for the reviews! I know you are very busy so I'm extra grateful that you did so :)
 * zyga has feedback on two updated PRs and jumps into iteration :)
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mborzecki> wow, didn't know that sigrok is packaged as snap
<mvo> mborzecki: what is it?
<mborzecki> mvo: it's for logic analyzers, dumping, viewing the traces and so on
<mborzecki> mvo: sigrok can also do basic protocol analysis, eg i2c or spi
<mborzecki> wonder if they ship the firmware for open source selae ripoffs too :)
<mvo> nice
<zyga> mborzecki: do you have any hardware like that?
<zyga> I managed to boot my opensuse insallation
<zyga> I don't know if it will work after reboot
<mborzecki> zyga: yeah, the low end 8 channel selae ripoff is < $5 on aliexpress, got 2 of those
<zyga> but it's closer than before
<zyga> I'm rebalancing btrfs now, apparently, so I'll leave it be
<mborzecki> on a side note, the 'new' selae analyzers can do analog signals too and iirc those were not supproted by sigrok at all
<zyga> mborzecki: nice
<zyga> mborzecki: I used to have an Agilent scope but I sold it as I didn't have time to really use it the way I wanetd
<zyga> *watned
<zyga> *wanted
<mborzecki> we also had some lecroy analyzers, but those had windows only software, because 'professioanl', the pricing was also 'professional' level, sigh
<mvo> zyga: I added a comment to 5621 - please have a look, I think the whole attempt to support this strange apparmor lxd setup is fruitless, I will go with a selftest instead
<mvo> zyga: a selftest that will simply error
<zyga> Ack, looking
<zyga> hmmm
<zyga> yeah, it looks like Alice is still falling
<mvo> zyga: I ran out of ideas
<mvo> zyga: which is sad, I had hoped to make it work
<mvo> zyga: but if we can't run snap-update-ns because of outside strange interferences not much left we can do, can we?
<zyga> yeah, I'm surprised how that happens
<zyga> I need to read the fine details
<zyga> but I think that doesn't change the outcome
<zyga> it's all hopeless at that point
<mvo> zyga: *despair*
<zyga> hey, despair is when the sky falls down
<zyga> this is just something we made :)
<mvo> zyga: well, at least we will now give a clear error message (well, not now but *soon*)
<zyga> yeah
<zyga> +1 for a self-test
<zyga> if we can make a reliable one
<mvo> zyga: I think we can
<mvo> zyga: I mean, we can just use the same detection we would have used otherwise
<niemeyer> Good morning!
<mup> PR snapd#5715 opened: selftest: detect if apparmor is unusable and error <Created by mvo5> <https://github.com/snapcore/snapd/pull/5715>
<mup> PR snapd#5621 closed: release: detect when apparmor is available but not usable <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5621>
<mvo> hey niemeyer ! good morning
<mvo> zyga: I also added a forum post about this, feel free to add details, I wonder if I should link to it from the error message in the selftest
<zyga> yeah, anything that helps people google it
<mvo> zyga: +1
<mvo> zyga: I was actually thinking that the selftests should provide data to snap (the command) as well, let me try to sketch something out
<zyga> hmm
<zyga> so snap version
<zyga> can say "but not functional"\
<zyga> ?
<zyga> but selftest makes the daemon stop
<mvo> zyga: something like "snap install foo" would return "snap cannot talk to snapd because: selftest-message"
<zyga> aha
<mvo> zyga: yeah, it needs to life in e.g. /run/snapd/selftest-fail or something
<zyga> we could drop a file in /run/snapd/selftest
<zyga> haha
<zyga> nice ;D
<zyga> we thought about the same idea :)
<mvo> zyga: *or* we could go into degrated mode in the daemon but that seems overkill
 * mvo hugs zyga 
<zyga> yeah, I agree, I think the file is sufficient
<mvo> zyga: I wonder if thats a good or a bad sign ;) I mean group-think and allthat
<zyga> and we need to unlink that file if snapd starts :)
<mvo> zyga: thanks, I add a quick PR
<zyga> :)
<zyga> I think it's good because it is simple
<mvo> zyga: yeah - we could also only look for it if we can't talk to the daemon but unlink is even easier
<zyga> oh, good idea
<zyga> yeah
<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#93 closed: hooks: unwind /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/93>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#93 opened: hooks: unwind /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/93>
<mup> PR snapd#5716 opened: tests: spread test for parallel-installs desktop file handling <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5716>
<mborzecki> there's a forum topic about docker from snap and LD_LIBRARY_PATH and it looks a bit weird, https://forum.snapcraft.io/t/ld-library-path-in-snapped-docker/6903/4 the problem seems to appear on ubuntu only, arch, opensuse, debian are fine
<mup> PR snapd#5700 closed: tests: significantly reduce execution time for managers test <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5700>
<mup> PR snapd#5717 opened: snapd: go into degraded mode when the selftest fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/5717>
<zyga> mvo: reviewed
<zyga> mborzecki: hmm
<zyga> mborzecki: LD_LIBRARY_PATH is managed by apparmor
<mvo> zyga: thanks, thats good stuff
<zyga> mborzecki: it's one of the special flags managed by AT_SECURE
<mup> PR snapd#5718 opened: overlord/ifacestate: remove "old-conn" from connect/undo connect handlers <Created by stolowski> <https://github.com/snapcore/snapd/pull/5718>
<mvo> zyga: fwiw, I tried the /run/snapd/selftest.err first but it was more convoluted
<zyga> mborzecki: in essence, it doesn't traverse setuid-rooot binaries
<zyga> mvo: this is nice :)
<niemeyer> pstolowski: #5618 reviewed
<mup> PR #5618: overlord: instantiate UDevMonitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5618>
<mborzecki> zyga: thanks for leaving a note under the topic ;)
<pstolowski> niemeyer: great, thank you!
<mborzecki> #5716 is an easy win if anyone's interested
<mup> PR #5716: tests: spread test for parallel-installs desktop file handling <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5716>
<niemeyer> I'm 100 PRs behind that still, in  #5623 now :)
<mup> PR #5623: advise-snap: add --dump-db which dumps the command database <Created by shawnl> <https://github.com/snapcore/snapd/pull/5623>
<mborzecki> zyga: pushed an update to #5713
<mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<zyga> mborzecki: added small review
<mborzecki> zyga: aa haha ok
<mup> PR snapd#5719 opened: strutil: add new ParseValueWithUnit <Created by mvo5> <https://github.com/snapcore/snapd/pull/5719>
<mborzecki> zyga: on arch with linux-hardened kernel and apparmor userland bits: https://paste.ubuntu.com/p/FQ9TyxXkjB/
<zyga> mborzecki: nice
<zyga> mborzecki: but not fully enabled (since we only do the fully enabled apparmor-in-snapd in tumblweed)
<mborzecki> zyga: yup, will need to tweak that a little
<mborzecki> [  336.086774] audit: type=1327 audit(1535108348.381:97): proctitle=61707061726D6F725F706172736572002D2D7265706C616365002D2D77726974652D6361636865002D4F006E6F2D657870722D73696D706C696679002D2D63616368652D6C6F633D2F7661722F63616368652F61707061726D6F72002D2D736B69702D726561642D6361636865002F7661722F6C69622F736E6170642F617070
<mborzecki> wow, not very useful
<niemeyer> pstolowski: Enumeration reviewed as well
 * niemeyer => lunch
<pstolowski> niemeyer: ty!
<zyga> mborzecki: yeah, processes put garbage there
<zyga> that's seccomp though
<zyga> do you have more ?
<mborzecki> zyga: the profiles appear to be loaded https://paste.ubuntu.com/p/3VGgW5bwRQ/
<zyga> mborzecki: no, I mean, the error is from seccomp
<zyga> not from apparmor
<mborzecki> zyga: ther was just some STATUS following that
<zyga> can you paste more please?
<mvo> pedronis: did I read your comment in 5606 right that you prefer a download options parameter instead of using the context? I can kill the context entirely when using the download options, it will just be a bit noisy because of the test updates
<mborzecki> zyga: https://paste.ubuntu.com/p/cK3FG7WJP4/
<zyga> mborzecki: this is interesting: [  928.212558] audit: type=1300 audit(1535108940.553:100): arch=c000003e syscall=1 success=yes exit=2953 a0=6 a1=f980dd043a0 a2=b89 a3=0 items=0 ppid=3853 pid=3854 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apparmor_parser" exe="/usr/bin/apparmor_parser" subj==unconfined key=(null)
<zyga> that's seccomp telling us that write is okay?
<jdstrand> zyga: seccomp is type=1326 (unless that recently changed?) I wonder if auditd is installed with rules to log writes to all files
<zyga> ahh
<zyga> thank you! so it's not seccomp at all
<zyga> I was confused by arch and syscall numbers
<zyga> I was confused by arch and syscall numbers
<jdstrand> mvo: fyi, I approved 5715 (thanks!). that is indeed a weird configuration and am happy with the new approach
<jdstrand> mvo: did you see my question yesterday about the -18 gadgets? do you want me to adjust the review tools for those?
<zyga> niemeyer: I'm using the spread snap and while google works now I was wondering if you could special case running from a snap and use $SNAP_COMMON to look for qemu images. I don't know if there are other dependencies (interfaces) for this at this time (probably)
<mvo> jdstrand: I did see it and I thought I had replied. apparently not :) sorry for that, please wait a little bit with the update of the review tools, we will discuss this today (or Monday). I think we want bases for gadgets in the new world but we could also simply always assume gadgets use the model.base. so its a bit of a policy decision if we want implicit or explicit bases for gadgets
<pstolowski> oh my, travis is like rolling a dice nowadays
<mvo> pstolowski|lunch: yeah, its rather annoying
 * mvo lunch
<mborzecki> zyga: jdstrand: https://paste.ubuntu.com/p/WWb3rXGskG/ well, hello-world.evil does not seem to be getting policed by apparmor, the profile is http://paste.ubuntu.com/p/8czF54H45C/
<zyga> mborzecki: because we don't enable apparmor
<mborzecki> aah damn
<mborzecki> right
<zyga> mborzecki: you need to patch apaparmor/backend.go
<mborzecki> zyga: that's the first pase
<mborzecki> zyga: but i still need to rebuild s-c
<zyga> no, I think you are OK
<zyga> s-c no longer plays any role
<zyga> unless you built it without apparmor entirely ;)
<mborzecki> zyga: yeah, i did :P it's a default install, i'm replacing the binaries i need
<jdstrand> mborzecki: what is the output of 'sudo aa-status'?
<mborzecki> jdstrand: http://paste.ubuntu.com/p/2f42M3D5Zv/
<jdstrand> mborzecki: can you run 'snap run --shell hello-world_foo.evil' in one terminal, then while that shell is open, run aa-status and see if a process is add to the profile (ie, look at the bottom of the output)?
<jdstrand> mborzecki: or do it with the non-_foo one
<mborzecki> jdstrand: zyga: wohoo, had to install s-c profile and load it, hello-world.evil is not getting blocked https://paste.ubuntu.com/p/Hn8tCkcxQs/
<mborzecki> s/not/now/
<jdstrand> yeah, I figured snap-confine was not performing the transition
<jdstrand> fyi, this could've been used to confirm the kernel was working right: aa-exec -p snap.hello-world.evil -- /snap/hello-world/current/bin/evil
<jdstrand> but you don't need that now of course
<mborzecki> jdstrand: zyga: i'll put that bit for interfaces/apparmor/backend.go up for review and post a topic in the forums
<mborzecki> anything else i could try here?
<zyga> mborzecki: is this a default config for arch now?
<zyga> mborzecki: run spread ;)
<mborzecki> zyga: no, it's linux-hardened kernel, it's not the default, but it is avaialble in community repo, i only had to grab apparmor from aur
<zyga> ooooh
<zyga> I fixed my opensuse install :)
<zyga> woooot
<zyga> and learned a lot while doing that :0
<zyga> :)
<jdstrand> mborzecki: it does seem like there is a problem though. whatever happened on that system it was failing open
<jdstrand> mborzecki: normally we see the 'snap-confine is running with elevated privileges but without and apparmor profile" (or whatever)
<jdstrand> an*
<mborzecki> jdstrand: 'snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks' this?
<jdstrand> yes
<jdstrand> as I understand what you did to make it work, you loaded the snap-confine profile
<mborzecki> jdstrand: i go that before i dropped snap-confine in /etc/apparmor.d (it wasn't there before)
<jdstrand> I would've expected that message if the profile wasn't loaded. instead, hello-world.evil ran without the profile change to the apparmor profile
<zyga> I think what happened is that we load the permissive profile
<mborzecki> jdstrand: hm it didn't run after i got that message
<zyga> you probably didn't rebuild snapd with the fix
<cachio> mvo, hey
<cachio> mvo, https://paste.ubuntu.com/p/sFhhhBzkQh/
<jdstrand> mborzecki: ok, so you didn't have the profile at all, then you got the message and it failed to run? if so, 'good'
<cachio> the output got from dragonboard
<mborzecki> jdstrand:  i rebuilt snapd with the fix, but s-c was not rebuilt with apparmor and there was no profile for it (basically the default build on arch), then in rebuilt s-c but forgot the drop the profile in /etc/apparmor.d (that's when it got blocked) and last thing i did is to copy the profile and load it, and that's where .evil got blocked and so on
<pedronis> mvo: are you going to work on landing #5234  ?  it has +1s but has conflicts and needs some tweak
<mup> PR #5234: snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234>
<jdstrand> mborzecki: ok, that makes sense and it sounds like there is no snapd problem. that was a 'packaging problem', if you will
<mborzecki> jdstrand: yes
<jdstrand> mborzecki: thanks for confirming that
<pedronis> mvo: yes,  IÂ prefer a download options,  context is not really meant to replace function arguments, it's more to cross unrelated layers or deal with cross-cutting concerns
<mup> PR snapcraft#2222 closed: lxd: support new style snap injection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2222>
<mup> PR snapd#5720 opened: interfaces/apparmor: do not downgrade confinement on arch with linux-hardened 4.17.4+ <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5720>
<mborzecki> zyga: jdstrand: ^^
<zyga> done
<mvo> pedronis: I'm updating 5234 (and the others) now that they all have reviews, no new PR from me until the others are landed, promised
<pedronis> mvo: :)
<pedronis> thx
<mvo> pedronis: thank you for the review(s)
<mvo> cachio: meh, that lookds not encouraging
<pedronis> mvo: I think Chipaca added some helper to show Publisher now
<pedronis> related to #5234
<mup> PR #5234: snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234>
<cachio> mvo, yes
<cachio> mvo, similar problem than the last time
<mvo> pedronis: yeah, also the verified publishers ansi and all that, that pr needs some serious work
<mvo> pedronis: I'm working through my pile, at least this one has clarity now
<mvo> cachio: I will have to dig into it
<mborzecki> heh, super dark outside, huuge storm coming my way
<zyga> mborzecki: oh
<mborzecki> zyga: it seems to be going east, so you're next :)
<ackk> hi, I have a json-schema question (asking here sice snapcraft uses it): does anyone know if it possible to define constants for the patterns used in patternProperties?
<zyga> mborzecki: yeah
<zyga> ackk: constants as in what?
<mborzecki> zyga: http://pogodynka.pl/polska/radary
<zyga> default values
<zyga> or what?
 * zyga is somewhat familiar with JSON schema
<ackk> zyga, I have the same value for the regexp used in patterProperties used in different objects, is there a way to avoid repeating it?
<zyga> mborzecki: I'm considering skipping standup to go for that one last bike ride this week
<zyga> ah
<sergiusens> does anyone know if chipaca is back next week?
<zyga> ackk: I see, last time I checked there was no other way than $ref
<mvo> sergiusens: he will be back tuesday iirc
<ackk> zyga, yeah but ref doesn't work in a key
<zyga> so if you can use types/refs (however that was called) to somehow define what you want
<zyga> otherwise no
<ackk> zyga, I see, that's what I thought but I was hoping I was wrong :)
<ackk> zyga, thanks
<mborzecki> zyga: did ~35km yday and ~27km day before that :) it's a pity it's getting dark around 8pm now
<mborzecki> and it's gonna be worse only
<zyga> mborzecki: I did just 23km yesterday and 14 the day before
<zyga> I would like at least a 10km minimal run :(
<zyga> but once it rains that's out of the question
<zyga> ackk: if you find out otherwise do let me know :)
<ackk> zyga, the little I found on the internet seems to confirm you can't
<zyga> ackk: it's like with css, people invent ${extra_letter}css to add variables and then compile it to css using piles of javascript ;)
<ackk> heh
<niemeyer> zyga: Sounds reasonable.. we might just check if $SNAP_COMMON is set and if so use that path in addition to the default location
<zyga> yeah
<zyga> and also a very nice use of $SNAP_COMMON :)
<zyga> exactly the sort of data we don't want to repeat
<niemeyer> zyga: Yeah.. let's just be careful to use a subpath there, instead of assuming the snap is necessarily spread
<niemeyer> Since people can embed spread in their own snaps
<zyga> mmm
<sergiusens> niemeyer: hey there. Wanted to ask if we can move today's meeting to Monday
<mup> PR snapd#5638 closed: interfaces: basic spread test for udev monitor <Blocked> <Hotplug> <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5638>
<niemeyer> sergiusens: Sure thing
<niemeyer> sergiusens: Morning
<sergiusens> thanks, this will give us time to prepare better for a couple of discussion points.
<sergiusens> niemeyer: and good afternoon for you!
<zyga> mborzecki: hmm
<zyga> mborzecki: can you checkout master and then go test ./... in interfaces
<zyga> I get errors related to the new file checker
<zyga> but they are clearly bogus
<zyga> the checker is used as in Not(testutil.FileContains)
<zyga>     c.Assert(profile+".src", Not(testutil.FileContains), "# complain mode logging unavailable\n")
<zyga> so we just want to check that something is not in the file
<mborzecki> zyga: works fine
<zyga> and then it says "failed"
<zyga> but the searched string is _not_ in the file
<mborzecki> zyga: you need to update vendored deps
<zyga> aaah
<zyga> thanks
<mborzecki> zyga: that's a bug in go-check that's fixed in master and included in the version we vendor
<zyga> nice
<mup> PR snapd#5721 opened: interfaces: retain order of inserted security backends <Created by zyga> <https://github.com/snapcore/snapd/pull/5721>
<zyga> standup!
<zyga> sorry
<mup> PR snapd#5593 closed: tests: new test for hostname-control interface <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593>
<mborzecki> zyga: why doesn't it boot?
<zyga> it was using a snapshot to load grub modules
<zyga> a btrfs subvolume snapshots
<zyga> and that snapshot is corrupted
<zyga> the rest is ok :D
<mborzecki> heh, nice feature btw
<zyga> it was reliably failing even after I fixed it
<zyga> for a reason :D
<zyga> haha
<mborzecki> i still think it's crazy to use btrfs by default, but whatever ;)
<zyga> for _grub_
<zyga> anyway
<zyga> I'm happy now
<zyga> I need to fix this but it's clear why it is broken
<mborzecki> did snapper complain at least?
<diddledan> can I get some tests of gimp from the edge channel please? I want to push stable if it is working fine
<zyga> snapper used all the space
<zyga> snapper didn't care
<diddledan> ping @popey @Wimpress ^^^^^
<mborzecki> gib me all your space ;)
<popey> oooh
<popey> diddledan: 2.10.6?
<diddledan> popey: I've added a banner image to the gimp store listing, so it can be a big-banner-featured at some point :-)
<diddledan> yup 2.10.6
<popey> \o/
<popey> diddledan: full screen splash intentional?
<diddledan> have you got a low-res screen? :-p
<diddledan> I've not changed anything regarding the splash
<diddledan> so that'll be whatever gimp does normally?
<diddledan> looks like the splash image from upstream is 1920x1080
<popey> ah, i'm 1080p :)
<diddledan> I've got 1080p and it doesn't go fullscreen for me :-/
<diddledan> https://usercontent.irccloud-cdn.com/file/SzjUD61N/Screenshot_20180824_145404.png
<zyga> I need a small break to walk the dog and eat something
<mvo> jdstrand: yeah, please allow bases for gadgets
<mvo> jdstrand: we just discussed this and agreeded its the right approach
<Wimpress> diddledan: gimp 2.10.6 "worked for me"
<diddledan> yey, thankyou
<zyga> re
<zyga> my dog is much happier now
<zyga> as am I :)
<zyga> good food, nice walk
 * zyga welcomes rain
<mup> PR snapd#5655 closed: snap,snap-exec: support command-chain for hooks <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/5655>
<danieru98> how can i install a snap in my home directory?
<popey> We don't support that.
<danieru98> is installation for only one user possible?
<popey> Not currently, no.
<danieru98> would be nice if snaps supported that, is that feature planned for the future? should i suggest that feature in Launchpad?
<mup> PR snapd#5722 opened: tests: test for the hostname interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5722>
<popey> danieru98: probably something to discuss on the forum, I think?
<mup> PR snapd#5723 opened: cmd: remove --skip-command-chain from snap run and snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5723>
<kyrofa> niemeyer, ^ there you go
<danieru98> popey, ok i'll create a thread explaining my use case and why snaps won't work for me without this feature.
 * cachio afk
<om26er> can anyone tell why this snap review failed https://dashboard.snapcraft.io/snaps/xbr-dashboard/revisions/1/ ?
<om26er> popey: ^
<om26er> jdstrand: Hi!
<mup> PR snapcraft#2224 opened: snapcraftctl: run in isolation mode <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2224>
<om26er> https://forum.snapcraft.io/t/my-snap-failed-needs-manual-review/7044
<niemeyer> kyrofa: Thanks!
<niemeyer> om26er: Heya
<om26er> niemeyer: hey
<niemeyer> om26er: jdstrand is a bit overwhelmed in the last few days, but he'll get to it for sure
<om26er> niemeyer: sure, no problem. The dashboard seems to have regressed (or this is a special case), previously it did mention the reason for automatic review' failure.
<niemeyer> om26er: It doesn't look like it failed the automated review
<niemeyer> om26er: It says not completed from what I can see
<niemeyer> om26er: It's definitely supposed to mention, but it seems to say the review hasn't finished yet for this case
<niemeyer> Which is a bit atypical given it's been there for an hour
<niemeyer> nessita, noise][: Anything you can see from your end here? ^
<noise][> roadmr: nessita: there was an issue earlier with reviews timing out, likely related
<roadmr> ohai
<jdstrand> niemeyer: thanks for that
<roadmr> om26er: this looks consistent with what we saw earlier; reviews are bumping against a too-strict timeout and end up being retried and eventually fail. We're tuning the timeout and I'll re-autoreview your snap once it's ready
<om26er> roadmr: sounds good, thanks
<jdstrand> whoops, I just pressed 'perform automated review again'
<om26er> well maybe it won't timeout this time ;)
<jdstrand> roadmr: ^ fyi
<roadmr> jdstrand, om26er : well maybe - if it makes it under the X-second threshold it'll be ok, but if not... pain :(
<roadmr> which is why we're increasing the timeout, so it's not such a race against fate
<jdstrand> roadmr: iirc, this is a new thing related to the xenial upgrade?
<jdstrand> or rather, it is aggravated by the xenial upgrade?
<roadmr> jdstrand: there're two causes
 * jdstrand listens
<roadmr> jdstrand: the first is the l1tf mitigations cutting our servers' performance in half :( yay it's like it's 2006 and we're all running on Intel Core 32-bit 1st-gen :)
<roadmr> jdstrand: but interestingly - we're seeing this because matiasb *fixed* things - if he hadn't, those reviews would end up in limbo
<roadmr> jdstrand: before, when a review hit the timeout, it would just end up stuck and need manual intervention from us
<jdstrand> ah, yes. I recall that is was like we were time warping. I think I used 2010, hehe :)
<roadmr> jdstrand: now, it hits a *soft* timeout, so it gets retried in hopes it'll pass this time
<roadmr> if it consistently fails up to X number of retries, it gets flagged for manual review
<roadmr> which is at least an actionable state
<jdstrand> I'm glad to hear about those fixes
<roadmr> jdstrand: this was deployed today but unfortunately it coincided with the world becoming a slower place for VMs :(
<jdstrand> sounds good and a good data point
<jdstrand> oh boo
<jdstrand> roadmr: well, thanks for taking the time to describe it to me. I guess you have twice as much idle time to chat now that computers take twice as long to do things ;P
<roadmr> haha I type just as fast, so poor computer has twice as much trouble keeping up with me :D
<jdstrand> hehe
<roadmr> jdstrand: I think it's a conspiracy theory to boost sales, since conveniently the only true fix is to buy new hardware
<jdstrand> roadmr: I know, right? it's a great strategy. put flaws in, fix them to make things slow, buy new hardware that will only get slower. buy new hardware that has cpu fixes to not be vulnerable to old flaws, but introduce new flaws. rinse and repeat
<jdstrand> we should be hardware guys :)
<om26er> well, ok the review failed again. Lets wait for the actual fix :)
<nessita> om26er, what's the snap?
<om26er> nessita: https://dashboard.snapcraft.io/snaps/xbr-dashboard/revisions/1/
<roadmr> jdstrand: yes we're in the wrong business.
<roadmr> nessita: I have it on a list of snaps to retry
<om26er> nessita: now it seem the review actually run
<diddledan> planned obsolescence for the win!
<nessita> roadmr, sorry I did not know, I retried it
<jdstrand> nessita: hehe, I did the same thing :)
<om26er> well this time there is a warning, so "progress" :)
<om26er> that brings me to the question: If automatic review gets back up, will I be able to push my snap with that pending warning ?
<om26er> "desktop interfaces (x11) specified without a corresponding meta/gui/*.desktop file..."
<jdstrand> om26er: no. you need to ship a desktop file
<jdstrand> then it will pass review (assuming no other errors/warnings)
<roadmr> nessita: not a problem! with these new softtimeout things, retrying should be harmless
<jdstrand> roadmr: not at all urgent, but can you schedule pulling in r1121 of the review tools?
<roadmr> jdstrand: sure thing!
<jdstrand> cachio: that has the cifs-mount addition ^
<jdstrand> cachio: I'll go approve the snap now
<cachio> jdstrand, thanks
<roadmr> om26er: I think your snap is unwedged now, though you still need to take care of the desktop file thing.
<om26er> roadmr: working on the desktop file, almost there :)
<roadmr> \o/ once it's ready, it should auto-review nicely
<roadmr> jdstrand: hi! so :( I had to disable resquashfs enforcement, because the extra time needed to process that was causing a lot of snaps to go over threshold and fail automated review.
<roadmr> jdstrand: do you mind if I leave it off during the weekend? we'll have a closer look on Monday
<mup> PR snapcraft#2225 opened: build providers: environment setup for projects <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2225>
<jdstrand> roadmr: well, if that is the best option considering the time, 'ok'. I definitely want to get out of the habit of turning them off
 * jdstrand realizes it is friday and I don't want to make people work over the weekend for this
<jdstrand> but, (and I know we're in sync on this point), I'd like to get to the point where we never turn them off again
<roadmr> jdstrand: yes, I recognize it's not ideal :( but we know for sure it makes things take longer, and we are seeing these odd timeouts, so it seemed like the only way to cut review times
<roadmr> jdstrand: this is abnormal, for sure: it was all working mostly OK, so next week we'll have a closer look and turn this back on as soon as feasible
<jdstrand> roadmr: I understand. as a member of the security team I had to say something :)
<jdstrand> but it's fine
<roadmr> indeed :)
<jdstrand> roadmr: I'm going eow, so if you need something, holler and I'll check back later
<roadmr> sure thing! enjoy your weekend
<tyhicks> rescanning all unscanned snaps might be a good idea next week
<mup> PR snapcraft#2226 opened: templates: reimplement templates as python classes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2226>
#snappy 2018-08-25
<mispp> which section to add in snapcrafft.yaml to add a runtime dependency (like libmysqlclient). i dont want to build that, but rather use the lib that's already compiled and in repos
<dave_uy> I'm trying to automate my snap but the cleanbuild fails on snapcraft.io. https://build.snapcraft.io/user/dmp1ce
<dave_uy> I try to reproduce locally on my Vagrant setup but it fails in a different way. Do I need to initialize lxd in a certain way to get the same results as on snapcraft.io?
<popey> dave_uy: looks like a proxy/firewall problem in the datacentre
<popey> https://launchpadlibrarian.net/385194928/buildlog_snap_ubuntu_xenial_armhf_30ab74512c9e3b64356085921b1cdfd1-xenial_BUILDING.txt.gz
<popey> Exception in thread "main" java.net.UnknownHostException: services.gradle.org
<dave_uy> Thank you.
<om26er> Is there a way for a snap to check if its running on UbuntuCore system (vs a desktop)
<ogra> om26er, not sure if  snap can read /proc/cmdline ... but if you find snap_core= on there you are definitely on core
<ogra> *if a snap
<om26er> ogra: snap_core= wher ?
<om26er> *where
<mup> PR snapcraft#2224 closed: snapcraftctl: run in isolation mode <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2224>
<om26er> if, this will do
<om26er> if [[ $(cat /proc/cmdline) = *"snap_core="* ]]; then echo 1; fi
<om26er> thanks ogra
<Son_Goku> zyga, hey
<Son_Goku> zyga, I'm having compilation failures trying to upgrade to 2.35 on s390x: https://kojipkgs.fedoraproject.org//work/tasks/4897/29294897/build.log
<Son_Goku> zyga, hmm, may be a bug in golang: https://bugzilla.redhat.com/show_bug.cgi?id=1622312
<om26er> is there a specific interface that Is should be using to avoid that denial ?
<om26er> https://paste.ubuntu.com/p/NSGrxDhHh8/
<om26er> ignore the fonts related denial, I am more concerned about the name="/proc/1465/mem" denial.
<om26er> diddledan: ^ can you help ?
<diddledan> I don't know of which plug, if any, would cover `/proc/<pid>/mem`
<diddledan> maybe process-control?
<diddledan> from a quick scan of of the interfaces I can't see any that include a rule referencing @{PROC}/@{PID}/mem
<om26er> diddledan: I have been doing that as well, didn't find any
<om26er> found this old issue https://bugs.launchpad.net/snappy/+bug/1644810
<mup> Bug #1644810: snapd system-observe interface is missing rules to allow memory usage analysis <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1644810>
<Son_Goku> zyga, niemeyer, snapd 2.35 update proposed: https://forum.snapcraft.io/t/snapd-updates-in-fedora/4342/6
<ogra> om26er, "if [[ $(cat /proc/cmdline) = *"snap_core="* ]]; then echo 1; fi" ?? geez ...
<ogra> om26er, "if grep -q snap_core= /proc/cmdline; then ... "
<ogra> (you might want to quote "snap_core=" for beautification, but thats not strictly necessary)
<ogra> :)
#snappy 2018-08-26
<Son_Goku> zyga, looks like the selinux-policy issue for EL7 will go away soon: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html-single/7.6_release_notes/#BZ1460322
<mup> PR snapd#5724 opened: tests: new test for the cpu-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5724>
<luciom> hello, is it possible to create a snap from C source using make or I have to point to a package like .deb?
<ogra> luciom, you can create a snap either way
<ogra> snapcraft is extremely flexible ... you can build things from source, use pre-compiled binaries or deb packages as you like
<luciom> ogra, thanks, what shall I set as "source-type" to compile C source? Documentation reports  that only "git, bzr, hg, svn, tar, deb, rpm, or zip" formats can be used
<ogra> luciom, really depends how you supply yur source (i mostly have my soucre on git and dont use source-type at all ... )
<luciom> ogra, I am trying to compile https://github.com/luciomarinelli/gtk-gnutella but I get error Failed to pull source: unable to determine source type of 'https://github.com/luciomarinelli/gtk-gnutella'.
<luciom> Check that the URL is correct or consider specifying `source-type` for this part.
<ogra> luciom, just try "source: ."
<ogra> since yyour snapcraft.yaml lives in the same tree you dont really need to pull it again
<ogra> looking at the tree it doesnt seem to use plain make though ... but instead some scripts to generate them
<luciom> ogra, there is a buld.sh script ready, may I feed it to snap?
<ogra> yeah, use override-build: to call ./build.sh ... and take a look at debian/control to get the "build-packages:" list (not debhelper but the rest)
<luciom> Ok, I will try thank ou
<luciom> thank you ogra
<om26er> any store (reviewer) up today ? https://dashboard.snapcraft.io/snaps/xbr-dashboard/revisions/22/
<popey> om26er: I don't even understand why that's failing
<ogra> what's the message ?
<ogra> (i cant see it, not a reviewer)
<popey> "human review required due to 'deny-connection' constraint for 'on-classic' from base declaration declaration-snap-v2_slots_deny-connection (xbr-dashboard, x11) "
<ogra> thats because the snap provides its own x11 plug
<ogra> Xwayland snaps need to do that to have x11 on core
<ogra> https://github.com/ogra1/wmx-kiosk-session/blob/master/snap/snapcraft.yaml#L46
<ogra> same as here ... i also need manual approval for my XWayland snaps
<ogra> the review tools only allow the x11 slot to come from the core snap by default ... jamie is working on a fix since a while
<om26er> @ogra: another issue is that my snap uses 'layouts' feature
<ogra> yeah, any "passthrough:" entry in your snapcraft.yaml will automatically push it into manual review
<om26er>  (https://forum.snapcraft.io/t/mirkiosk-snap-wont-start-on-ubuntu-core/7050/5?u=om26er)
<ogra> i got the exact same issue with https://github.com/ogra1/xdmcp-client/blob/master/snap/snapcraft.yaml
<om26er> that message has my snapcraft.yaml as well
<ogra> while the x11 plug thing can be whiteisted after the first manual review, i think the passthrough bit cant
<ogra> so you need to wait for jamie
<om26er> hmm, that was the only way I found for my app to work on UbuntuCore
<om26er> apparently Qt have those paths hard-coded somewhere
<ogra> if you need x11 and layouts, yeah
<ogra> the xdmcp thing above also searches fro keyboard data in a hardcoded path ... though i'd probably get away with it when re-compiling Xorg from source .... but that was too much effort for such a simple snap
<ogra> so i'm waiting for layouts to go in officially ... then you wont need passthrough anymore
<ogra> om26er, i dont get why you need the layouts though ... desktop-launch should actually export FONTCONFIG_PATH and FONTCONFIG_FILE pointing the the respective dirs under $SNAP ... whatever toolkit you use should pick up these env vars to find the shipped fonts
<dave_uy> How do I unrelease from stable channel?
<mwhudson> dave_uy: snapcraft close?
<dave_uy> That's it. Thanks.
#snappy 2019-08-19
<mup> PR snapd#7272 opened: [PATCH] interfaces/bluez: enable communication between bluetoothd and meshd via dbus <Created by jrigling> <https://github.com/snapcore/snapd/pull/7272>
<mborzecki> morning
<mborzecki> brb, new kernel
<mborzecki> re
<zyga> Hejka
<mborzecki> zyga: hey hey
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mborzecki> mvo: anything intersting happened on thu/fri last week?
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/7257 failed on 14.04
<mup> PR #7257: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/7257>
<pedronis> mvo: hi, did you see my fix for the FindU/Gid spread problem, it was a silly issue
<mvo> pedronis: aha, thanks! I noticed it failing but then had to leave and was a bit puzzled, thanks for sorting it out
<mvo> pedronis: oh fun! now I see the fix, silly indeed
<mvo> pedronis: thanks :)
<mvo> mborzecki: I run it in spread with -debug now
<zyga> re
 * zyga looks after PRs from last week
<zyga> thank you for iterating on https://github.com/snapcore/snapd/pull/7254 everyone!
<mup> PR #7254: cmd/snap-update-ns: fix pair of bugs affecting refresh of snap with layouts <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7254>
<pstolowski> morning
<zyga> hey  :)
<mvo> hey zyga and pstolowski !
<mborzecki> pstolowski: hey
<mborzecki> mvo: can you cherry-pick e864cd99affea16b8742a9f3b5257dfb5f65065f to 2.40? it's blocking https://github.com/snapcore/snapd/pull/7264
<mup> PR #7264: packaging/fedora: build on RHEL8 (2.40) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7264>
<mvo> mborzecki: sure
<mvo> mborzecki: done
<mborzecki> mvo: thank you
<pedronis> mvo: I merged master into #7124 and gave my +1, but I have a question there, that maybe you can answer too
<mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
<mvo> pedronis: looking now
<mup> PR snapd#7263 closed: snap: cleanup some tests, clarify some errors <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7263>
<mvo> pedronis: I will work on your question about 7124 and push a fix (I think we need one but I double check now)
<pedronis> thx
<pstolowski> zyga: can you finish the review of #7081? would be great to land it
<mup> PR #7081: ifacestate: optimize auto-connect by setting profiles once after all connects <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7081>
<zyga> pstolowski: sure, on it
<pstolowski> thanks!
<mvo> pedronis: I think we also need to delete the group, i'm checking now
<mvo> pedronis: aha, no, nevermind
<mup> PR snapd#7267 closed: many: simpler access to snap-seccomp version-info <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7267>
<mborzecki> this is new: 2019-08-19 07:56:22 Cannot allocate google:ubuntu-18.10-64: cannot allocate new Google server for ubuntu-18.10-64: the resource 'projects/ubuntu-os-cloud/global/images/family/ubuntu-1810' was not found
<mborzecki> images are gone or what?
<Chipaca> 1804 just worked for me fwiw
<Chipaca> bah, 09:38:37, 20 minutes ago
<jamesh> 18.10 reached end of life at the end of July
<jamesh> maybe the official images got pulled to encourage upgrades?
<mborzecki> duh
<mborzecki> thought we copy those images to our project :/
<Chipaca> mborzecki: but we don't have 18.10 in google in our spread.yaml
<mborzecki> Chipaca: that's a job for 2.40 branch
<Chipaca> ah
<mborzecki> hm an update neded then? :)
<jamesh> It's going to be interesting to see what GitHub Actions does to the CI service landscape in the next year
<Chipaca> mborzecki: pull #7127 into 2.40
<mup> PR #7127: tests: removing support for ubuntu cosmic on spread test suite <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7127>
<Chipaca> mborzecki: that's f2fa5ce91609d31b8263c92f5f46488d2eedd1f3 if it makes it any easier :)
<mborzecki> mvo: can you cherry-pick f2fa5ce91609d31b8263c92f5f46488d2eedd1f3 ?
<Chipaca> hehe
<mborzecki> Chipaca: thanks!
<zyga> mvo: did you see that snapd-master cannot be uploaded?
<pstolowski> zyga: happy birthday! ðº ð
<zyga> pstolowski: thank you :)
<zyga> more gray hair to grow I guess :D
<pstolowski> :)
<mvo> mborzecki: sure, done
<mborzecki> mvo: thank you
<mvo> zyga: yes, the socket symlink fix will fix this
<mvo> zyga: onces spread is green I think we can merge it
<mvo> zyga: oh? I had no idea - HAPPY BIRTHDAY :-D
<zyga> thank you everyone
<mborzecki> zyga: 37?
<zyga> yep
<pstolowski> oh boy, you're young
<mborzecki> zyga: happy almost-40 :)
<zyga> pstolowski: are you older?
<pstolowski> zyga: 42
<zyga> pstolowski: you look like 30
<pstolowski> :D
<mborzecki> pedronis: hi, the renames we talked about https://github.com/snapcore/snapd/pull/7273
<mup> PR snapd#7273 opened: gadget, overlord/devicestate: rename Position/Layout <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7273>
<mup> PR #7273: gadget, overlord/devicestate: rename Position/Layout <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7273>
<pedronis> mborzecki: thx, will look
<zyga> mvo: I found a simpler way to solve the lxd problem https://github.com/snapcore/snapd/pull/7274
<mup> PR snapd#7274 opened: tests: change cgroups so that LXD doesn't have to <Created by zyga> <https://github.com/snapcore/snapd/pull/7274>
<mup> PR #7274: tests: change cgroups so that LXD doesn't have to <Created by zyga> <https://github.com/snapcore/snapd/pull/7274>
<mborzecki> does the store support searching for snaps by free/non-free license?
<mvo> zyga: nice! good job
<Chipaca> mvo: silly question: where is grub-editenv supposed to be in a core18 system?
<mvo> Chipaca: we may not have it there, we don't need it for snapd, it handles all of this via the internal grubenv code
<mvo> Chipaca: do you need it for tests?
<Chipaca> ahh
<Chipaca> mvo: maybe not
<Chipaca> maybe i was just being lazy :)
<mvo> heh, ok
<zyga> pstolowski: I'm still going through
<zyga> need a coffee, brb
<Chipaca> how did one stop initramfs before it pivoted into the real thing?
<Chipaca> something-bottom
<zyga> Chipaca: break=bottom or break=top
<zyga> Chipaca: in the kernel command line
<Chipaca> thanks
<Chipaca> my core18 is coming up mounted weird :)
 * Chipaca debugs
<mborzecki> Chipaca: weird how?
<Chipaca> mborzecki: it's something i broke with my boot changes
<Chipaca> weird as in not mounted? :)
<Chipaca> but, mounted
<Chipaca> no home
<mborzecki> heisenmount
<pedronis> are we setting snap_core  wrong ?
<Chipaca> these are the questions i'm asking myself :)
<Chipaca> there's some weird dependency that i'm not seeing, so i'm going to go back to plan C and redo this bit by bit
<Chipaca> but first, a wild lunch appears!
 * Chipaca is in the tall grass
<mvo> pedronis: I added some comments to 7124, I think we want some more tests for check_snap.go otherwise just nitpicks. probably fine in a followup. I also broke the spread test - it looks like on arch groupdel is not actually working :/ at least that is what the error indicates
<mborzecki> mvo: do you have more details about the problem on arch?
<mvo> mborzecki: working on getting details, maybe just some different default
<mvo> mborzecki: USERGROUPS_ENAB seems to be false on e.g. tumbleweed (zyga can you confirm) ? this is set in login.defs
<mborzecki> mvo: 196:USERGROUPS_ENAB yes
<mvo> mborzecki: ok, I look further
<mborzecki> mvo: which spread test is that?
<zyga> mvo: checking
<zyga> mvo: USERGROUPS_ENAB is not an option listed in /proc/config.gz
<zyga> perhaps the configuration has changed and is no longer there?
<mvo> mborzecki: it was in 7124 but I think I made it robust enough now
<zyga> this is on 5.2.5
<mborzecki> zyga: it's in /etc/login.defs
<mvo> zyga: login.defs
<zyga> ah, sorry
<zyga> it's indeed set to "no"
<mvo> zyga: thanks! I updated the test
<mborzecki> btw. do user ids still start at 500 by default in opensuse?
<mborzecki> zyga: ^^
<zyga> mborzecki: I don't think so
<zyga> my id is 1000
<mup> PR snapd#7269 closed: tests: add test for services disabled during refresh hook <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7269>
<zyga> mborzecki: UID_MIN is 1000 on TW
<mup> PR snapd#7268 closed: tests: add /var/cache/snapd to the snapd state to prevent error on the store <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7268>
<mup> PR snapd#7236 closed: packaging/ubuntu-16.04: provide a way to reset snapd without purging <Created by mwhudson> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7236>
<mborzecki> mvo: shall we land https://github.com/snapcore/snapd/pull/7109 ?
<mup> PR #7109: [RFC] snap-confine: fallback gracefully on a cgroup v2 only system <Created by mvo5> <https://github.com/snapcore/snapd/pull/7109>
<mvo> mborzecki: if it works well enough for fc31 then yes
<mvo> (IMHO)
<mborzecki> mvo: with this branch, the list of failing tests is here: https://forum.snapcraft.io/t/snapd-with-unified-cgroup-hierarchy/12528/2
<zyga> Chipaca: what is 408?
<zyga> https://www.irccloud.com/pastebin/2uUquJFw/
<Chipaca> zyga: request timeout
<Chipaca> zyga: https://httpstatusdogs.com/408-request-timeout
<Chipaca> er
<Chipaca> zyga: https://httpstatusdogs.com/408
<Chipaca> zyga: note it's a _client_ error
<Chipaca> these days using GPRS you'll hit a lot of 408s
<zyga> 2fa
<zyga> mborzecki: hmm, one test exploded on me on fedora
<zyga> https://www.irccloud.com/pastebin/Q9PySGal/
<zyga> it's pretty odd, seems like random corruption and failure
<zyga> (it didn't fail on the same code before)
<zyga> sudo: unable to execute ./hightest: Permission denied
<zyga> may be something I broke after all, please ignore me
<mborzecki> zyga: iirc hightest only checks user id's in high values range
<jdstrand> mvo: hey, thanks for the updates for 7124, shall I take over now (note, groupdel --force isn't available until newer releases, but I can fix that)
<ogra> jdstrand, https://paste.ubuntu.com/p/TpynTdQv8Z/ ... adding time-control (which is a bit funny given the app doesnt have anything to do with time) makes the environment error go away due to teh explicit denial you added there ... wouldnt it make more sense to put that and the /proc/1/sched denial into some generic place instead ?
<ogra> i assume we never want any snap app to read either anyway
<mvo> jdstrand: lets have a quick sync with samuele - in a meeting right now
<mvo> jdstrand: most of my comments are really just nitpicks
<jdstrand> mvo: we need to fix the groupdel issue, so I'll fix that and small nits
<mvo> jdstrand: \o/ thank you
<jdstrand> mvo: and wait for you for other stuff
<mvo> jdstrand: sorry, was not aware that --foce is not there :/
<mborzecki> zyga: isn't that a default umask or sth?
<zyga> AFK for cooking
<mvo> jdstrand: ok, I just wait for your push and then we can do more stuff in a followup. I am happy to help if you want
<mvo> ijohnson: hey! 7214 is green and has two +1 - can I merge it ?
 * ijohnson looks
<ijohnson> mvo: I made the changes that jdstrand requested, but I'm not sure if we need jdstrand to re-approve the changes before merging
<jdstrand> ijohnson: I just now approved (for the security policy bits)
<ijohnson> thanks jdstrand, then mvo yes I think it's good to be merged
<mvo> ta
<mup> PR snapd#7214 closed: interfaces/network-setup-control: allow dbus netplan apply messages <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7214>
<ogra> zyga, i think i found a layouts bug :(
<ogra> zyga, a snap that ises a layout can be installed fine (and teh layout works as expected) ... but if i try to upgrade it i get https://paste.ubuntu.com/p/KnbskvpwQ7/
<ogra> (and note that there is no /etc/libblockdev anywhere on the host, so the error is bogus)
<ogra> s/ises/uses/
<ogra> note that snap remove/install works fine as well
<zyga> ogra: hey
<zyga> ogra: it was recently fixed, can you check edge
<ogra> i will ... good to know it is known then
<zyga> ogra: it was bug ....
<ogra> yeah
<zyga> https://bugs.launchpad.net/snapd/+bug/1808821
<mup> Bug #1808821: snap with layout cannot be updated multiple times <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1808821>
<ogra> btw, is there any possible way to layout something in /run ?
<zyga> ogra: no, not to /run AFAIR
<zyga> we NACK that for security reasons
<ogra> i'm trying to package udisks2 and it tries to write to /run/mount/utab
<zyga> there's an interface for that
<zyga> but udisks and utab is a bit of a special case
<zyga> it's complex to get right, I think utab is a bit of a lost case :/
<ogra> well, the snap uses the udisks interface
<ogra> yeah
<zyga> I can explain later after lunch, bbl
<ogra> awe dropped the official udisks2 snap and i want to make at least a demo snap for people relying on auto-mounting on core ... so i'm trying my luck here :)
<ogra> it automounts fine already
<ogra> but sadly it never cleans up /media/root but instead adds dir after dir if utab isnt accessible
<ogra> (one new one for each plug of a disk)
<Chipaca> 		return fmt.Errorf("no not remove kernel assets: %s", err)
<Chipaca> "no anything but that"
<mvo> Chipaca: heh
<mvo> Chipaca: where does this one comes from?
<Chipaca> mvo: that's in the old (current master) boot/kernel_os.go's RemoveKernelAssets
<pedronis> #7135 is ready for reviews
<mup> PR #7135: image: support prepare-image --classic for snapd snap only images <Created by pedronis> <https://github.com/snapcore/snapd/pull/7135>
<mvo> stgraber: hey, is there any in-cloud lxd images mirror? in our spread tests for snapd (that run in gce) I saw that pulling an image sometimes gets ~60kb/sec download speeds only
<jdstrand> mvo: just finishing up some unit tests
<stgraber> mvo: using ubuntu: as image remote? If so, we've been requesting it be served by more than a single machine in London for years...
<stgraber> mvo: you could use images:ubuntu/bionic which is our community image server that unlike the main Ubuntu one does have multiple distributed servers backing it
<pedronis> ijohnson: I commented briefly on 7270
<ijohnson> pedronis: but what about for the disable case? if we only save the info in the change and the change gets garbage collected we would lose that info when someone goes to enable a snap
<pedronis> ijohnson: ?
<ijohnson> say someone disables a snap, we save the list of services in the change, they wait for xyz days and the change in state.json disappears
<ijohnson> don't changes in state.json disappear?
<pedronis> ijohnson: I'm missing something here
<pedronis> what worries you?
<ijohnson> (sorry responding to your comment on #7270, figured it would be quicker over IRC)
<mup> PR #7270: [RFC] overlord: save disabled snap svcs on unlink snap tasks <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7270>
<ijohnson> I'm worried about saving the list of disabled services inside a chance since changes aren't persistent
<ijohnson> ... afaik
<pedronis> ijohnson: you are thinking of code that is not there yet
<pedronis> in the code is all about the change, no?
<pedronis> do you have a case were we need to remember across changes?
<ijohnson> snap install xyz, snap stop --disable xyz.svc; snap disable xyz; sleep 10000000000; snap enable xyz
<ijohnson> the enable and disable of the entire snap are different changes, no?
<pedronis> yes
<ijohnson> so in that case if we saved the disabled services in the change we would lose it when we disable the entire snap and re-enable the snap
<ijohnson> it would specifically not be available when we do the enable of the snap
<jdstrand> mvo: ok, I made the adjustments where it was clear to me what was wanted. I didn't do the bit flags/options struct or invert error message
<pedronis> ijohnson: I see, problem is we don't do anything like that so far
<pedronis> and there are two approaches to this
<jdstrand> mvo: I think this is what you had in mind for testing 'passing as expected': https://github.com/snapcore/snapd/pull/7124/commits/047c7bc64062d0938f1d7b152c540170d7e2f710
<mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
<pedronis> ijohnson: we could  remember the state as an "intention" when we actually get the enable/disable command
<pedronis> ignore what is really happening on disk
<pedronis> sorry I mean the enable/disable command for services (not for the snap)
<jdstrand> mvo: please let me know what else you need
<jdstrand> arg, a conflict
 * jdstrand fixes
<pedronis> ijohnson: that would be more similar to what we do in general
<pedronis> it means tough we could stomp on the user doing things outside snapd
<pedronis> we don't really promise to always support that tough
<pedronis> ijohnson: 2nd approach, we can do what your code is doing, we need to think how to make clear that that state is different from all other state we keep tough
<pedronis> which is the part that confused everybody
<pedronis> because as I said we don't have state like that
<pedronis> so far
<ijohnson> pedronis: hmm so in your first option would we really be "enabling"/"disabling" the service not in the systemd state, but rather inside snapd?
<ijohnson> so the systemd unit would always show up as "enabled", but if the user disabled it with --disable, then `snap run the-svc` would never really run the service?
<pedronis> ijohnson: isn't that true with your code as well?
<pedronis> we remember exactly what the user did
<jdstrand> mvo: ok, resolved conflict and merged
<ijohnson> no that's different from how I was imagining it, in my case the state of the service is always in systemd, and just while the snap is inactive between revisions we save the disabled services
<ijohnson> then on "link-snap", after generating the systemd services we go through that list and disable them and everything is normal
<ijohnson> s/everything/everything else/
<pedronis> ijohnson: yes, I understand
<pedronis> not sure how it relates to your point tough
<ijohnson> do you think we need a meeting to discuss? I can explain my reasoning in a forum post if that would be helpful
<mvo> jdstrand: I love your commit message "don't use --force with groupdel since it is only documented, not implemented" :)
<pedronis> ijohnson: no I think I understand you what you are saying, nothing stop us to show that snapd state and reality have diverged
<pedronis> though
<zyga> re
<pedronis> anyway I'm just trying to make clear that there isn't only one way
<zyga> sorry, kitchen emergency
<pedronis> to attack this
<pedronis> having just one place with state is appealing
<ijohnson> hmm
<jdstrand> mvo: I know right? I had to revert --force in one of my commits on this PR so I learned the hard way
<pedronis> but the current code in the PR is confusing
<ijohnson> well from a user perspective I think this would be more confusing because now `snap run the-snap.the-svc` doesn't always actually run the snap
<pedronis> snap run doesn't work for service like that
<pedronis> anyway
<pedronis> ijohnson: I mean confusing code wise
<pedronis> 3 people have read and didn't get what was supposed to be going on
<ijohnson> I understand that the code proposal was probably not along the same lines of what has done before, I can clean it up, but in the back of my mind it keeps nagging at me that systemd and snapd are no longer in sync with state
<jdstrand> mvo: so, on later releases, --force doesn't work, but -f does but on earlier releases neither are documented or implemented. anyhoo, no --force for us :)
<pedronis> ijohnson: as I said, right now I'm holding both possiblities as viable
<jdstrand> mvo: it is surprising with how mature those utilities are, how there are still changes and bugs for simple stuff
<pedronis> ijohnson: the problem with the code is generally SnapState is an absolute truth or intention about the snap
<pedronis> and the new field you added is neither
<ijohnson> well in my mind, the new field is an absolute truth, but perhaps the name is wrong
<ijohnson> the field is an absolute statement about the state of the services when the snap was unlinked, to be used when we re-link
<pedronis> ijohnson: that's the problem, as named you would think it's true also while that snap is active
<pedronis> but that's not true
<pedronis> it's not even reset
<pedronis> atm
<ijohnson> I have more changes in the link-snap that would reset it, but I hadn't decoupled that from the change that actually fixes the bug with this state
<ijohnson> I suppose I could add that change in link-snap to this PR and then rename it to be clear as to what state is being staved in SnapState
<pedronis> so DisabledServicesAsLastActive might be a better name
<pedronis> also it likely belongs to SnapState
<pedronis> and not the one of the SideInfos
<pedronis> we don't let mess much with a disable snap anyway
<ijohnson> yeah I wasn't sure which one to put it in, SideInfo was the path of least resistance for me
<ijohnson> okay, thanks pedronis I think I'm unblocked on this then I will refactor to make it clearer
<pedronis> ijohnson: basically it belongs close to the Active flag
<ijohnson> pedronis: is SnapState saved per-revision? it seems like SnapState is saved only once per snap instance, when the state I need to track is per-revision
<pedronis> ijohnson: is per snap
<pedronis> why do you think you need to track this per revision?
<ijohnson> well, imagine you have a snap that gets refreshed multiple times and you want to revert back to one of the previous revisions
<ijohnson> each revision could hypothetically have different snap service names
<ijohnson> that also at least handles service renames on revert, since if on rev 1 you have "svc1" and on rev 2 it gets renamed to "svc2", when you get to revision 3 you will only have saved "svc2" and lost the name of "svc1"
<pedronis> yes, but the service picture is only for the current one
<ijohnson> what do you mean current one? I thought this flag was meant for only non-current snaps?
<ijohnson> s/snaps/snap revisions/
<pedronis> I mean  you install a snap with svc1 and svc2
<pedronis> you refresh it
<pedronis> same services
<pedronis> you disable svc2
<pedronis> you revert
<pedronis> you want to keep svc2 disabled
<ijohnson> I guess I didn't think that was a use case we cared about
<ijohnson> I was more worried about: you install a snap with svc1 and svc2, svc2 doesn't work well, so you disable it, you refresh and now svc2 works better, you enable it, but then you revert and don't want to re-enable svc2 because it was broken in the previous revision
<ijohnson> hmm I guess I'm not sure we can handle both cases automatically without choosing one use case over the other or having some kind of flag
<pedronis> I think, thinking of disable services as per revision
<pedronis> is a bit "too much"
<ijohnson> I guess from the use case we had on the field team with edgex, it was more important for usability to not automatically re-enable services from previous revisions that were disabled
<ijohnson> because for example on low power hardware you don't want some of those services running because they are resource intensive
<pedronis> well, disable again and revert after
<ijohnson> hmm
<ijohnson> how would you handle service renames in that situation? I don't think you could
<pedronis> if there renames is all up to the snap
<pedronis> or the admin
<pedronis> notice that if there is not admin
<pedronis> there is likely no disabled services either
<zyga> I think for renames the refresh hook should have a chance to control services
<ijohnson> at least in the per-revision version, you handle svc renames going backwards in time
<ijohnson> zyga: yes the snap will always have post-refresh hook to control services
<pedronis> the problem is that is unclear that people expect that behavior
<ijohnson> zyga: I just added a spread test to make sure that works/continues to work :-)
<pedronis> ijohnson: to explain, we have similar problem with connections
<pedronis> but connections are also not per revision
<pedronis> slot and plugs can come and go
<ijohnson> hmm right I can see that
<pedronis> and be renamed
<ijohnson> I guess my expectation is that the snap's hooks can handle renames going forward in time, but snapd should handle renames going backwards in time
<ijohnson> but that's just my expectation
<ijohnson> what do we do with connections on disable/enable?
<pedronis> they stay
<pedronis> ijohnson: anywway, what we can do is not reset any disable that has no current matching service
<pedronis> (that's a bit similar to what we do with manual disconnects)
<ijohnson> yes in my implementation all service names that don't match a currently existing service it's just ignored and goes on
<ijohnson> was thinking about adding a warning or something
<pedronis> ijohnson: yes, but my point is that we also want to reset the list
<pedronis> but we could keep in it
<pedronis> those services that didn't match
<pedronis> so they would be disbaled if we go back to an impl
<pedronis> that has them
<pedronis> need to be a bit careful though
<ijohnson> I guess from a consistency standpoint, services should act like connections
<ijohnson> so if that's what's wanted I can make it per-snap, and also handle non-matching service names not disappearing somehow
<pedronis> yes
<pedronis> as I said, it would be odd for services and connections to have vastly different
<pedronis> semantics vs revisions
<ijohnson> pedronis: so we currently store connections separate from snaps in data.conns in state.json
<pedronis> we do
<ijohnson> should I try to match that more closely with storing services, or should I still try to fit the service states inside SnapState ?
<pedronis> no strong preferences
<pedronis> conns are also always there, and they are intentions
<pedronis> in your case, state is more state that we cannot keep/pass to systemd momentarily
<ijohnson> right, yeah I guess connections is also something that snapd explicitly controls
<ijohnson> I think I will stick to putting it inside SnapState then
<pedronis> ijohnson: basically, you can think this way, if there's a unit systemd is authoritative about the state, we keep our state when that cannot be
<ijohnson> yes
 * ijohnson lunches
<popey_> Since when did the output of "snap info" change to no longer show the channel map?
<popey_> wait, it shows for some but not all my snaps. how odd
<popey_> oh, it's confusing because I have a file in the current directory the same name as a snap, so it's doing "snap info folder/"
<popey_> :(
<popey_> that's gonna break a bunch of snapcrafters builds, as they use "snap info (snapname)" to interrogate the store
<zyga> popey_: this has been like that for extremely long now
<zyga> popey_: perhaps it should be tweaked in two ways
<zyga> popey_: it could say "local file in big bright green text"
<zyga> popey_: or it could require snap info ./foo to trigger that semantics
<popey_> zyga: yeah, or perhaps some way to override and say "No, check the store please!"
<Aavar> so, where does a snap keep it's config files? For example if I install something from apt it creates a config in a .file, but it seems a snap does not do that.
<ijohnson> Aavar, it depends on the snap, some snaps keep their configuration files in the installation directory $SNAP which resolves to /snap/<name-of-snap>/current/, some keep it in $SNAP_DATA, which is usually /var/snap/<name-of-snap>/current, some keep it in $SNAP_USER_DATA which is $HOME/snap/<name-of-snap>/current
<Aavar> ijohnson, Do you know if it will be purged on removal of the snap?
<ijohnson> Aavar, $SNAP and $SNAP_DATA will be removed if you do `snap remove <name-of-snap>` (but note you could restore it if you have snapshots enabled) while $SNAP_USER_DATA will persist after removal
<Aavar> ijohnson, thank you :)
<ijohnson> Aavar you're welcome :-)
#snappy 2019-08-20
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: found a bug in snap info, try `snap install hello-world hello-world_foo`, then compare `snap info hello-world` and `snap info hello-world_foo`
<mborzecki> mvo: the fix is super simple so no big deal
<mvo> nice
<mborzecki> mvo: also this request sounds sane https://forum.snapcraft.io/t/feature-request-link-to-store-page-in-snap-info/12838
<mvo> indeed
<mborzecki> i'll open PRs for both in a bit
<mvo> ta
<mup> PR snapd#7274 closed: tests: change cgroups so that LXD doesn't have to <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7274>
<mup> PR snapd#7257 closed: packaging: fix symlink for snapd.session-agent.socket <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7257>
<mborzecki> surprisingly the hardest part of the fix is figuring out the whitspace in channel output and disabling whitespace-cleanup :/
<mup> PR snapd#7275 opened: cmd/snap: fix remote snap info for parallel installed snaps <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7275>
<mborzecki> mvo: ^^
<mvo> mborzecki: thanks, looking
<mup> PR snapd#7124 closed: many: create system-usernames user/group if both don't exist <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7124>
<mvo> I just branched 2.41 locally
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<zyga> good morning
<zyga> sorry for being late, Lucy is very active today and I had to help more
<pstolowski> o/
<zyga> hey :)
 * zyga runs TW updates
<mvo> hey zyga
<zyga> good morning, how are you doing todayt?
<mvo> zyga: good, a bit sleepy but good, today is 2.41~pre1 day!
<zyga> excellent, time to roll those releases :)
<mborzecki> zyga: hey
<zyga> :)
 * zyga fights gnome-shell
<mborzecki> zyga: the year of linux desktop
<zyga> I can either get 100% scaling and background or 200% scaling and solid white background
<zyga> in x mode, in wayland the resolution is stuck but I have background
<mborzecki> zyga: ui scaling?
<zyga> yeah
<mborzecki> heh
<zyga> hey pedronis, good morning
<mborzecki> zyga: fwiw, who needs to look at the background ;) all my windows are full screen
<zyga> mborzecki: white BG at 500 nits can hurt
<mborzecki> zyga: it's called front camera flash in smartphones :)
<mborzecki> pedronis: hi, opened the PR with renames yday, https://github.com/snapcore/snapd/pull/7273 in case you want to look, or i can poke others for reviews
<mup> PR #7273: gadget, overlord/devicestate: rename Position/Layout <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7273>
<pedronis> mborzecki: I'll do a quick scan
<mborzecki> pedronis: thanks!
<pedronis> mborzecki: made a couple of remarks, about fields
<pedronis> let me know if they make sense
<pedronis> or not
<mborzecki> pedronis: s/StructureLayout/Layout/ sounds fine, but s/ContentLayout/Content/ is tricky, VoluemContent already has a field named Content, maybe RawContentLayout/RawLayout would work?
<pedronis> mborzecki: why is tricky?
<pedronis> (I'm missing something here)
<pedronis> mborzecki: what is your worry?
<mborzecki> pedronis: LaidOutStructure embeds *VolumeStructure which alreay has a field named Content (that describes all content, raw and filesystem), thus suggestion to use Raw(Content,Layout) which is only present for raw content anyway
<pedronis> mborzecki: no, then the boring LaidOutContent is probably my preference
<mborzecki> pedronis: haha, boring works for me too :)
<mup> PR snapd#7276 opened: cmd/snap: include snapcraft.io page URL in snap info output <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7276>
<mborzecki> zyga: https://lists.opensuse.org/opensuse-project/2019-08/msg00011.html
<zyga> yeah, I saw that earlier
<zyga> brb
<zyga> geez, my son is still sleeping
<mborzecki> Chipaca: thanks for the reviews, is default store check only possible within snapd?
<Chipaca> mborzecki: needs a device auth context i think
<Chipaca> mborzecki: meaning, yeah
<mborzecki> Chipaca: ok, then the store-url could be added to the snapd api on /v2/snaps/<snap>
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: would be even nicer if it came from remote
 * zyga quick breakfast
<mborzecki> Chipaca: heh ;)
<mup> PR snapd#7275 closed: cmd/snap: fix remote snap info for parallel installed snaps <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7275>
<zyga> re
<Chipaca> mborzecki: #1840751 FWIW
<mup> Bug #1840751: Please include store-url when it exists <Snap Store:New> <https://launchpad.net/bugs/1840751>
<mborzecki> Chipaca: thank you!
<zyga> yay, I think I'm down to 0 leaks on all classic systems
<zyga> core seems to leak something odd
<zyga> not snaps visible in snap list
<zyga> but actual mounted squashes and loopback devices
<zyga> I have three cleanup patches upcoming, just let the classic run finish again
<zyga> and looking at core, core tests don't overlap with classic fully so I bet there are some I just didn't look at
<pedronis> mvo: I hope I fixed 7135, not quite sure what happened with that assertion
<mup> PR snapcraft#2671 opened: docker: remove snapcraft-wrapper <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2671>
<mvo> pedronis: thanks
<mup> PR snapcraft#2672 opened: docker: use apt-get to avoid warnings <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2672>
<zyga> re
<mup> PR snapd#7277 opened: [RFC] overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>
<pstolowski> pedronis: ^ a high-level ack/nack on the apporach would be great
<pstolowski> *approach
<pstolowski> zyga: sorry for pestering... #7081 waves at you ;)
<mup> PR #7081: ifacestate: optimize auto-connect by setting profiles once after all connects <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7081>
<zyga> indeed, after this call I'll jump right in
<mup> PR snapcraft#2673 opened: Single dockerfile <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2673>
<pedronis> pstolowski: btw, there are still a couple of things to do here: https://trello.com/c/yxC3omC9/245-snap-snapctl-unset-support
<pstolowski> pedronis: yes, i saw your comment, thanks, i'm on it
<mborzecki> Chipaca: https://paste.ubuntu.com/p/sFtP2kQ5M6/ not sure about the part that finds whether it's a custom store or not
<pedronis> mborzecki: I think we shouldn't do anything until we have store support
<mup> PR snapd#7031 closed: debian: re-enable systemd environment generator <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7031>
<mborzecki> pedronis: yeah, you're probably right, i'll keep the branch so that the client bits are ready when store updates the api
<mup> PR snapd#7278 opened: tests: unmount fusectl after testing <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7278>
<mup> PR snapd#7279 opened: tests: restore nsdelegate clobbered by LXD <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7279>
<mup> PR snapd#7276 closed: cmd/snap: include snapcraft.io page URL in snap info output <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7276>
<mup> PR snapd#7264 closed: packaging/fedora: build on RHEL8 (2.40) <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7264>
<mup> PR snapd#7280 opened:  debian: re-enable systemd environment generator (2.41) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7280>
 * zyga coffee
<Chipaca> jdstrand, zyga, mvo, fun coffee read: https://lwn.net/Articles/796687/
<zyga> Chipaca: I take that and raise https://lwn.net/Articles/796641/
<mup> PR snapd#7281 opened: cmd/snap: fix snap unset help string <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7281>
<mvo> Chipaca: nice, that was on my reading list
<Chipaca> zyga: fuse tangled into the package manager
<mvo> Chipaca: nice to hear that its apparently worth it :)
<Chipaca> zyga: what could go wrong?
<Chipaca> mvo: :)
<zyga> Chipaca: squashfs :)
<Chipaca> zyga: fuse pinning a core, but everywhere all the time
<Chipaca> and that's when it's working :)
<Chipaca> anyway, will read more
<Chipaca> mvo: when was core 4486 from?
<Chipaca> never mind, over a year old
 * Chipaca used 'git log' to get a good enough guess
<Chipaca> ok i'm off to look lunch in the face
<mup> PR snapd#7247 closed: interfaces/mount: forward SNAPD_DEBUG to ns tools <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7247>
<mup> PR snapd#7282 opened: asserts: move Model to its own model.go <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7282>
<diddledan> seems futexes are blocked but silently... https://www.irccloud.com/pastebin/rolINucz/
<diddledan> I can't find any mention of seccomp blocking the syscall in /var/log
<mup> PR snapcraft#2664 closed: cli: handle exception when cleaning a part with a fresh project <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2664>
<mup> PR snapcraft#2666 closed: tests: move meta testing to its own package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2666>
<mup> PR snapcraft#2667 closed: yaml utils: move OctInt from meta <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2667>
<Chipaca> mvo: https://irclogs.ubuntu.com/2019/08/19/%23snappy.html#t15:08
<mup> PR snapd#7283 opened: tests: unmount binfmt_misc on cleanup <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7283>
<mup> PR snapd#7278 closed: tests: unmount fusectl after testing <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7278>
<zyga> mvo: is this what you mentioned a moment ago?
<zyga> https://www.irccloud.com/pastebin/e89eTfcR/
<Chipaca> zyga: what was this about snap info of files?
<Chipaca> something to do with The Pope(y)
<pedronis> Chipaca: I think we might check if a dir exist before doing anything else, that does unexpected/expected things if you happen to be sitting somewhere with a dir foo which contains snap foo
<Chipaca> hmm, i thought i'd checked for that, but â¦ maybe? is there a concrete bad case?
<pedronis> Chipaca: it's not a priority either way, please queue it
<Chipaca> there is some weird behaviour if you have a directory foo and do 'snap info foo' and foo is an installed snap that the store knows about and the foo directory does not contain a snap
<Chipaca> e.g., snap install http go; cd /snap/go/current/src/net; snap info http â no channel map; weird
<jdstrand> Chipaca: re lwn> on the agenda for lunch :)
<Chipaca> jdstrand: :)
<mup> PR snapcraft#2659 closed: Add support for building inside podman containers <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2659>
<Chipaca> but, i'd like to know if that is the strangeness or if there's something worse
<Chipaca> popey: ^
<mvo> zyga: yes
<diddledan> jdstrand: I presume futex is being blocked somewhere but I can't find any log: https://www.irccloud.com/pastebin/rolINucz/
<mup> PR snapd#7284 opened: tests: clean user and group for test system-usernames-install-twice <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7284>
<jdstrand> diddledan: the futex syscall is allowed by default. the man page for futex has some things to say about EPERM. specifically: "(FUTEX_UNLOCK_PI)  The  caller  does not own the lock represented by the futex word" and "(FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_CMP_REQUEUE_PI)  The  caller is  not  allowed  to  attach  itself  to the futex at uaddr". you may want to see the man page for more context
<diddledan> hmm
<jdstrand> for the last point, it also says "(This may be caused by  a state corruption in user space.)
<diddledan> I wonder what mycroft is doing that it is failing
<jdstrand> "
<diddledan> something in the voice/speech part of mycroft is reporting this https://www.irccloud.com/pastebin/crszJzeL/
<diddledan> so in response I did an strace which only shows futex failing
<jdstrand> hmm
<diddledan> I'm not sure where that error lies in the mycroft code though, because it's huge :-)
<diddledan> mycroft itself is python but it has a few C-like libraries that it calls - I did a bit of research and found references to C++
<diddledan> research on the specific error message, I mean
<mup> PR snapd#7285 opened: httputil: improve http2 PROTOCOL_ERROR detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/7285>
<jdstrand> diddledan: does it use the preload for the semaphore? it is python multithreading that needs that.... I would've expected a denial. it is possible the kernel is rate limiting it. you could: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.mycroft.* ; sudo journalctl --output=short --follow --all | sudo snappy-debug
<diddledan> I do launch it with the snapcraft-preload, yes
<jdstrand> diddledan: then try again. the reload will cause denials that are being rate limited to show (until they are rate limited again) and the snappy-debug turns off general kernel rate limiting
<jdstrand> diddledan: the above might make a denial pop out that was rate limited, so still worth a try
<zyga> Chipaca: afk
<Chipaca> zyga: ?
<ijohnson> thanks Chipaca!
<ijohnson> Chipaca: also do you think the unit tests I have there are sufficient or do I need to add more, etc. ?
<mup> PR snapd#7286 opened: tests: use images:ubuntu/ in lxd tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7286>
<ijohnson> (in #7149 that is)
<mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<Chipaca> ijohnson: hmm, i didn't look at coverage
<Chipaca> ijohnson: will do in a bit
<ijohnson> okay, sounds good
<mup> PR snapd#7287 opened: hookstate/ctlcmd: snap unset command <Created by stolowski> <https://github.com/snapcore/snapd/pull/7287>
<Chipaca> hmm
<mvo> zyga: fwiw, I think I know why the system-users test is failing, fixing now
<zyga> Oh? Iâm eager to know
<Chipaca> ijohnson: maybe i'm not spotting it: what would cause jsonResult to be true?
<Chipaca> ijohnson: in model and serial queries i mean
<ijohnson> specifying ?json=true in a REST API call (i.e. not using the CLI)
<mvo> zyga: PR will be up in some minutes but its boring :)
<Chipaca> ijohnson: thought so. Commented, wrt coverage and other bits and bobs
<ijohnson> got it, thanks
<Chipaca> ijohnson: I'd accept these to be in a followup fwiw, if it makes this easier to land
<Chipaca> it's already quite big
<ijohnson> I dunno, what does mvo think?
<zyga> re
<zyga> Chipaca: sorry, I noticed the message and replied from my phone
<zyga> Chipaca, popey: you guys should talk about snap info :)
<mvo> ijohnson: I miss some context I think but followup sounds good especially if the pr is already big
<mvo> 2.41 is branched so having it in a not 100% state for a tiny bit is not too terrible
<ijohnson> mvo: it's PR #7149, not sure if you wanted to make a review pass on that
<mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<ijohnson> IIRC, this wasn't needed for 2.41
<mvo> ijohnson: yeah, its fine for .42
<ogra> .42 is the answer !
<diddledan> is .41 out yet? *ducks the swinging punches*
<ijohnson> mvo: so do you want to review that PR as well before landing for 2.42? or am I good to merge once tests are green?
<Chipaca> ijohnson: needs two approvals to merge tho
<ijohnson> ah I guess Graham only reviewed the help message, I forgot that
<mvo> ijohnson: yeah, what john said, needs two +1 :)
<mup> PR snapd#7288 opened: tests: cleanup "snap_daemon" user in system-usernames-install-twice <Created by mvo5> <https://github.com/snapcore/snapd/pull/7288>
<zyga> mvo: did you see https://github.com/snapcore/snapd/pull/7284
<mup> PR #7284: tests: clean user and group for test system-usernames-install-twice <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7284>
<mvo> zyga: meh, I did not
<zyga> your PR looks more comprehensive :)
<zyga> but I didn't look deeper yet
<mvo> zyga: yeah, the extrausers bit
<mup> PR snapcraft#2669 closed: Plugin catkin: forward parallel build count <Created by artivis> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2669>
 * cachio lÃ±unch
<mup> PR snapd#7281 closed: cmd/snap: fix snap unset help string <Simple ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7281>
<mup> PR snapd#7280 closed:  debian: re-enable systemd environment generator (2.41) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7280>
 * zyga takes a break
<zyga> I added service leak detector
<zyga> checking for stuff that affects systemd serrvices
<zyga> *services
<zyga> so looking forward to what the outcome will be
<zyga> I'll grab coffee and be back to check
<cachio> pstolowski|afk, #7110 updated
<cachio> thanks
<mup> PR #7110: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>
<mup> PR snapd#7289 opened: tests: ubuntu 18.10 removed from the google-sru backend on the spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7289>
<zyga> re
<mup> PR snapd#7279 closed: tests: restore nsdelegate clobbered by LXD <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7279>
<mup> PR snapd#7290 opened: tests: allow test user XDG_RUNTIME_DIR to phase out <Created by zyga> <https://github.com/snapcore/snapd/pull/7290>
 * cachio afk
<mup> PR snapd#7283 closed: tests: unmount binfmt_misc on cleanup <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7283>
<popey> Zyga Chipaca can we talk about snap info over mail or a bug? Been on a plane for 11 hours
<diddledan> where you at this week, popey ?
<popey> Arizona
<diddledan> \o/
<popey> It am hot
<diddledan> boo
<diddledan> I saw your post earlier about 40degrees
<mup> PR snapd#7291 opened: Add new cases into arch_test <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7291>
<mup> PR snapd#7292 opened: interfaces: k8s worker node updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7292>
<mup> PR snapd#7293 opened: interfaces: k8s worker node updates - 2.41 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7293>
#snappy 2019-08-21
<mborzecki> morning
<mup> PR snapd#7282 closed: asserts: move Model to its own model.go <Simple ð> <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7282>
<guiverc> if `snap set core ..` will set a value, is there a command/option to show the value before without changing?
<mborzecki> guiverc: there's snap get, try `snap get system -d` (system is an alias for core)
<guiverc> thanks mborzecki, appreciated..  i expected a bunch of results but only "seed".. thank you.   (now I have two!)
<mborzecki> mvo: hey
<mborzecki> mvo: pushed a little patch to https://github.com/snapcore/snapd/pull/7288
<mup> PR #7288: tests: cleanup "snap_daemon" user in system-usernames-install-twice <Created by mvo5> <https://github.com/snapcore/snapd/pull/7288>
<mvo> mborzecki: thank you
<mvo> mborzecki: looking
<mvo> mborzecki: are tests any happier this morning?
<mup> PR snapd#7293 closed: interfaces: k8s worker node updates - 2.41 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7293>
<mup> PR snapd#7292 closed: interfaces: k8s worker node updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7292>
<mborzecki> mvo: snap_daemon pops up, unless one was lucky to hit the right spread seed/job sequence
<mvo> mborzecki: aha, shellecheck ! thank you
<mvo> zyga: second review of 7288?
<mvo> zyga: please :)
<mvo> mborzecki: thanks, lets try to get the fix in then
<mvo> mborzecki: or we merge sergios fix and put mine on top
<mvo> mborzecki: its missing the --extrausers but otherwise is good afaict
<mborzecki> mvo: fine either way
 * mvo flips a coin
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/7166 has some unforseen consequences in spread tests
<mup> PR #7166: client: add doTimeout to http.Client{Timeout} <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<mvo> mborzecki: oh no
<mvo> mborzecki: lets park it for now, it seems its full of it
<mvo> mborzecki: I mean, its a snake nest
<mborzecki> mvo: in detail tests/main/snap-network-errors fails, we try to cause a dns timeout to trigger particular error message, but we hit the context deadline earlier than that :)
<mup> PR snapd#7284 closed: tests: clean user and group for test system-usernames-install-twice <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7284>
<mup> PR snapd#7291 closed: tests: add new cases into arch_test <Created by ardaguclu> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7291>
<mup> PR snapd#7289 closed: tests: ubuntu 18.10 removed from the google-sru backend on the spread.yaml <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7289>
<mvo> shame that images:ubuntu/... in lxd is different, the speed we get from it is impresssssive (almost 100Mb/sec)
<pstolowski> morning
<pstolowski> mvo: ouch :(
<mvo> pstolowski: good morning
<mvo> pstolowski: ouch for what?
<pstolowski> mvo: for images; and hey :)
<mvo> pstolowski: heh - yes!
<mvo> pstolowski: hopefully its something silly but I have no idea right now, running spread to get a machine
<mvo> pstolowski: but the speed is impressive
<pstolowski> uhm
<mborzecki> pstolowski: hey
<zyga> good late morning
<zyga> mvo: that images:ubuntu is different is very eyebrow-raising
<zyga> I would love to understand that more, I'll ask stephane
<mvo> pedronis: just fyi, I updated the official spreadsheet with some "c" and the roadmap forum
<mvo> zyga: ta
<pedronis> mvo: thx
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7287#pullrequestreview-277252195
<mup> PR #7287: hookstate/ctlcmd: snapctl unset command <Created by stolowski> <https://github.com/snapcore/snapd/pull/7287>
<pstolowski> zyga: ty
<mborzecki> mvo: zyga: https://events.linuxfoundation.org/events/linux-security-summit-north-america-2019/program/schedule/ sadly slide deck is not available, will have to wait for videos
<mborzecki> mvo: zyga: duh, bad link, try this https://sched.co/RHal
<zyga> yeah, I noticed your interest on twitter :)
<mvo> mborzecki: interessting
<mborzecki> zyga: yeah, https://static.sched.com/hosted_files/lssna19/e5/LSS2019-Retrospective-16-9.pdf this talk in particular could be interesting
<mborzecki> zyga: like their naming, 'research directorate' :D
<zyga> we should have a research overlord
<mup> PR snapd#7294 opened: tests: trivial snapctl test cleanup <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7294>
<pstolowski> mvo: ^ a byproduct of your #7287 review ;)
<mup> PR #7287: hookstate/ctlcmd: snapctl unset command <Created by stolowski> <https://github.com/snapcore/snapd/pull/7287>
<mvo> pstolowski: heh, nice
<mvo> pstolowski: thank you!
<zyga> hmm
<zyga> mborzecki: can you open snap-mgmt.sh.in please
<zyga> mborzecki: go to line 50
<zyga> mborzecki: it says
<zyga> units=$(systemctl list-unit-files --no-legend --full | grep -vF snap.mount.service || true)
<zyga> mborzecki: would you expect that to produce output?
<zyga> ah, sorry ignore me
 * zyga is silly
<mborzecki> zyga: hmm looking at the code, we could do better and glob unit names, though idk if the mock systemctl in 14.04 supports that
<zyga> mborzecki: my problem was that it inherited "set -x"
<zyga> so it was super noisy in test output and I got confused about why I'm looking at all the shell output that looked like systemctl output
<mborzecki> zyga: right, so globbing would fix that ;)
<mborzecki> zyga: systemctl list-unit-files --no-legend --full var-lib-snapd-snap\*
<zyga> mborzecki: set +x :D
<mvo> mborzecki, zyga: can you somehow figure out if we have an rpm that provdies buildrequires for golang.org/x/net (or /x/net/http2)?
<mvo> on suse and fedora?
<zyga> checking
<mborzecki> mvo: probably golang-x-net-devel
<zyga> mvo: actually rpm has a nice thing for that
<mvo> mborzecki: nice
<zyga> rpm -q --whatprovides 'golang(golang.org/x/net/http2)'
<mvo> zyga: cool, what does it output for you on suse?
<zyga> nothing provides it
<zyga> checking fedora
<mvo> zyga: meh, thats slightly sad
<zyga> mvo: the nice aspect is that the golang() function takes a normal go import
<zyga> mvo: that's ok, just vendor
<mborzecki> zyga: you need to have the package instaled for that to work though
<zyga> suse switched policy
<mvo> zyga: we vendor on opensuse?
<zyga> mborzecki: ahh
<mvo> zyga: nice
<zyga> mvo: yes
<mborzecki> zyga: dnf provides 'golang(golang.org/x/net/http2)'
<mborzecki> golang-x-net-http-devel in rawhide at least
<zyga> zypper what-provides 'golang(golang.org/x/net/http2)' -> empty
<zyga> mvo: fedora 29 -> ... (checking)
<mvo> this may make 7285 not viable - oh well
<pstolowski> :(
<mvo> yes
<mvo> :(
<zyga> mvo: look  https://www.irccloud.com/pastebin/qcjPShoI/
<pstolowski> that reminded me of gorilla PR & fedora again. onto it
<mvo> zyga: thanks, so fedora seems to be fine
<pstolowski> mvo: what is the firstboot speedup trello card about?
<mvo> pstolowski: don't worry about it just yet, I tried to put people to the next tasks we need to do, its still a bit tentative. the idea for this card is that we want to do certain operations during image creation already (like hashing and puting the wrappers in place) instead of doing these expensive operations in firstboot
<mvo> stgraber: it looks like the images:ubuntu/* do not have fuse installed by default so snapd will not work there (our snapfuse help dies with a confusing mount error). could those be added? (cc zyga)
<zyga> mvo: thank you :)
<zyga> brb
<pstolowski> mvo: i see, makes sense. 19.10 is not too far away though ;)
<mborzecki> zyga: makes me wonder if there's a switch for dnf that does the same as rpm -q --provides
<mvo> pstolowski: yes
<mvo> pstolowski: its not far and there is stuff that needs finishing first but I think its one of the next things we need to tackle :)
<pstolowski> mvo: sounds good
<ackk> hi, snapcraft question, "system-usernames" still needs to be passed via "passthrough", right?
<mborzecki> zyga: dnf repoquery --provides golang-x-net-http-devel-0-0.53.20190622git1da14a5.fc31.noarch :P
<pedronis> ackk: yes
<ackk> pedronis, thanks
<zyga> re
<mborzecki> needs a 2nd review https://github.com/snapcore/snapd/pull/7273
<mup> PR #7273: gadget, overlord/devicestate: rename Position/Layout <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7273>
<zyga> mborzecki: found a typo in that nfs test
<mborzecki> zyga: haha
<zyga> umount vs unmount
<zyga> man...
<zyga> on the up side, cleanup-tool will fix that
<zyga> because it will not be spelled at all
<mup> PR snapd#7295 opened: tests: spam test logs less while waiting for systemd unit to stop <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7295>
<mup> PR snapd#7296 opened: tests: remove redundant activation check for snapd.socket snapd.service <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7296>
<mborzecki> mvo: shall we land https://github.com/snapcore/snapd/pull/7288 ?
<mup> PR #7288: tests: cleanup "snap_daemon" user in system-usernames-install-twice <Created by mvo5> <https://github.com/snapcore/snapd/pull/7288>
<zyga> + apt-key add -
<zyga> + wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key
<zyga> gpg: no valid OpenPGP data found.
<zyga> hmmm, not a great day today
<mvo> mborzecki: if it has 2 +1 yes - I saw anohter failure recently
<mvo> mborzecki: I think the fix from sergio is not complete
<zyga> mvo: did you see that gpg error?
<mvo> zyga: I did not
<mup> PR snapd#7297 opened: cmd/snap-mgmt: set +x on startup <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7297>
<zyga> nfs-test is now clean on arch
<zyga> nfs-support test
<zyga> I also found a few minor mistakes there, all corrected now
<Chipaca> sigh. snap downloads broken right now.
<Chipaca> good time to have lunch
<zyga> uh
<zyga> Chipaca: store side?
<Chipaca> yes
<zyga> uh
<zyga> ok, break time
<Chipaca> yes
<zyga> just kidding
<zyga> review time
<zyga> or actually I *could* go on a bike ride
<mborzecki> zyga: https://paste.ubuntu.com/p/xYgYggB78W/ the diff is here: https://paste.ubuntu.com/p/HMxFrdjVxs/
<zyga> looking
<zyga> mborzecki: something doesn't look right
<zyga> the MS_SLAVE change must happen after unshare
<zyga> also tabs-vs-spaces :)
<zyga> mborzecki: move the /var/snap and SNAP_MOUNT_DIR changes to global setup
<zyga> I think the rest is ok
<zyga> mborzecki: please run the mount-ns test and see what it tells you before and after
<mborzecki> zyga: unshare(CLONEW_NEWNS) is called before sc_setup_parallel_instance_classic_mounts()
<zyga> mborzecki: also, to see what happens, always unshare for classic snaps
<zyga> mborzecki: right but what setup parellel instance classic mount does is too much
<zyga> the loop must be in the global setup code
<zyga> well
<zyga> not must but should be :)
<zyga> otherwise you are making this change here after unshare
<zyga> but it propagates out anyway
<zyga> because / is shared
<zyga> so let's be explicit and make it globally so
<mborzecki> ah, right
<mborzecki> ok, let me fix that
<zyga> thanks!
<zyga> and make sure to run that test :)
<mborzecki> yup
 * zyga -> coffee
<zyga> Chipaca: should we run the connectivity check in the 'before we waste spread time' part of the check?
<mup> PR snapd#7298 opened: tests: clean up after NFS tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7298>
<zyga> ok really time for that coffee
<mborzecki> parallel installed go and node seem to work https://paste.ubuntu.com/p/jQwzJM2Bht/
<mborzecki> my jsfu is too low to test anything more than simple file writes though
<zyga> mborzecki: where is lsof on arch?
<zyga> mborzecki: I found a pair of interesting bugs in tests
<zyga> ok, found it
<zyga> extra/lsof
<mup> PR snapcraft#2668 closed: Restore cmake artifacts <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2668>
<mup> PR snapd#7299 opened: sanity: report proper errror when fuse is needed but not available <Created by mvo5> <https://github.com/snapcore/snapd/pull/7299>
<mup> PR snapd#7300 opened: interfaces/network-{control,manager}: allow 'k' on /run/resolvconf/** <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7300>
<mvo> jdstrand: thanks for this one! is it the only change we need?
<mup> PR snapd#7301 opened: interfaces/network-{control,manager}: allow 'k' on /run/resolvconf/** - 2.41 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7301>
<jdstrand> mvo: np. sorry about the kernel regression
<mvo> jdstrand: no worries
<jdstrand> mvo: curious, what is the timeline for 2.41? should I do a 2.40 PR?
<mup> PR snapcraft#2674 opened:  file_utils: introduce link_or_copy_files <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2674>
<mvo> jdstrand: release to stable planned on sep 9, see https://forum.snapcraft.io/t/the-snapd-roadmap/1973
<jdstrand> mvo: you make such pretty tables :)
 * jdstrand would resort to ascii art
<mup> PR snapcraft#2675 opened: docs: quick init for lxd in HACKING.md <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2675>
<mup> PR snapd#7302 opened: cmd/snap-confine: add support for parallel instances of classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
<mborzecki> zyga: the code is up, we can interate on this ^^
<ackk> jdstrand, hi, thanks for the new snapd build, seems to work nicely. To confirm, that's called 2.40 but it's basicaly 2.41 right?
<jdstrand> ackk: it is, but you should be able to use --edge now
<jdstrand> edge, maybe beta
<jdstrand> sorry, --beta
<ackk> jdstrand, nice
<jdstrand> ackk: https://forum.snapcraft.io/t/the-snapd-roadmap/1973
<ackk> yeah I was just looking at that :)
<jdstrand> probably both actually (I see today that edge has the properly version)
<ackk> jdstrand, is the snap_daemon user created by the deb or snapd itself? IOW do we need the 2.41 deb to be in bionic to get that, or will the beta snap do it?
<jdstrand> mvo: 2.5 weeks might be a little too long for robertliu on that bug. we might need an out of band snapd build with that cherrypick. please advise.
<mup> PR snapd#7294 closed: tests: trivial snapctl test cleanup <Simple ð> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7294>
<jdstrand> mvo: there is a possibility that there could be another similar bug or two, but I don't think many
<jdstrand> ackk: it is created by snapd
<ackk> jdstrand, oh cool, so on a clean bionic install snap install snapd --beta should be all we need?
<jdstrand> ackk: this will work with just beta and on core
<jdstrand> ackk: yep
<ackk> awesome
 * ackk gives that a spin
<ackk> # snap install --beta snapd
<ackk> error: cannot install "snapd": cannot install snapd snap on a model without a base snap yet
<ackk> jdstrand, ^ but I have core18 installed
<ackk> I guess I need "core" as well?
<jdstrand> mvo: not many because as I said in the bug, all the interfaces have been run through later kernels. in this NM case, the NM 1.2 snap on uc16 did something different than the 1.10 snap. I don't think there are going to be a lot of these
<jdstrand> ackk: on bionic, just 'core'
<jdstrand> ackk: afaik, bionic won't reexec into the snapd snap yet. (also, looking at snap info snapd, edge and beta appear to be new enough, though report 2.40 still)
<ackk> jdstrand, I think it does if you have the latest deb?
<mvo> jdstrand: good, thank you
<jdstrand> ackk: that is a question for others here
<jdstrand> mvo: do you want a 2.40 PR?
<mvo> jdstrand: its fine, I can cherry pick there
<mvo> jdstrand: I hope there will no 2.40 point release though
<ackk> jdstrand, so I'm confused, on bionic do I just install core or core + snapd --beta?
<jdstrand> mvo: do you require a point release for a hotfix? (not sure what you would call that). I'm a little concerned since it is network-manager we need that
<jdstrand> ackk: all I did in my testing was the deb in the archive and core --beta
<ackk> jdstrand, oh ok cool
<ackk> thanks
<jdstrand> ackk: if you have the snapd snap installed, then I guess you could try a newer one of it, but someone else would need to comment
<ackk> jdstrand, yeah my next question was indeed, if you have both core and snapd, which snapd is being re-exec'd ?
<jdstrand> mvo: anyhoo, let me know if you need anything. since you are reading this, could you comment on ackk's question?
<zyga> mborzecki: review sent
<mborzecki> zyga: thx
<mup> PR snapd#7296 closed: tests: remove redundant activation check for snapd.socket snapd.service <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7296>
<zyga> jdstrand: could you look at https://github.com/snapcore/snapd/pull/7205 please
<zyga> it's just a RFC, 12 lines of code
<mup> PR #7205: rfc: introduce confinement options failsafe flag <Created by zyga> <https://github.com/snapcore/snapd/pull/7205>
<ackk> jdstrand, will beta be versioned 2.41 at some point, or just at release?
<jdstrand> ackk: that would be another question for mvo
<ackk> jdstrand, he, sorry
<jdstrand> ackk: the fact that snap info show it as 2.41, I would expect snap version to be the same
<ackk> I see 2.40 in snap info snapd"
<ackk> jdstrand, also snap version reports 2.40
<jdstrand> zyga: I could destroy as system in less than that ;)
<jdstrand> s/as/a/
<zyga> jdstrand: I know you could, but I can only propose a small RFC :D
<jdstrand> I thought I looked at this already...
<zyga> jdstrand: perhaps at the sprint
<jdstrand> yeah, I didn't publicly comment apparently
<mvo> ackk: its a bug, its on my list, next beta for the snapd snap should have a 2.41~preN version again
<zyga> jdstrand: thank you
<jdstrand> mvo: can you describe when reexec happens wrt the deb, core, core18 and the snapd snap?
<jdstrand> mvo: in this case bionic, but also generally
<ackk> mvo, ah, awesom thanks. I take that means that "assumes: [snapd2.41]" will work at that point?
 * jdstrand doesn't know either, but should
<mvo> jdstrand: re-exec will check the version and use semantic version compare to decide if it should re-exec
<jdstrand> mvo: so it knows to check all of core, core18 and snapd snaps?
<jdstrand> that was the bit I wasn't sure of. I've only ever personally worked with core
<ackk> I thought if the snap has a base: declaration, the snapd snap was used instead
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7298 is green
<mup> PR #7298: tests: clean up after NFS tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7298>
<zyga> mvo: if you could review I would be 50% closer to green classic mount table
<mvo> zyga: ok, I see what I can do
 * zyga is having lunch 
<zyga> mborzecki: can you review https://github.com/snapcore/snapd/pull/7290 please
<mup> PR #7290: tests: allow test user XDG_RUNTIME_DIR to phase out <Created by zyga> <https://github.com/snapcore/snapd/pull/7290>
 * Chipaca thinks he found the bug and is as happy as a partridge
 * Chipaca suspects "feliz como perdiz" does not translate well
<mup> PR snapd#7303 opened: Allow reading an Xwayland Xauth file. Fixes LP: #1840925 <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7303>
<oSoMoN> jdstrand, your opinion welcome on the above ^
<mup> PR snapd#7304 opened: many: move channel parsing to snap/channel <Created by pedronis> <https://github.com/snapcore/snapd/pull/7304>
<pedronis> Chipaca: that's probably something for you to review ^
<Chipaca> pedronis: tag me for it please
<Chipaca> just adding unit tests for the bits that broke the world :-)
<Chipaca> it was: when you have a model, and the model has a base that is not "core", and you install "core", the new code tried to setnextboot to it
<Chipaca> which was a lot of fun
<mvo> Chipaca: the code tried to change next boot to core? i
<Chipaca> the tests were broken because they tested a snap that was called "core" but was type snap.TypeBase
<Chipaca> which is not the type of "core" in the wild :-)
<Chipaca> mvo: the new code
<mvo> Chipaca: aha, ok
<mvo> Chipaca: puhh, I was concerned :)
<mvo> Chipaca: thanks for tracking this down!
<Chipaca> and while doing that i've thought of ways to make it simpler, but at this point it'll probably be a sneaky followup
<Chipaca> also, i've got a fix for a bug in download i need to push
<Chipaca> also also i need a break
 * Chipaca breaks
<Chipaca> wrt bug in download: https://forum.snapcraft.io/t/snaps-download-should-be-resumable/3561/11?u=chipaca and down
 * Chipaca really breaks
<mup> PR snapd#7305 opened: check-pr-title.py: allow {} in pr prefix <Created by mvo5> <https://github.com/snapcore/snapd/pull/7305>
<ijohnson> hey mvo, since git blame says you last touched TestInstallDefaultProviderRunThrough, should the order of the ops in the fake ops be deterministic? The test seems to expect that, but I am getting different ordering of the ops every time I run
<ijohnson> all I changed was I added new ops when my additional backend methods run, but those are always in the same relative positions
<ijohnson> (need to step out for a couple minutes, but we can also discuss tomorrow during SU if it's near your EOD too)
<mvo> ijohnson: I'm near EOD sry but also slightly puzzled, this test runs all the time so if its not deterministic must be causing this (I probably lack context)
<ijohnson> okay, np I'll dig deeper later this afternoon and we can sync up on it tomorrow
<pedronis> ijohnson: you said you are adding ops?
<pedronis> if you are missing wait between tasks
<ijohnson> to the fake ops in the fakeSnappyBackend
<pedronis> you might get out of order stuff
<ijohnson> hmm
<pstolowski> ijohnson: if you're getting ops in random order, it usually means some of the tasks are not chained up properly (WaitFor etc); are you touching task creating code as well?
<pedronis> ^ this
<ijohnson> it's possible I'm missing those, but I'm not creating actual Task structs, just additional ops in the fakeSnappyBackend to track what was called
<ijohnson> just like f.appendOp(&fakeOp{...}}
 * ijohnson will be back in a little bit
<pstolowski> ijohnson: hard to tell without more context.. maybe create a draft of your PR so I can take a look
<pstolowski> ijohnson: eod here.. if you won't figure this out i can look at this tomorrow morning
 * pstolowski pstolowski|afk
<mup> PR snapd#7306 opened: overlord/configstate: sort patch keys to have deterministic order with snap set <Created by stolowski> <https://github.com/snapcore/snapd/pull/7306>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7306#pullrequestreview-277924024
<mup> PR #7306: overlord/configstate: sort patch keys to have deterministic order with snap set <Created by stolowski> <https://github.com/snapcore/snapd/pull/7306>
<ijohnson> pstolowski: if I can't figure it out by my EOD I'll push up the changes to my PR and add a comment there explaining it
 * pedronis dinner
<zyga> mvo: https://github.com/snapcore/snapd/pull/7288/files#r316296747
<mup> PR #7288: tests: cleanup "snap_daemon" user in system-usernames-install-twice <Created by mvo5> <https://github.com/snapcore/snapd/pull/7288>
<zyga> mvo: let me know, I'll gladly send the changes
 * zyga is back to iterate on PRs
<mup> PR snapcraft#2676 opened: spread: 64 workers for each system <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2676>
<zyga> systemd and cgroups across time
<mup> PR snapd#7295 closed: tests: spam test logs less while waiting for systemd unit to stop <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7295>
<mup> PR snapcraft#2677 opened: erorrs: preserve quotes when printing SnapcraftPluginCommandError <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2677>
 * cachio EOD
<mup> PR snapcraft#2678 opened: [WIP] cli: introduce --provider <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2678>
<mup> PR snapcraft#2679 opened: Colcon <Created by danielwangksu> <https://github.com/snapcore/snapcraft/pull/2679>
#snappy 2019-08-22
<mup> Bug #1841001 opened: removing docker snap leaves apparmor misconfigured <Snappy:New> <https://launchpad.net/bugs/1841001>
<mborzecki> morning
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: pedronis: morning guys
<mup> PR snapd#7304 closed: many: move channel parsing to snap/channel <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7304>
<mup> PR snapd#7305 closed: check-pr-title.py: allow {} in pr prefix <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7305>
<mup> PR snapd#7303 closed: interfaces/wayland,x11: allow reading an Xwayland Xauth file. Fixes LP: #1840925 <Created by oSoMoN> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7303>
<mborzecki> mvo: check this out https://i.imgur.com/4P10y8J.png
<mvo> mborzecki: woooooooo
<mborzecki> blender          2.80     33     stable    blenderfoundation*  classic
<mborzecki> blender_279      2.79b    20     2.79      blenderfoundation*  classic
<mvo> mborzecki: thats really cool
<mborzecki> mvo: didn't try any rendering though, hope they don't do some funny ipc with named sockets/semaphores that could conflict
<mvo> mborzecki: right
<mup> PR snapd#7230 closed: tests: make interfaces-contacts-services cleanup more robust <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7230>
<mvo> mborzecki: do you have a spread test (a very simple) one already for the parallel install on classic?
<mborzecki> mvo: not yet, wanted to update zyga_'s mount-ns test, but doing some reviews first
<mvo> mborzecki: ok, just curious
<pstolowski> mornings
<mvo> good morning pstolowski !
<zyga> hey
<zyga> I got renamed to zyga_ and got banned/muted, not sure why
<zyga> I didn't realize nothing got through
<zyga> mborzecki: nice work
<mborzecki> looking at ian's PR, got confused by task handlers again, iirc when a do callback fails, it should clean all the work it did internally right? so for instance if doLinkSnap fails on say, createSnapCookie it should run UnlinkSnap() (which isn't done really)?
<zyga> mborzecki: not entirely
<mvo> zyga: happend to me earlier as well!
<zyga> mborzecki: when a handler fails it should clean up itself
<zyga> mborzecki: when a handler finishes but another fails later
<zyga> mborzecki: the undo handler for that task is called
<zyga> mborzecki: that's the current approach
<zyga> it's a bit hard to use TBH and hard to get right
<zyga> it would be nice if we ran the "undo" one automatically but none of the code is ready for it
<zyga> I spent way too long last night fighting cgroups
<mborzecki> right, so if something inside doLinkSnap() fails after backend.LinkSnap() is called, it should ideally call backend.UnlinkSnap() before returning from the handler
<zyga> there's something wonky going on that doesn't make sense to me yet
<zyga> especially that it spans both ancient systemd and super recent systemd (on arch)
<zyga> but not on other systems
<zyga> mborzecki: I think it's well worth having a discussion about task handlers
<zyga> mborzecki: I doubt we write them correctly today, it's very hard to do
<zyga> mborzecki: in addition I would raise that the use of get/set is very pythonish
<zyga> and doesn't fit go
<zyga> it'd be nice if there were actual types
<mborzecki> zyga: snap get/set ?
<zyga> no
<zyga> task handlers call get/set on task state
<zyga> it's all a bit of wild west without typing
<zyga> task state that is
<zyga> pstolowski: about 7081
<zyga> I'm writing one quick test to check something and then if that fails I'm +1 it
<zyga> brb
<pstolowski> zyga: great, ty :)
 * zyga writes actual hand-made test that could be changed to spread test later on
<mborzecki> noticed some PRs form yday were restarted, anyone know what failed there?
<mborzecki> pstolowski: Chipaca: hey
<Chipaca> mborzecki: ð
<mup> PR snapd#7307 opened: mkversion.sh: fix version from git checkouts <Created by mvo5> <https://github.com/snapcore/snapd/pull/7307>
<pstolowski> hey Chipaca
<mvo> zyga: what exactly is needed for 7299?
<zyga> mvo: let me push it
<mvo> zyga: ta
<mvo> zyga: you may need to pull first but there should be no conflicts
<mvo> zyga: I just applied your suggestions
<pedronis> #7271 and #7135 need 2nd reviews
<mup> PR #7271: many: generalize assertstate.Batch to asserts.Batch, have assertstate.AddBatch <Created by pedronis> <https://github.com/snapcore/snapd/pull/7271>
<mup> PR #7135: image: support prepare-image --classic for snapd snap only images <Created by pedronis> <https://github.com/snapcore/snapd/pull/7135>
<mvo> 7287 also needs a second review, should be an easy win
<mup> PR snapd#7297 closed: cmd/snap-mgmt: set +x on startup <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7297>
<zyga> mvo: ah, I see it is only running on 18.04
<mvo> zyga: I will work on your suggestions for 7288 now to land it I just saw another failure. or maybe we land as is and I do a followup?
<mvo> zyga: it should unbreak some missing cleanups
<mvo> 7300 was failing iirc
<zyga> mvo: +1
<pstolowski> mvo: ty for pushing the naming fix to #7306!
<mup> PR #7306: overlord/configstate: sort patch keys to have deterministic order with snap set <Created by stolowski> <https://github.com/snapcore/snapd/pull/7306>
<mvo> pstolowski: no worries, looked so trivial I figured it would do no harm
<zyga> mvo: https://github.com/snapcore/snapd/pull/7299 +1
<mup> PR #7299: sanity: report proper errror when fuse is needed but not available <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7299>
<zyga> https://github.com/snapcore/snapd/pull/7299#discussion_r316560942
<mup> PR snapd#7288 closed: tests: cleanup "snap_daemon" user in system-usernames-install-twice <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7288>
<mborzecki> zyga: mvo: https://github.com/systemd/systemd/issues/10872#issuecomment-523809771
<zyga> mborzecki: interesting!
<zyga> mborzecki: I need to change our stuff
<zyga> thanks!
<mborzecki> zyga: btw. make fmt keeps changing cmd/libsnap-confine-private/error.c cmd/snap-confine/udev-support.c :/
<zyga> mborzecki: indent suuucks
<zyga> mborzecki: just don't use it
<zyga> mborzecki: run it once and commit the changes to the new code
<zyga> mborzecki: discard the rest
<mborzecki> zyga: yeah, too small for a seaprate PR though
<mborzecki> zyga: maybe i'll add those in a separate patch in the parallel installs PR
<mup> PR snapd#7308 opened: tests: add new "user-tool" helper and use in system-user tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7308>
<zyga> mborzecki: I'm confused, what do you mean
<zyga> mvo: oh :D
<zyga> mvo: I was writing user tool just now
<zyga> though my version is in python :D
<zyga> mvo: let's get your version, I will only replace the implementation on top, ok?
<mborzecki> zyga: https://paste.ubuntu.com/p/pQN7XFWP3V/ that's the diff, since it's fairly small, too small for a PR, so i'll add it to 7302
<zyga> mborzecki: don't change that please
<zyga> mborzecki: my suggestion is to respect indent only on new code
<mborzecki> zyga: hm ok
<zyga> and not change existing files exactly because indent is unstable
<zyga> mborzecki: and new files, if possible, should be formatted with clang-format
<pstolowski> zyga: can you also re-review #7287?
<mup> PR #7287: hookstate/ctlcmd: snapctl unset command <Created by stolowski> <https://github.com/snapcore/snapd/pull/7287>
<zyga> pstolowski: enqueued
<pstolowski> zyga: fifo or lifo? ;)
<zyga> pstolowski: life-o
<diddledan> lipo? last-in, pooped-out? :-p
<Chipaca> lipo is the opposite of pooped-out tho
<Chipaca> hoovered-out more like
<Chipaca> mvo: did you see #1841001 ?
<mup> Bug #1841001: removing docker snap leaves apparmor misconfigured <Snappy:New> <https://launchpad.net/bugs/1841001>
<zyga> mvo: I saw that
<zyga> mvo: it's not easy to fix
<zyga> mvo: we discussed that at the last sprint
<zyga> we can only remove apparmor profiles after all processes using them are gone
<zyga> but that's hard to measure now
<mvo> Chipaca: I did not see it :/
<zyga> mvo: https://github.com/snapcore/snapd/pull/7309
<Chipaca> zyga: that's removing them from the kernel though, isn't it?
<mup> PR #7309: tests: re-implement user tool in python <Created by zyga> <https://github.com/snapcore/snapd/pull/7309>
<zyga> Chipaca: can you re-state your question?
<zyga> Chipaca: we are not removing the profiles
<Chipaca> zyga: as opposed to removing them from disk? Or is this bug about in-kernel?
<mup> PR snapd#7309 opened: tests: re-implement user tool in python <Created by zyga> <https://github.com/snapcore/snapd/pull/7309>
<zyga> Chipaca: because removing them would remove them from running processes
<zyga> Chipaca: it's about kernel
<zyga> Chipaca: they are gone from disk
<Chipaca> ah
<zyga> Chipaca: they persist in the kernel until you reboot
<zyga> yeah :/
<Chipaca> zyga: what's "any-python"?
<zyga> Chipaca: tests/lib/bin/any-python
<Chipaca> ah
<zyga> I wish it wasn't needed
<zyga> I wish unix had py
<zyga> but ...
<zyga> well :)
<zyga> mvo: https://twitter.com/rbtcollins/status/1164327713269620737
<mvo> zyga: uh
<mvo> zyga: thanks
<mvo> zyga: we had this discussion before, we suck and we need to fix it :(
<zyga> there are three bugs there
<zyga> I'm going through them now
<mvo> zyga: thank you
<mvo> zyga: nice picture of robert, haven't seen a picture of him in years, I'm quite impressed :)
<zyga> https://bugs.launchpad.net/snappy/+bug/1841001
<zyga> https://bugs.launchpad.net/snappy/+bug/1840244
<zyga> https://bugs.launchpad.net/snappy/+bug/1656976
<mup> Bug #1841001: removing docker snap leaves apparmor misconfigured <Snappy:Triaged> <https://launchpad.net/bugs/1841001>
<mup> Bug #1840244: docker snap cannot bind mount ssh sockets correctly <Snappy:Triaged> <https://launchpad.net/bugs/1840244>
<mup> Bug #1656976: classic mode cannot start services <Snappy:Triaged> <https://launchpad.net/bugs/1656976>
<zyga> all triaged, the last one is easy-ish
<zyga> the other two are not
<zyga> the middle one is an UX usability bug
<mvo> maybe we need to make twitter our bts?
<zyga> the first one are two bugs in one
<zyga> one needs to be handled by docker snap
<zyga> the other by us eventually
<zyga> I'll raise this at the standup
<zyga> mvo: who wants to triage the remaining NEW bugs?
<zyga> I need that coffee
<mvo> zyga: I think we should talk in the standup but to make this work we will need something like bug triage duty on specific days
<mvo> zyga: I think
<mvo> zyga: like the security team is doing
<zyga> yeah
<zyga> it cannot be knee-jerk reactionary like that
<mvo> zyga: or we need to put someone on it (like sergio) and make it his reposonbility
<diddledan> coffee sounds like a plan, zyga
<zyga> yeah
 * zyga goes to make some
<mup> PR snapd#7310 opened: devicestate: add missing test for remodeling possibly removing required flag <Created by pedronis> <https://github.com/snapcore/snapd/pull/7310>
<pedronis> mvo: ^ there's a bit of doSetModel that was not unit tested that I need to tweak in the core20 model work
<Chipaca> mvo: is #1579268 really an issue with snapd? I thought it was an issue with the snaps themselves
<mup> Bug #1579268: Mouse cursor is different inside graphical windows of snaps (snaps not using system theme) <Snappy:New> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1579268>
<diddledan> hah, we've just had that mentioned in the Ubuntu Podcast Telegram channel :-)
<mvo> Chipaca: I think its a issue with the snaps but iirc zyga was looking into this a while ago, not sure if we need to tweak anything on our side
<Chipaca> mvo: there's also the issue that if people use themes that aren't packaged they're not usable from the snap
<Chipaca> mvo: that aspect i'd say is wontfix? or did we have plans for that? or is that what zyga was looking at
<mvo> Chipaca: we had plans for this, the idea was to have theme-snaps that would be auto-downloaded
<mvo> Chipaca: this was a colaboration with the desktop team, there should be a forum post somewhere
 * mvo looks
<mvo> Chipaca: jamesh is a good POC I think
<diddledan> only a POC? I think james might claim to be GA/RTM
<diddledan> at least MVP
<Chipaca> diddledan: I don't think jamesh is an airport in Colombia
<diddledan> really?
<Chipaca> diddledan: 87% sure
<diddledan> I think this needs more investigation
<mup> Bug #1579268 changed: Mouse cursor is different inside graphical windows of snaps (snaps not using system theme) <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1579268>
<mup> Bug #1581188 changed: How to run snappy from inside Docker - systemd issues? <Snappy:Won't Fix> <https://launchpad.net/bugs/1581188>
<tomwardill> I'm doing `snap set snap-store-proxy.internal.store.id=''` but the value does not appear to change. Is this likely to be a problem with the snap-store-proxy configure hook, or am I doing something wrong?
<tomwardill> ideally, I'd like to set it to null/no value
<Chipaca> ogra: you around?
<ogra> yes
<Chipaca> tomwardill: doesn't =null do that?
<ogra> and no, i have no idea about that nextcloud box :P
<Chipaca> ogra: #1587453, i'm not sure if that's an Invalid or a Won'tFix or a Confirmed Wishlist
<mup> Bug #1587453: Reduce write to SD cards <raspberry-pi> <Snappy:New> <https://launchpad.net/bugs/1587453>
<tomwardill> Chipaca: `=null` will work on another key, but the value doesn't change on the key I care about
<tomwardill> so I guess it's my problem somewhere :)
<Chipaca> tomwardill: sounds like a validation bug yeah
<Chipaca> tomwardill: also note there's going to be 'snap unset' soon
<tomwardill> Chipaca: ah, that sounds like what I'm after :)
<Chipaca> pstolowski: what release is snap unset scheduled for?
<diddledan> is it even meant to be user changable considering it's marked internal?
<ogra> Chipaca, wontfix unless you plan to hack up disk cache settings randomly
<pstolowski> Chipaca: it partially landed for 2.41 (and what landed is fully usable), however 'snapctl unset' didn't make it
<mup> Bug #1587453 changed: Reduce write to SD cards <raspberry-pi> <Snappy:Won't Fix> <https://launchpad.net/bugs/1587453>
<mup> Bug #1593151 changed: Snapd should support custom servers <Snappy:Won't Fix> <https://launchpad.net/bugs/1593151>
<mup> Bug #1593435 changed: snap install will go get store version instead of sideload <Snappy:Invalid> <https://launchpad.net/bugs/1593435>
<mup> Bug #1593558 changed: sox not configured for pulseaudio when packaged in a snap <Snappy:Invalid> <https://launchpad.net/bugs/1593558>
<mup> Bug #1593915 changed: Ad the "snap all refresh" command <Snappy:Fix Released> <https://launchpad.net/bugs/1593915>
<mup> Bug #1593958 changed: Downloading snaps takes too long <Snappy:Fix Released> <https://launchpad.net/bugs/1593958>
<mup> Bug #1593960 changed: snap refresh unfriendly error message <Snappy:Fix Released> <https://launchpad.net/bugs/1593960>
<mup> Bug #1593989 changed: snap installed .desktops collide with .deb installed .desktops in unity7 <Snappy:Fix Released> <https://launchpad.net/bugs/1593989>
<diddledan> all the bugs!
<mup> PR snapd#7311 opened: snap/naming: introduce SnapRef, Snap, and SnapSet <Created by pedronis> <https://github.com/snapcore/snapd/pull/7311>
<mup> PR snapd#7312 opened: tests: use user-tool to remove test user in the non-home test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7312>
<mup> Bug #1594328 changed: snappy keeps several copies of the same snap <Snappy:Fix Released> <https://launchpad.net/bugs/1594328>
<mup> PR snapd#7313 opened: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/7313>
<pedronis> mvo: ^
<mvo> pedronis: nice
<diddledan> did someone turn on the firehose? http://www.belch.com/img/firehose.jpg :-p
<mup> Bug #1580738 changed: exec in desktop file should be app name and not include the friendly (current) package name <snapd:Confirmed> <https://launchpad.net/bugs/1580738>
<mup> Bug #1594842 changed: Docs have "revision" as an int <Snappy:Fix Released> <https://launchpad.net/bugs/1594842>
<mup> Bug #1600140 changed: App indicator adds an entry for each snap launch <snap-desktop-issue> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1600140>
<mup> Bug #1600489 changed: freecad after being installed with snap doesn't exists <Snappy:Invalid> <https://launchpad.net/bugs/1600489>
<Chipaca> mvo: #1606539 is fixed, yes?
<mup> Bug #1606539: handler errors from `snap create-user` gracefully <Snappy:New> <https://launchpad.net/bugs/1606539>
<mup> Bug #1601859 changed: Need a way to autostart applications (not services) <Snappy:Fix Released> <https://launchpad.net/bugs/1601859>
<mup> Bug #1607252 changed: User data is missing or lost when utilizing a snap instead of a traditional package <Snappy:Fix Released> <https://launchpad.net/bugs/1607252>
<mup> Bug #1607744 changed: "snap install <filename>" over an already installed snap doesn't copy the user data <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1607744>
<mup> Bug #1609757 changed: Enable ordering of services provided by a snap <cpc> <Snappy:Fix Released> <https://launchpad.net/bugs/1609757>
<Chipaca> pedronis: were you aware of the request in #1609864 ?
<mup> Bug #1609864: Enable a command to be run on machine shutdown <cpc> <Snappy:New> <https://launchpad.net/bugs/1609864>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7306
<mup> PR #7306: overlord/configstate: sort patch keys to have deterministic order with snap set <Created by stolowski> <https://github.com/snapcore/snapd/pull/7306>
<pstolowski> zyga: ty
<mup> PR snapd#7290 closed: tests: allow test user XDG_RUNTIME_DIR to phase out <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7290>
<pstolowski> zyga: otoh, i'm slightly scared of loosing 'green' spread status on that PR...
<zyga> haha, sure
<zyga> follow up +1
<pstolowski> tough times
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7287#pullrequestreview-278333771 +1
<mup> PR #7287: hookstate/ctlcmd: snapctl unset command <Created by stolowski> <https://github.com/snapcore/snapd/pull/7287>
<zyga> pstolowski: I'm mid-way writing that spread test for batch profiles but I went upstairs for a moment and doing reviews from a laptop now
<pstolowski> zyga: sure, thanks for trying to break it
<mup> Bug #1611526 changed: temp directories not deleted when snap fails to start <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1611526>
<mup> Bug #1611530 changed: can't install devmode snap from store <landscape> <Snappy:Won't Fix> <https://launchpad.net/bugs/1611530>
<mup> Bug #1611706 changed: Test suite failures on Arch <Snappy:Fix Released> <https://launchpad.net/bugs/1611706>
<pstolowski> ah, 7287 is actually rebuilding anyway for previous changes...
<zyga> pstolowski: 7287 can land now
<zyga> oh
<zyga> bummer
<pstolowski> nah it can't
<pedronis> Chipaca: no
<pstolowski> let's see, if it fails for random reason, i'll make the spread test tweak as well
<zyga> jdstrand: can you please enqueue https://github.com/snapcore/snapd/pull/7252
<mup> PR #7252: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7252>
<pstolowski> zyga: ah, no, 7287 can land indeed, ty, i confused my two PRs
<mup> Bug #1611837 changed: all-snaps: Boot breaks on reboot <Snappy:Invalid> <https://launchpad.net/bugs/1611837>
<mup> Bug #1612783 changed: snapd requires U1 account to install local packages <Canonical System Image:Fix Released> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1612783>
<mup> Bug #1614730 changed: dpkg: dependency problems prevent configuration of snapd -  snapd depends on ubuntu-core-launcher (>= 1.0.23) <oil> <Snappy:Fix Released> <https://launchpad.net/bugs/1614730>
<mup> PR snapd#7287 closed: hookstate/ctlcmd: snapctl unset command <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7287>
<mup> PR snapd#7225 opened: tests: don't repeat checks <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7225>
 * zyga hugs Chipaca!
<mup> Bug #1616508 changed: snap install overwrites its own output <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1616508>
<mup> PR snapd#7234 closed: tests: make sure snapd is built against new gorilla mux <Simple ð> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7234>
<Chipaca> zyga: what's the status of #1620592 ?
<mup> Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <snap-confine:Triaged> <Snappy:New> <https://launchpad.net/bugs/1620592>
<mup> Bug #1618239 changed: console-conf uses 20+MB memory at rest on embedded systems <subiquity (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1618239>
<zyga> Chipaca: I'd have to re-check, I don't remember
<Chipaca> :)
<Chipaca> zyga: same question wrt #1620650 although that one might be for mborzecki these days
<mup> Bug #1620650: After installing krita from beta channel, krita crashes when opening the snap. <Calligra:Unknown> <Snappy:New> <https://launchpad.net/bugs/1620650>
<zyga> Chipaca: I don't know either, I could check but I'd need to update to 19.10 as my gpu doesn't work on ubuntu today (2080s)
<Chipaca> i set it to confirmed because even if it's better than what it was in the bug, it's still not perfect
<Chipaca> (wrt PRIME setup)
<mup> Bug #1620771 changed: when /home is somewhere else, snaps don't work <link> <snap> <symlink> <Snappy:Won't Fix> <https://launchpad.net/bugs/1620771>
<pedronis> mvo: I'm getting:  groupdel: cannot remove the primary group of user 'snap_daemon'
<pedronis> is that fixed somewhere?
<pedronis> (in spread to be clear)
<mvo> pedronis: yes, should be fixed with current master
<mvo> pedronis: https://github.com/snapcore/snapd/pull/7288 was the relevent pr
<mup> PR #7288: tests: cleanup "snap_daemon" user in system-usernames-install-twice <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7288>
<mup> Bug #1621132 changed: Porting guide is out of date <Snappy:Fix Released> <https://launchpad.net/bugs/1621132>
<mup> Bug #1621142 changed: no "please press enter" message shown on serial console <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1621142>
<mup> Bug #1621144 changed: serial console is not cleared before console-conf runs <subiquity:Triaged> <https://launchpad.net/bugs/1621144>
<pedronis> pstolowski: if I understood zyga correctly #7081 can be merged?
<mup> PR #7081: ifacestate: optimize auto-connect by setting profiles once after all connects <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7081>
<pstolowski> pedronis: no, he is working on some kind of test to verify it
<pedronis> pstolowski: did you speak again? I thought he said in the standup that he wasn't blocking it anymore
<zyga> pstolowski: can we merge it now and adjust if my test finds something
<zyga> pstolowski: it's just a spread test
<pstolowski> pedronis: yes we talked about it this morning
<zyga> if it works we can merge it anyway
<zyga> and this way we get more exposure during the dev cycle
<pedronis> yea, we just cut 2.41
<pedronis> it's a good time as any
<pstolowski> zyga: ok, sounds good
<zyga> merge away
<mup> PR snapd#7081 closed: ifacestate: optimize auto-connect by setting profiles once after all connects <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7081>
<mvo> zyga: I get this error in the (new) lxd test:
<mvo> + lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-tools.echo from-the-inside' ubuntu
<mvo> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<mvo> zyga: do you have any idea ? its strange but maybe something missing inside the container or crazyiness like this?
<zyga> that's odd, do you have a debug shell?
<zyga> can you check aa-status
 * zyga is still upstairs, reading https://github.com/snapcore/snapd/pull/7271
<mup> PR #7271: many: generalize assertstate.Batch to asserts.Batch, have assertstate.AddBatch <Created by pedronis> <https://github.com/snapcore/snapd/pull/7271>
<pedronis> fwiw it will be tweaked a bit, given mvo input, it had a bit of  along gestation/back and forth on my part on details
<mvo> pedronis: thanks! I was wondering how useful my ramblings were, glad it seems they were :)
 * mvo lunches 
<zyga> mvo: ping me about the lxd failure
<zyga> mvo: after lunch
<mup> PR snapd#7298 closed: tests: clean up after NFS tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7298>
<mup> Bug # changed: 1621147, 1621304, 1621323, 1621339, 1621378
<Chipaca> mvo: what's your opinion on #1621666 ?
<mup> Bug #1621666: It is possible to install the classic snap in a classic system <classic> <Snappy:New> <https://launchpad.net/bugs/1621666>
<mup> Bug # changed: 1621380, 1621550, 1621568, 1621623
<Chipaca> pedronis: is #1621769 accurate? care to comment there?
<mup> Bug #1621769: impossible to create a model assertion compatible with both snapd 2.13 and 2.14 <Snappy:New for mvo> <https://launchpad.net/bugs/1621769>
<Chipaca> pedronis: otherwise i'll tag it wontfix
<pedronis> we would have to change the past
<mup> Bug #1621805 changed: sudo snap abort <change-id> won't abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:Fix Released> <https://launchpad.net/bugs/1621805>
<mup> Bug # changed: 1623120, 1623802, 1625605, 1625698
<mup> PR snapcraft#2680 opened: spread tests: minor performance improvements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2680>
<mup> Bug #1626617 changed: console-conf does not allow to set up dns for static ip <plano-acan> <verification-done-yakkety> <netplan:Fix Released by pitti> <nplan (Ubuntu):Fix Released by pitti> <subiquity (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Released> <subiquity (Ubuntu Xenial):Won't Fix>
<mup> <nplan (Ubuntu Yakkety):Fix Released> <subiquity (Ubuntu Yakkety):Won't Fix> <https://launchpad.net/bugs/1626617>
<Chipaca> OK, I'm done triaging for today
<Chipaca> more tomorrow (and every friday from now until forever)
<zyga> Chipaca: fantastic stuff, thank you
<zyga> Chipaca: I can happily work on triage every friday as well
<Chipaca> zyga: question: does /v2/interfaces?doc=true&select=all return all even cross-arch?
<zyga> cross-arch?
<Chipaca> zyga: maybe better if we choose different days
<Chipaca> zyga: like, are there armhf-only interfaces, and if so do those appear in that
<zyga> interfaces don't model architecture
<Chipaca> good :)
<Chipaca> ok
<zyga> so yeah
 * zyga eats a snack qucikly
<zyga> back to that integration test pawel :)
<pstolowski> zyga: you're not giving up easily, i give you that ;)
<zyga> pstolowski: it's mainly because I suck at reading the code well enough to have confidence in that
<zyga> so black box tests FTW
<zyga> pstolowski: btw, I updated to catalina
<zyga> it's neat
<pstolowski> zyga: it's stil beta isn't it?
<zyga> yeah
<zyga> coming out in fall as usual
<pstolowski> zyga: yeah, it has know problems affecting x-plane, so no-no for me atm
<pstolowski> *known
<mborzecki> zyga: pushed changs to #7302
<mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
<ogra> parallel insanity ...
<pedronis> pstolowski: about 7207, I don't think we have any tests about using seed.yaml to install multiple instance, I wouldn't consider it supported atm
<pstolowski> pedronis: right, that's why my initial changes were happy.. but if we want to address this (i.e. actively prevent), i'd opt for a separate PR
<mup> PR snapd#7300 closed: interfaces/network-{control,manager}: allow 'k' on /run/resolvconf/** <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7300>
<mup> PR snapd#7301 closed: interfaces/network-{control,manager}: allow 'k' on /run/resolvconf/** - 2.41 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7301>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7302#pullrequestreview-278394393
<mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
<pstolowski> pedronis: thanks for the suggestions under #7005
<mup> PR #7005: debug: state-inspect debugging utility <Created by stolowski> <https://github.com/snapcore/snapd/pull/7005>
<pstolowski> pedronis: nice idea with 'state' as the main sub-command
<zyga> mvo: I have a solution to all our problems ;-)
<zyga> mvo: https://github.com/snapcore/snapcraft/pull/2676
<mup> PR snapcraft#2676: spread: 64 workers for each system <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2676>
<mvo> zyga: hehe
<zyga> on the other hand I'd love to see the numbers if we tried that
<zyga> just really curious
<mup> PR snapd#7308 closed: tests: add new "user-tool" helper and use in system-user tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7308>
<mup> PR snapd#7285 closed: httputil: improve http2 PROTOCOL_ERROR detection <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7285>
<mup> PR snapd#7314 opened: tests/main/mount-ns: account for clone_children in cpuset cgroup on 18.04 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7314>
<zyga> this is scary https://lwn.net/Articles/796951/
<pedronis> this needs a 2nd review: https://github.com/snapcore/snapd/pull/7135
<zyga> git diff not showing changes because timestamps
<mup> PR #7135: image: support prepare-image --classic for snapd snap only images <Created by pedronis> <https://github.com/snapcore/snapd/pull/7135>
 * zyga child care break
<Saviq> pstolowski: hey, I think you know about hooks ;) is there any way to know, in a pre-refresh hook, what revision we're getting refreshed to? we'd like to fail the refresh if someone tries to go from core18-based Multipass to a core16-based one if they have any instances running (as they will fail to resume again)
<Saviq> it's a corner case, but if there is something we could do to let users know how to go about it, we would :)
<ijohnson> Saviq: I don't think there's anything like that currently available in hooks, but you could use epochs
<ijohnson> core16 based multipass could be epoch 0, and core18 multipass could be epoch 1, and as long as you never publish a epoch 1* (or maybe 0* I don't recall) a refresh between them will never be allowed or happen automatically
<Saviq> ijohnson: right, I know, but that's too strict, we can refresh both ways, it's a runtime check whether it's ok or not
<pstolowski> Saviq: as ijohnson says.. no way of knowing that right now.. that's not the first request for something like this we get
<Saviq> ack, thanks guys :)
<ijohnson> I suppose you could do something like write to a file in $SNAP_DATA or $SNAP_COMMON that says if there are instances running in pre-refresh, then in post-refresh check if that file is there and if you switched bases, then exit 1 from the post-refresh hook forcing a revert back to the previous one
<pstolowski> Saviq: i have very vague memories of a forum topic about this, but can't find it...
<ijohnson> Saviq: do multipass instances currently continuing running during a refresh?
<Saviq> ijohnson: they get suspended and resumed
<Saviq> (because they're actually child processes of multipassd)
<ijohnson> okay, so then the instance would get resumed when multipassd starts up again?
<ijohnson> if that's the case then the file method I mentioned above should work, it's a bit of a hack/workaround, but would have the desired affect I think
<Saviq> ijohnson: yeah it sounds workable indeed
<Saviq> thanks :)
<ijohnson> Saviq: I prototyped a similar type of thing before and can share some example code if you're interested
<mup> PR snapd#7315 opened: store, image, cmd: make 'snap download' leave partials <Created by chipaca> <https://github.com/snapcore/snapd/pull/7315>
<ijohnson> jdstrand: from a gut feeling do you think that providing net_admin and sys_admin to daemon-notify is ack'able ? if your gut feeling is no, then I'm just gonna close #6697
<mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
<jdstrand> ijohnson: gut feeling is no. I still have an item for it, but it is going to take a while for a full investigation (sorry it is lingering)
<jdstrand> (ie, it is in trello so won't be forgotten)
<zyga> ijohnson: sorry for lagging on older PRs, quick question on https://github.com/snapcore/snapd/pull/6697/files#r316741453
<mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
<ijohnson> jdstrand: okay that's fine I think I'll leave it open in case you can find a workaround or something in your investigation, it would still be a nice to have
<ijohnson> zyga: thanks I'll take a look, perhaps network isn't actually necessary there I have a habit of just shotgunning network access for every snap I write :-)
<zyga> ijohnson: I asked because it tends to hide missing permissions in the actual interface being tested
<ijohnson> right
<zyga> if there's a legitimate reason for it please add a comment there
<ijohnson> yep, running spread right now to see
<jdstrand> ijohnson: you could still close it with a note that you will reopen pending investigation
<mup> PR snapcraft#2680 closed: spread tests: minor performance improvements <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2680>
<mup> PR snapcraft#2676 closed: spread: 64 workers for each system <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2676>
 * ijohnson lunches
<mup> PR snapd#7316 opened: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
<ardaguclu_> hi, is there any mocking for logging?
<ardaguclu_> I created PR 7316
<mup> PR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
<mup> PR snapd#7315 closed: store, image, cmd: make 'snap download' leave partials <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7315>
<mup> PR snapcraft#2681 opened: spread: fix unbound variable error <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2681>
<mup> PR snapcraft#2682 opened: tests: change default spread provider to lxd outside of travis <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2682>
#snappy 2019-08-23
<mup> PR snapcraft#2670 closed: Plugin colcon: forward parallel build count <Created by artivis> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2670>
<mup> PR snapcraft#2681 closed: spread: fix unbound variable error <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2681>
<mup> PR snapcraft#2675 closed: docs: quick init for lxd in HACKING.md <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2675>
<mborzecki> morning
<mvo> morning! so much red :/ has anyone looked for patterns yet?
<mborzecki> mvo: morning, no haven't looked yet, i'm pushing golang-github-snapcore-gettext to fedora, but noticed that it was all red yesterday evening too
<mvo> mborzecki: ok, I have a look
<mup> PR snapd#7317 opened:  httputil: rework protocol error detection  <Created by mvo5> <https://github.com/snapcore/snapd/pull/7317>
<mvo> looks like fastly is very unhappy 503, protocl_errors etc
<mborzecki> mvo: looked at 3 prs, 3 different errors :/
<mvo> mborzecki: I looked at the test update one from samuele and it was all protocol_errors
<mvo> mborzecki: another one a mix of protocol_errors and 503
<mvo> mborzecki: but yes, there is odd stuff in the mix in others too
<mvo> mborzecki: looks like the protocol_error detection is buggy :/
<mborzecki> mvo: perhaps looking at the string was more reliable
<mvo> mborzecki: its funny, I think some of the ones failing use the old string detection so its something fishy, maybe the old code was buggy too and we were just lucky :(
<mvo> mborzecki: but yeah, pushed a PR with better string based detection and slightly improved debug
<mborzecki> mvo: hm type assertion didn't work then?
<mvo> mborzecki: maybe or its something strange with the imports, the bundled golang h2_bundle.go does not have a StreamError
<mvo> mborzecki: so it might be some strange interplay between the bunblded http2 and the x/net/http2
<mvo> mborzecki: I can dig some more, its just so time consuming :/
<mborzecki> mvo: there's http2StreamError, iirc h2_bundle is x/net/http2 impoted and all funcs and types with http2 prefix
<mvo> mborzecki: yeah, this is the one my latest PR string matches on. its not an exported error unfortunately
<mborzecki> mvo: //go:generate bundle -o h2_bundle.go -prefix http2 -underscore golang.org/x/net/http2
<mvo> mborzecki: what is strange is that I had a tiny go example client running against a (c) http2 server that would produce stream errors and there I got the right errors
<mvo> mborzecki: anyway, I will investigate but it seems worthwhile to unblock ppl
<mvo> mborzecki: also 7312 would be good
<mvo> mborzecki: I saw some issues where the non-home user could not be deleteted because some process was still in use which I think this PR will fix (--force ftw!)
<mborzecki> mvo: did you import x/net/http2 in that tiny go client?
<mvo> mborzecki: yeah, I have to for the error casting
<mvo> mborzecki: it is also imported in httputil
<mvo> mborzecki: http://paste.ubuntu.com/p/5m7nzf3yNZ/
<mborzecki> mvo: ok, the docs on https://godoc.org/net/http say we'd need to use ConfigureTransport() or sth
<mvo> mborzecki: hm, I thought its doing this automatically
<mborzecki> mvo: perhaps then it would always use the http client from imported lib
<mvo> mborzecki: let me try that
<mvo> mborzecki: and indeed
<mvo> mborzecki: my test code is doing this
<mvo> mborzecki: because I need to override the tls config :(
<mvo> mborzecki: if we override the default transport will it fall back to http1 automatically?
<mvo> mborzecki: also - I wonder if its worth it vs string detection :/
<mborzecki> mvo: yeah, i'd assume that it falls back autmatically
<mborzecki> mvo: quckly scanning the code, it sets up the handler of upgrading the protocol once h2 is seen in ALPN
<mborzecki> mvo: so your client code would start with http.Transport{} and then call http2.ConigureTransport() on that
<mvo> mborzecki: let me play with this
<mup> PR snapd#7307 closed: mkversion.sh: fix version from git checkouts <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7307>
<mup> PR snapd#7273 closed: gadget, overlord/devicestate: rename Position/Layout <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7273>
<ackk> hi, anyone has an idea on how to find out what's keeping loop devices busy in https://bugs.launchpad.net/snapd/+bug/1841137 ?
<mup> Bug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:New> <https://launchpad.net/bugs/1841137>
<mvo> Chipaca: hey, good morning, you are around early :)
<mvo> hey pedronis ! still lots of reds but some progress in hopefully making things less red
<Chipaca> mvo: forgot to close irc before suspending the notebook yesterday, so it connected as soon as i opened it to catch up with the world over breakfast
<Chipaca> mvo: good morning =(
<Chipaca> er, i meant =(
<Chipaca> wait
<Chipaca> =)
<Chipaca> there
<mvo> Chipaca: hahaha
<Chipaca> silly half-asleep hands
 * mvo kicks Chipaca from irc again until he has tea/coffee
<mup> PR snapd#7271 closed: many: generalize assertstate.Batch to asserts.Batch, have assertstate.AddBatch <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7271>
 * Chipaca disappears
<mborzecki> Chipaca: hey, good morning
<mborzecki> mvo: you're trying out wth ConfigureTransport then? in which case I'll stop going through 7317 ;)
<mvo> mborzecki: I'm looking into it but I think its not worth waiting
<mvo> mborzecki: I'm also more and more convinced that whatever we do we need a test :/
<pstolowski> morning
<mvo> mborzecki: which is annoying, I think I will snap my libevent-server hack from nghttp2
<mvo> mborzecki: so that we have something we can test against - one issue with this is that http2 is tls so I need keys and for self-signed I need to alter the config which lead to the issue that my test client was not quite in the same state as the real one
<mvo> mborzecki: did I mention its annoying ;)
<mup> PR snapd#7306 closed: overlord/configstate: sort patch keys to have deterministic order with snap set <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7306>
<mvo> thanks pstolowski ! nice to see this one goingin
<pstolowski> mvo: yeah, that was the last one
<pstolowski> mvo: can you take another look at https://github.com/snapcore/snapd/pull/7219 ? it's close to landing
<mup> PR #7219: devicestate/firstboot: check for missing bases early <Created by stolowski> <https://github.com/snapcore/snapd/pull/7219>
<mborzecki> pstolowski: hey
<mvo> pstolowski: yes! fiddling a bit with tests then I'm ready
<mvo> a review for 7312 would be great, it should eliminiate another relatively common test failure
<zyga> Good morning
<mvo> hey zyga
<zyga> Sleeping with two kids and a dog on one bed
<zyga> Ugh
<zyga> Brb
<mborzecki> looks like some redditors attended the london meetup https://www.reddit.com/r/linux/comments/ctxaff/rebootless_kernel_updates_by_canonical/
<mup> PR snapd#7318 opened: many:  merging asserts.Batch Precheck with CommitTo and other clarifications <Created by pedronis> <https://github.com/snapcore/snapd/pull/7318>
<pedronis> mvo: ^ the follow to asserts.Batch PR
<mup> PR snapd#7312 closed: tests: use user-tool to remove test user in the non-home test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7312>
<mup> PR snapd#7319 opened: spread.yaml: set centos-7-64 to manual <Created by mvo5> <https://github.com/snapcore/snapd/pull/7319>
<pedronis> Chipaca: have you have a moment, can you double check the last changes to https://github.com/snapcore/snapd/pull/7149
<mup> PR #7149: cmd: add snap model command; daemon: add /v2/model, /v2/model/serial REST APIs <Remodel :train:> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7149>
<Chipaca> pedronis: sure, in a bit
<pstolowski> pedronis: hey, on pi3 the aa_parser timings are indeed showing significant difference with multiple runs vs all-at-once, the later is 3x faster with just 11 snaps. i'm writing a summary
<pedronis> thank you
<zyga> pstolowski: nice work
<mvo> pstolowski: nice!
<mborzecki> mvo: have you seen this error /usr/sbin/deluser: `/sbin/userdel jim' returned error code 8. Exiting. ?
<mborzecki> mvo: accroding to manapage, 8 means the user is logged in
<zyga> jim?
<mvo> mborzecki: yes
<mvo> mborzecki: this is what the Pr you most recently reviewed was about
<mvo> mborzecki: using the new "user-tool del" that uses deluser --force
<mborzecki> mvo: wondering why userdel believes the user is logged in though
<mborzecki> mvo: could that be somehow related to issues that zyga saw on arch
<mvo> mborzecki: I think it checks for processes that are owned by the user
<mvo> mborzecki: the issue from zyga was about systemd creating files or something?
<zyga> mvo: why did you add --remove to userdel?
<zyga> mvo: pam I think
<zyga> mvo: and why only to one branch of the code?
<mvo> zyga: it removes the homedir as well
<zyga> aha, and should it run on core too?
<mvo> zyga: uh, you are right, the second one should also have it for completness
<zyga> mvo: I rebased https://github.com/snapcore/snapd/pull/7309/files
<mvo> zyga: the current master should fix the practical failure but it still should be consistent
<mvo> zyga: ta
<mup> PR #7309: tests: re-implement user tool in python <Created by zyga> <https://github.com/snapcore/snapd/pull/7309>
<zyga> mvo: if you can review that I'll follow up with extra --remove in the core case
<zyga> I'm looking at chipaca's PR
<mup> PR snapd#7320 opened: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
 * Chipaca curses at his trackpad
<Chipaca> zyga: thank you for looking at my pr
<Chipaca> oh, drat, import cycle
<Chipaca> in tests
<Chipaca> :-(
<mup> PR snapd#7320 closed: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<mborzecki> Chipaca: :( and i was looking at it
<Chipaca> mborzecki: sorry :-( it shouldn't change too much, but import cycles are hard to fix
<Chipaca> mborzecki: need to shunt the code around
<mborzecki> Chipaca: fwiw you could just call snap.SanitizePlugsSlots
<mborzecki> or not :/ need to import interfaces/builtin
<Chipaca> pstolowski: question for you sir
<Chipaca> pstolowski: why is 'plug/slot sanitization not possible from snap command'?
<pstolowski> Chipaca: because that would required all interfaces/ code to be imported, since they define BeforePrepare* methods
<Chipaca> pstolowski: and why is that bad?
<pstolowski> Chipaca: i don't know, might be historical; at some point i was told it was bad ;). maybe pedronis / mvo / zyga remember
<mborzecki> zyga: experimental.parallel-instances is set to true, shouldn't there be a feature file in /var/lib/snapd/features?
<zyga> Chipaca: as in statically?
<zyga> Chipaca: because some are only sanitized after connections I guess
<zyga> but I think it'd be nice to have a pre-check
<zyga> mborzecki: not always, check for is-exported
<zyga> mborzecki: only exported flags have this
<pedronis> Chipaca: I'm not sure what's the question there?
<Chipaca> 1 sec
<Chipaca> pedronis: in cmd/snap/main.go we replace snap.SanitizePlugSlots with a nop
<mup> PR snapd#7320 opened: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<Chipaca> pedronis: there's even a comment, // plug/slot sanitization not used nor possible from snap command, make it no-op
<pedronis> Chipaca: ah
<pedronis> not sure
<Chipaca> pedronis: but, for #1617302, I _want_ that code to be usable
<mup> Bug #1617302: Specifying a nonexistent plug does cause any errors <Snapcraft:Triaged> <Snappy:Triaged by chipaca> <https://launchpad.net/bugs/1617302>
<pedronis> you'll have to dig
<Chipaca> pedronis: so, I dropped that no-op'ing
<Chipaca> pedronis: and nothing broke :-)
<mborzecki> zyga: hm maybe we should export all experimental flags by default
<pstolowski> zyga: no, this is about BeforePreparePlug|Slot, so static
<zyga> mborzecki: we had that discussion
<zyga> mborzecki: and it was nacked
<pedronis> Chipaca: might be there is a size concern
<mborzecki> zyga: duh, ok
<zyga> mborzecki: I think it's fine to export it if there is a purpose
<zyga> pstolowski: interesting, then I don't know
<Chipaca> pedronis: might be; locally snapd goes from 17 to 18 MBs with that import (from 10 to 11 stripped)
<mborzecki> zyga: heh, so we're missing a bit that updates the feature files on startup :/
<zyga> mborzecki: hmm?
<mborzecki> zyga: the feature files are created only when core config is updated
<pstolowski> Chipaca: ok, i've an idea
<zyga> mborzecki: I thought we had that, because I kept looking at that code at the time and it was full of interesting avenues
<zyga> mborzecki: ah, because you exported it now and it is gone
<mborzecki> zyga: s/gone/not added/
<zyga> yeah
<Chipaca> pstolowski: sounds dangerous
<pstolowski> Chipaca: i think we did this because they were already validated on install, so you're not paying the penalty every time on snap run - execApp reads the yaml and calls Sanitize internally (and is noop atm)
<Chipaca> pstolowski: can you comment on the PR?
<Chipaca> pstolowski: it sounds like i need to do some trickery :-)
 * Chipaca is fine with trickery
<pstolowski> sure
<mup> PR snapd#7310 closed: devicestate: add missing test for remodeling possibly removing required flag <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7310>
<mup> PR snapd#7318 closed: many:  merging asserts.Batch Precheck with CommitTo and other clarifications <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7318>
<pstolowski> Chipaca: commented
 * pstolowski will learn one day the spelling of "negligible" after looking it up again in the dict
<pedronis> reminder: #7135 needs a 2nd review
<mup> PR #7135: image: support prepare-image --classic for snapd snap only images <Created by pedronis> <https://github.com/snapcore/snapd/pull/7135>
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/7185#pullrequestreview-278861850
<mup> PR #7185: boot, etc.: refactor boot to have a lookup with different imps <Created by chipaca> <https://github.com/snapcore/snapd/pull/7185>
<mup> PR snapd#7314 closed: tests/main/mount-ns: account for clone_children in cpuset cgroup on 18.04 <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7314>
<Chipaca> zyga: I can't refactor all the things in a single PR :-/
<Chipaca> it'd be un-reviewable
<zyga> Chipaca: that's fine, that's why my general comment was "how do you want to proceed"
<Chipaca> zyga: "find a nice sandy riverbank and have a cookout"
 * Chipaca goes for coffee
<mup> PR snapd#7135 closed: image: support prepare-image --classic for snapd snap only images <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7135>
<pstolowski> pedronis: https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909
<mup> PR snapd#7311 closed: snap/naming: introduce SnapRef, Snap, and SnapSet <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7311>
<ogra> pstolowski, i wish you would test on actual low-end HW (imx6ull like rigado uses or a beaglebone/pocketbeagle) with actual single core CPU and respectively slow IO channels ... but it is awesome that this gets finally attacked at least :)
<ogra> pi's are way to powerful :)
<pstolowski> ogra: haha, pi3 is the slowest hw i have :)
<zyga> pstolowski: boot with cpu=1
<zyga> or whatever the switch is
<mborzecki> cpus iirc
<ogra> zyga, that doesnt help shpwing actual single core IO performance
<zyga> IO performance?
<pstolowski> i think the point of the test has already been proved
<ogra> yeah, the prob with real single core arm is that your IO is just something like a fifo ... if you take multi-core HW you still use the fast IO channels. even if you limite the number of cores
<ogra> yeah, it has
<pstolowski> and it obviously will be much worse on weaker specs
<ogra> but it wont give you realistic numbers as we get them on real customer HW
<ogra> right
<mborzecki> pstolowski: maxcpus https://elixir.bootlin.com/linux/latest/source/Documentation/admin-guide/kernel-parameters.txt#L2368 if you want to play with it
 * ogra points at 30min firstboot times :)
<pstolowski> mborzecki: yeah i know, i used it for some other test the other day
<mborzecki> pstolowski: each time we do an interation on performance :P
<mup> PR snapd#7321 opened: tests: restore dpkg selections after upgrade-from-2.15 test <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7321>
<zyga> where did mvo go?
<mup> PR snapd#7322 opened: tests: wait_for_service shows status after actual first minute <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7322>
<zyga> mborzecki: ^ two trivial PRs
<zyga> mborzecki: slightly longer but also simple https://github.com/snapcore/snapd/pull/7309
<mup> PR #7309: tests: re-implement user tool in python <Created by zyga> <https://github.com/snapcore/snapd/pull/7309>
<mup> PR snapd#7323 opened: features, overlord: make parallel-installs exported, export flags on startup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7323>
<mborzecki> zyga: feature flag ^^
<zyga> looking
<zyga> mborzecki: please also change cmd/libsnap-confine-private/feature.[ch]
<mborzecki> duh /o\
<zyga> :D
<mborzecki> ok, i can change that bit in the PR with C code
<zyga> mborzecki: add one liner test to TestControlFile as well please
<zyga> and if you do roll the C changes to flags here as well
<zyga> so that the other PR focuses only on the meat of the parallel installs for classic snaps
<zyga> d'oh
<zyga> I found why interfaces-fuse_support misbehaved
<zyga> I'll also rename the directory because it's silly
<zyga> hey mvo
<zyga> mvo: can you look at https://github.com/snapcore/snapd/pull/7319 - there's a question there
<mup> PR #7319: spread.yaml: set centos-7-64 to manual <Created by mvo5> <https://github.com/snapcore/snapd/pull/7319>
<mup> PR snapd#7319 closed: spread.yaml: set centos-7-64 to manual <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7319>
<zyga> thanks!
<mvo> zyga: yes, already replied, the most recent run of another PR was green so it seems to be resolved already
<zyga> mvo: I think 7321 is something you want to look at as well
<mvo> zyga: I saw it on 2 PRs before hence the change but looks short-lived
<zyga> (super simple)
<zyga> and if you still want to after that, https://github.com/snapcore/snapd/pull/7309 to put the user-tool change to rest
<mup> PR #7309: tests: re-implement user tool in python <Created by zyga> <https://github.com/snapcore/snapd/pull/7309>
<mvo> zyga: thanks, I will followup in this one
<mvo> zyga: on the 7321
<mup> PR snapd#7324 opened: image: improve/tweak some warning/error messages <Created by pedronis> <https://github.com/snapcore/snapd/pull/7324>
<pedronis> Chipaca: ^
<Chipaca> pedronis: thank you
<mup> PR snapd#7325 opened: cmd/libsnap-confine-private: add checks for parallel instances feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7325>
<mborzecki> zyga: ^^
<zyga> +1
<mup> PR snapd#7225 closed: tests: don't repeat checks <â Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7225>
<zyga> mborzecki: can you do a pass over the two simple PRs I sent
<zyga> I'll grab coffee and be back soon
<mvo> zyga: I added a comment to 7321, might be best to have a quick HO so that we can chat about the intended result
<zyga> mvo: d'oh!
<zyga> man so dpkg is not doing what I thought it would do
<mvo> zyga: no worries, its a common misconception
<mvo> zyga: this mechasnism is *really* old :)
<mup> PR snapd#7299 closed: sanity: report proper errror when fuse is needed but not available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7299>
<zyga> mvo: so are you saying there is no reliably way to save/restore actual packages installed on the system?
<mvo> zyga: is that what you want? checkpoint; do stuff; restore?
<zyga> yes
<zyga> so that this test doesn't impact the set of installed packages that much
<mvo> zyga: ok, let me scratch my head about this a wee bit
<mvo> zyga: there is no trivial way I think
<zyga> mvo: also, to actually describe the snasphot
<zyga> so that we can use the same thing for detection
<zyga> (in other words, to produce a diff when test doesn't clean up)
<mborzecki> zyga: sure, will do
<mvo> zyga: I add something in python-apt to tests/lib/bin
<zyga> mvo: super, thank you
<mvo> zyga: there is actually a tool called apt-clone which we might use but it won't remove stuff, should be easy to add though
<mvo> zyga: sry that this is so hard :/
<mup> PR snapd#7326 opened: tests: unmount fuse connections only if not initially mounted <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7326>
<zyga> mvo: for context, I have an in-flight tool called "testbed-tool" that invokes helper tools to examine system state (it uses mountinfo-tool currently)
<zyga> mvo: if we do it right I can use your apt code once you have it
<zyga> mvo: please look at 7326 -- that's the last leak on classic
<zyga> it took me longer because I was blind and didn't see - vs + in the diff :)
<zyga> this unblocks mount-ns test again
<zyga> we still leak stuff on core, mainly in mysterious ways (mounts that are not accounted to any snaps)
<zyga> but this is a major step towards not leaking anything anymore :)
<mup> PR snapd#7321 closed: tests: restore dpkg selections after upgrade-from-2.15 test <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7321>
<zyga> mborzecki: I'll focus on re-enabling mount-ns test on classic only now
<mborzecki> zyga: btw. parallel installs PR also broke socket activation under enforcing selinux, wonde if there's osmething wrong with the contexts after the bind mount
<mborzecki> zyga: obviously nothing in the logs :P
<zyga> mborzecki: oh, that's odd
<zyga> https://www.irccloud.com/pastebin/6v7HDXvH/
<zyga> do you have the log?
<mborzecki> zyga: no, need to try locally and probably disable noaudit
<zyga> +1
<zyga> I'll spawn some tests and return to 7218
<zyga> mvo: https://github.com/Originate/scriptkeeper
<pedronis> pstolowski: can #7219 be landed?
<mup> PR #7219: devicestate/firstboot: check for missing bases early <Created by stolowski> <https://github.com/snapcore/snapd/pull/7219>
<mborzecki> zyga: https://forum.snapcraft.io/t/cannot-use-gimp-snap-as-rawtherapee-external-editor/12908 heh /tmp
<mvo> zyga: I pushed something to your PR
<mvo> zyga: I am running a test locally now
<zyga> mvo: which one?
<mvo> zyga: the apt one
<zyga> ah, I closed it
<zyga> you can reopen though
<mvo> zyga: yeah, once the local run is done I will
<zyga> mvo: what did you push, gh is not showing anything (because it is closeD)
 * zyga hugs mvo for not giving up :)
 * zyga just ran 1400 tests without leaking a single mount entry 
<zyga> I'm _so_ happy we reached this stage
<zyga> core is the next battleground but it is already in a saner state because many of the bugs were shared
<mvo> zyga: hm, it rejected my push with permission denied
<mvo> zyga: thats odd
<zyga> yeah because it's closed now
<zyga> let me reopen
<zyga> mvo: try now please
<mvo> zyga: aha, interessting
<mvo> zyga: yeha, that works now
<mup> PR snapd#7321 opened: tests: restore dpkg selections after upgrade-from-2.15 test <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7321>
<zyga> mvo: git add apt-tool
<zyga> :D
<zyga> and I *love* what we are doing to tests
<zyga> 2000 tests and no leaks
<mvo> zyga: yeah, I could have sworn I did a git add before, maybe typoed
<mvo> oh well
<mup> PR snapcraft#2671 closed: docker: remove snapcraft-wrapper <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2671>
<mborzecki> wow, systemctl restart bluetooth killed the whole shell
<mvo> pushed now
<zyga> I wonder if core has a systemic problem or is it some systemic test that messes up there
<zyga> mborzecki: whaaat?
<zyga> mvo: mind if I improve on it? :D
<zyga> just with CLI and types
<zyga> mvo: cli helps to detect bugs in the invocation form the hsell
<zyga> *shell
<zyga> mvo: types help others and somewhat ourselves as we read the code
<mvo> zyga: lets wait to see if it actually works
<zyga> mvo: what happens when cache.commit() fails? is there a rollback or something?
<zyga> mvo: +1
<mvo> zyga: no, then the world is on fire
<zyga> heh
<zyga> the good old world of classic packages
<mvo> zyga: yes
<mvo> zyga: I destroyed my chroot just now with some strange maintainer script
<mvo> oh well
 * Chipaca wanders off to ponder lunch
<mvo> zyga: I'm a mupett s/python/pytho3/ for a start, reruning the test
<zyga> mvo: try any-python if it is compatible with python2 and python3
<mup> PR snapd#7327 opened: snap/naming: simplify SnapSet somewhat <Created by pedronis> <https://github.com/snapcore/snapd/pull/7327>
<mup> PR snapd#7322 closed: tests: wait_for_service shows status after actual first minute <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7322>
<pedronis> pstolowski: could you merge master into #7207 ? #7129 has a conflict now
<mup> PR #7207: snap: prevent duplicated snap name and snap files when parsing seed.yaml <Created by stolowski> <https://github.com/snapcore/snapd/pull/7207>
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<pedronis> wrong one
<pedronis> #7219
<mup> PR #7219: devicestate/firstboot: check for missing bases early <Created by stolowski> <https://github.com/snapcore/snapd/pull/7219>
<pstolowski> pedronis: yes, on it
<pstolowski> ok, i hope i merged correctly.. it was slightly confusing
<pedronis> pstolowski: I can double check
<mborzecki> slightly larger review around configstate & configcore https://github.com/snapcore/snapd/pull/7323 if anyone's interested
<mup> PR #7323: features, overlord: make parallel-installs exported, export flags on startup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7323>
<mborzecki> and it's green :P
<zyga> mborzecki: one comment there still needs changes
<mborzecki> hmmm
<mborzecki> w8
<mborzecki> du, didn't force push :/
<zyga> mvo: what's the status of https://github.com/snapcore/snapd/pull/7321?
<mup> PR #7321: tests: restore dpkg selections after upgrade-from-2.15 test <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7321>
<mvo> zyga: meetings, sry, need to look
<zyga> no worries
<mborzecki> zyga: hm about dpkg selections, there's probably a quick'n'dirty way to do that with rpm, baiscally rpm -qa > state.before and later rpm -ev $(grep -f state.before -v state.after)
<mborzecki> zyga: tbh, we could probably do the same with every package manager we support
<pedronis> pstolowski: this one I think needs a merge from master: https://github.com/snapcore/snapd/pull/7207
<mup> PR #7207: snap: prevent duplicated snap name and snap files when parsing seed.yaml <Created by stolowski> <https://github.com/snapcore/snapd/pull/7207>
<zyga> mborzecki: yeah, mvo started that for apt but we can explore generalizing it
<mup> PR snapd#7325 closed: cmd/libsnap-confine-private: add checks for parallel instances feature flag <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7325>
<mborzecki> zyga: and wow, rpm -e is sooo much faster than dnf erase zsh
<zyga> python :)
<pstolowski> pedronis: pushed
<pedronis> pstolowski: thanks, let's see how it goes
 * zyga runs a bunch of tests and breaks for a while
<zyga> ping me on TG for insta-back
<mup> PR snapd#7324 closed: image: improve/tweak some warning/error messages <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7324>
<mvo> zyga: the tool should finally be ok - sry for the slow going on this
<zyga> mvo: cool, I'm back now
<zyga> looking
<zyga> - Download snap "snapd-hacker-toolbelt" (22) from channel "stable" (stream error: stream ID 1; PROTOCOL_ERROR)
<zyga> booo
<mvo> zyga: I have a PR for that :/
<mvo> zyga: which failed in system-usernames-missing-user cleanup on tumbleweed :(
<pedronis> pstolowski: did you do something different when pushing the last time:  https://travis-ci.org/snapcore/snapd/jobs/575808884
<pedronis> mvo ^
<zyga> mvo: do we have a deadlock in those PRs?
<zyga> one fix blocking landing another
<mvo> zyga: I'm not sure why the tumbleweed one fails, I need to check, its strange
<mvo> zyga: I mean, I think we cleanup so I wonder how the snap_daemon can be there already
<zyga> mvo: userdel vs deluser?
<zyga> just a guess
<zyga> mvo: https://github.com/snapcore/snapd/pull/7309 is green
<mup> PR #7309: tests: re-implement user tool in python <Created by zyga> <https://github.com/snapcore/snapd/pull/7309>
<pstolowski> pedronis: hmm i don't think so
<mvo> zyga: checking
<pedronis> pstolowski: there is something weird there: https://github.com/snapcore/snapd/pull/7219/commits see the butlast commit
<mup> PR #7219: devicestate/firstboot: check for missing bases early <Created by stolowski> <https://github.com/snapcore/snapd/pull/7219>
<pedronis> pstolowski: I'm going to force push to it again
<mvo> zyga: merged now, sorry, my comment about shell was actually super silly
<mup> PR snapd#7309 closed: tests: re-implement user tool in python <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7309>
<zyga> mvo: hah, no worries :)
<zyga> mvo: thank you, one less PR
<mvo> zyga: like this user-tool was using "not" which is so not-standard
<zyga> not standard
<zyga> yeah
<zyga> just less insanity
<pstolowski> pedronis: hmmmmm i might have ctrl+c'ed git push upon realizing i did this from the vm, maybe something github got confused
<zyga> I think some of the shell stuff could be removed too, python has user/group lookup
<mvo> zyga: I'm still super puzlled though, I got an error that "groupadd snap_daemon" already exists. however afaict we cleanup carefully where we add this group (and user)
<zyga> mvo: hmmm, did you investigate with -debug
<mvo> zyga: yeah, I added some quick comments
<zyga> or with -shell-before
<mvo> zyga: I'm doing this now
<mvo> zyga: I suspect it depends on the order of tests so it will be tricky to reproduce
<mvo> but its very annoying, I think we really want 7317
<zyga> mvo: use this thing before my helpers are merged
<zyga> mvo: cat ../../runtime-state/runs | tr ' ' '\n'
<zyga> offtopic
<zyga> I just realized that the USB-C port on my GPU is really a generic USB-C port
<zyga> so I just plugged an ethernet card into my GPU
<mvo> zyga: yeah, not reproducible anymore when running locally :/
<zyga> and it worked
<zyga> the future is indeed now
<mvo> zyga: wuut? woah
<zyga> haha
<zyga> yeah
<zyga> my reaction exactly
<mvo> zyga: where does the ethernet card show up? on your main system?
<pstolowski> heh
<zyga> mvo: on the usb bus, the GPU provides an USB-C controller that is connected to the host
<mvo> zyga: magic!
<zyga> mvo: ubuntu 18.04 doesn't work with RTX 2080super so I need to reinstall 19.10 to try
<zyga> I just plugged an USB-C SSD
<zyga> and it also worked
<zyga> lol
<zyga> this is great
<zyga> this is on a computer that has only 2.0 USB ports otherwise
<zyga> (10 year old)
<zyga> :D
<mvo> zyga: where in the testsuite do you hook into to "measure" stuff. I want to see what test leaves the snap_daemon user behind
<zyga> mvo: let me show you one sec
<zyga> mvo: look at v
<zyga> https://github.com/snapcore/snapd/pull/7168
<mup> PR #7168: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>
<mvo> zyga: is it restore_project_each?
<zyga> look closer
<mvo> zyga: looking
<zyga> but ideally, just extend testbed-tool
<zyga> it's very easy
<zyga> though this is the shell version, the python rewrite is the one I will propose, it's just half done because I was busy fixing actual bugs
<pedronis> pstolowski: I redid the merge and pushed again
<mvo> zyga: aha, estore_suite_each() ?
<zyga> mvo: not quite
<pstolowski> pedronis: thank you
<zyga> mvo: because there are two things at play
<zyga> mvo: look where I put reset.sh --reuse-core call
<zyga> mvo: both need to be in place for the tool to be effective and precise
<zyga> mvo: please fork that and just hack testbed-tool
<zyga> on core some tests reboot which actually affects the mount table
<zyga> but that's fine, it's just a few of them
<mvo> zyga: my use-case is much simpler, I just need to check for getent passwd snap_daemon
<zyga> mvo: sure
<mvo> zyga: but I appreciate the hints where to look/hook into etc
<zyga> :-)
<mvo> zyga: its probably something silly but I can't pinpoint it
<mvo> zyga: maybe your python rewrite is enough, could be some stupid shell side effect or whatnot
 * mvo shakes fist
<zyga> mvo: try it
<mvo> yeah, doing a tumbleweed spread run now
<mvo> zyga: also I think I only saw this on tumbleweed so far so maybe something funny is going on there for real
<zyga> chasing bugs on Friday evening
<zyga> could be
<zyga> I'll make coffee and see how my tests are doing
<mvo> yeah, not a great time, I will soon need to leave to play some hockey
<mvo> zyga: good luck!
<zyga> https://github.com/snapcore/snapd/pull/7326 failed again
<mup> PR #7326: tests: unmount fuse connections only if not initially mounted <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7326>
<zyga> I restarted it on xdg stuff and on some other junk before
<zyga> slow transfers
<zyga> mvo: replied to your python comments
<zyga> I'll shoot a follow up with a comment and extra --remove
<zyga> but first, coffee!
<zyga> that USB-C thing made me think
<zyga> I could use one cable to connect everything I need for my PCc
<zyga> usb-c -> usb-c screen -> hub with mouse / keyboard network
<zyga> the original motherboard would only have the power cord
<zyga> so mac-like, gosh
<zyga> :D
<zyga> back to coffee
 * genii 's ears perk up for a second when he gets highlighted by "coffee"
<pstolowski> pedronis: #7202 is green, we can merge
<mup> PR #7202: tests: sync journal log before start the test <Simple ð> <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7202>
<pstolowski> grr i mean #7207
<mup> PR #7207: snap: prevent duplicated snap name and snap files when parsing seed.yaml <Created by stolowski> <https://github.com/snapcore/snapd/pull/7207>
<pstolowski> merged
<mup> PR snapd#7207 closed: snap: prevent duplicated snap name and snap files when parsing seed.yaml <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7207>
<zyga> re, sorry
<zyga> baby interrupt
<zyga> lucy was walking a little for the first time!
<pstolowski> zyga: wooah!
<pstolowski> pedronis: and #7219 is in a weird limbo state
<zyga> one small interrupt and I'm back a
<mup> PR #7219: devicestate/firstboot: check for missing bases early <Created by stolowski> <https://github.com/snapcore/snapd/pull/7219>
<pstolowski> i've canceled & restarted the job
<zyga> back
<zyga> stuff is annoyingly red
<zyga> journal match failed
<pstolowski> 7219 stuck on https://usercontent.irccloud-cdn.com/file/yVpp7zaJ/Zrzut%20ekranu%202019-08-23%20o%2018.27.57.png
<zyga> pstolowski: I heard that travis has issues with google
<zyga> pstolowski: requesting a VM on gce can take multiple minutes
<zyga> pstolowski: that's why LXD is so hot for them
<pstolowski> zyga: oh well, time for weekend i guess
<zyga> it's insta-up
<pstolowski> o/
<zyga> pstolowski|afk: enjoy the summer!
<zyga> see you on Monday
<mup> PR snapd#7326 closed: tests: unmount fuse connections only if not initially mounted <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7326>
<zyga> google:ubuntu-core-16-64:tests/main/interfaces-account-control:accore18 needs fixes
<mup> PR snapcraft#2683 opened: meta: move _errors to errors with related error classes <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2683>
<mup> PR snapd#7328 opened: tests: pass --remove to userdel on core <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7328>
<mup> PR snapcraft#2683 closed: meta: move _errors to errors with related error classes <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2683>
<mup> PR snapcraft#2684 opened: meta: decouple DesktopFile logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2684>
<popey_> ogra_: https://twitter.com/ABRStewart/status/1165029896013398016
<popey_> (nethack is outdated)
<popey_> Words that I wouldn't have expected to say, with that meaning, in 2019
<popey_> jdstrand: you may have noticed, we're catching up with store requests.
#snappy 2019-08-24
<Psil0Cybin> Hey what gives
<Psil0Cybin> im trying to install snapd on Kali its having ALL Sort of probelms
<Psil0Cybin> the /home directory wont let me install any application
<Psil0Cybin> nor run it
<Psil0Cybin> it says my /home is not my /home?
<Psil0Cybin> What?
<Psil0Cybin> https://bugs.launchpad.net/snappy/+bug/1620771
<mup> Bug #1620771: when /home is somewhere else, snaps don't work <link> <snap> <symlink> <Snappy:Won't Fix> <https://launchpad.net/bugs/1620771>
<Psil0Cybin> can someone help me with this plz
<Psil0Cybin> https://forum.snapcraft.io/t/support-for-non-home-homedirs/11209
<popey_> Psil0Cybin: do you have an interestingly different /home setup?
<Psil0Cybin> popey_, not that i know of buit im using kali linux
<Psil0Cybin> so perhaps it did something special for me
<Psil0Cybin> popey_, would i follow something along these lines
<Psil0Cybin> https://miloserdov.org/?p=2448&PageSpeed=noscript
<Psil0Cybin> or https://miloserdov.org/?p=2448 but why would i add anything to my bash?
<mup> PR snapd#7317 closed:  httputil: rework protocol error detection  <Test Robustness> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7317>
<mup> PR snapd#7219 closed: devicestate/firstboot: check for missing bases early <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7219>
<ogra> popey, nethack updated ...
<katnip`> how do update my snap apps?
<ogra> you mean the ones you packaged ? or as a user ?
<katnip`> as a user
<ogra> you dont, they update themselves as soon as something new is released to the channel you are using
<katnip`> oh ok, ty
<ogra> (snap info <package> gives you info about the revisions available in different channels, what you are tracking locally etc etc)
<katnip`> alright, very nice,  thank you
<mup> PR snapd#7327 closed: snap/naming: simplify SnapSet somewhat <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7327>
<ardaguclu_> When I delete the state.json file, although it creates a new one but daemon can not start
<ardaguclu_> it is something intended or is it unexpected behavior?, I want to delve into it.
<ardaguclu_> BTW, I am talking about while debugging, current snapd is working in initialize system state
<uebera||> Hi. Is there some kind of hook which allows you to send a mail whenever a snap gets updated instead of comparing the current output of "snap list" with the last run using a cron job?
<mup> Bug #1841327 opened: Install snaps in Dockerfile <Snappy:New> <https://launchpad.net/bugs/1841327>
#snappy 2019-08-25
<Saviq> sitter: hey, I'm trying to move https://snapcraft.io/subsurface to use the kde framework snap (to deduplicate and to get newer Qt), unfortunately the framework snap doesn't include QtBluetooth - I tried to build it myself as a part, but private headers (correctly) are not there in the build snapâ¦ got any pointers? prior art? I suppose I could just check out qtbase at the same version and use it as include path to build qtconnectivity, but maybe you have
<Saviq> other ideas? :)
#snappy 2020-08-17
<mup> PR snapd#9168 opened: o/hookstate/ctlcmd: make is-connected check whether the plug or slot exists <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9168>
<zyga> mvo hello
<zyga> mvo I'll be off today, Lucy had fever all night and my wife has some errands so I'm just not available
<zyga> if there's something you want to talk about we can do a short 1:1
<zyga> or talk via messages
<mvo> zyga: thanks, no worries
<mup> PR snapd#9169 opened: secboot,cmd/snap-bootstrap: don't import boot package from secboot <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9169>
<jdstrand> mvo: hey, fyi, I'm going to address feedback in PR 8920 and submit 1-2 'misc policy updates' PRs today/tomorrow
<mup> PR #8920: interfaces: update cups-control and add cups for providing snaps <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>
<mvo> jdstrand: great, thanks you
<jdstrand> mvo: I'll address the teardown item for PR 9120 now. for PR 9167, I thought about having that in wrappers/desktop.go and having the apparmor policy pull it out, but the more I thought about it, I agreed with James that it should be in snap info. if you want me to put it in wrappers, I can do that though
<mup> PR #9120: interfaces: add kernel-crypto-api interface <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9120>
<mup> PR #9167: many: correctly calculate the desktop file prefix everywhere <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9167>
<mvo> jdstrand: it's fine, no worries
<jdstrand> mvo: you probably noticed that for anything going to master that I'd like in 2.46, I'm then creating a 2.46 PR. I'll be doing that with PR 9167 and PR 8301
<mup> PR #9167: many: correctly calculate the desktop file prefix everywhere <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9167>
<mup> PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301>
<mvo> jdstrand: I think I agree with james here too plus we could always tweak later if e.g. Samuele feels strongly
<jdstrand> mvo: assuming that works for you :)
<mvo> jdstrand: thanks for that, that works
<mvo> jdstrand: I may actually merge master into 2.46 because since we branched only changes we want there anyway have landed
<jdstrand> mvo: yeah, I think what convinced me is when I saw some 3 different spots trying to calculate the desktop files
<mvo> jdstrand: exactly
<mvo> ijohnson, cmatsuoka a review for 9152 would be great if you have some spare cycles
<ijohnson> mvo: sure I will look this morning then
<cmatsuoka> mvo: sure, will check
<ijohnson> mvo: I just looked at your review of 9010, thanks for the review the TODO there is fine, the TODO is just about moving something from the initrd fs layout units to snap-bootstrap itself, it's not a regression or missing functionality
<ijohnson> mvo: I will push a patch changing that const name however
<mvo> ijohnson: nice, thank you!
<mvo> ijohnson: if there is no regression I will approve it, wasn't totally clear to me
<ijohnson> thanks
<mvo> ijohnson: feel free to do as a followup though, given that the PR is green and already long/big etc
<ijohnson> mvo: sure that would actually be nicer to do as a followup then
<mvo> ijohnson: and we want followups anyway
<mvo> ijohnson: +1
<ijohnson> yes indeed
<mvo> ijohnson: let's discuss in the uc20 meeting how to coordinate the landing with the kernel
<ijohnson> mvo: ack I will wait to hit the big green button then just so we understand that
<mvo> ijohnson: \o/
<mvo> ijohnson: all right, let's merge away I think :)
<ijohnson> mvo: so from that meeting I am good to squash merge #9010 ?
<mup> PR #9010: cmd/snap-bootstrap/initramfs-mounts: call systemd-mount instead of the-tool <Run nested> <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9010>
 * ijohnson clicks the button
<ijohnson> ð
 * mvo hugs ijohnson 
<mup> PR snapd#9010 closed: cmd/snap-bootstrap/initramfs-mounts: call systemd-mount instead of the-tool <Run nested> <Squash-merge> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9010>
<mup> PR snapd#9170 opened: cmd/snap-bootstrap/initramfs-mounts: tweak names, add comments from previous PR <Simple ð> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9170>
<mup> PR snapd#9169 closed: secboot,cmd/snap-bootstrap: don't import boot package from secboot <Simple ð> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9169>
<MikeRL> Anyone know how to restart all snap related services under systemd? I'm running into an error. https://paste.ubuntu.com/p/BXyVY4sk4X/
<MikeRL> Hopefully this is the correct channel for snap related support/
<MikeRL> Also will apt-purging snapd cause all snaps to be deleted?
<MikeRL> In the meantime, I will reinstall the snapd package. Via synaptic. Hopefully that stops the error.
<ijohnson> MikeRL: you can try restarting snapd via `systemctl restart snapd`
<ijohnson> MikeRL: removing the apt snap package will remove all your snaps, but not your snap data, but purging the package will also remove the snap data as well
<MikeRL> ijohnson, Thanks. The reinstall fixed it.
<MikeRL> snap list still shows snaps like chromium as there.
<ijohnson> great glad to hear that
<MikeRL> I saw that same error on a Microsoft page for Windows Subsystem for Linux. Weird. I got that error on a Pi 4 on Ubuntu Mate beta 2.
<MikeRL> Wonder if there's any logs. Should I look for some? Where to look?
<MikeRL> Maybe it's a bug?
<ijohnson> MikeRL: if you have `journalctl --no-pager -u snapd` as well as `snap changes` that would be useful to include in a bug report on bugs.launchpad.net/snapd
<MikeRL> ijohnson, Working on it.
<MikeRL> Well I've hit an issue. Snapd doesn't allow me to report snaps without contact info.
<MikeRL> I did this via ubuntu-bug.
<MikeRL> https://bugs.launchpad.net/snapd/+bug/1891926
<mup> Bug #1891926: Snapd won't connect to internet <deb> <network> <snapd> <snapd:New> <https://launchpad.net/bugs/1891926>
<MikeRL> I would've used a more descriptive title, but I'm uncertain to what a better one would be.
<ijohnson> thanks MikeRL, could you also include `journalctl --no-pager -u snapd.socket` in that bug report if you're able?
<MikeRL> On the way.
<MikeRL> Done.
<mup> PR snapd#9166 closed: interfaces/many: miscellaneous updates for strict microk8s - 2.46 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9166>
<mup> PR snapd#9170 closed: cmd/snap-bootstrap/initramfs-mounts: tweak names, add comments from previous PR <Simple ð> <Skip spread> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9170>
<mup> Issue core20#61 closed: /etc/writable is double mounted <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/core20/issues/61>
#snappy 2020-08-18
<zyga> good morning
<zyga> battery running low, brb
<zyga> re
<zyga> mvo: quiet day, eh?
<mvo> zyga: good morning
<mvo> zyga: yes, pretty quiet
<mvo> zyga: did you enjoy your long weekend?
<zyga> yes, though lucy had fever yesterday and we were worried
<zyga> it's all meant to be quite different, my wife returned to work today and (before I got sick) I was supposed to take two weeks off
<zyga> but reality struck and here we are :)
<mvo> zyga: yeah, reality is annoying sometimes - but you can't argue with it - it's always right :/
<zyga> :D
<zyga> yep
<pstolowski> morning
<mvo> good morning pstolowski
<mvo> pstolowski: hope you had a nice long weekend
<pstolowski> mvo: hey! yes, was very nice
 * zyga had breakfast
<zyga> Lucy still sleeping :)
<zyga> I'm working on the udev integration branch
<zyga> it's open for so long and should not take long to finish
<mvo> zyga: nice!
<zyga> hmm, some store EOFs
<zyga> - Download snap "core18" (1885) from channel "stable" (unexpected EOF)
<zyga> is unexpected EOF something we retry on?
<mvo> pstolowski: unless you disagree I will (squash) merge 9152
<mvo> zyga: probably, might be worthwhile to check the logs
<zyga> mvo: here it was during "snap install shellcheck" before we ran spread
<zyga> so no logs
<pstolowski> mvo: fantastic! yes, go for it, thanks
<mup> PR snapd#9152 closed: cmd/snapd-generator: generate drop-in to use fuse in container <Bug> <Preseeding ð> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9152>
<zyga> store is really unhappy today
<mup> PR snapd#9102 closed: corecfg: add "system.timezone" setting to the system settings <Run nested> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9102>
<pstolowski> jamesh: hi! minor comment to your snapctl is-connected PR
<jamesh> pstolowski: looking
<jamesh> pstolowski: would it actually be possible to call snapctl in a context where implicit plugs and slots existed?
<pstolowski> jamesh: we have a 'hack' for implicit slots (AddImplicitSlots helper) that we explicitly call over SnapInfo of system snap in various places. if core had interface hooks for slots than I image it would be needed. but i'd leave it as is for now because it's not going to be needed any time soon
<pstolowski> s/image/imagine/
<jamesh> I suppose core has a configure hook where it could make a difference if it actually checked
<pstolowski> jamesh: it has but the hook is "hijacked" and handled internally
 * zyga moves to the office, lucy is now awake and handled by grandparents
<pstolowski> mvo: there is one question from Samuele pending your input on https://github.com/snapcore/snapd/pull/9084, can you take a look?
<mup> PR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<mvo> pstolowski: sure, looking
<mvo> pstolowski: replied
<pstolowski> ty
<zyga> mvo: uh
<zyga> we have a very silly bug in master
<zyga> mvo: patch coming right up
<mvo> zyga: oh, ok
<mup> PR snapd#9171 opened: [RFC] "virtual" configuration for timezone <Needs Samuele review> <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9171>
<mup> PR snapd#9172 opened: tests: update spread test for unknown plug/slot with snapctl is-connected <Simple ð> <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9172>
<pstolowski> jamesh: i've updated snapctl spread test to test the new error message ^
<zyga-mbp> mvo https://github.com/snapcore/snapd/pull/9173
<mup> PR #9173: cmd: compile snap gdbserver shim correctly <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9173>
<mup> PR snapd#9173 opened: cmd: compile snap gdbserver shim correctly <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9173>
<mvo> zyga-mbp: thank you
<zyga-mbp> I really wonder what tests will say
<zyga-mbp> I never tried this
<mvo> 9084 needs a second review if someone has some spare cycles
<mup> PR snapd#9120 closed: interfaces: add kernel-crypto-api interface <Needs Samuele review> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9120>
<mup> PR snapd#9165 closed: interfaces: add kernel-crypto-api interface - 2.46 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9165>
<zyga-mbp> looking
<mup> PR snapd#9167 closed: many: correctly calculate the desktop file prefix everywhere <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9167>
<zyga-mbp> pstolowski https://github.com/snapcore/snapd/pull/9084#pullrequestreview-469207489
<mup> PR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<zyga-mbp> brb, I'll fetch some water
<mvo> 9081 also needs a second review
<mvo> jdstrand: 8301 has conflicts now, could you please have a look?
<mvo> pstolowski: just fyi, I uploaded a new snapd to groovy with the lxd generator fix so that should allow groovy lxd preseed images. could you please let the relevant people know (still needs some hours before it enters groovy proper, still building of course)
<pstolowski> mvo: sure, thanks
 * zyga fetched lunched instead
<zyga> re
<zyga> opensuse tumbleweed seems to be unhappy
<zyga> error: cannot query the store for updates: got unexpected HTTP status code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh"
<zyga> more store woes
<zyga> pstolowski: ping
<zyga> I have this in a debug shell
<zyga> + lxd.lxc exec my-nesting-ubuntu -- snap set lxd waitready.timeout=240
<zyga> error: cannot perform the following tasks:
<zyga> - Run configure hook of "lxd" snap (snap "lxd" has no "configure" hook)
<zyga> nested snaps are all broken, not mounted
<pstolowski> zyga: ok, that's weird
<pstolowski> zyga: is it master?
<zyga> yep
<zyga> but seems random
<zyga> https://paste.ubuntu.com/p/3YspQRfGvT/
<zyga> interesting failed unit
<zyga> no snap mounted
<zyga> I guess one idea would be to not run hooks on broken snaps
<zyga> the snaps are on disk
<zyga> looking at the mount units
<zyga> there are no mount units?!?
<pstolowski> did i broke something with systemd generator thing..?
<zyga> maybe
<zyga> looking
<pstolowski> mvo: was #9152 green when it landed, or did you merge manually?
<mup> PR #9152: cmd/snapd-generator: generate drop-in to use fuse in container <Bug> <Preseeding ð> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9152>
<zyga> fstab has only LABEL=cloudimg-rootfs	/	 ext4	defaults	0 0
<zyga> but there's no /dev/disk/by-label
<zyga> I guess that's because of a container
<zyga> and also explains the failed unit
<zyga> seems like a separate container bug
<zyga> I don't see any evidence that snapd generator ran
<zyga> well
<zyga> actually
<zyga> I do see snap.mount
<mvo> pstolowski: I thought it was, maybe I was mistaken
<zyga> and nothing else
<mvo> pstolowski: do you see errors now?
<zyga> what's the other file we should have created?
<zyga> the file /run/systemd/container is present
<zyga> and has the word "lxc"
<zyga> I guess that's why nothing mounted btw
<zyga> but it's funny
<zyga> I guess terrible
<zyga> that we INSTALLED snaps in broken state after mounting failed
<zyga> mounting should have undone everything
<zyga> changes and tasks from the container https://paste.ubuntu.com/p/VPH4DwbGvx/
<pstolowski> zyga: there should drop-ins in /run/systemd/generator for all the snap mount  untis for /etc/systemd/system
<pstolowski> zyga: are there mount units in /etc/../system ?
<zyga> there are no drop ins
<zyga> https://paste.ubuntu.com/p/ft8pr6qXrC/
<zyga> and there are no mount nits
<zyga> but we remove them in undo
<zyga> although this makes no sense because "snap list" shows all the snaps installed and broken
<zyga> this is tests/main/lxd
<zyga> perhaps it's using older non-repackaged core18 + snapd
<zyga> hmm hmm
<pstolowski> zyga: ok if there are no mount units then root cause is elsewhere, not in the generator
<zyga> can you just spread 16.04 + tests/main/lxd
<zyga> and see if that fails
<zyga> pstolowski: well, mount units do get removed on undo
<zyga> but I really don't know what to make of this
<zyga> the generator only has the /snap sharing mount
<zyga> but doesn't have the drop ins
<zyga> ah
<zyga> 1337.2.46~pre2
<zyga> well
<zyga> 1337 is the repackaged
<zyga> so...
<zyga> hmmm
<mvo> zyga, pstolowski standup
<zyga> it seems broken
<zyga> oh
<zyga> joining
<jdstrand> mvo: hi! certainly, I'd love to. thanks for the reviews/merges! :)
<mvo> jdstrand: thank you!
<jdstrand> mvo: fyi, the cups one should good for re-review whenever people have a chance (though I'm going to merge master real quick). I'll quickly respond to any feedback there. moving on to 'misc policy updates' then after, will go through any PR reviews that need me
<zyga> jdstrand: could you try to look at https://github.com/snapcore/snapd/pull/7614 again
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<zyga> jdstrand: I pushed it forward
<jdstrand> zyga: sure
<pstolowski> zyga: main/lxd failed for me as well
<zyga> good
<zyga> so it's a real thing
<zyga> (reproducible)
<zyga> pstolowski: try reverting the generator changes to see if that does something
<jdstrand> "corecfg: add "system.timezone" setting to the system settings"
<jdstrand> nice! :)
<zyga> jdstrand: snap regedit ...
<zyga> ;-)
<jdstrand> ah, I wonder if that lxd thing is what was causing my spread tests to fail...
<jdstrand> zyga: heh
<zyga> jdstrand: I think we may have broken master
<pstolowski> zyga: ok will do just in case, although it would contradict what ijohnson said
<zyga> pstolowski: sure - just a sanity check
<pstolowski> oh it wasnt't squash-merged
 * jdstrand will keep an eye on commits to master for something to unbreak things then
<ijohnson> zyga: yeah I saw it on my PR's last night before the generator stuff had landed
<zyga> ah, sorry, I couldn't hear that exactly
<zyga> that's good, maybe something environmental changed
<zyga> jdstrand: and comments in that PR are a bit in a weird state, I could not reply to some
<zyga> jdstrand: so please open new comments on anything that you find wrong
<mup> PR snapcraft#3165 closed: Update cmake plugin to support Ninja generator <enhancement> <Created by GamePad64> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3165>
<zyga> pstolowski, ijohnson: interesting
<zyga> in a debug shell look at the other container (my-ubuntu)
<zyga> it has core installed as well
<zyga> and guess what, core works
<zyga> all the seeded snaps are broken
<zyga> core is not seeded
<zyga> does this make _any_ sense to you?
<zyga> maybe what is really broken
<zyga> is that /etc/systemd/system just doesn't have any mount units
<zyga> maybe the image is broken to begin with
 * zyga looks
<zyga> pstolowski: confirmed
<zyga> the image is busted
<zyga> however it was made is wrong
<zyga> pstolowski: should I expect to see mount units inside a squashfs lxd image? (in a container image downloaded by lxd)
<zyga> I see the snaps and everything else
<zyga> but the mount units are simply missing
<zyga> as if it was seeded but then something filtered out the .mount units
<zyga> pstolowski: to reproduce look at /var/snap/lxd/common/lxd/images/97c470e427c425cf2ec4d7d55b6f1397ea55043c518b194a58fc6b9da426f540.rootfs on /tmp/dupa type squashfs (ro,relatime)
<zyga> cc stgraber ^
<jdstrand> mvo: fyi, PR 8301 is deconflicted
<mup> PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301>
<zyga> stgraber: it seems that 20.04.1 images that lxd pulls in are snap seeded in a broken way
<zyga> stgraber: etc/systemd/system does not have any mount units
<stgraber> zyga: that'd be a bit concerning as the squashfs we use is supposed to be identical filesystem as the cloud image
<zyga> stgraber: can you double check that I'm not making some rookie mistake
<zyga> I mounted the .rootfs as downloaded by lxd
<zyga> and looked at /etc/systemd/system therein
<stgraber> it's this image in your case: http://cloud-images.ubuntu.com/releases/focal/release-20200804/
<zyga> are they all identical?
 * zyga pulls the squashfs
<stgraber> they should be
<zyga> a bit slow to pull, I'll let it do its thing
<pstolowski> i wonder if they started preseeding them and something went wrong
<zyga> the date says 4th of August
<zyga> maybe it is before we had some fixes?
<zyga> and it's just busted \
<ogra_> zyga, my yesterdays focal image that i installed looks fine here ... why would mount units be n the readonly squashfs though ?
<zyga> ogra_: IIRC because we pre-seed things
<zyga> so they start faster
<zyga> isn't the squashfs expanded anyway, it's just a template
<zyga> it's not a snap
<ogra_> root@focal:~# ls /etc/systemd/system/*.mount|wc -l
<ogra_> 8
<zyga> ogra_: that's not what I'm seeing
<ogra_> root@focal:~# snap list|wc -l
<ogra_> 6
<zyga> what are the mount units?
<zyga> I had 0 mount units
<zyga> (though I'm still getting the image stgraber suggestd)
<ogra_> root@focal:~# ls /etc/systemd/system/*.mount
<ogra_> root@focal:~#
<ogra_> bah
<ogra_> let me pastebin that
<zyga> I saw the failure in a spread test that was just "lxd launch ..." things
<zyga> thanks
<ogra_> https://paste.ubuntu.com/p/HJJ3NN9hxm/
<zyga> right
<zyga> this is more like what I would expect
<zyga> I think an image is broken then, the only question is why and how to fix it
<stgraber> stgraber@castiana:~/Downloads$ tar Jtvf ubuntu-20.04-server-cloudimg-amd64-root.tar.xz | grep etc/systemd | grep mount
<ogra_> thats what i got with "lxc launch ubuntu:20.04 focal" ...
<stgraber> stgraber@castiana:~/Downloads$
<pstolowski> zyga: also, it's from 4th Aug but started failing yesterday?
<zyga> pstolowski: yeah, I think we are missing something
<zyga> stgraber: 97c470e427c425cf2ec4d7d55b6f1397ea55043c518b194a58fc6b9da426f540.rootfs can we map that hash to something on cdimage?
<stgraber> pstolowski: assuming it's using ubuntu:, the images are manually promoted by CPC IIRC, though indeed feels a bit old
<stgraber> zyga: I did it for you
<stgraber> zyga: that's the URL I gave you
<zyga> ah
 * zyga looks at one more idea
<stgraber> current ubuntu:focal is indeed 20200804 on cloud-images.u.c
<stgraber> ubuntu-daily:focal would be 20200814
<stgraber> there's a pretty good chance that the cloud images would similarly be missing those files, it's really meant to be identical across the board
<stgraber> so you probably should be talking to CPC :)
<mup> PR snapd#9173 closed: cmd: compile snap gdbserver shim correctly <Bug> <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9173>
<zyga> thanks mvo
<ijohnson> sorry had to step out for IRL things
<ijohnson> so is the lxd image just busted then ?
<zyga> ijohnson: it seems so but unclear why
<zyga> I noticed something buggy in the test
<zyga> looking now
<zyga>     lxd.lxc launch --quiet "ubuntu:${VERSION_ID:-}" my-ubuntu
<zyga> VERSION_ID is not defined anywhere
<zyga> what does that fetch?
<zyga> latest?
<stgraber> ah so you went from bionic to focal last week then
<zyga> I think it's a bug and it was meant to fetch the one matching
<zyga> so it's likely that this bug triggers another one
<stgraber> "ubuntu:" fetches the latest recommended LTS
<stgraber> that was bionic until 20.04.1
<stgraber> now is focal
<ijohnson> zyga: I think we get VERSION_ID from /etc/os-release which gets sourced somewhere in the prepare for a spread run iirc
<zyga> ijohnson: I doubt that
<zyga> thre was some code in that task.yaml
<zyga> it's gone now
<zyga> must have been killed by accident
<zyga> and ${VERSION_ID:-} masked that
<ijohnson> haha fair enough
<zyga> it used to load version id from the host
<zyga> because it was about alignment of the container to the system
<zyga> as we copy stuff inside
<pstolowski> zyga: i'm looking at ubuntu-20.04-server-cloudimg-amd64-root.tar.xz (also dated 4/08) is this as good as any other image there? fwtw it is NOT preseeded, it's still seeding the old way
<zyga> I see
<zyga> I'll start by fixing that VERSION_ID
<zyga> but it seems we have more bugs
<zyga> pstolowski: can you focus on trying to understand what's going on in the inner layer
<zyga> I'll send a patch fixing the symptom we see
<zyga> ijohnson: you broke it ;D
 * ijohnson runs and hides
<ijohnson> zyga: was it my use the same version of lxd everywhere PR ?
<zyga> d4a802934b1e62ec8924ea1c165a627695df5044
<zyga> that's the broken patch
<zyga> anyway, fixes coming
<ijohnson> zyga: haha to be fair though you approved the PR :-D
<zyga> no hard feelings
<zyga> at this point I'm beyond shame
<zyga> I made so many bugs
<ijohnson> yeah bugs happen
<ijohnson> no worries
<pstolowski> zyga: so what's actually broken? do i need to keep looking?
<zyga> pstolowski: that test is broken when invoked with a focal image
<zyga> pstolowski: on a xenial host
<zyga> pstolowski: it should work
<zyga> pstolowski: to reproduce just grab xenial VM
<zyga> pstolowski: install lxd the same way
<zyga> pstolowski: and boot focal
<zyga> pstolowski: that should work and give you a working focal container with working snaps
<pstolowski> zyga: ok so it's a test issue, not a real problem?
<zyga> pstolowski: it's a real problem
<zyga> pstolowski: the test just now stumbled onto it
<zyga> pstolowski: it was not exercising that before
<pstolowski> ah ok
<zyga> pstolowski: but effectively started doing that because of another issue and recent promotion of focal
<zyga> pstolowski: PR coming up, I've explained it there as well
<zyga> just confirming that my patch fixes it
<ijohnson> zyga: so the right thing for this lxd test is for a xenial host to run a xenial container and a focal host to run a focal container ?
<zyga> ijohnson: yes
<zyga> there's a comment there explaining why
<ijohnson> zyga: I wonder if we should expand the lxd test to have more variants i.e. xenial host launches focal, bionic and xenial
<ijohnson> oh
 * ijohnson goes to read that comment
<zyga> yes but then we should not just blindly copy snapd
<zyga> but I agree
<ijohnson> ah yes
<ijohnson> I see
<ijohnson> see if we built the snapd snap and used that as part of our tests we could avoid this
<zyga> yes
<zyga> I'm sure we could
<zyga> it's just a limitation of the current setup
<zyga> all proper builds will work
<zyga> (properly built rpm will work on rpm distros)
<zyga> geez that test is sloooooow
<ijohnson> mmmm also this test is disabled for uc20 too
<zyga> (network)
<ijohnson> we should re-enable that and make sure lxd works on uc20
<zyga> I agree
<zyga> maybe worth splitting lxd test
<zyga> and thinking of a cache for lxd images if that helps
<zyga> FYI https://github.com/snapcore/snapd/pull/9174
<mup> PR #9174: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>
<zyga> opened while local test is still going
<zyga> so likely it works now
<zyga> but I want to break now as my wife just returned from her first day of work after Lucy was born
<zyga> I'll work later in the evening, to focus on bug triage
<zyga> I think it's still broken though
<zyga> just got this
<zyga> https://paste.ubuntu.com/p/yJ6HThPdN6/
<mup> PR snapd#9174 opened: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>
 * zyga akf
<ijohnson> zyga: approved
<zyga> ijohnson: let's see it pass
<ijohnson> well it "looks correct" :-)
<zyga> I agree :)
<zyga> oh
<zyga> it passed
<zyga> woooot
<zyga> Ok
<zyga> I'm really afk now
<mvo> zyga \o/
<mvo> jdstrand: one quick question in 8301
<cmatsuoka> ijohnson: do you have any idea on why chooser triggering is not working in recover mode? the trigger file in /run is not there but I still didn't check if it's not being generated at all, or it's not being moved from initramfs to the real system
<ijohnson> cmatsuoka: oh hey I tried that and it seemed to work for me with all edge snaps just now
<cmatsuoka> oh really? then it must be something I'm doing locally, let me recheck
<ijohnson> cmatsuoka: yes it took like a minute to trigger the chooser, etc. but it definitely wasn't 10 minutes or longer before the chooser came up
<jdstrand> mvo: answered
<mup> PR snapcraft#3251 opened: build providers: honour http proxy settings for snapd <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3251>
<cmatsuoka> ijohnson: indeed it works with edge, so probably my remastering of initramfs is the source of the problem
<cachio> mvo, hey
<cachio> failover tests failing on master as well
<mvo> cachio: hey
<mvo> cachio: oh no! can you please paste the full error log?
<cachio> mvo, https://paste.ubuntu.com/p/7c56xfYGwC/
<cachio> I just merged before running the tests
<cachio> so my master is up to date
<mup> PR snapcraft#3252 opened: snapcraft: use system certificates by default for https requests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3252>
<mvo> cAug 18 14:55:53 localhost.localdomain snapd[3776]: Aug 18 14:55:28 localhost.localdomain systemd[3584]: snapd.service: Failed at step EXEC spawning /snap/snapd/x1/usr/lib/snapd/snapd: Exec format error
<mvo> hm, but maybe this is just the message that it failed correctly
<mvo> cachio: the "external:" image, how was this build?
<mvo> cachio: also, what is the output of "journalctl -u snapd-failover.service"?
<cachio> mvo, ubuntu-image snap
<mvo> cachio: I need to be afk for some minutes but I guess my question is, what commands do I need to run to trigger this error myself (to reproduce :)
 * mvo is afk for some minutes but will read scrollback
<cachio> let me run again
<cachio> mvo, wget https://storage.googleapis.com/spread-snapd-tests/images/pc-amd64-16-beta/pc.img.xz
<cachio> sudo kvm -snapshot -smp 2 -m 1500 -net nic,model=virtio -net user,hostfwd=tcp::8022-:22  -serial mon:stdio pc.img
<cachio> then run
<cachio> export SPREAD_EXTERNAL_ADDRESS=localhost:8022
<cachio> ./tests/lib/external/prepare-ssh.sh localhost 8022 <your-lp-id>
<cachio> spread -debug external:ubuntu-core-16-64:tests/core/core-to-snapd-failover16
<cachio> mvo, following those step you can reproduce 100%
<pstolowski> zyga: i'm playing with this broken lxc container. in this state i cannot remove or refresh broken snapd snap, a dead end
<cmatsuoka> ijohnson, mvo: I ran some extra tests here and apparently what makes the difference in the reboot from chooser is using a local, unchanged core20 snap vs the edge asserted core20
<pstolowski> zyga: interestingly, i could manually snap install lxd and core18 snaps from seeds, and after that snap set lxd waitready... woks
<pstolowski> *works
<cmatsuoka> ijohnson, mvo: erm, wait. that's strange. let me do it again
<pstolowski> zyga: also saw this, not sure if it means anything https://pastebin.ubuntu.com/p/sJvDhxp5gy/
<cmatsuoka> ijohnson, mvo: the actual problem with the server connection timeout is caused by snapd snap injection, not sure exactly why, but it's local, so sorry for the noise
<zyga> pstolowski: re
<zyga> pstolowski: that's a known issue, I can explain but I think it is neither new nor a problem for this test
<zyga> pstolowski: today it is late so I won't dig deeper
<zyga> I will focus on bug triage and a small thing I was working on earlier
<zyga> let's attack this tomorrow morning
<pstolowski> zyga: yeah i think i'll stop here as well
<zyga> https://github.com/snapcore/snapd/pull/9174 is making progress, though 16.04-64 is still in progress
<mup> PR #9174: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>
<mup> PR snapd#9175 opened: tests: find -ignore_readdir_race when scanning cgroups <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9175>
<mup> PR snapcraft#3253 opened: extensions: prepend the snapd glvnd path <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/3253>
<zyga> Saviq: o/ I noticed your question yesterday but I was off
<zyga> Saviq: can you grab me tomorrow - we can discuss that then
<zyga> ijohnson: commented and asked a question on https://bugs.launchpad.net/snapd/+bug/1889092
<mup> Bug #1889092: getent does not support extrausers on uc18 <snapd:Confirmed> <https://launchpad.net/bugs/1889092>
<ijohnson> zyga: interesting point, perhaps getent works fine with uc20 or even uc22
<ijohnson> zyga: also your lxd test PR failed again same problem
<zyga> https://github.com/snapcore/snapd/pull/9174#issuecomment-675586745
<mup> PR #9174: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>
<zyga> no
<zyga> not the same problem
<zyga> mvo: we may need to revert pawel's generator
<zyga> mvo: now that we test it better
<zyga> it doesn't work on 16.04
<zyga> it was just never tested correctly
<ijohnson> zyga: sorry how do you know that it is the generator?
<zyga> the generator never ran
<zyga> or ran and did nothing
<ijohnson> zyga: your PR tests failed with the same configure hook problem
<zyga> this test passed when we were testing against a different, more recent container (by accident)
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/9174/checks?check_run_id=998982860 shows a different error
<mup> PR #9174: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9174>
<ijohnson> Run configure hook of "lxd" snap (snap "lxd" has no "configure" hook)
<zyga> I see this failure:
<zyga> 2020-08-18T15:30:31.5864620Z Sanity check that mount overrides were generated inside the container
<zyga> 2020-08-18T15:30:31.5864910Z + MATCH '/var/run/systemd/generator/snap-core-.*mount.d/container.conf'
<zyga> 2020-08-18T15:30:31.5865202Z + lxd.lxc exec my-ubuntu -- find /var/run/systemd/generator/ -name container.conf
<zyga> 2020-08-18T15:30:31.5865318Z grep error: pattern not found, got:
<zyga> which suggests that what I wrote above is likely
<ijohnson> zyga: ok so 16.04 failed but 20.04 failed same way with the configure hook
<ijohnson> zyga: I was only looking at the 20.04 failure
<zyga> I see
<zyga> well
<zyga> 20.04 is broken because the image is broken :)
<ijohnson> hey bionic is working well then
<zyga> we are now testing image matching the host
<ijohnson> with pawel's generator
<zyga> so it's totally expected that focal is broken
<zyga> that's the issue pawel was looking into just a moment ago
<zyga> and that's what we immediately saw
<zyga> the PR doesn't change that, it just makes host match the container
<ijohnson> right ok so this makes sense then
<zyga> yeah
<zyga> I think we need to fix more than one issue here
<zyga> and if this is something we badly need for 2.46 we need to delay
<ijohnson> so focal is totally broken because broken images, and xenial is broken because the generator didn't run
<zyga> ijohnson: if focal is preseeded then yes
<zyga> if it's not pre-seeded then I thing something else is at play
<zyga> mvo: ^ please ack if this is a release blocker
<zyga> I'll copy this log to pawel
<zyga> so that he knows about it
 * cachio lunch
 * zyga EODs
<mup> PR snapd#9176 opened: cmd/snap: use â¬ instead of â where applicable <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9176>
<mup> PR snapcraft#3253 closed: extensions: prepend the snapd glvnd path <Created by Saviq> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3253>
<mvo> zyga: hey, I was just looking at the scrollback
<zyga> mvo: mmm
<mvo> zyga: so the generator needs reverting?
<zyga> mvo: it might
<zyga> mvo: I have a hunch it doesn't work on 16.04
<mvo> zyga: oh, ok
<zyga> mvo: the test was flaky, it never ran on a 16.04 container
<zyga> mvo: we should discuss with pawel when he reads this tomorrow
<zyga> mvo: I just wanted to let you know
<zyga> mvo: as this seems to be relevant to 2.46
<mvo> zyga: totally
<mvo> zyga: let's tackle this in the morning when pawerl and you and me are around
<zyga> indeed
<mvo> zyga: thanks for the heads up
<zyga> :)
<mup> PR snapcraft#3219 closed: meta: detailed warnings for resolution of commands <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3219>
<dariball> hey hey, I am building a ubuntucore image with some snaps targetting raspi4, is there some best practice to test the image in some virtualisation/emulation ? qemu seems not to be trivial. the ubuntucore docs propose `multipass` but I assume this is then x86 only as long as I do not run it on a raspi, right ?
<zyga-mbp> ijohnson|lunch https://listed.zygoon.pl/17533/measuring-coverage-of-shell-scripts
<zyga-mbp> dariball for raspi4 you pretty much need a raspi4
<ijohnson> zyga-mbp: nice! :-)
<ijohnson> I'm really curious now how much of our shell scripts actually get run :-)
<zyga-mbp> ijohnson so was I :)
<zyga-mbp> although I have a second agenda here, that's a bit more annoying to accomplish
<zyga-mbp> I want to write unit tests for makefiles
<zyga-mbp> but the way make executes stuff makes that hard
<zyga-mbp> this was a step towards that
<zyga-mbp> ijohnson an aggregate mode would be nice
<ijohnson> you mean a unit test for a makefile itself ?
<zyga-mbp> something like bashcov --cumulative ...
<zyga-mbp> yes
<zyga-mbp> I wrote a build system a while ago
<ijohnson> interesting what's the use case for it?
<zyga-mbp> and I really want to get to 100% coverage and documentation
<zyga-mbp> https://github.com/zyga/zmk/
<zyga-mbp> documentation is still sparse
<zyga-mbp> but testing is pretty solid
<dariball> zyga-mbp: means using a raspi4 with a regular ubuntu where I then run multipass, right ?
<zyga-mbp> I know some things are not tested as I didn't write any tests yet (for certain modules)
<zyga-mbp> but for those that are, I want to see if anything is missing
<zyga-mbp> dariball no, I mean you need to run it on real metal
<zyga-mbp> the best way forward is to automate deployment
<zyga-mbp> we're doing that for tests of snapd and ubuntu core itself
<zyga-mbp> but it's not something that's easy or fun
<zyga-mbp> dariball CPU architecture is just one aspect of the problem
<zyga-mbp> you really need an emulated "raspberry pi" virtualized but nobody made one that's not broken
<zyga-mbp> so deployment on the real thing is really the only viable option
<zyga-mbp> there are hardware add-ons that allow you to deploy to a SD card and boot a PI with that card
<dariball> yeah this was my impression until now ... tried some qemu stuff, but thanks for confirming my impression
<zyga-mbp> some companies manufacture them
<zyga-mbp> some people make more or less successful implementations of that idea
<zyga-mbp> IIRC canonical even has the most successful as a test engineer now :)
<zyga-mbp> but anyway, it's not something I can recommend
<zyga-mbp> unless you have a budget to spend
<zyga-mbp> ijohnson as for testing
<zyga-mbp> ijohnson I wrote unit tests in make
<zyga-mbp> for make
<zyga-mbp> ijohnson for example, how to compile a library written in C++
<zyga-mbp> https://github.com/zyga/zmk/blob/master/examples/libhello-cpp/Test.mk
<zyga-mbp> but there's some complexity involved in making sure all combinations are covered
<ijohnson> interesting I remember you mentioning zmk before
<zyga-mbp> it's slowly growing
<zyga-mbp> I paused all development while I was ill as working was hard as-is
<zyga-mbp> anyway :)
<zyga-mbp> i think bashcov is more interesting for us
<zyga-mbp> ijohnson (although to be fair, that was a smoke test for an example, unit tests are more complex as they try to cover all the features, some being optional)
<ijohnson> yeah bashcov seems very interesting in combination with our spread-shellcheck
<zyga-mbp> for spread task.yaml's the problem will also be the fact that it just streams a bunch of text and not let us trace much
<zyga-mbp> but we could find ways around that
<zyga-mbp> we could patch spread to generate something that mimics the tests tree
<zyga-mbp> and has actual scripts for everything
<zyga-mbp> that source each other or what not
<zyga-mbp> then bashcov could trace the whole execution
<zyga-mbp> please read my post, play with the code, the idea came to me yesterday
<zyga-mbp> and I implemented a working copy half an hour ago
<zyga-mbp> I'm sure there's room for improvement
<zyga-mbp> (bashcov handles ". foo.sh" sourcing today)
<zyga-mbp> time to slack now
 * zyga-mbp goes away
<mup> PR snapd#9177 opened: tests: remove support for ubuntu 19.10 from spread tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9177>
<mup> PR snapd#9178 opened: secboot: document exported functions <Simple ð> <Skip spread> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9178>
<mup> PR snapcraft#3254 opened: tests: restrict colcon / ros2-foxy test to amd64 & arm64 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3254>
#snappy 2020-08-19
<zyga> good morning
<zyga> today was way more efficient
<zyga> not even 9 and Lucy is 100% taken care of :)
<zyga> and I had an hour-long morning walk to exercise
<zyga> mvo o/
<mvo> good morning zyga
<pstolowski> morning
<zyga> pstolowski please check the message I sent on tg last evening
<zyga> mvo https://listed.zygoon.pl/17533/measuring-execution-coverage-of-shell-scripts
<pstolowski> zyga: looking
<zyga> pstolowski I think the first thing to establish is if the generator really works on 16.04
<zyga> if it does not we need to focus on that problem firsst
<zyga> if it does, we just need to understand what's broken in the test (on 16.04) and fix the image (on 20.04)
<pstolowski> zyga: got it, thanks for the clues, i'm investigating
<zyga> super, thank you!
<mvo> good morning pstolowski
<mvo> zyga: I guess I still need to merge 9174, right?
<zyga> yes
<zyga> and we need to deal with the fallout
<mup> PR snapd#9174 closed: tests: fix lxd test wrongly tracking 'latest' <Test Robustness> <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9174>
<mup> PR snapd#9178 closed: secboot: document exported functions <Simple ð> <Skip spread> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9178>
<mvo> hm, arch is also broken in the interfaces-udisks2 test it seems
<zyga> I noticed last night
<zyga> maybe an interface changed upstream
<zyga> I wrote so many udisks2 tests in this company :P
<mup> PR snapd#9177 closed: tests: remove support for ubuntu 19.10 from spread tests <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9177>
<mvo> zyga: we can probably disable it on arch for now, it's mostly relevant for  core anyway
<zyga> arch is the harbinger of doom on remaining systems
<mvo> zyga, pstolowski fwiw, systemd 229 (xenial) should support system generators, it ships systemd-fstab-generator so the functionality itself should be there
<zyga> that's reassuring, so the question is - why is the test failing to observe the generator data
<zyga> maybe it doesn't support something else, like /run/systemd/container?
<mvo> zyga: yeah, a good question
<pstolowski> mvo: also Dmitri was saying they way it's implemented would work all the way back to xenial
<mvo> zyga, pstolowski fwiw, inside my lxc xenial I see /run/systemd/container - but maybe it's racy or something?
<zyga> interesting, maybe
<mvo> also we should check if we have the snap.mount in lxd, this is what the old generator was generating
<zyga> I did see that one
<mvo> and when I run it manually inside lxd it work, puzzling
<zyga> which is even more puzzling
<zyga> like half of it ran
<zyga> but that was in the 20.04 container so that was a bit optimistic
<zyga> I didn't re-check 16.04
<jamesh> Looks like the Go latest/edge snap is broken based on CI results
<zyga> mvo, pstolowski: if that's okay, I'll focus on features for now, if you need me please just say so
<zyga> jamesh oh, I think mwhudson may want to know
<zyga> hi :)
<jamesh> mwhudson: ^^^ I get a failure when it tries to copy a file to /snap/go/6312/pkg/linux_amd64/runtime.a -- maybe the library is missing from the snap or out of date?
<pstolowski> mvo, zyga yeah i just concluded the same. manual run creates dropins. but daemon-reload only creates snap.mount ð§
<pstolowski> ah wait silly me
<pstolowski> scratch that; yes daemon-reload doesn't have the effect, weird
<zyga> pstolowski maybe time to dig into systemd source
<mvo> pstolowski: I am making some progress, fails with exit code 2
<mvo> pstolowski: if I put systemd into debug mode inside lxc and call daemon-reload
<pstolowski> mvo: right i see exit 2 in journalctl
<mvo> pstolowski: I bet PATH is unset
<mvo> pstolowski: we have a null check for that
<mvo> pstolowski: there you go
<pstolowski> mvo: ha, that's great finding
<pstolowski> mvo: i'll test a quickfix by hardcoding things
<zyga> so PATH is unset?
<zyga> that's, interesting
<mvo> pstolowski: yeah, http://paste.ubuntu.com/p/mphVQNCqKK/ fixed it for me
<zyga> mvo so another place to bake path ;-) ?
<mvo> pstolowski: in my quick test, I have a meeting now so can't work on this, thanks for taking over \o/
<zyga> I wonder if this was fixed in future systemd
<mvo> zyga: yeah, fun
<mvo> zyga: it is evidently
<mvo> zyga: or it would fail in the same way
<zyga> what's the path we get there?
<mvo> pstolowski: I had this suspicion during the review that the environment maybe totally blank but then did not mention it. oh well :/
<mvo> zyga: no idea
<mvo> zyga: I remembering looking at this a while ago but it's even hard to see debug prints when generators run :(
<zyga> mvo open(/tmp/foo) and redirect stderr there
<zyga> to be clear, I'm mainly asking about the path drive this problem to a clear solution
<zyga> and not bake a slightly wrong path by accident
<zyga> I'd love to double check both the value of PATH and the method systemd computes it
<pstolowski> so yes hardcoding a path there makes it happy
<mvo> \o/
<pstolowski> mvo, zyga: what do you think about a fallback with a predefined path
<mvo> pstolowski: I don't think we have an alternative :)
<zyga> I think it's unavoidable, I just want to use a correct value
<mvo> zyga: which one of the correct values ;P
<zyga> brb, let me fetch something to drink
<zyga> it's finally not so hot today but I just had a small sip in the morning
<pstolowski> zyga: this is only for 16.04, we don't have preseeding for non-ubuntu
<pstolowski> and therefore we don't need dropins elsewhere
<zyga> pstolowski you say that but it's only a bit of code that will not be looked at in 6 months when something changes, let's just spend the extra 30 minutes to understand how PATH is provided in 18.04+ and what the value is
<pstolowski> zyga: it's not strictly about PATH but where snapfuse is installed, that's not going to change in 16.04
<zyga> my point is that we should not make this about 16.04
<zyga> we either need path and we need to provide it somehow (and maybe only conditionally for old systemd)
<zyga> or we don't need path and we bake something else in
<pstolowski> of course man pages doesn't say anything about env and path
<mvo> zyga, pstolowski meeting is over - I think we should simply use a sanitized versoin of /etc/environment PATH in the generator
<mvo> zyga, pstolowski i.e.
<mvo> PATH="/usr/sbin:/usr/bin:/sbin:/bin"
<mvo> do you see any downside?
<pstolowski> mvo: do you mean hardcoded? or do you think we should parse /etc/environment?
<mvo> pstolowski: hardcoded
<mvo> pstolowski: not more parsing code
<zyga> I think hardcoded is ok if PATH is NULL
<pstolowski> mvo: that's what i'm running right now
<pstolowski> yes that's what i hae
<pstolowski> *have
<mvo> pstolowski: also the PATH in /etc/environment is silly - it include /usr/local and /games and stuff which I think we don't want
<mvo> pstolowski: \o/
<pstolowski> +1
<zyga> (although the exact string should be picked up from systemd most likely)
<mvo> zyga: from systemd?
<zyga> even if we copy-paste the string, yeah
<mvo> zyga: from the systemd source you mean?
<zyga> yes
<mvo> zyga: which version of systemd? with unified /usr/bin,/bin or without? not sure about the advantage over /etc/environment which is the "canonical" thing for ubuntu
<pstolowski> i looked at systemd, starting from manager_run_generator and didn't see any explicit paths
<mvo>  systemd uses a fixed value of
<mvo>            "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
<mvo> that's what the manpage for systemd.exec tells me
<mvo> When compiled for systems with "unmerged /usr" (/bin is
<mvo>            not a symlink to /usr/bin), ":/sbin:/bin" is appended.
<pstolowski> ah, i didn't look into that man page :/
<pstolowski> joys of a dozen of manpages
<mvo>                 m->transient_environment = strv_new("PATH=" DEFAULT_PATH);
<mvo> pstolowski: no worries, it's really hidden
<pstolowski> ty!
<mvo> and https://github.com/systemd/systemd/blob/master/src/basic/path-util.h#L13
<mvo> so we could include "local" given that systemd is also doing this
<mvo> zyga, pstolowski thanks, I think that's indeed the best option, stick to what systemd is using with unmerged-usr
<mvo> (and we should document it in the code why we picked the particular values)
<pstolowski> yes doing
<mvo> thank you!
<pstolowski> amazing how many things can go wrong. starting with lxd test issue the hid the problem
<mvo> indeed
<mvo> the joy of complexity!
<zyga> mvo we should move off latest go
<zyga> go test runtime: copying /home/runner/.cache/go-build/63/633155d8056ad255f77968645705b93d20bb3173db582e095c1d93bb6cdab259-d: open /snap/go/6312/pkg/linux_amd64/runtime.a: read-only file system
<mup> PR snapd#9179 opened: cmd/snapd-generator: use PATH fallback if PATH is not set <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9179>
<mvo> zyga: oh, where do you see this?
<mvo> fwiw, I'm debugging the udisks2 arch failure right now
<zyga> mvo our unit test action
<zyga> https://github.com/snapcore/snapd/pull/9175/checks?check_run_id=1001916625
<mup> PR #9175: tests: find -ignore_readdir_race when scanning cgroups <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9175>
<mvo> zyga: ok
<mvo> zyga: we can temporarly disable, I can look once I resolved udisks2
<pstolowski> just saw "go test runtime: ... open /snap/go/6312/pkg/linux_amd64/runtime.a: read-only file system" on my PR
<jamesh> pstolowski: the edge channel of the Go snap seems to be broken, yeah
<mwhudson> jamesh: hmm haven't looked at the go-tip snap for a long time
<mwhudson> jamesh: can you tell when it broke?
<mwhudson> til snap refresh --edge does not change tracks
<jamesh> mwhudson: it looks like it was working 10 hours ago when edge was version devel-77a11c0.  It's broken now on devel-84a6245
<mwhudson> oh ok
<mwhudson> that at least narrows things down :)
<jamesh> mwhudson: this is based on browsing through snapd's CI logs
<mwhudson> hmm very very light testing has it still working
<jamesh> mwhudson: This is an example failed run: https://github.com/snapcore/snapd/pull/9168/checks?check_run_id=1001544453
<mup> PR #9168: o/hookstate/ctlcmd: make is-connected check whether the plug or slot exists <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9168>
<jamesh> it looks like it's trying to copy a compiled version of the runtime.a package to $GOROOT, and tripping up on the read only file system error
<mwhudson> hmm
<jamesh> (since $GOROOT is obviously a squashfs)
<mwhudson> $ go_edge list -f '{{ .Stale }}' runtime
<mwhudson> true
<mwhudson> seems bad
<jamesh> clearly that would fail with EACCESS as a normal user.  But the CI is running as root, so gets EROFS instead
<jamesh> my mistake: this wouldn't be running as root.  It's still getting EROFS though
<mwhudson> stalereason is "not installed but available in build cache"
<mwhudson> which doesn't make a lot of sense
<mwhudson> will have to look tomorrow
<mup> PR snapd#9180 opened: github: use latest/stable go, not latest/edge <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/9180>
<mvo> the arch thing is strange, I can manually mount it but mounting via udevctl (without a snap in between even) fails. so udisks is wonky there it seems
<zyga> mvo ^ this seems to be working
<zyga> mvo shall I look?
<zyga> pstolowski and ideas on the 20.04 image?
<mup> PR snapd#9181 opened: tests: disable udisks2 test on arch linux <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9181>
<mvo> zyga: look at what?
<zyga> arch
<mvo> zyga: I think it's fine, I pushed a PR
<zyga> great
<zyga> ah, I see it
<zyga> just above
<mvo> zyga: hm, latest/stable is 14.07 but there is a 1.15 too
<mvo> zyga: oh well,
<zyga> mvo how many things shall we debug today? :)
<zyga> I would stick to something that works for a few days and let mwhudson look
<mup> PR snapd#9180 closed: github: use latest/stable go, not latest/edge <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9180>
<zyga> mvo you need to force merge https://github.com/snapcore/snapd/pull/9181#pullrequestreview-470319752
<mup> PR #9181: tests: disable udisks2 test on arch linux <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9181>
<mvo> zyga: yeah
<mvo> pstolowski: one comment in 9179
<mup> PR snapd#9181 closed: tests: disable udisks2 test on arch linux <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9181>
<mup> PR snapd#9182 opened: tests: re-enable udisks test on debian-sid <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9182>
<zyga> pstolowski one more comment from me
<pstolowski> ty
<pstolowski> zyga: re 20.04 i can't reproduce, i don't remember what i did yesterday..
<zyga> pstolowski boot 16.04 and use a 20.04 container
<zyga> or boot 20.04 and boot a 20.04 container
<zyga> inside the container check if snapd seeded and has correctly installed snaps
<zyga> and if any snap is broken
<pstolowski> so yeah 20.04 + 20.04 works
<mvo> I booted a qemu with the failure but I have a meeting now
<pstolowski> 16.04 + 20.04 container also worked
<zyga> pstolowski when it works
<zyga> can you look at the hash of the rootfs squash
<zyga> maybe it just got fixed there
<zyga> the one we saw fail was ....
<pstolowski> where is it stored?
<zyga> look at /var/snap/lxd
<zyga> it's the big file there
<zyga-x240> pstolowski: 97c470e427c425cf2ec4d7d55b6f1397ea55043c518b194a58fc6b9da426f540.rootfs
<zyga> I'm going to grab some coffee and think about a problem
<zyga> pstolowski feel free to telegram/facetime me if you want to talk
<zyga> mvo  same ^
<pstolowski> zyga: https://paste.ubuntu.com/p/ZQgyZ9tkjd/
<pstolowski> i have that + some newer
<pstolowski> hmm but 97c470e427c4 is being used (i think)
 * mvo is in a meeting
<zyga> re
<zyga> pstolowski is 9* rootfs something that was pre-seeded?
<zyga> I spent a while thinking about possible ways to handle ~/snap and I have some experiments to run
<zyga> but first lunch, then standup, then experiments and then PT
<pstolowski> zyga: no, not preseeded
<pstolowski> seeded the old way
<zyga> ok, so it should seed normally
<zyga> and with your generator fix
<zyga> does it work?
<pstolowski> it doesn't have any of my generator changes, that's unrelated. but  i tested my generator fix on 16.04
<zyga> but does it seed normally or are snaps broken
<zyga> if it works that's good
<pstolowski> i can't repro anymore for some reason. i don't remember if it seeded fine or not, but all snaps were broken. i'd like to understand what's different today or what am i missing (and why you can reproduce)
<mvo> I have a meeting in 2min but I'm inside the nested lxd container and it looks like /snap is not mounted at all
<mvo> no mount units generated but "snap changes" tells me that the seeidng was successful
<zyga> mvo hmmmmm
<zyga> perhaps nesting is the key
<zyga> pstolowski there were two containers in the lxd test, the one that had more problems was indeed the nesting one
<mup> PR snapd#9176 closed: cmd/snap: use â¬ instead of â where applicable <â Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/9176>
<pstolowski> zyga: ok, reproduced with lxd test in my-nesting-ubuntu
<zyga> that's great
<zyga> I wonder why nesting matters
<zyga> I guess we'll learn ;)
<zyga> mvo, pstolowski: I guess we should force-merge https://github.com/snapcore/snapd/pull/9179
<mup> PR #9179: cmd/snapd-generator: use PATH fallback if PATH is not set <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9179>
<zyga> to reduce the number of failures and have a clear picture of what's what as we iterate
<pstolowski> +1
<mvo> zyga in a meeting
<zyga> k
<mvo> zyga meeting overruns
<zyga> k
<mvo> zyga I will be slightly late
<zyga> should we wait or start
<pstolowski> zyga: i wonder where is this coming from in this failing container https://pastebin.ubuntu.com/p/vGBtq6YCGc/
<zyga-x240> pstolowski: quick idea, change snapd to log anything we log in any case via tasks to systemd
<zyga-x240> we'd get time-correlated logs
<zyga-x240> and that would be a very welcome change in general
<mup> PR snapd#9179 closed: cmd/snapd-generator: use PATH fallback if PATH is not set <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9179>
<zyga-x240> thanks for merging that
<pstolowski> zyga-x240: that's an interesting idea
<pstolowski> zyga-x240: one other observation in the meantime
<zyga-x240> yeah?
<pstolowski> zyga-x240: this unmounting of snaps appears 2 seconds after 12:44:13 my-nesting-ubuntu systemd[1]: snapd.seeded.service: Succeeded.
<pstolowski> zyga-x240: and after snapd restart
<zyga-x240> why does snapd restart?
<zyga-x240> for the seeding?
<zyga-x240> I mean snapd + core18 model?
<pstolowski> yes i think so
<pstolowski> 2020-08-19T12:43:20Z INFO Requested daemon restart (snapd snap).
<pstolowski> 2020-08-19T12:43:20Z INFO Waiting for automatic snapd restart...
<pstolowski> that's from our change 1 log
<zyga-x240> can you check if systemd knows about the mount units?
<zyga-x240> systemctl status snap-snapd-1234.mount
<pstolowski> zyga-x240: it doesn't
<zyga-x240> pstolowski: and journald, it should remember
<pstolowski> zyga-x240: indeed, but nothing interesting, mounts followed by unmount
<zyga-x240> pstolowski: so the key question is why did systemd stop it
<zyga-x240> pstolowski: can you paste the log?
<zyga-x240> (everything in the nested container)
<pstolowski> sure
<pstolowski> zyga-x240: https://paste.ubuntu.com/p/9jgxNM5ZDz/
<zyga> pstolowski note that the log doesn't say anything about the mount units being stopped
<zyga> I suspect it's not that
<zyga> can you do a test please
<zyga> craft a quick unit for whatever snap
<zyga> start it with systemd
<zyga> check the log to see what it says
<zyga> then unmount that by hand
<zyga> then check the unit status
<pstolowski> zyga: these umounts appear right after  "Stopped Snap Daemon.", isn't that weird?
<mvo> pstolowski, zyga it looks like prep-snapd-in-lxd.sh fails in "apt autoremove --purge -y snapd" because it cannot unmount /snap directory
<zyga> ohh, wait a second
<mvo> (or are you guys at this point already?)
<zyga> no!
<pstolowski> nope
<mvo> *but* that does not make the test fail, the following "apt update" is run
<zyga> heh
<mvo> which is super strange
<mvo> *gar*
<mvo> because we do "lxc exec -- bash /root/prep...
<mvo> but theere is a "#!/bin/sh -e" in the script but no set -e
<mvo> *fail*
<zyga> ah
<zyga> nice
<mvo> so that's the first thing we need to fix
<pstolowski> oh
<mvo> so that it at least fails at the right point :)
<mvo> I push a fix for this in 2min
<ijohnson> sorry folks that's my fault
<zyga> mvo I guess the bash -e is not needed
<zyga> just invoke it
 * ijohnson is bad at lxding
<zyga> mvo and the error is repeated below
<zyga> for the inner case
<pstolowski> hmm isn't it messing up with seeding when it removes snapd deb initially?
<zyga> I think that's an existing issue
<zyga> there's an open PR
<zyga> we should look at it and maybe land it
<zyga> there was some discussion so it never moved
<mup> PR snapd#9183 opened: tests: use "set -ex" in prep-snapd-in-lxd.sh <Created by mvo5> <https://github.com/snapcore/snapd/pull/9183>
 * pstolowski short lunch break
<zyga> mvo commented
<zyga> I can push a patch if you want and agree with my suggestion
<mvo> zyga: I wonder if it is using bash because 755 mode is not transfered on "lxc file push" or something, but I'm too lazy to test. if it works +1
<zyga> yes
<zyga> it's that
<zyga> ;D
<zyga> mvo yeah, I'll get it to work and push
<ijohnson> now that you mention it, yes I think that's why I did that
<ijohnson> because the mode was lost when pushing it
<mvo> zyga: let's not overcomplicate it, if we need a bunch of chmods I think it's fine
<zyga> yeah, and lxd file push mode is broken (or was last time)
<zyga> yeah
<mvo> zyga: but I have no strong opinions, just a bit tired that it's red :)
<zyga> so it's like a rock
<zyga> you turn it over
<zyga> and there's a new rock attached to it
<zyga> and it's another problem
<mvo> heh
<zyga> and we turn it over and, guess what,
<zyga> it's a rock
<mvo> haha
<mvo> I really want to also get to the bottom of what is actually broken before my next meeting :(
<pstolowski> lol
<zyga> it's a quarry
<zyga> wife back, afk
<mup> PR snapd#9182 closed: tests: re-enable udisks test on debian-sid <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9182>
<mvo> zyga, pstolowski /snap is mounted inside lxd - does http://paste.ubuntu.com/p/h95HbBjKqk/   make sense?
<cmatsuoka> ijohnson: are the existing disk cross-checks enough to validate that name-enc comes from the right disk, and name, if encrypted, comes from name-enc (and therefore from the right disk)?
<ijohnson> cmatsuoka: with my PR, we do the following things: https://www.irccloud.com/pastebin/B549qart/
<zyga> looking
<zyga> mvo yes it makes sense
<zyga> mvo containers don't use MS_SHARED /
<zyga> (for whatever reason)
<cmatsuoka> ijohnson: so the answer seems to be yes. I'm asking because you left a TODO comment about doing these checks in secboot_tpm
<zyga> the systemd generator we have used to emit a mount unit to do just that
<zyga> make /snap -> /snap bind mount
<zyga> and then change sharing
<zyga> all to allow snaps to mount into derivative mount namespaces via mount event propagation
<ijohnson> cmatsuoka: I left a TODO about doing these checks in secboot_tpm ? it's probably left over with my PR that should implement all the cross-checking we want
<zyga> otherwise things appear to work until you refresh and then the view in the container disagrees with the view in the per-snap mount namespace
<mvo> zyga ok, so we need an extra umount in purge?
 * mvo tries that
<zyga> I think it's more complex than that
<zyga> we had issues with this
<zyga> and I think we have something in purge but it may not work
<zyga> or we may not have, I honestly don't recall
<zyga> I would say we want systemctl stop snap.mount
<zyga> not an unmount
<pstolowski> re
<zyga> and only if this is a container
<cmatsuoka> ijohnson: why are the checks in the paste just for run mode? aren't we cross-checking in recover mode as well?
<ijohnson> cmatsuoka: all those checks are for run and recover mode (or should be at least), but for run mode, we use ubuntu-boot as our reference mountpoint/partition, where as for recover mode we use ubuntu-seed as our reference mountpoint/partition - that should be the only difference
<zyga> mvo: I pushed to https://github.com/snapcore/snapd/pull/9183/files
<mup> PR #9183: tests: use "set -ex" in prep-snapd-in-lxd.sh <Created by mvo5> <https://github.com/snapcore/snapd/pull/9183>
<cmatsuoka> ijohnson: ah right, thanks
<zyga> afk again
<mvo> zyga and that works, i.e. mode is preserved?
<mup> PR snapd#9184 opened: [RFC] packaging: umount /snap on purge for good measure <Created by mvo5> <https://github.com/snapcore/snapd/pull/9184>
<jdstrand> mvo: hey, fyi PR 8301 has two approvals but fails the 4 lxd tests (unrelated failure). PR 8920 also has the same failures and has all comments addressed. these are both ones we discussed for 2.46. by my eod, I will have my misc updates PR done (ie, easy reviews). Depending on the speed in which I do that, I may have a separate very small, policy updates only PR for k8s-support (for microk8s strict on
<mup> PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301>
<mup> PR #8920: interfaces: update cups-control and add cups for providing snaps <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>
<jdstrand> focal). I know what is needed, but I want to document why and that might take a moment (but it will only be like 3 rules, so fast to review)
<mvo> jdstrand: we are debugging/fixing this lxd things as we speak
<jdstrand> mvo: ack, let me know if you want me to merge master
<mvo> jdstrand: not quite there yet, also I have a super busy afternoon with meetings so there maybe little progress, but maybe my team will pickup 9184 (if it's green)
<jdstrand> mvo: have you decided if you are going to pull master back to 2.46? (you mentioned you may not; if you do, hopefully 8301 and 8920 will be applied and I won't need to do separate PRs for 2.46 (though, if that is what you want, that is of course fine)
<ijohnson> cmatsuoka: thanks, for the comment, I see the TODO and just pushed a commit to remove it
<pstolowski> ijohnson: since you worked on this area of main/lxd test -
<ijohnson> pstolowski: s/worked/broke/ but yes
<pstolowski> haha
<cmatsuoka> ijohnson: thanks, I'm building an image from this branch to run a minimal test before +1'ing it
<pstolowski> ijohnson: why do we push snapd deb into the nested container to test that snapd isn't working if there is snapd already there?
<ijohnson> pstolowski: that is to ensure that we don't regress and actually start working in that nested container, because if that started working it would very very very likely be a confinement bug somewhere in the stack
<ijohnson> pstolowski: or it would mean that snapd stopped doing all the checks that it should be doing
<pstolowski> ijohnson: ah ok, so we want to test the current snapd code for this, makes sense
<pstolowski> thx
<ijohnson> yes
<mvo> jdstrand: pretty sure I will (90%) just merge master into 2.46 at this point, so many fixes went into that
 * cachio lunch
<pstolowski> i've been trying to improve prep-snapd-in-lxd.sh in the lxd test but no luck so far and i'll soon stop for today, need to take my daughter for the training
<ijohnson> pstolowski: where did you get ?
<ijohnson> pstolowski: I am happy to take another look at improving it, I have some modifications I made locally yesterday that probably help quite a bit and may overlap with your work that I could propose
<pstolowski> ijohnson: i don't have anything tangible to share, i tried to stop snapd service before apt-get remove.., now also trying apt-get remove without --purge
<ijohnson> pstolowski: ack I will propose something on top of what 9183 already does then
<pstolowski> ijohnson: mvo is also experimenting in 9184, but i haven't tried that
<ijohnson> cachio: why is BUILD_SNAPD_FROM_CURRENT false for tests/nested/manual ?
<ijohnson> it seems to me that even though we use the HOST: ... trick for that env var for the manual suite it doesn't take effect when we run nested spread tests as part of a PR with that label
<ijohnson> cachio: see https://github.com/snapcore/snapd/pull/9102/files#r473185796 for example, that duplicate system key makes the test fail for me now on master, but it somehow passed on that PR
<mup> PR #9102: corecfg: add "system.timezone" setting to the system settings <Run nested> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9102>
<mup> PR snapcraft#3254 closed: tests: restrict colcon / ros2-foxy test to amd64 & arm64 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3254>
<cachio> ijohnson|lunch, it is because SPREAD_BUILD_SNAPD_FROM_CURRENT=true is defined for the github actions workflow
<ijohnson|lunch> cachio: yeah I wonder if that is working though
<cachio> I'll update that value in the PR to make sure we allways use it
<ijohnson|lunch> cachio: have you seen other issues like this before ?
<cachio> ijohnson|lunch, I'll update PR 9098 with this
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<cachio> thanks for the heads up
<ijohnson|lunch> where the nested spread test passes on the PR but then immediately after merging fails ?
<cachio> ijohnson|lunch, just pushed the update
<mup> PR snapd#9185 opened: secboot: use the snapcore/secboot native recovery key type <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9185>
<mup> PR snapd#9186 opened: interfaces: add vcio interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9186>
<jdstrand> ogra_: hey, that is for you ^
<ogra_> whee !
 * ogra_ dances
 * cachio -> kinesiologist
<ijohnson> jdstrand: small comment on that vcio PR
<jdstrand> ijohnson: thanks, responded
<ijohnson> jdstrand: how did you check?
<ijohnson> I don't see that device in the device cgroup on my rpi running uc20 for a snap that uses an interface that puts it into the device cgroup
<jdstrand> ijohnson: I logged into an rpi UC device and /dev/vcio was present
<jdstrand> oh, the device cgroup, sorry, I was thinking of kmod
<jdstrand> ijohnson: you are right about udev
<ijohnson> jdstrand: don't we need `connectedPlugUDev: ...` rules to ensure that the device gets added to the device cgroup ?
 * jdstrand adjusts
<ijohnson> ah ok, I see
<jdstrand> ijohnson: ok, pushed
<ijohnson> ack
<ijohnson> jdstrand: one more comment on that PR, but otherwise lgtm
<ijohnson> cachio: hey I noticed the tests/nested/core/core-snap-refresh-on-core test fail on uc16
<ijohnson> cachio: the test is currently flaky and needs to be updated
<cachio> in my pr?
<cachio> because I already updated that
<ijohnson> cachio: oh sorry I just saw it fail on master
<ijohnson> cachio: which PR did you fix it in ?
<cachio> #9098
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<ijohnson> cachio: no you need to make more changes in addition to that PR
<ijohnson> cachio: the function refresh_to_new_core is coded wrong right now
<ijohnson> cachio: that function currently does this:
<ijohnson>             execute_remote "sudo snap refresh core --${NEW_CHANNEL}"
<ijohnson>             execute_remote "snap info core" | grep -E "^tracking: +latest/${NEW_CHANNEL}"
<ijohnson> cachio: it should wait for a reboot immediately after the `snap refresh` command, then get the info for the tracking channel after the reboot
<ijohnson> cachio: right now the test is racing with snapd, if snapd finishes quick enough then it won't respond to `snap info` and it will hang
<cachio> ijohnson, ah, I just saw that depending on the var it was trying to refresh to the same revision and failed
<ijohnson> cachio: here's an example failure log https://pastebin.ubuntu.com/p/Wbgq47BYRg/
<ijohnson> cachio: yes that's an independent issue
<cachio> ijohnson, ah, nice, I'll fix it in that case
<ijohnson> thanks!
<cachio> thanks for that
<ijohnson> cachio: I also saw google-nested:ubuntu-20.04-64:tests/nested/manual/refresh-revert-fundamentals:snapd fail in github actions
<ijohnson> cachio: but I don't see an obvious reason why that failed yet
<cachio> ijohnson, do you have a link?
<ijohnson> cachio: yes one moment
<ijohnson> cachio: https://pastebin.ubuntu.com/p/Yskh9yqNZH/
<cachio> thanks
<cachio> I'll insvestigate that one too
<jdstrand> ijohnson: nice! done
<ijohnson> cachio: if you could look at https://github.com/snapcore/snapd/pull/9187 that would be great
<mup> PR #9187: tests/lib/nested.sh: use more robust code for finding what loop dev we mounted <Run nested> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9187>
<cachio> sure
<ijohnson> jdstrand: thanks, +1d, we still need pedronis to review the iface name, he is back next week I think
 * jdstrand nods
<mup> PR snapd#9187 opened: tests/lib/nested.sh: use more robust code for finding what loop dev we mounted <Run nested> <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9187>
<cachio> ijohnson, seems to be ok the change
<cachio> lets see the results
<cachio> thanks!
<ijohnson> thanks cachio
<ijohnson> it passed for me once locally so ð¤
<cachio> nice
<mup> PR snapd#9188 opened: interfaces: misc policy updates xlvi <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9188>
<mup> PR snapcraft#3255 opened: remote-build: use requests.get() instead of urlopen() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3255>
#snappy 2020-08-20
<dstathis> n 20.04 many services (in particular kubelet) are packaged as snaps
<dstathis> Does anyone know how to correctly interact with services running as a snap? There doesn't seem to be a systemd unit
<dstathis> for example 'systemctl status kubelet' (or docker or whatever) fails with a not found error
<jamesh> dstathis: systemd units owned by snaps will have names like "snap.$snapname.$app.service".  You should see them in the "systemctl list-units" output.
<ish> I've installed a few Snaps on Fedora 32, and those with tray icons have garbled menus...  Anything obvious I'm missing?
<oerheks> For font issue, libpango can be a reason
<oerheks> or libfreetype
<mup> PR snapd#8301 closed: interfaces/many: deny arbitrary desktop files and misc from /usr/share <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8301>
<mup> PR snapd#9183 closed: tests: use "set -ex" in prep-snapd-in-lxd.sh <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9183>
<mborzecki> morning
<mvo> good morning mborzecki
<mborzecki> mvo: hey
<zyga> good morning
<zyga> I will be around shortly
<zyga> just need to send some paperwork for the insurance
<zyga> mvo if you can, please merge https://github.com/snapcore/snapd/pull/9175
<mup> PR #9175: tests: find -ignore_readdir_race when scanning cgroups <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/9175>
<mborzecki> zyga: hey
<zyga> hi
<mvo> zyga: looking
<zyga> just random test failure fix
<mvo> zyga: thanks, what did you change in the force push, unfortunately GH does not show me a diff for that :/
<zyga> mvo I moved the -ignore_readdir_race after the path
<zyga> originally it was the first argument but old find didn't like that
<zyga> compare https://github.com/snapcore/snapd/commit/cd5b94776066bbe76359e912c960c9d4258abc9c and https://github.com/snapcore/snapd/commit/8c10ddfc32cf8f909ba73bfcfe691f174917c2e4
<mvo> zyga: ta
<mup> PR snapd#9175 closed: tests: find -ignore_readdir_race when scanning cgroups <Simple ð> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9175>
<zyga> thank you
<zyga> uh, it's a meeting day
<zyga> just meetings and meetings
<pstolowski> morning!
<mborzecki> pstolowski: hey
<pstolowski> hey mborzecki, welcome back!
<mvo> good morning pstolowski
<mvo> fwiw, I'm working on the lxd test failures currently
<zyga> mvo thank you
<mvo> yw - it's very painful as each iteration takes forever
<mvo> but I hope I have a handle on it now (but I thought this the two previous runs too :(
<zyga> mvo 300+ MB download is not free
<pstolowski> mvo: thank you, i'm trying something as well on top of your existing PR but i'm not clear what root problem is and yes it is super slow
<mvo> pstolowski: http://paste.ubuntu.com/p/p6pFKnRxrb/ is my best attempt so far, test is running
 * mvo also wonders why wait_for_service seems to be not using the retr-tool
<jamesh> mvo: I noticed the desktop code review meeting isn't on my calendar for this week.  Did you cancel it, or is that a glitch?
<mvo> jamesh: I canceled it because we lack people but if you want to do it I can be available for you
<mvo> jamesh: you also should have goten a mail about this by the calendar :/
<jamesh> mvo: I don't see any email about the cancellation, which is why I asked.  That's fine.
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/9150 can land too
<mup> PR #9150: gadget,kernel: add new kernel.{Info,Asset} struct and helpers (1/N) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9150>
<mborzecki> mup: and https://github.com/snapcore/snapd/pull/9156
<mup> mborzecki: In-com-pre-hen-si-ble-ness.
<mborzecki> mvo: and https://github.com/snapcore/snapd/pull/9156
<mup> PR #9156: boot: copy boot assets cache to new root <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9156>
<jamesh> mvo: I think https://github.com/snapcore/snapd/pull/9168 is good to merge, but is failing on ubuntu-20.04-64 for some tests/main/lxd:snapd_cgroup_* tests
<mup> PR #9168: o/hookstate/ctlcmd: make is-connected check whether the plug or slot exists <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/9168>
<pstolowski> jamesh: yes these tests have been investigated since yesterday
<jamesh> pstolowski: is it best just to wait til they get fixed then?
<mvo> jamesh: if the failure is just on lxd I can force-merge
<mvo> jamesh: merged
<jamesh> mvo: cheers!
<mvo> mborzecki: landed 9150 now too
<mvo> mborzecki: and 9156
<mborzecki> mvo: thanks!
<mup> PR snapd#9150 closed: gadget,kernel: add new kernel.{Info,Asset} struct and helpers (1/N) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9150>
<mup> PR snapd#9156 closed: boot: copy boot assets cache to new root <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9156>
<mup> PR snapd#9168 closed: o/hookstate/ctlcmd: make is-connected check whether the plug or slot exists <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9168>
<mvo> fwiw, 9184 passed locally now for me on 20.04, let's see if it survies a full spread run
 * mvo takes a short break while waiting for this
<zyga-x240> nice work
<pstolowski> \o/
<mvo> so looks like 20.04 is now working but 16.04 is still failing :( *oh well* but with a very different error
<zyga-x240> mvo: what does 16.04 say?
<mvo> zyga-x240: "Failed to execute operation: Connection timed out"
<mvo> zyga-x240: in a meeting right now, I can paste the full error late but it's also in the CI i think
<zyga-x240> hmmm
<zyga-x240> ijohnson: https://github.com/snapcore/snapd/pull/9187#discussion_r473820780
<mup> PR #9187: tests/lib/nested.sh: use more robust code for finding what loop dev we mounted <Run nested> <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9187>
<zyga-x240> hmmm
<mborzecki> zyga-x240: hmm trouble getting self-hosted runners? https://github.com/snapcore/snapd/runs/1006992307
<zyga-x240> hmm checking
<zyga-x240> the host is up
<zyga-x240> workers are up
<zyga-x240> I think I know what's going on
<zyga-x240> it seems that cla checks are hitting a time-out to grab a worker
<zyga-x240> I don't recall seeing that before, we have queueing for a reason after all
<zyga-x240> I restarted that and it passed instantly
<zyga-x240> so... no idea/
<mborzecki> hahah
<mborzecki> well, maybe it's a one off occurrence
<zyga-x240> I hope so but I fear we will learn in time
<zyga-x240> time for coffee, I'm falling asleep here
<zyga-x240> maybe pressure is low or something
<zyga-x240> mvo: I looked and it looks like systemd is not responding, maybe the socket is gone somehow?
<zyga-x240> but no idea why
<mvo> zyga-x240: so the nested lxd shows me a gazillion "permission denied", e.g. /bin/mount for / exited 1, mount: permission denied etc
<mvo> on 16.04
<zyga-x240> mvo: seems like lxd apparmor
<zyga-x240> mount is really disallowed
<zyga-x240> only bind may be allowed
<mvo> yeah, strange that it's inside the nested though
<zyga-x240> maybe nesting is broken somehow
<zyga-x240> I wonder if we can stop doing something and get nested working without snapd
<zyga-x240> and then see what part breaks it
<mborzecki> zyga-x240: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1889318 is it because when run by lxc there's no apparmor namespace setup like lxd does?
<mup> Bug #1889318: install chromium in lxc container for 20.04 fails <amd64> <apport-bug> <focal> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1889318>
<mvo> zyga-x240: it fails even before snpad it seems
<mvo> zyga-x240: hm, well, maybe or maybe not
<zyga-x240> mborzecki: looking
<zyga-x240> I ... don't know
<mvo> hm, "interessting" - it fails in systemctl daemon-reload but everyting else seems to work
<zyga-x240> well
<zyga-x240> when systemd is not responding
<zyga-x240> it's not really a place where things work
<mvo> the funny thing is - systemctl restart snapd works
<mvo> systemctl --list works
<mvo> afaict all the things I tried work
<zyga-x240> hmm
<mvo> just not the daemon-reload
<mvo> it's a bit strange
<zyga-x240> what does daemon-reload say?
<zyga-x240> I mean, there is journal
<mvo> and I think this is broken since forever
<mvo> we never saw it because that script did not have set -e
<zyga-x240> ohhhh
<zyga-x240> that's interesting
<zyga-x240> so it would fail on stable releases as well
<zyga-x240> mvo: do you have 5 minutes for a quick call?
<jdstrand> mvo: hi! thanks for committing PR 8301! have you decided to marge master into release/2.46? if you aren't, I need to prepare a PR for 8301 (that would include 9167) for 2.46 (which is fine, just need to know that I should do it :)
<mup> PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8301>
<jdstrand> mvo: all that is left for new PRs that small k8s-support one that I need to investigate. then I'll be doing 'needs security review' reviews
<mvo> jdstrand: thank you
<jdstrand> mvo: (also, PR 8920 needs final reviews)
<mup> PR #8920: interfaces: update cups-control and add cups for providing snaps <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>
<jdstrand> mvo: do note that I intentially did not milestore PR 9186 for 2.46. that needs discussion. if there happened to be a 2.46 point release after that is merged, we could consider it, but it floating into 2.47 would be fine too
<mup> PR #9186: interfaces: add vcio interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9186>
<mvo> ok
<jdstrand> mvo: I'm looking at https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+security+review%22. nothing is milestoned for 2.46. is there anything in there that should be that you would like me to prioritize?
<jdstrand> if not, I have a good idea of the priority
<zyga> I keep getting vendor.json changes
<zyga> I purged cache
<zyga> purged the tree
<zyga> it keeps changing
<jdstrand> zyga: me too! I'd love to see that resolved. (my dev container is on bionic still. wonder if it is a focal vs bionic thing)
<pstolowski> mvo: why is #9171 blocked?
<mup> PR #9171: [RFC] config: "virtual" configuration for timezone <Needs Samuele review> <Run nested> <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9171>
<mborzecki> zyga: jdstrand: perhapos a different version of govendor was used when vendor.json was last updated in the tree
<zyga> hmm
<mborzecki> the difference is a checksum only
<mborzecki> (at least here)
<zyga> perhaps but what's the version and who has it is interesting
<mborzecki> i have 1.0.9
<zyga> I have 1.0.9 in /usr/bin and 1.0.8 in GOPATH
<mborzecki> btw. i guess we all should be using the latest master govendor, since we're go getting it in run-checks
<zyga> and get-deps uses that
<zyga> mborzecki: totally offtopic: https://github.com/snapcore/snapd/pull/9189
<mup> PR #9189: snap/snapenv: set SNAP_REAL_HOME <Created by zyga> <https://github.com/snapcore/snapd/pull/9189>
<mup> PR snapd#9189 opened: snap/snapenv: set SNAP_REAL_HOME <Created by zyga> <https://github.com/snapcore/snapd/pull/9189>
<zyga> mborzecki: running 1.0.9 modifies my vendor.json
<mborzecki> zyga: there's a couple of recent commits to vendor.json, mine was on 3.08 (and i'm using 1.0.9), the later commits were by claudio, samuele and jamesh
<zyga> hmmmm
<zyga> the change comes from 7a9cb154a0c (Claudio Matsuoka     2020-08-13 09:08:15 -0300 115)                        "revision": "68200eea7bdcb97e27fe8e5ff443776383908637",
<zyga> so maybe claudio has older version
<mborzecki> let's ping him when he's online
<zyga> yeah
<mvo> pstolowski: I think 9171 really needs samuele approval, I think it's okay otherwise, if the design gets approval I would like to tweak it a bit more with some helpers
<pstolowski> mvo: i made a few comments, not sure what was already discussed and agreed, so maybe my comments make no sense
<mvo> pstolowski: cool, happy for any feedback at this point
<mvo> pstolowski: hm, great point about snap get -d
<mvo> pstolowski: I think you are right, we should probably not bypass this for that
 * mvo scratches head
<pstolowski> mvo: yes i think we are breaking some high level assumptions here. and i fear it's going to be annoying to handle :/
<mvo> pstolowski: yeah, this needs more discussion for sure
<mvo> pstolowski: your comment about the transations is also interessting, maybe we need to hook into commit() here instead
<mvo> lxd tests passed locally in 9184
 * mvo vanishes for lunch
<zyga> enjoy
<pstolowski> mvo: what if we do store in state but synchronize config state with system setup? or is it too terrible?
 * pstolowski lunch as well
<zyga> pstolowski: who wins?
<zyga> pstolowski: if system was modified when snapd was down?
<pstolowski> zyga: system always wins. we update system on snap set.
<pstolowski> but maybe it's naive
<pstolowski> just throwing ideas
<zyga> pstolowski: so when would we use the value from state?
<pstolowski> zyga: we would always update state from system before reading. that could simplify transaction logic without special-casing. but just brainstorming at this point
<pstolowski> anyway, time for lunch
<zyga> pstolowski: I see
<zyga> I don't know either, just trying to understand your point better
<cachio> zyga, hi
<cachio> zyga, do you have any idea about what could be causing that when I test beta image and do "systemctl --user daemon-reload" as root I get "Failed to connect to bus: No such file or directory
<cachio> "
<cachio> If I do that as ubuntu user I dont see any error, but as root I see that error
<cachio> and it makes fail the snapd-failover test
<zyga> cachio: hi
<zyga> cachio: yes, I explained that a few days ago
<zyga> cachio: when we reload systemd-logind.service on older versions of systemd
<zyga> cachio: we cause it to forget about the session of the root user
<zyga> cachio: then subsequent test that prepares a session for the root user
<zyga> cachio: enables linger, which starts services and so on
<zyga> cachio: but then the restore disables linger
<zyga> cachio: because systemd logind is no longer tracking the incoming ssh session of the root user
<zyga> cachio: it shuts down systemd --user for root
<cachio> zyga, do you know which is the difference between the test we run in github and the one I run in beta validation to explain why it works in github and fails with the beta image?
<zyga> cachio: I don't know what version beta was forked form
<zyga> cachio: please check if it contains changes to prepare-restore.sh
<zyga> talking exactly about this issue in the commit message
<cachio> zyga, I see the change
<cachio> I need to see how to make it for external backend
<cachio> thanks for the explanation
<zyga> cachio: the fix I made is generic
<zyga> cachio: if you have it and the bug persists then there's something more broken
<cachio> zyga, yes
<cachio> but in case of external backend we exit before that code
<zyga> cachio: output from loginctl list-sessions would help
<zyga> cachio: when do we exit then?
<cachio> zyga, most of the prepare_project is not done for external backend
<cachio> I am trying to move the linger configuration to see if it works
<zyga> cachio: I see
<zyga> cachio: yeah, you need to apply the fixes to systemd-logind
<zyga> cachio: those are one-off
<zyga> cachio: do you perform package upgrades? what's the target?
<zyga> is that core16?
<cachio> yes
<zyga> core16 needs a special workaround
<zyga> in essence, I repackage core
<zyga> though recently ijohnson applied a fix to core so maybe that is no longer required
<zyga> following that /var/lib/systemd/linger is bind-mounted to writable using a mount unit
<zyga> look at the patches I apply to replicate that
<zyga> I wasn't aware the external target skips all of that
<cachio> zyga, no problem, I'll try to extend that to external
<zyga> you may only need the 1) mount unit 2) change to logind configuration followed up by REBOOT
<ijohnson> zyga: the core fix has not landed yet, PR is still open
<ijohnson> also morning folks
<ijohnson> hey mborzecki welcome back
<cachio> pstolowski, hey, any idea about thie error https://paste.ubuntu.com/p/SRTGRMHx45/
<cachio> it is happening in Core20-early-config test
<cachio> I see this gadget.yaml parse error: Duplicate key: system
<cachio> not sure if it could be the raeson
<pstolowski> looking
<zyga> ijohnson: I see
 * zyga was having pierogis for lunch
<ijohnson> cachio: that was what I fixed in my PR
<pstolowski> cachio: yeah, definately
<zyga> cachio: there's a duplicate key :)
<ijohnson> cachio: that is fixed by #9187
<mup> PR #9187: tests/lib/nested.sh: use more robust code for finding what loop dev we mounted <Run nested> <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9187>
<pstolowski> right, i was just going to say that :), thanks ijohnson
<cachio> ijohnson, ah, thanks!!!
<mvo> ijohnson: should I force merge 9187? there are still failures in nested
<cachio> mvo, the errors in nested are fixed in other pr
<ijohnson> mvo: let me look quickly
<cachio> in mine
<ijohnson> mvo: the tests are still failing
<ijohnson> also SU time now
<cachio> pr: #9098
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<ijohnson> mvo: sorry I meant the tests still seem to be running?
<cachio> but mine fails sometimes because the erorr which is fixed on 9187
<cachio> ijohnson, I retriggered the tests
<mup> PR snapd#9081 closed:  secboot,cmd/snap-bootstrap: cross-check partitions before unlocking, mounting <Run nested> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9081>
<zyga-mbp> oh, and I'm making progress on unit testing bash, https://listed.zygoon.pl/ has the details
<cachio> zyga-mbp, so I see we do https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L662
<zyga-mbp> right
<cachio> we need that for external as well?
<zyga-mbp> you want that and the configuration change immediately below that
<zyga-mbp> yes
<cachio> ok, that plus the change https://github.com/snapcore/snapd/blob/master/tests/lib/prepare-restore.sh#L446
<zyga-mbp> cachio note that this is the static part, the dynamic part is where we decide systemd-logind needs reloading and REBOOT
<zyga-mbp> yes
<cachio> perfect
<zyga-mbp> we try to enable linger for the test user, if that fails we know we need to restart
<zyga-mbp> note that this does essentially the same change (configuration file edit) so make sure to just reboot in that case as the config file is already in place, just inactive
<cachio> ok
<zyga-mbp> I hope this works :)
<zyga-mbp> cachio I left a small comment on v
<zyga-mbp> https://github.com/snapcore/snapd/pull/8986/files
<mup> PR #8986: tests: new snaps-state command - part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8986>
<cachio> zyga-mbp, thanks!!
<zyga> cachio: any luck?
<cachio> zyga, no yes, trying in 5 minutes
<zyga> ok
<cachio> still making some changes
<mup> PR snapd#9188 closed: interfaces: misc policy updates xlvi <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9188>
<ijohnson> mvo: 9184 is super super green :-)
<mup> PR snapd#9190 opened: [RFC] cmd/s-b/initramfs-mounts: make recover -> run mode transition automatic <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9190>
<cachio> zyga-mbp, Could not enable linger: No such file or directory
<cachio> I  see that
<zyga-mbp> cachio, ok do you have a shell
<cachio> when I do loginctl enable-linger test
<cachio> yes
<zyga-mbp> is the logind.conf file modified?
<cachio> yes
<cachio> StateDirectory=systemd/linger
<zyga-mbp> is /var/lib/systemd/linger a mount point to the corresponding directory in writable?
<cachio> with this config
<cachio> I created that in writable
<zyga-mbp> that's not all, is a mount in place?
<cachio> I cant write to /var/lib/systemd/linger
<zyga-mbp> is there a mount unit that makes /var/lib/systemd/linger a bind mount to /writable/system-data/....
<cachio> it is protected
<zyga-mbp> you need the linger directory to exist
<zyga-mbp> and it must be a mount point as I've explained
<zyga-mbp> no way around that
<zyga-mbp> THEN you can reboot to reconfigure logind
<zyga-mbp> (via REBOOT)
<cachio> I cant create /var/lib/systemd/linger
<zyga-mbp> and then it will work
<zyga-mbp> cachio so merge the core change and rebuild the snap
<cachio> which is the change to merge?
<zyga-mbp> ian proposed a PR for core
<cachio> zyga-mbp, ok, so no workaround until the chagne in core is merged
<zyga-mbp> correct
<zyga-mbp> unless you can repackage core
<cachio> zyga-mbp, agree but on beta validation we don't repack core
<cachio> so I'll push the change done by ian
<cachio> ijohnson, is this the change? https://github.com/snapcore/core/pull/116
<mup> PR core#116: extra-files/writable-paths: make all /var/lib/systemd writable <Created by anonymouse64> <https://github.com/snapcore/core/pull/116>
<ijohnson> yes
<cachio> waiting for a second review?
<cachio> ijohnson,
<zyga-mbp> ijohnson what happens when we remove entries?
<ijohnson> cachio: I can actually merge it, not sure if I should wait though
<ijohnson> zyga-mbp: what do you mean ?
<zyga-mbp> ijohnson this looks good but may need follow ups for hacks in prepare-restore
<zyga-mbp> ijohnson the removal of /var/lib/systemd/rfkill and random-seed lines
<ijohnson> hmm
<zyga-mbp> I'd +1 without those
<zyga-mbp> but now that I see them
<zyga-mbp> I would not keep them
<zyga-mbp> I just want to understand what happens in practice
<ijohnson> I need to think about this, I don't remember how refreshes work, but I think it's just the initramfs that modifies the etc/fstab according to the writable-paths
<zyga-mbp> on existing systems that shipped with those lines
<zyga-mbp> cachio can you test that upgrade
<ijohnson> so after a refresh to the revision here it should work fine
<zyga-mbp> I think it's very important for correctness
<ijohnson> there have been other situations where we drop things there though that have landed without controversy however I think
<ijohnson> one moment
<zyga-mbp> ijohnson we are trigger happy sometimes
<pstolowski> mvo: +1 for #9184
<mup> PR #9184: packaging: umount /snap on purge in containers <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9184>
<ijohnson> zyga-mbp: see https://github.com/snapcore/core18/pull/127
<mup> PR core18#127: Make /var/cache writable and disable dynamic motd <Created by woodrow-shen> <Merged by vorlonofportland> <https://github.com/snapcore/core18/pull/127>
<zyga-mbp> ijohnson in another call
<cachio> zyga-mbp, ijohnson sorry, which upgrade?
<ijohnson> cachio: nvm I can test the upgrade, it is about the writable-paths changes
<cachio> ijohnson, ah, ok, thanks
<zyga-mbp> re
<zyga-mbp> cachio check if we can upgrade core from what it looks like now to what is proposed in that PR 127
<mup> PR #127: Use cap instead of cap1 where only one capability is being manipulated <Created by zyga> <Merged by elopio> <https://github.com/snapcore/snapd/pull/127>
<zyga-mbp> cachio to see if anything explodes
<zyga-mbp> I mean
<zyga-mbp> we'll know if we land it
<zyga-mbp> and run tests
<zyga-mbp> but a quick run might be helpful as well
<zyga-mbp> mvo ^ do you know what happens if we remove existing entries from writable paths?
<ijohnson> ugh building the core snap is so annoying
<ijohnson> I wish we could update the core snap to build with modern snapcraft
<cachio> ijohnson, yes
<cachio> tomorrow I can test that we new core is in edge
<ijohnson> cachio: but the PR hasn't been merged though is the thing
<cachio> I really don't know how to build core
<ijohnson> I just built it locally though
<ijohnson> cachio: do you use wormhole? I can send it to you in a few moments
<cachio> I can test that if you built core?
<cachio> ijohnson, yes
<cachio> please send me it
<mvo> zyga-mbp: if we remove writable-path they stop being writable which may break things - what in particular are you asking?
<zyga-mbp> mvo please look at https://github.com/snapcore/core/pull/116/files
<mup> PR core#116: extra-files/writable-paths: make all /var/lib/systemd writable <Created by anonymouse64> <https://github.com/snapcore/core/pull/116>
<zyga-mbp> are those changes safe in your eyes
<ijohnson> zyga-mbp: fwiw he already approved it
<zyga-mbp> I know but not sure if he really looked ;D (sorry mvo)
<mvo> zyga-mbp: oh, this should be fine
<zyga-mbp> mvo in that case let's land it
<zyga-mbp> and rebuild core
<mvo> zyga-mbp: removing subpath but making more available is fine
<zyga-mbp> we can always revert
<zyga-mbp> and this will help cachio
<mvo> zyga-mbp: please approve first
<ijohnson> well I have it built now, testing what happens on refresh of a core16 vm
<ijohnson> cachio: I don't think you need to test what I built here anymore
<cachio> ok
<mup> PR snapcraft#3250 closed: cli: implement list-tracks <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3250>
<mup> PR snapcraft#3252 closed: snapcraft: use system certificates by default for https requests <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3252>
<ijohnson> jdstrand: is this a typo or intentional? https://github.com/snapcore/snapd/pull/9188/files#r474066839
<mup> PR #9188: interfaces: misc policy updates xlvi <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9188>
 * zyga-mbp needs to break soon
<mup> PR snapcraft#3255 closed: remote-build: use requests.get() instead of urlopen() <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3255>
<mvo> ijohnson: if you test is successful please let me know and I will merge
<ijohnson> mvo: yes sorry got distracted it is rebooting now
<mvo> ijohnson: no worries
<ijohnson> mvo: mmm the VM didn't come back after the refresh
<ijohnson> mvo: need to debug, perhaps there is a problem
<mvo> ta
 * cachio lunch
<mvo> ijohnson: uh, I accidently merged 116 :/ let's hope it's not a  problem with that change or I have to revert
<ijohnson> mvo: my hope is that this is a multipass problem, I am recreating a uc16 VM with plain qemu :-/
<mup> PR core#116 closed: extra-files/writable-paths: make all /var/lib/systemd writable <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/core/pull/116>
 * zyga runs away from meetings and works for a while in quiet
<zyga> mvo: shall we merge https://github.com/snapcore/snapd/pull/9184
<mup> PR #9184: packaging: umount /snap on purge in containers <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9184>
<zyga> just to make some progress and see how it behaves over time
<ijohnson> I'd say so
<zyga> yeah
<zyga> me too
<dstathis> Has anyone here used kubelet installed via snap? If so do you know how to get it to use the systemd cgroup driver?
<ijohnson> joedborg: can you answer dstathis question ?
<ijohnson> mmm mvo, better revert that core PR, I can reproduce the problem in qemu, I need to debug this, but it somehow broke ssh
<ijohnson> so sorry :-/
<joedborg> Hey dstathis.  Weâre currently working on this under strict confinement for both microk8s and a fully working kubernetes node (I.e. kubelet, proxy, containerd etc).  This isnât complete yet though as there are lots of working parts that need working through
<dstathis> joeborg: The snap of kubelet is not complete yet? I'm asking because kubelet is no longer available via apt. Only snap
<dstathis> (in Ubuntu 20.04)
<mvo> ijohnson: my bad, I should not have merged prematurely
<ijohnson> no, it's my bad I didn't test an actual refresh of it
<zyga> mvo: https://github.com/snapcore/snapd/pull/9184#pullrequestreview-471764868 can I merge?
<mup> PR #9184: packaging: umount /snap on purge in containers <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9184>
<mvo> zyga: yes, I'm still trying to create a reproudce for the lxd team about the systemctl daemon-reload
<joedborg> dstathis: that is usually used by our kubernetes distribution Charmed Kubernetes.  It is a classic snap, so shouldnât need any interfaces connected.  However itâs not really documented outside of CK context
<mvo> zyga: but merging will make things work again
<zyga> mvo: ok
<zyga> merging
<zyga> it's ok to revert if it explodes in new ways
<dstathis> joedborg: is there another recommended way to install kubelet on 20.04? Or do you know how to configure the cgroup diver using the snap?
<mup> PR snapd#9184 closed: packaging: umount /snap on purge in containers <â  Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9184>
<joedborg> dstathis: I donât know for sure, but Iâm reasonably confident you do `snap set kubelet [kubelet arg]=[value]
<joedborg> You need to swap hyphens for underscores i.e `api-server` becomes `api_server`
<ijohnson> how does a change to /var/lib/systemd/private cause `sshd[1151]: Missing privilege separation directory: /var/run/sshd` :-(
<dstathis> joedborg: is there a way to ask the snap which configuration options it will recognize? I know there is a command line argument that can be passed in this case
<joedborg> dstathis: sadly not as snap config is key value without any firm validation
<mvo> ijohnson: pushed the revert now
 * mvo gets dinner
<ijohnson> thanks, I am very puzzled how this is broken
<mvo> yeah
<zyga> what is broken?
<zyga> I heard qemu
<ijohnson> zyga: my writable-paths PR somehow breaks ssh
<zyga> ijohnson: aha
<zyga> maybe it only breaks ssh in testing
<ijohnson> so you were right :-O
<zyga> what are the symptoms?
<zyga> ijohnson: ha
<dstathis> joedborg: 'sudo snap set kubelet cgroup-driver=systemd' worked. Thanks
<zyga> ijohnson: heh, I didn't mean to
<ijohnson> zyga: it makes the ssh server service fail to start like this:
<ijohnson> https://www.irccloud.com/pastebin/NbSCym9q/
<zyga> interesting
<zyga> but how is that related to what you did?
<ijohnson> I have no idea
<zyga> maybe we neutered the whole directory
<zyga> there used to be more state in that systemd tree
<zyga> now it's all an empty directory
<zyga> maybe that's why?
<ijohnson> zyga: no the other files are still there
<zyga> oh
<zyga> I'll look at ssh source
<ijohnson> zyga: the files are /var/lib/systemd/... and those are still there in the core snap after I made this change
<ijohnson> unless systemd is doing something weird with /var/lib/private
<zyga> hah
<zyga> do we have /var/empty?
<zyga> this is what this is complaining about
<zyga> ah, no
<zyga> sorry
<zyga> confflags += --with-privsep-path=/run/sshd
<ijohnson> zyga: /var is not empty
<zyga> if /run/sshd doesn't exist I'd love to log in interactively
<zyga> and see the status
<zyga> of all the services
<zyga> I bet something else failed
<ijohnson> mmm actually there is a tmpfiles failure earlier
<zyga> ijohnson: can we retry with just added linger
<zyga> and then circle back with more oomph
<ijohnson> https://www.irccloud.com/pastebin/4GceHjg4/
<zyga> unsafe symlinks? never heard that one before
<zyga> checking
<ijohnson> yeah very odd
<zyga> I cannot find that in current systemd
<zyga> trying older
<zyga> ijohnson: I think this explains it
<zyga> https://github.com/systemd/systemd/issues/14226#issuecomment-560467107
<ijohnson> mmmm interesting let me see
<zyga> ijohnson: I'm too tired to build core and boot it in qemu
<zyga> I wish there was a fire-and-forget for that
<ijohnson> zyga: no worries thank you for looking!
<ijohnson> I am actively debugging this
<ijohnson> ha actually I'm a fool I didn't even build the right branch, so this core snap that I built is just master
<zyga> ijohnson: it would be amazing if we could test core against snapd test suite
<zyga> just build it there and clone snapd in an action
<zyga> and set some env in a spread run
<zyga> so it gets that core
<zyga> I think it's doable now
<ijohnson> it would be amazing if I didn't need all this chroot and vm nonsense with a legacy snapcraft to build the core snap
<ijohnson> and I could just do `snapcraft --use-lxd`
<zyga> ijohnson: we could use one action to build it and store an artefact
<zyga> ijohnson: and then another action to test it
<ijohnson> zyga: sorry what do you mean? for the snapd repo ?
<zyga> run all of snapd tests against a core built from a branch of the core repo
<zyga> right?
<zyga> so we get way better coverage
<ijohnson> mmm that would be nice
<zyga> the checkout action can checkout any repo
<zyga> so we have 90% of what we want in the snapd repo already
<zyga> we just need to teach snapd test suite to use a core that's wgettable from somewhere
<zyga> it can still rebuild / repack snapd
<zyga> but the base would be from the PR changing the core snap
<zyga> we could even write a test that runs only in this mode
<zyga> where a vanilla core can refresh to the new core
<zyga> and boot
<zyga> anyway
<zyga> you get the point
<ijohnson> also :-( I think the whole reason this failed is because I forgot to do this:
<ijohnson>   - sudo sed -i '/^deb/s/$/ universe/' $CHROOT/etc/apt/sources.list
<ijohnson> so the snap I built built from the wrong packages
<ijohnson> *sighes
<zyga> oh?
<zyga> oh well
 * zyga suspends and takes a break
<ijohnson|lunch> https://github.com/snapcore/core/blob/master/.travis.yml is how I build all my core snaps
<ijohnson|lunch> but just doing that locally
<ijohnson|lunch> and I missed a step
<cachio> zyga-mbp, this test is failing as well
<cachio> https://paste.ubuntu.com/p/GXdqXc4YWg/
<cachio> could be related to the revious issue ?
<zyga-mbp> it's the same failure
<zyga-mbp> yeah
<zyga-mbp> it's expected
<cachio> or you think it is something different
<cachio> zyga-mbp, nice, thanks, I thought that but just wanted to make sure
<cachio> thanks
<zyga-mbp> cool
 * cachio afk
<mup> PR snapd#9189 closed: snap/snapenv: set SNAP_REAL_HOME <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9189>
<joedborg> dstathis: ah thanks for letting me know
<cachio> cmatsuoka, https://github.com/snapcore/snapd/pull/9098/checks?check_run_id=1008878037#step:5:7412
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<cmatsuoka> cachio: let's see...
<cachio> now without any error during reboot
<cachio> during boot
<cachio> no reboots involved
<cmatsuoka> ah nice!
<cmatsuoka> excellent
<cmatsuoka> ah wait
<cmatsuoka> but it failed?
<cmatsuoka> ugh
<cachio> couldnt login after that
<cmatsuoka> and this is qemu without kvm?
<cachio> yes
<cmatsuoka> let me see this log in detail
<cachio> ijohnson, I merged master and still see
<cachio> 2020-08-20T18:18:54.2486726Z + mount /dev/mapper/ /tmp/tmp.wFbPmXutiu
<cachio> 2020-08-20T18:18:54.2486835Z mount: /tmp/tmp.wFbPmXutiu: /dev/mapper is not a block device.
<cachio> sorry, thought that #9187 was merged
<mup> PR #9187: tests/lib/nested.sh: use more robust code for finding what loop dev we mounted <Run nested> <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9187>
<ijohnson> cachio yeah it's not merged, needs mvo to merge it though maybe now If I merge master to that PR it will be green
<cachio> ijohnson, I see lxd tests failing there https://github.com/snapcore/snapd/pull/9187/checks?check_run_id=1007716427#step:5:7003
<mup> PR #9187: tests/lib/nested.sh: use more robust code for finding what loop dev we mounted <Run nested> <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9187>
<ijohnson> cachio yeah let me merge master to this pr so we have some chance of being all green
<cachio> ijohnson, nice, thanks
<ijohnson> cachio: running now, let's see how it does
<cachio> cool
<cmatsuoka> cachio: I think I found the problem
<cachio> cmatsuoka, awesome
<cachio> which one?
<cachio> which is?
<cmatsuoka> I think there's a call missing there, I'm checking the change history to see if this is was lost at some refactoring, or it was never there
<cachio> cmatsuoka, nice
<cmatsuoka> cachio: I'm checking a possible fix with chris
<cachio> cmatsuoka, nice, thanks
<cachio> please ping me if you need to test it
<cmatsuoka> cachio: thanks, I think we'll need to test it a lot since it seems that it happens infrequently
<cachio> cmatsuoka, yes
<mup> PR snapd#9191 opened: interfaces/{docker,kubernetes}-support: load overlay and support systemd cgroup driver <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9191>
<mup> PR snapd#9192 opened: interfaces/{docker,kubernetes}-support: load overlay and support systemd cgroup driver - 2.46 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9192>
<mup> PR snapcraft#3251 closed: build providers: honour http proxy settings for snapd <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3251>
<mup> PR snapd#9193 opened: interfaces/many: deny arbitrary desktop files and misc from /usr/share - 2.46 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9193>
<mup> PR snapd#9194 opened: Interface cups slot 2.46 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9194>
<mup> PR snapd#9195 opened: interfaces: misc policy updates xlvi - 2.46 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/9195>
<mup> PR snapd#9159 closed: cmd/snap-update-ns: detach all bind-mounted file <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9159>
<mup> PR snapd#9196 opened: osutil: add OpenExistingLockForReading <Created by zyga> <https://github.com/snapcore/snapd/pull/9196>
<mup> PR snapd#9187 closed: tests/lib/nested.sh: use more robust code for finding what loop dev we mounted <Run nested> <Test Robustness> <â  Critical> <Created by anonymouse64> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9187>
#snappy 2020-08-21
<mborzecki> morning
<mvo> good morning mborzecki
<mborzecki> mvo: hey
<mborzecki> mvo: 2.46 branch needs cherry-picks with fixes for the tests
<mvo> mborzecki: I think I will just merge master there
<mborzecki> mvo: unless we just merge master
<mborzecki> cool
<mvo> mborzecki: I had hoped for some fixes from sergio
<mup> PR snapd#9191 closed: interfaces/{docker,kubernetes}-support: load overlay and support systemd cgroup driver <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9191>
<mvo> mborzecki: before I do that
<mvo> mborzecki: thanks for merging this
<mvo> mborzecki: also nice to see green PRs again
<mborzecki> mvo: yeah, even if it's just temporary ;)
<mvo> mborzecki: ha! you are such a pessimist :) it will be perfect from now on!
<mborzecki> mvo: weird, this branch https://github.com/snapcore/snapd/pull/9196 is in the upstream repo instead of zyga-mbp's fork
<mup> PR #9196: osutil: add OpenExistingLockForReading <Created by zyga> <https://github.com/snapcore/snapd/pull/9196>
<mvo> mborzecki: he probably made this by mistake :/
<mborzecki> mvo: wonder if there's some fine grained permission switches to prevent from pushing new branches unless they meet certain pattern (eg. release/..)
<mvo> mborzecki: aha, I think so
<mup> PR snapd#9186 closed: interfaces: add vcio interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9186>
<zyga-mbp> good morning
<zyga-mbp> wha'ts up?
<zyga-mbp> oh did I push to origin?
 * zyga-mbp reads backlog while eating breakfast cereals on the side
<zyga-mbp> interesting how this failed, wonder why
<mup> PR snapd#9196 closed: osutil: add OpenExistingLockForReading <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/9196>
<zyga-mbp> reopened from my fork
<mup> PR snapd#9197 opened: osutil: add OpenExistingLockForReading <Created by zyga> <https://github.com/snapcore/snapd/pull/9197>
<pstolowski> morning
<mvo> good morning pstolowski
<zyga-mbp> hey Pawel
<mup> PR snapd#9198 opened: features: add HiddenSnapFolder feature flag <Created by zyga> <https://github.com/snapcore/snapd/pull/9198>
<mborzecki> pstolowski: zyga-mbp: hey
 * zyga-mbp reboots for upgrades
<mvo> stgraber: hey, do you think you could have a quick look at lp 1892568 ? it's about a nested lxd test we run that is failing on 16.04 and we need advise if it's worth keeping this test. I can trivial reproduce this if you need any debug from me
<mvo> zyga: lp 1892568 might also be interessting for you, it has my findings about the nested lxd issue on 16.04
 * mvo takes a short break
<mborzecki> sourcing nested.sh in the debug shell sets -e, so a first non-successful command ends your shell :/
<mup> PR snapd#9161 closed: kernel: add kernel.Validate() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9161>
 * zyga-x240 goes afk for 30 min
<mvo> mborzecki: I think/hope that I have kernel-refs in gadget updates working now but writing the spread test for it is such a chore
<mborzecki> mvo: hahah, i feel your pain
<mborzecki> mvo: have you looked at the gadget update spread tests?
<mup> PR snapd#9199 opened: snapstate: installSizeInfo helper that calculates total size of snaps and their prerequisites <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9199>
<zyga-mbp> re
<zyga-mbp> man, lucy misses mom badly today
 * zyga-mbp hugs mvo and mborzecki for writing excellent tests for hard cases
<mup> PR snapd#9197 closed: osutil: add OpenExistingLockForReading <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9197>
<zyga-x240> mvo: back?
<mvo> meeting
<zyga-x240> mvo: so about https://launchpad.net/bugs/1892568 - I get 404
<zyga-x240> what am I missing?
<zyga-x240> https://github.com/snapcore/snapd/pull/9200 <- super simple
<mup> PR #9200: runinhibit: open the lock file in read-only mode in IsLocked <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9200>
<mup> PR snapd#9200 opened: runinhibit: open the lock file in read-only mode in IsLocked <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9200>
 * zyga-x240 small break
<cachio> mvo, hi, the PR 116 on core has been merged today right?
<mup> PR #116: Feature/mount snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/116>
<cachio> it is not included in core on edge yet, right?
<mvo> cachio: yes, this morning
<mvo> cachio: quite possible, I can trigger a rebiuld for core
<mvo> zyga-mbp: https://bugs.launchpad.net/snapd/+bug/1892468
<mup> Bug #1892468: Nested dbus test useful? <snapd:New> <https://launchpad.net/bugs/1892468>
<cachio> mvo, yes please
<cachio> so I can test the fix for the failover test
<zyga-x240> mvo: thanks, weird that the other link did not work
<mvo> cachio: I triggered a build now
<mvo> zyga-x240: maybe I did a typo?
<cachio> mvo, thanks
<pstolowski> i see selinux-lxd failures on all selinux systems, not sure if this is related to my PR; has anyone seen it on other branches?
<mborzecki> pstolowski: got logs?
<pstolowski> mborzecki: https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/11690/signedlogcontent/67?urlExpires=2020-08-21T12%3A10%3A26.5605826Z&urlSigningMethod=HMACV1&urlSignature=vfCuP7XdBACxjXIQPWWvoGYGTxdhjW9ptv9tIA%2BbDPY%3D
<pstolowski> (PR #9084)
<mup> PR #9084: o/snapstate: check disk space before creating automatic snapshot on remove (3/N) <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9084>
<zyga-x240> 2020-08-21T11:51:03.3746915Z type=AVC msg=audit(1598010641.669:5223): avc:  denied  { getattr } for  pid=131226 comm="snapd" path="/var/snap/lxd/common/ns/shmounts" dev="nsfs" ino=4026532238 scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=file permissive=1 <-
<zyga-x240> oh, pawel is gone
<mup> PR snapd#9201 opened: [RFC] boot: observe update & rollback of trusted assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9201>
<zyga-x240> OMG
 * zyga-x240 learned something fantastically terrible 
<zyga-x240> O M G
<mborzecki> zyga-x240: hm?
<zyga-x240> you will never believe how insanely surprising shell is
<zyga-x240> set -e is ignored in some cases
<zyga-x240> and man, there's a super super super silly case
<zyga-x240> you can have pages of shell code
<zyga-x240> you can set -e
<zyga-x240> you can set -e 10 times in a row
<zyga-x240> run false
<zyga-x240> then true
<zyga-x240> and that doesn't stop
<zyga-x240> set -e
<zyga-x240> echo "LOL shell"
<zyga-x240> false
<zyga-x240> echo "I'm still here"
<zyga-x240> true
<zyga-x240> how you ask?
<zyga-x240> simple
<zyga-x240> just _at any level above_
<zyga-x240> put that in a context where set -e is ignored
<zyga-x240> such as
<zyga-x240> if foo; then ... fi
<zyga-x240> if that set -e and echo and false and true was in a "foo" function
<zyga-x240> set -e is irrelevant
<zyga-x240> I'm still here prints
<zyga-x240> and $? is 0
<zyga-x240> because that's a shell list
<zyga-x240> the return value is the return value of the last element
<zyga-x240> and the fact that this is a function which sets -e is irrelevant
<mup> PR snapd#9202 opened: tests/nested/core20/tpm: verify trusted boot assets tracking  <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9202>
<zyga-x240> because the context of the function call (at any level above!) is one where set -e is ignored
<zyga-x240> like ! foo
<zyga-x240> if foo
<zyga-x240> foo | bar
<zyga-x240> or other similar
<stgraber> mvo: 404
<zyga-x240> how f**** crazy is that
<zyga-x240> stgraber: try https://bugs.launchpad.net/snapd/+bug/1892468
<mup> Bug #1892468: Nested lxd test useful? <snapd:New> <https://launchpad.net/bugs/1892468>
<zyga-x240> mborzecki: surprise
<mborzecki> zyga-x240: it's friday and i think i'm a bit slow already, do you have an example?
<zyga-x240> mborzecki: yeah, I have a very complex one
<zyga-x240> let me try to make a simple script now that I get it
<zyga-x240> and the manual documents this
<zyga-x240> but doesn't connect the dot
<zyga-x240> between set -e ignored
<zyga-x240> and _any parent call_ set -e ignored
<zyga-x240> https://paste.ubuntu.com/p/QDh6JwqCW9/
<zyga-x240> mvo: ^ tell me how many bugs we have left?
<zyga-x240> mvo: in shell
<mup> PR snapd#9172 closed: tests: update spread test for unknown plug/slot with snapctl is-connected <Simple ð> <Test Robustness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9172>
<zyga-x240> mvo: onto that test now
<zyga-x240> ogra_: https://paste.ubuntu.com/p/7njRQNhRZz/
<zyga-x240> ogra_: check this out
<mvo> zyga-x240: \o/ *thank you*
<mvo> zyga-x240: also for sharing that snippet
<mvo> zyga-x240: I wonder if shellcheck should warn about "if func()", I would argue it should
 * ijohnson afk little bit
<zyga-x240> mvo: I don't know, it's such a misfeature
<zyga-x240> maybe it should if set -e is in effect
<zyga-x240> I feat it may be very noisy
<mvo> zyga-x240: I think this is worth a bugreport
<mvo> zyga-x240: not sure, do you think if func() is common?
<zyga-x240> mvo: yeah, I'll file one over weekend
<zyga-x240> I want to write a blog post about this as well
<mvo> zyga-x240: amen
<zyga-x240> I'll refer to bugs in shellcheck and the example
<mvo> zyga-x240: please do!
<zyga-x240> after being at canonical for a decade I'll write a mail to tech@ ...
<pstolowski> mborzecki: can you re-paste what you found about that selinux denial before i dropped from irc?
<zyga-x240> mvo: test written, just waiting to see if it passes
<mvo> zyga-x240: thanks so much
<mvo> zyga-x240: I'm sure for some people it's not a surprise
<zyga-x240> mvo: maybe we should hire them?
<mvo> zyga-x240: maybe we should write less shell
<mborzecki> pstolowski: zyga-x240 belived that snapd traverses too far and trespassed to locations managed by lxd
<zyga-x240> mborzecki: not quite, it's not like it's not our space
<zyga-x240> it's just that there are weird and wonderful objects there
<zyga-x240> that are not just files
<zyga-x240> and selinux doesn't like that
<mborzecki> right
<mborzecki> pstolowski: but i'd ahve to look at the PR again, maybe there's more to it
<cachio> zyga-x240, is this enough for the failover test on a core image https://paste.ubuntu.com/p/dTmddSv3Cw/ ?
<zyga-x240> cachio: not quite, remember that you cannot restart logind
<zyga-x240> you must reboot
<cachio> yes
<cachio> well I try both things
<zyga-x240> well, we tried already
<zyga-x240> you cannot restart logind safely until systemd 246
<cachio> but still see
<cachio> + systemctl --user daemon-reload
<cachio> Failed to connect to bus: No such file or directory
<zyga-x240> cachio: I'd have to review your changes,
<cachio> didnt push it yet
<cachio> trying manually first
<cachio> but that change that manually did is not enough to make the tests work
<zyga-x240> change what manually?
<cachio> https://paste.ubuntu.com/p/dTmddSv3Cw/
<cachio> that
<zyga-x240> cachio: sorry that's not correct
<cachio> but with reboot
<zyga-x240> I see
<zyga-x240> can you tell me loginctl list-sessions after rebooting?
<cachio> ok
<zyga-x240> cachio: one thing that may be at play, is that root has no session
<zyga-x240> since external target uses external user
<zyga-x240> so disable-linger root may still, really, just shut stuff down
<zyga-x240> but prepare enables linger
<zyga-x240> which should make that irrelevant
<mup> PR snapcraft#3256 opened: repo: consolidate BaseRepo and Ubuntu & reorganize package <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3256>
<cachio> zyga-x240, https://paste.ubuntu.com/p/yp37m39TsD/
<zyga-x240> is the external user logged in?
<cachio> no
<cachio> zyga-x240, https://paste.ubuntu.com/p/d2Wcn7JJdh/
<zyga-x240> this is with the external user logged in
<cachio> yes
<zyga-x240> ok
<zyga-x240> well, this much looks sensible
<cachio> perhaps the problem is that here we use external instead of root to run the tests
<cachio> zyga-x240, could be that affect?
<zyga-x240> cachio: well, as I said above
<zyga-x240> it should not matter
<zyga-x240> so what fails now?
<zyga-x240> which of the tests beaks
<cachio> fails the same
<cachio> spread -debug external:ubuntu-core-16-64:tests/core/core-to-snapd-failover16
<cachio> this fails
<zyga-x240> mvo: updated https://github.com/snapcore/snapd/pull/9200
<mup> PR #9200: runinhibit: open the lock file in read-only mode in IsLocked <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9200>
<cachio> during restore
<zyga-x240> cachio: how does it fail?
<cachio> zyga-x240, https://paste.ubuntu.com/p/HGjKDsXpKk/
<zyga-x240> yeah, I think that test needs tests.session -u root prepare / restore
<zyga-x240> try adding that (prepare in 1st line, restore in last line)
<zyga-x240> and run that test alone
<cachio> sure
<zyga-x240> it should pass then, the problem is that systemctl --user really assumes you have root
<zyga-x240> that's implicit for our tests
<zyga-x240> actually
<zyga-x240> cachio: wait
<zyga-x240> cachio: so in external mode tests run as non-root entirely?
<zyga-x240> or run as root somehow via sudo or something like that?
<cachio> they use external user
<cachio> they are not root
<zyga-x240> mvo: https://github.com/snapcore/snapd/pull/9200/files
<mup> PR #9200: runinhibit: open the lock file in read-only mode in IsLocked <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/9200>
<zyga-x240> cachio: hmmm
<zyga-x240> cachio: then that will not suffice
<zyga-x240> cachio: we need a bigger hammer
<zyga-x240> cachio: and in addition
<zyga-x240> cachio: that test should *not* fail anymore
<zyga-x240> + systemctl --user daemon-reload
<zyga-x240> if this runs as external
<zyga-x240> then when it fails, please list sessions and do systemctl status
<zyga-x240> (just without logging in again)
<zyga-x240> let's examine what is going on
<cachio> zyga-x240, ok
<mup> PR snapcraft#3257 opened: plugins v2: use repo.Repo not repo.Ubuntu in colcon <bug> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3257>
<cachio> zyga-x240, https://paste.ubuntu.com/p/RMb9qPVBFp/
<cachio> so it connects using external
<cachio> but then uses root
<cachio> as for other backends
<zyga-x240>              â â ââ3480 sudo -i /bin/bash /tmp/tmp.zwRt33mi04
<zyga-x240> but it uses sudo
<zyga-x240> cachio: I'm about to EOD
<zyga-x240> this needs more oomph
<zyga-x240> sudo is incorrect
<cachio> ok
<cachio> lets continue on Mondya
<zyga-x240> ok
<cachio> enjoy the weekend
 * zyga-x240 takes a break and heads for PT
<zyga-x240> cachio: thank you, you too
<zyga-x240> cachio: we need to either not use sudo
<zyga-x240> cachio: or give root a real session
<zyga-x240> cachio: not a mismatch of the two
<ijohnson> zyga-x240: github meeting? or will you miss that?
<zyga-x240> ijohnson: I'll pass
<ijohnson> k
<zyga-x240> I need to prep for PT
<zyga-x240> I marked myself as optional
<zyga-x240> and I'm tired
<zyga-x240>  cachio is that sudo from spread or from us?
<cachio> I think spread does it
<zyga-x240> ok
<cachio> let me check
<cachio> zyga-x240, I see this in spread
<cachio> func (c *Client) sudo() string {
<cachio> 	if c.config.User == "root" {
<cachio> 		return ""
<cachio> 	}
<cachio> 	return "sudo -i "
<cachio> }
<cachio> in the client
<zyga-x240> we will need some changes then
<zyga-x240> it's not broken per se
<zyga-x240> but it's not the same as logging in as root
<zyga-x240> so bummer
<pstolowski> cachio: a few comments to nested PR
<cachio> pstolowski, thanks!
<cachio> zyga-x240, nice, tanks for the help, so lets continue on Monday
 * cachio lunch
<ijohnson> jdstrand: hey in #9191 I noticed that you didn't add overlay as a kernel module for the kubernetes-support interface like you did with docker, is there a reason you made it docker-support only?
<mup> PR #9191: interfaces/{docker,kubernetes}-support: load overlay and support systemd cgroup driver <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9191>
<ijohnson> jdstrand: also not sure if you saw my ping about a possible typo in #9188
<mup> PR #9188: interfaces: misc policy updates xlvi <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9188>
<mup> PR snapcraft#3257 closed: plugins v2: use repo.Repo not repo.Ubuntu in colcon <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3257>
<ijohnson> man it feels good to have green PR's again that we can just merge
<mup> PR snapd#9190 closed: cmd/s-b/initramfs-mounts: make recover -> run mode transition automatic <Run nested> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9190>
 * zyga is back from PT
<zyga> ijohnson: it does feel good :)
<mup> PR snapd#9200 closed: runinhibit: open the lock file in read-only mode in IsLocked <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9200>
<mup> PR snapcraft#3258 opened: schema/snapcraft.json: allow type: os with build-base <Created by anonymouse64> <https://github.com/snapcore/snapcraft/pull/3258>
<cachio> ijohnson, hey
<cachio> for some raeson nested tests are fialing to boot on uc16 and 18 after merging with master
 * ijohnson is meeting, will look in a bit
<cachio> ijohnson, sure, thanks
<ijohnson> cachio: so what's failing?
<ijohnson> cachio: and is it 100% reproducible ?
<cachio> I can't login
<cachio> it is like hte user is not created
<ijohnson> cachio: for all nested spread tests ?
<cachio> not sure if all but many
<cachio> I ran
<cachio> google-nested:ubuntu-16.04-64:tests/nested/core/core-snap-refresh-on-core
<cachio> and could reproduce it
<cachio> still have a shell
<ijohnson> cachio: ok I will take a look
<cachio> the cloud init info is copied correctly
<ijohnson> cachio: usually what I have taken to doing to reproduce these things is to shut down the nested-vm systemd service, then start the VM manually with qemu, but using -serial mon:stdio then create a user via console-conf to login to the VM and poke around to see what ran/didn't run, etc.
<ijohnson> cachio: it's running now
<ijohnson> let's see what we get
<cachio> yes
<cachio> ip 34.74.111.154
<jdstrand> ijohnson: I'm not really here but it is because overlay is needed for docker and containerd. k8s can be configured for either and therefore must also plugs docker-support
<ijohnson> jdstrand: ack, makes sense
<ijohnson> cachio: I opened #9203 to fix that
<mup> PR #9203: tests/lib/nested.sh: fix partition typo, unmount the image on uc20 too <Run nested> <Simple ð> <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9203>
<mup> PR snapd#9203 opened: tests/lib/nested.sh: fix partition typo, unmount the image on uc20 too <Run nested> <Simple ð> <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9203>
<cachio> ijohnson, in configure_cloud_init_nested_core_vm_uc20 is ok to use p2 right?
<ijohnson> cachio: yes p2 is ubuntu-seed on uc20
<cachio> good
<ijohnson> but uc16 / uc18 have p3 as writable
<cachio> yes
<cachio> I see you added kpartx -d "$IMAGE"
<cachio> in configure_cloud_init_nested_core_vm_uc20
<cachio> it never was there?
<cachio> ijohnson, +1
<ijohnson> cachio: yes I accidentally dropped it in my previous PR I think
<ijohnson> maybe it wasn't ever there tbh though
<cachio> ijohnson, ok, np
<ijohnson> cachio: actually to be fair it was never there before my refactor
<cachio> ijohnson, ouch
<ijohnson> cachio: this might have been why some of the uc20 tests will randomly fail if they get the wrong image that was leftover from before still mounted, we could copy files to the wrong image
<cachio> ijohnson, yes
<cachio> it could be
<cachio> I am taking a look the the history
<ijohnson> hopefully this is all green on this PR
<cachio> I removed that
<cachio> I found when
<cachio> could that produce the randome reboots?
<ijohnson> cachio: probably not
<zyga> cachio: o/
<zyga> cachio: have we lost xdelta3?
<zyga> https://github.com/snapcore/snapd/pull/9203/checks?check_run_id=1014017904
<mup> PR #9203: tests/lib/nested.sh: fix partition typo, unmount the image on uc20 too <Run nested> <Simple ð> <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9203>
<ijohnson> whelp
<ijohnson> that seems problematic
<zyga> hey ijohnson
<ijohnson> hey zyga
 * zyga likes cross-timezone work, pop into irc and there are your colleagues, any time of the day
<cachio> zyga, didnt update the images since mongay
<ijohnson> :-D
<cachio> monday
<zyga> cachio: hmm, any idea what may be going on then?
<zyga> this is nested, maybe it didn't run for a while?
<cachio> it is failing in ubuntu and debian
<cachio> let me boot an instance
<cachio> all the ubuntus
<ijohnson> zyga: I've been running nested tests basically all day
<ijohnson> let me see if I can reproduce running it again
<zyga> hmm
<zyga> thnx
<cachio> this seems to be happening in the machines which run spread
<cachio> not in gce
<ijohnson> yeah spread is running fine on my machine
<cachio> zyga, are those machines running in your home??
<cachio> zyga, I see this Runner name: 'claudio-spread-1'
<ijohnson> cmatsuoka: mmmm
<cachio> cmatsuoka, are yo uhosting github action clients?
<cmatsuoka> yes
<cmatsuoka> one runner
<cmatsuoka> is it misbehaving?
<ijohnson> cmatsuoka: is xdelta3 installed on that machine ?
<cachio> yes
<cmatsuoka> let me check, I just ran zyga's runner building script
<cmatsuoka> ijohnson: no xdelta3
 * cmatsuoka installs 
<ijohnson> cmatsuoka: so yeah we will need to install that
<ijohnson> and update zyga's doc
<cmatsuoka> done
<cachio> nice
<cachio> cmatsuoka, thanks
<cmatsuoka> zyga sent me instructions by email so I'm replying with a note about the missing package
<zyga> cmatsuoka: ohhh
<zyga> cmatsuoka: also install python-launchpadlib
<cmatsuoka> ah
<zyga> cmatsuoka: and we should drop that mail into a gdoc or whatever that we are happy with and can be updated
<cmatsuoka> python3-launchpadlib was already installed
<zyga> ok
<cmatsuoka> python3-launchpadlib is already the newest version (1.10.13-1).
<zyga> https://github.com/zyga/bashcov/blob/master/bashunit
<zyga> run that
<zyga> write stuff like that
<zyga> https://github.com/zyga/bashcov/blob/master/bashcov_test.sh
<zyga> try breaking the test, the output is interesting as well
 * zyga EODs and goes to pay taxes
<zyga> taxes paid
<ijohnson> have a good weekend zyga!
<mup> PR snapcraft#3259 opened: cli: introduce set-default-tracks <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3259>
<mup> PR snapd#9203 closed: tests/lib/nested.sh: fix partition typo, unmount the image on uc20 too <Run nested> <Simple ð> <Test Robustness> <â  Critical> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9203>
<ijohnson> cmatsuoka: mmm but the tests weren't done running :-/
<cmatsuoka> oh really? the button was green
<ijohnson> https://github.com/snapcore/snapd/pull/9203/checks?check_run_id=1014236898
<mup> PR #9203: tests/lib/nested.sh: fix partition typo, unmount the image on uc20 too <Run nested> <Simple ð> <Test Robustness> <â  Critical> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9203>
<ijohnson> shows the nested runs were still running
<cmatsuoka> oh noes
<ijohnson> perhaps github's ui shows it's green when all the required ones are green?
<ijohnson> all the other tests had finished except the spread-nested
<ijohnson> labels
<cmatsuoka> humm it's possible, I'll pay attention to the run status even when it's green
<cmatsuoka> i was quite sure it wouldn't allow you to merge before the tests completed :\
<ijohnson> for the required checks yes it won't
<ijohnson> but for the non-required ones, I always thought the button would show up as grey
<ijohnson> as in you could still click it but it wasn't fully green
<cmatsuoka> oh well let's hope it finishes without any issues now
<cmatsuoka> well even if it fails the p2 fix was needed anyway
 * cmatsuoka EOWs
<cmatsuoka> have a nice weekend
<ijohnson> thanks cmatsuoka you too!
