#snappy 2015-09-14
<fgimenez> good morning
<dholbach> good morning
 * ogra_ tickles seb128
<ogra_> seems someone found my G+ post about personal ...
<ogra_> https://lists.ubuntu.com/archives/snappy-devel/2015-September/001033.html
<ogra_> https://lists.ubuntu.com/archives/snappy-devel/2015-September/001036.html
<ogra_> seb128, i assume nobody is interested in getting bugs yet for this ?
<seb128> hey ogra_
<seb128> not that I know of, no
<JamesTait> Good morning all; happy Monday, and happy Eat a Hoagie Day! ð
<zyga-phone> Good morning
<Chipaca> JamesTait: what's a hoagie?
<mvo> Chipaca: I reviewed your branches, I guess next step is to get them onto the 15.04 image or is something pending from your side
<JamesTait> Chipaca, https://en.wikipedia.org/wiki/Submarine_sandwich#Hoagie
<Chipaca> mvo: we need to decide what to do about activation in 15.04
 * Chipaca hugs JamesTait for not sending him to lmgtfy
<Chipaca> mvo: also maybe we don't need to backport to 15.04 if we don't want to ship these there and instead ship trunk to 15.04?
<JamesTait> Chipaca, nah, enough people have asked that I realise not everyone watches Man vs Food. ð
<Chipaca> mvo: next step for _me_ is thinking a little bit about services, and implementing the fruit of my thinkage
<Chipaca> JamesTait: that looks like a sandwich you can't eat politely :)
<JamesTait> Oh, definitely.
<mvo> Chipaca: re trunk> https://bugs.launchpad.net/snappy/+bug/1493706 worried me a bit about that (I still think its a good idea in general, but this worried me about regressions)
<ubottu> Launchpad bug 1493706 in Snappy "side-loading frameworks broken" [Critical,Triaged]
<mvo> Chipaca: activation? what has changed here (pardon my ignorance)
<Chipaca> mvo: oh, maybe you didn't notice? the coreos activation doesn't build on 15.04
<Chipaca> mvo: it uses os.Unsetenv, which wasn't it go 1.3
<mvo> Chipaca: oh, this activation, sorry, was confused
<Chipaca> mvo: stgraber's activation patch/fork fixes that
<Chipaca> mvo: so we need to decide whether to ship his fork, or his patch :)
<Chipaca> or whether we give up and vendor
<mvo> yeah, let me deal with that then
<Chipaca> mvo: and that's one we need to fix independently of backporting or not
<mvo> yep
<ogra_> mvo, the snappy config output if you just call it vs if you change a value look very different now ... if you chnage a value it prints all of the ppp values afterwards, if you just call the config command without setting anything the ppp values are omitted
<ogra_> setting a value: http://paste.ubuntu.com/12395367/ vs calling snappy config http://paste.ubuntu.com/12395393/
<mvo> ogra_: hm, that looks like a bug :/
<Chipaca> mvo: you need to stop apologizing to me for the state of the codebase, already; i've been here long enough :)
<ogra_> mvo, note i also seeded libnss-myhostname on the weekend for bug 1495058 and bug 1464396
<mvo> Chipaca: sorry
<ubottu> bug 1495058 in Snappy "updating the hostname via snappy config does not update /etc/hosts" [Undecided,New] https://launchpad.net/bugs/1495058
<mvo> Chipaca: :P
<ubottu> bug 1464396 in Snappy ""sudo: unable to resolve host ..." when custom hostname is used." [Critical,Triaged] https://launchpad.net/bugs/1464396
<mvo> Chipaca: ok, I will try to stop
<Chipaca> mvo: :D
<ogra_> (just as a FYI)
<mvo> Chipaca: do you have a link to the build failure btw?
<mvo> Chipaca: because the version of golang-systemd in the archive does not use os.Unsetenv so I'm a bit puzzled
<Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/serve/+merge/270372
<mvo> ta
<mvo> Chipaca: heh, its just our CI that is confused
<mvo> Chipaca: I commented in the MP
<Chipaca> mvo: so with that change to dependencies it'll be happy again?
<mvo> ogra_: hm, I just upgraded to ubuntu-core 147 and I do see the ppp config stuff, anything unusual aobut your image?
<mvo> Chipaca: I think so, I tested locally and it looked happy
<mvo> (ie. checked out the right revno and there was no os.Unsetenv() anywhere)
<Chipaca> mvo: your diff failed here, though
<mvo> :(
<mvo> I will redo it with a proper branch instead of a inline diff
<mvo> it needs tabs
<Chipaca> not sure why
<Chipaca> ah
<mvo> maybe LP ate them
<Chipaca> mvo: nah, i can patch by hand
<Chipaca> let's see if this works now :)
<ogra_> mvo, nope, nothing unusual
<ogra_> that was a plain install of 145 and i saw/see the same on 146 and 147
<mvo> ogra_: ok, I will try harder to reproduce
<ogra_> hmm, the machine doesnt boot anymore after auto upgrade :/
<ogra_> and indeed i have no serial board for that HW :/
<ogra_> well, or it doesnt bring up the static network setup
<Chipaca> serve landed \o/
<sergiusens> \o/
<Chipaca> sergiusens: mo'in!
<sergiusens> Chipaca, serve me a beer
<sergiusens> :-P
<sergiusens> Chipaca, good morning
<Chipaca> $ GET http://localhost:8080//1.0/packages/beer
<Chipaca> {"metadata":null,"status":"Not Found","status_code":404,"type":"error"}
<sergiusens> Chipaca, bummer :-)
<Chipaca> sergiusens: easy enough to fix though
<sergiusens> Chipaca, yeah, extend and serve myself :-P
<ogra_> hmm, so after autopilot upgrade it seems my static network doesnt come up anymore
<ogra_> mvo, does snappy config apply the /etc/network/interfaces.d file on every boot ?
<ogra_> Sep 14 09:18:00 aleph2 systemd[1]: ifup-wait-all-auto.service start operation timed out. Terminating.
<ogra_> Sep 14 09:18:00 aleph2 systemd[1]: Failed to start Wait for all "auto" /etc/network/interfaces to be up for network-online.target.
<ogra_> Sep 14 09:18:00 aleph2 systemd[1]: Unit ifup-wait-all-auto.service entered failed state.
 * ogra_ sees that in syslog of the failed machine 
<ogra_> oha !
<ogra_> Sep 14 09:16:01 aleph2 kernel: [   43.590490] r8169 0000:01:00.0 eth3: renamed from eth0
<ogra_> thats bad
<Chipaca> ogra_: what happened to stable network interface names?
<Chipaca> shouldn't that be ens3 or sth
<ogra_> 15.04
<ogra_> should it there ?
<Chipaca> I don't know
<Chipaca> my brain no longer supports 15.04
 * ogra_ is running 15.04 edge here 
<Chipaca> :)
<ogra_> it should definitely never rename it
<ogra_> no matter oif the name is foople0 or eth0 :)
<ogra_> wow and in /writable/system-data/etc/udev/rules.d i have the persistent-net.rules file with two different entries for the same MAC
<ogra_> thats gross
<ogra_> mvo, bug 1495452
<ubottu> bug 1495452 in Snappy "auto upgrade unintentionally updates /etc/udev/rules.d/70-persistent-net.rules" [Undecided,New] https://launchpad.net/bugs/1495452
<ogra_> pitti, is there a way to prevent this ? ^^^
<ogra_> (why would it add a device at all if there is a MAC existing for it in that file already)
<pitti> ogra_: that sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765577
<ubottu> Debian bug 765577 in udev-udeb "netboot install writes duplicates to 70-persistent-net.rules" [Serious,Fixed]
<pitti> ogra_: is that vivid?
<ogra_> pitti, yeah, the 15.04 edge image that we want to release this week
<pitti> (as the entire 70-persistent generator is completely gone from wily)
<ogra_> not sure we could drop the generator since 15.04 still seems to use the old way of naming devices
<pitti> ogra_: could you clean up the file, apply http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/diff/?id=f9cb380a, and see if that helps:
<pitti> ?
<pitti> if so, we can SRU that
<ogra_> ok
<sergiusens> Chipaca, mvo can I get an ack on https://code.launchpad.net/~sergiusens/snapcraft/collisions/+merge/270942 ?
<ogra_> well, i'm not really sure how to trigger it again now :(
<ogra_> to verify it wouldnt do that again
<ogra_> removing the line manually brings it up normally again ... it doesnt add it anew
<pitti> ogra_: nevermind, vivid already does have that thing
<ogra_> well, then it doesnt help obviously :)
<ogra_> (teh immage build is actually from yesterday so everything in -security and -updates should be in it
<pitti> ogra_: but what's weird is that the file header exists multiple times too
<ogra_> )
<pitti> it's actually not wrong -- there are three MACs with different names, and the rules are just duplicate, not contradicting AFAICS
<pitti> oh, :f8 is eth0 and eth3
<ogra_> well, except that the second entry for eth0 is named eth3
<ogra_> right :)
<ogra_> and i also got: Sep 14 09:16:01 aleph2 kernel: [   43.590490] r8169 0000:01:00.0 eth3: renamed from eth0
<ogra_> on the first boot after the auto-upgrade
<mvo> sergiusens: I have a look now
<sergiusens> mvo, thank you very much
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦[ -e "$RULES_FILE" -o -e "$tmp_rules_file" ] || PRINT_HEADER=1
<pitti> ogra_: ^ hm, it shouldn't print the header again if the file already exists
<pitti> ogra_: could it be that /etc/udev/rules.d/ (or the actual file) is a bind mounted dir/file, which isn't bound in initramfs already?
<pitti> i. e. the generator would race with bind-mounting the file?
<ogra_> pitti, yeah, could be, i have to check the inird script
<ogra_> pitti, but would the generator run from initrd ?
<ogra_> the bind mount is definitely done via fstab processing
<pitti> ogra_: AFAICS 70-persistent-net.rules gets copied into initramfs, but not the 75-persistent-net-generator.rules -- that shold only happen in the "real" fs
<ogra_> right and we cant generate the initrd on the device so the file should be either empty or not exist at all
<pitti> ogra_: "lsinitramfs -l /initrd.img |grep net-gen" to double-check?
<pitti> right
<pitti> but if you fstab-mount it, you have a race
<ogra_> GEEZ !
<ogra_> where does lsinitramfs come from and why dont i know about it !!!
<ogra_> gzip: /boot/initrd.img-3.19.0-28-generic: not in gzip forma
<ogra_> t
<ogra_> bah
<ogra_> (amd64)ogra@aleph2:~$ lzcat /boot/initrd.img-3.19.0-28-generic |cpio --extract --quiet --list|grep net-gen
<ogra_> (amd64)ogra@aleph2:~$
<ogra_> nope, not there
<ogra_> and the 70-persistent-net.rules file would also just vanish after the bind mount anyway
<ogra_> it wouldnt be mangled
<ogra_> pitti, this is clearly triggered only by an upgrade of the readonyl image part ... so i wonder if anything in there triggers it
 * ogra_ tries a snappy rollback and snappy update loop again ... 
<ogra_> rollback comes up fine again
 * ogra_ updates and reboots again 
<ogra_> upgraded fine, didnt change the rules file
 * ogra_ rolls back again and waits tile the autopilot kicks off the upgrade ... probably that causes a race
<mvo> ogra_: the ppp issue you see is on arm? or in a vm?
<ogra_> mvo, on x86 hardware
<mvo> sergiusens: the config branch as well?
<mvo> ogra_: real hw? interessting, I poke some more
<sergiusens> mvo, config branch is not done yet :-) the previous ones if you want you can review :-)
<ogra_> mvo, OOOH !
<sergiusens> mvo, I ran into collision problems when working on config (more complex and multiple parts al including ubuntu packages)
<ogra_> mvo, sudo vs no sudo makes the difference
<mvo> ogra_: oh, of course :/
<ogra_> (amd64)ogra@aleph2:~$ snappy config ubuntu-core |grep timezone
<ogra_>     timezone: Europe/Berlin
<ogra_> (amd64)ogra@aleph2:~$ date
<ogra_> Mon Sep 14 11:01:59 UTC 2015
<sergiusens> ogra_, for snappy config? I thought we had 'am I root' detection there
<ogra_> bah, that doesnt look right either
<mvo> sergiusens: yeah, I started but then got distracted
<sergiusens> mvo ogra_, we also need input hand holding in our config for ubuntu-core
<sergiusens> specially with ogra who typos a lot ;-)
<ogra_> haha
<ogra_> well, for configuring i used http://paste.ubuntu.com/12396598/ for this particular install
<ogra_> if you see any typos, please tell me :)
<ogra_> that the timezone doesnt get set is worrying :/
<sergiusens> ogra_, I don't see anything wrong, maybe check if /usr/share/zoneinfo/Europe/Berlin exists on the system?
<sergiusens> ogra_, it works fine for me for America/Cordoba
<ogra_> it exists
<ogra_> and /etc/writable/timezone is also set correctly
<ogra_> sergiusens, is that on 15.04 ?
<ogra_> (where America/Cordoba works)
<ogra_> ah, now autopilot rebooted it ... /me waits if the interface gets renamed this time
<ogra_> bah, came up fine
<sergiusens> ogra_, seems it doesn't work anymore http://paste.ubuntu.com/12407670/
<ogra_> yeah, bad
<ogra_> but i wonder why ... the files are all correct
<sergiusens> ogra_, /etc/timezone has the correct data
<ogra_> right, here as well
<sergiusens> ogra_, did we drop some dependency?
<sergiusens> ogra_, I can be blind and just blame systemd :-P
<ogra_> not that i'm aware of
<ogra_> aha
<ogra_> /etc/localtime points to UTC
<ogra_> something didnt update it along
<ogra_> due to the snappy config changes ?
<sergiusens> ogra_, no, this is older
<sergiusens> ogra_, snappy config only ever updated /etc/timezone
<ogra_> and that worked ?
<sergiusens> ogra_, yeah
<ogra_> (just asking because the hostname update only worked half)
<sergiusens> ogra_, hostname update has a bug logged somewhere; want to fix? shouldn't be complicated ;-)
<ogra_> sergiusens, fixed it on the weekend :)
 * sergiusens finds ogra_ fixes things fast to scratch his itches ;-)
<zyga> hey guys
<ogra_> so lets see what happens if i properly update /etc/localtime
<ogra_> (amd64)ogra@aleph2:~$ sudo cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime
<ogra_> [sudo] password for ogra:
<ogra_> (amd64)ogra@aleph2:~$ date
<ogra_> Mon Sep 14 13:20:06 CEST 2015
<ogra_> sergiusens, i cant really belive that ever worked correctly ... (i rather guess nobody wimply noticed)
<ogra_> *simply
<ogra_> these files always need to be updated alongside
<sergiusens> mvo, do you know if meta/hooks/config can be a symlink?
<ogra_> sergiusens, bug 1495474
<ubottu> bug 1495474 in Snappy "setting the timezone via snappy config does not actually update the time zone" [Undecided,New] https://launchpad.net/bugs/1495474
<mvo> sergiusens: I think it can and its probably a good idea too, if it does not work there might be a bug
<sergiusens> mvo, great, because I'm working on having snapcraft just symlink ;-)
<ogra_> pitti, ouch ...
<ogra_> (amd64)ogra@aleph2:~$ mount|grep -c etc
<ogra_> 18
<ogra_> pitti, dont you think we could simply make the generator run later ... mounting everyting of /etc in initrd sounds wrong
<rickspencer3> ppisati, hey, sorry, I lost track, when do you think I'll be able to use pwm on my rpi2?
<ppisati> rickspencer3: latest kernel has it working (both 3.19 and 4.2)
<ppisati> rickspencer3: if you are willing to do some manual hacking, you can test it right now
<rickspencer3> ppisati, can I just install rolling?
<rickspencer3> ppisati, actually, let me ask differently ...
<rickspencer3> could you send detailed instructions to the snappy mailing list on how to test it?
<ppisati> rickspencer3: ok, i'll do
<rickspencer3> thanks ppisati
<rickspencer3> I'm looking forward
<pitti> ogra_: well, you'll just keep running into races like this
<ogra_> pitti, hmm, yeah :(
<pitti> this is like the 10th time this issue bubbles up
<pitti> ogra_: you could restart udev once again after mounting everything, but you'd need to do "start udev", "stop udev", "mount everything in /etc", "restart udev"
<ogra_> well, i guess that needs some discussion first ... i can add a function that parses out all the /etc dirs and mounts them indeed
<ogra_> do we actually restart it at all ? i thought we carry the running daemon  binary over from the initrd
<pitti> no, we restart it
<ogra_> rickspencer3, you will need a device tarball ... i'll roll one durign the week anyway for the 15.04.3 image that is planned this week
<pitti> otherwise we'd keep the initramfs-tools' libc6 (and all libs) in RAM
<pitti> also, the i-t udev has only a minimal set of rules
<ogra_> rickspencer3, we dont have automated builds for RPi yet, so there is no specific tarball for the rolling images
<rickspencer3> ogra_, ok, noted
<rickspencer3> I think if ppisati emails directions to the list, that is the best way forward
<ogra_> pitti, yeah, i always thought we onyl re-process the rules and keep the daemon running ... but indeed that would keep libc and friends in ram too
<rickspencer3> I have all these servos and motors and rgb leds that are hungry for some pwm
<ogra_> rickspencer3, not if he doesnt use the exact same setup the device tarball will use
<rickspencer3> ogra_, um, then he should do that?
<rickspencer3> I don't mind updating the image later if necessary
<rickspencer3> I would just like to be unblocked
<ogra_> well, why not just wait a day til i get to it and can offer the ready made tarball for testing
<rickspencer3> ogra_, if that's what ppisati's directions say to do, that is fine with me
 * ogra_ is just currently busy with x86 since we have to have a specific release ready for this for 15.04.3
<ogra_> (and i run into bugs over and over with nearly everything atm :/ )
<ppisati> ogra_: rickspencer3 well, my directions would be how to manually install a kernel, update the dtb, etc
<ppisati> that's how i test new kernels
<ogra_> just cp'ing over the binary ?
<ogra_> yeah, that would work for testing indeed
<ppisati> ogra_: yep, literally
<ppisati> and the dtb too
<ppisati> and the modification to config.txt
<ppisati> i'm writing it now
<ogra_> cool, yeah, thats good
<zyga> sergiusens: hey, there's no schema support for per-part properties
<zyga> sergiusens: would you like a patch for that?
<zyga> sergiusens: so that a given part type can be validated
<sergiusens> zyga, the only reason that isn't there is because there is an alternate thing in place for that (which I want to get rid of) plugins/*.yaml
<zyga> sergiusens: hmm?
<zyga> sergiusens: do you want to remove all the plugin/part types?
<sergiusens> it uses a custom rule engine to support plugins/extensions
<sergiusens> zyga, no, I don't want to get rid of that
<zyga> sergiusens: ah, sorry, I misunderstood
<zyga> sergiusens: where is that thing then?
<zyga> sergiusens: in other words, when adding a new plugin type, where do I patch the schema?
<sergiusens> zyga, in the path I just gave you ;-)
<sergiusens> zyga, it's separate
<zyga> ah, that was a path, /me looks
<zyga> hmm I don't see plugins/extensions
<zyga> sergiusens: did you paste anything I've missed?
<sergiusens> zyga, http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/files/head:/plugins/
<zyga> sergiusens: right but that's not a json schema
<zyga> sergiusens: (I know about this part)
<zyga> sergiusens: if that's all then it's fine, I'm just looking around to see what to patch
<sergiusens> zyga, how would you support a 3rd party type with the schema?
<zyga> sergiusens: well, you can put all of that in the master schema
<zyga> sergiusens: assuming all plugins are in trunk
<zyga> sergiusens: and none are installed from a 3rd party add-on
<zyga> sergiusens: with add-ons you'd have to use some more nifty features but I think it's also possible
<sergiusens> zyga, none that you know of ;-)
<zyga> sergiusens: (I wrote json-schema-validator, which we're not using)
<zyga> sergiusens: my json schema is rusty but not that rusty :)
<zyga> sergiusens: so with all of them in trunk you can use specific property schemas
<zyga> and conditional parts
<sergiusens> zyga, right, we'd have to hack in local references; AFAIK, jsonschema only supports http
<zyga> sergiusens: it's all doable with pure json schema
<zyga> sergiusens: no, I don't think you need that
<zyga> sergiusens: what I was thinking of is....
<zyga> sergiusens: https://github.com/zyga/json-schema-validator/blob/master/json_schema_validator/tests/test_validator.py#L733
<zyga> sergiusens: something like this
<zyga> sergiusens: you can validate per-plugin type
<zyga> sergiusens: using requires  you can look at the outer object
<zyga> sergiusens: this is a random code example, the key idea is requires
<zyga> sergiusens: https://github.com/zyga/json-schema-validator/blob/master/schema-spec/draft-zyp-json-schema-03.txt#L564
<zyga> using the 03 draft wording
<sergiusens> zyga, I know about requires
<zyga> sergiusens: anyway, this is just an optional thing
<sergiusens> zyga, but this would only work for 'built' in plugins
<zyga> sergiusens: yes
<zyga> sergiusens: if the design requires 3rd party plugins then it won't work this wy
<zyga> way*
<zyga> (without a way to let each plugin ship any object)
<sergiusens> zyga, exactly, it supports 3rd party plugs
<zyga> sergiusens: and having a custom sub-schema for it
<zyga> sergiusens: ah, I see, thanks
<sergiusens> zyga, so we'd need schema snippets and load the references befor sending t to the validator
<zyga> sergiusens: you could just validate the generic schema and then sub-validate each plugin specifically
<sergiusens> zyga, sure, if you want to extend the schema, go ahead, I don't mind, right now all parts are part of a pattern properties
<tedg> Hey zyga, can we talk about pip and checkbox?
<tedg> zyga: It seems that checkbox is using multiple requirements files?
<zyga> tedg: yes, we sure can
<zyga> tedg: checkbox is not using requirements files the way you think
<tedg> zyga: I couldn't see a way they got consolidated.
<zyga> tedg: everything important is specified by setup.py meta-data
<tedg> Oh, okay.
 * tedg stops thinking
<zyga> tedg: if you get plainbox to work then checkbox is easier :)
<ogra_> pitti, oh ...
<tedg> zyga: So how do I know the requirements?
<zyga> tedg: if I can give you a bit of advice on requirement files: follow what travis-ci allows
<zyga> tedg: it's spelled in setup.py
<zyga> tedg: install_requires
<zyga> tedg: the standard way
<ogra_> pitti, i just noticed that i didnt remove "allow-hotplug eth0" from my /e/n/i setup, could that confuse the generator ?
<zyga> tedg: if you do what travis-ci allows then any python project will be snappy buildable
<ogra_> (does it check for that in any way ?)
<zyga> tedg: most projects just setup.py develop / install their deps
<pitti> ogra_: no, it doesn't look at that at all
<ogra_> ok
<tedg> zyga: I find "the standard way" doesn't really exist anywhere :-)
<zyga> tedg: and using wheels is the current hotness to make that easier to do
<zyga> tedg: I disagree
<zyga> tedg: setuptools is the way
<zyga> tedg: requirements are for separate concerns
<zyga> tedg: like deployment or other weird web scenarios
<zyga> tedg: if you setup.py install is broken then users complain (if they care)
<zyga> tedg: but it's definitely the standard way
<tedg> zyga: Travis CI just allows you to run binaries. We're not interesting in providing a bunch of scripts...
<tedg> zyga: http://docs.travis-ci.com/user/languages/python/
<zyga> tedg: yes but it supports certain things for free out of the box: like using setuptools without asking
<tedg> zyga: So like what we do with the python3-project plugin?
<zyga> tedg: yes, except right now that implementation is broken
<zyga> tedg: (for the same reasons I said earlier)
<tedg> zyga: So I think there's a patch for that, we just need to work out the details.
<tedg> zyga: But, to be clear, you don't want or use a requirements.txt file.
<sergiusens> tedg, if we accept the fix from BjornT I think zyga's problem would be a non issue
<zyga> tedg: it'd be nice if we support it if people want to use it (for version pinning)
<zyga> tedg: but it should be optional IMHO
<tedg> sergiusens: I think so too, but I haven't pinged you about your brainstorming weekend yet :-)
<sergiusens> tedg, hasn't happened :-/
<tedg> sergiusens: Start your weekend now! ;-)
<sergiusens> tedg, good idea
<zyga> sergiusens: btw, I failed with my .run() cleanup, it's utterly hard to clean up run to be space free and run without shell
<zyga> sergiusens: I will rescue a few patches from that but the whole patchset has failed (too many changes, tests change, etc)
<tedg> sergiusens: So let's take BjornT's patch for now and then we'll fix it later. I think it's more important to provide features today than provide smaller snaps.
<tedg> Hate taking on technical debt, but adoption is more important.
<sergiusens> tedg, certainly
<ogra_> how else would the duct tape producing industry survive ?
<tedg> So then elopio if you could look at my pip branch and tell me how to format the long lines in python compatible way I think it's ready too.
<tedg> ogra_: I believe there is a pact between the WD-40 industry and the duct tape industry. An evil, evil pact.
<tedg> elopio, sergiusens: I put pip tests in the integration suite. Is that where we want them? They take longer because they download stuff.
<ogra_> tedg, lol
<zyga> tedg: can I review it it as well?
<tedg> zyga: sure!
<zyga> tedg: ok, I'll check it out now
 * zyga cries for clean, logical commits :|
<zyga> tedg: there's no chance to squash those commits into separate changes?
<tedg> zyga: Eh, plastic surgery makes you look more beautiful, but hides who you really are :-)
<zyga> tedg: well, reading a merge commit to see why it's there really is bad for review
<zyga> tedg: and reviewing the whole change in one commit is not so nice
<zyga> tedg: can you have a more realistic requirements please? argparse is hardly good (bundled with 3), something that has deps of its own perhaps?
<tedg> zyga: You're not going to get me excited about the difficulty of reading a 200 line diff.
<tedg> zyga: We're not testing PIP here, just that PIP gets called.
<zyga> tedg: that's not useful
<zyga> tedg: the test doesn't check that what you do works in pratice IMHO
<zyga> tedg: especially that it does work if you have argparse installed on the host
<zyga> tedg: or if you have something it depends on installed is also present
<ppisati> rickspencer3: sent
<tedg> zyga: ? We're not looking at the host installation.
<rickspencer3> thanks ppisati
<tedg> zyga: We're testing that it gets downloaded and installed into the part. If it's in the host the test will fail.
<zyga> tedg: does it work if you use this plugin to install plainbox?
<zyga> tedg: (since plainbox is installed most of the time, that's an interesting test in itself)
<ppisati> rickspencer3: it's a bit long and hackish, but i tested every step on a clean snappy instalation, so it should just work
<ppisati> (last famous words...)
<rickspencer3> haha
<tedg> zyga: I looked at plainbox and it seemed to have multiple requirements files, which it doesn't support. But you said that you don't use requirements files, which is what this branch supports.
<zyga> tedg: hmm
<tedg> zyga: So I think the answer is no.
<zyga> tedg: but what about _no_ requirements
<zyga> tedg: and just "get this thing from pypi"
<zyga> tedg: which is akin to pip install $stuff
<tedg> zyga: No, didn't add that. I think that people mostly do that in their setup.py. No?
<zyga> tedg: hmm, but then they cannot use this part, right?
<zyga> tedg: or am I missing something
<zyga> tedg: use case: I want to pull in some tools into my snap, those are python tools I can pip install on my host
<zyga> tedg: so I use python3 parts
<zyga> tedg: and the part name is the pip thing to install
<zyga> tedg: I can also use requirements (e.g. to handle optional elements)
<zyga> tedg: the example pip-test in your MR could look like:
<tedg> zyga: This isn't about having tools on your host, this is about dependencies for your snap. You won't be able to use these tools for anything other than building/running.
<zyga> parts:\n
<zyga> tedg: I _know_ that was an analogy
<zyga> tedg: parts: argparse: type: python2
<zyga> tedg: e.g. if I want to have a script that uses some libraries I can just use the python3/python2 parts in my snapcraft to pull them from pypi
<tedg> zyga: If you were only targetting snappy, that would make some sense? But it seems like if you wanted your build system to work anywhere else you'd use setup.py and requirements.txt.
<zyga> tedg: (my analogy was about moving a familiar developer/user experience)
<zyga> tedg: so if I wrote a script on ubuntu
<zyga> tedg: and I need some stuff from pypi (that you can normally pip install)
<zyga> tedg: then I want to copy that into my snap by using a python3/python2 part type and just listing the thing I want
<sergiusens> tedg, yes, system interactions into integration_tests is fine
<tedg> So your use case is someone custom modifying a system instead of someone building something that could be deployed in production and used by other people.
<zyga> tedg: the requirement file that you specify is relative to snapcraft.yaml, right?
<tedg> zyga: Yes, it would be in the project directory.
<zyga> tedg: ok
<zyga> tedg: looking at the MR, I'd like an explanation of what the pull method is doing there
<zyga> tedg: the symlink and oll the other stuff seem a bit magic
<zyga> tedg: can you explain what that is doing and why?
<tedg> zyga: Yeah, it's a bug. Seems that you can't change the root and specify the deb layout.
<zyga> tedg: mmmm, I'm sure you can, what did you try?
<zyga> tedg: the deb layout just uses dist-packages
<tedg> zyga: Specifying deb layout and the root directory :-)
<zyga> tedg: I did just that :)
<tedg> zyga: Just the two command lines, then it put everything in /usr
<zyga> tedg: hmmm, I'll look at that
<zyga> tedg: I understand your branch doesn't address separation of python from the host yet
<zyga> tedg: and something else that sergiusens mentioned will work on that?
<zyga> tedg: specifically that pip will not install things that are on the host, so plainbox for example would be broken because its dependencies might be on the host for most developers
<zyga> tedg: (and we should just force it to install everything as if system python didn't exist and didn't have any packages)
<tedg> zyga: This branch allows normal setuptools to install into the parts: https://code.launchpad.net/~bjornt/snapcraft/setuptools/+merge/270733
 * zyga looks
<zyga> hmmmm
<zyga> this is not enough
<tedg> zyga: Provide a test, we will fix it :-)
<zyga> tedg: sure
<tedg> IRC based TDD ;-)
<zyga> tedg: one thing is that this will break if you are in a virtualenv
<tedg> Hmm, that uses prefix instead of root dir.
<zyga> and many python developers are ;)
<zyga> my testing showed that you need to avoid importing site
<zyga> and you need to explicitly run the python from stage dir, not any python
<zyga> this runs any python2 and any python3
<zyga> which is wrong
<zyga> to avoid importing site you need to pass -S
<zyga> then it will work
<tedg> The PATH is configured to only run the version from the parts install.
<zyga> so that's one test case :)
<zyga> tedg: I found that not to be the case, perhaps another bug was at play?
<tedg> That then adjusts the directories to use the correct site directory.
<zyga> tedg: ok, I'll check again now
<tedg> You might make sure to run my branch in that regard, there was a small bug with environments that it fixes. I don't think it broke that for python-project though.
<tedg> Only broke in python itself.
<sergiusens> mvo, http://paste.ubuntu.com/12408693/ any idea?
<zyga> sergiusens: what's the schedule for stable API for plugins/parts?
<sergiusens> mvo maybe the profile thing doesn't like symlinks
<zyga> sergiusens: as in, what's the deadline for making changes to those parts
<sergiusens> zyga, the spec is in place, it can't change; just needs implementation
<zyga> sergiusens: so all the methods need to return True?
<sergiusens> zyga, no, that's an implementation detail; but in any case once we do release, which is sometime this week it can't change as plugin writing docs would need to change as well
<sergiusens> zyga, I say if you don't like that, get it done today ;-)
<zyga> sergiusens: that's what I wanted to hear ^_^
<zyga> sergiusens: I'll talk to you in a sec, stand-up time
<zyga> sergiusens: is there a public link to the spec?
<zyga> sergiusens: or is it the same private doc?
<sergiusens> zyga, I thought the gdoc I gave you was public
<zyga> sergiusens: ah, I assumed otherwise
<zyga> sergiusens: ok :)
<mvo> sergiusens: no, sorry, this is a 15.04 image? might be a sideload issue
<zyga> mvo: did you think about the sideload issue I've mentioned last week?
<zyga> mvo: (to store sideload flag not in $prefix)
<mvo> zyga: the origin information (.sideload, .mvo) is causing us some grief but I have not thought it through yet
<sergiusens> zyga, mvo  if it is not in the form of $name.sideload it would be in the form of /apps/$origin/$name
<mvo> that was the discussion in cape town, right?
<sergiusens> mvo, nope, this was our invention in Austin
<zyga> sergiusens: I don't understand how that addresses that C/C++ stuff that hardcodes --prefix cannot be sideloaded
<zyga> sergiusens: maybe I'm missing stuff, sorry, split attention
<sergiusens> mvo, btw, I can't symlink the config hook
<mvo> sergiusens: its exploding :( ?
<mvo> sergiusens: the aa_exec error?
<sergiusens> zyga, I don't know what you are talking about either; all I'm saying is that the problem you present is not solvable by hardcoding paths
<sergiusens> mvo, aa_exec, or the runner (or snappy) how was it again that the profile for config was created?
<zyga> sergiusens: ah, sorry, I didn't understand that, so what is the approach to software that does hardcode stuff today?
<tedg> zyga: You shouldn't hardcode prefixes, you really need to use the environment variables there.
<zyga> sergiusens: well, preach upstream, the reality is different
<mvo> sergiusens: aa-clickhook is doing that still - is that on rolling or 15.04?
<zyga> tedg: ^^^
<tedg> You're gonna need to chroot things for those cases.
<zyga> tedg: if I want to integrate an upstream project I don't want to have to patch it)
<sergiusens> mvo, 15.04
<zyga> tedg: that's a bit unfortunate IMHO, why is that required?
<tedg> We have talked about providing some amount of automatic chroot, but haven't gotten to it.
<zyga> tedg: if the prefix was deterministic from version and snap name, that would be enough for all the C software in the world
<tedg> zyga: Because we don't want to commit to even /apps
<zyga> tedg: since we'll break everything on 16.04 I think it would be useful to have a prefix that works in the meantime, even if we change it later
<zyga> tedg: maybe the chroot thing will fix it but it sounds like an overkill to me
<tedg> What you're saying is if we backed ourselves into another hardcoded filesystem layout things would be easier. But the problem is hardcoded filesystem layouts, not how they're layed out.
<zyga> tedg: and (again) today, it's not working
<zyga> tedg: no, hardcoded filesystem layout are a reality for the past few decades
<zyga> tedg: if we require software to be relocatable then we put extra roadblock
<tedg> Yes, let's fix it!
<zyga> tedg: that's silly, that's not our battle to fight
<tedg> Heh, frankly, we chose to fight it over three years ago.
<zyga> tedg: and especially, I don't see what we gain by requiring this apart from nebulous "not hardcoded"
<zyga> tedg: if that means that we cannot easily integrate major upstream software than I just see that as a disadvantage
<fgimenez> ogra_, i'm looking into https://code.launchpad.net/~elopio/snappy/resize_test/+merge/270892, should this work in 15.04?
<tedg> zyga: An opinion that you're entitled to. I think the fix for those folks is to chroot it until they realize it's 1990 already.
<zyga> tedg: I think that's a bold statement from the world where _everything_ written in C hardcodes prefix and we gain exactly nothing today by not supporting that
<zyga> tedg: and targetting IOT space will intersect a lot of those projects
<zyga> tedg: and last time I checked ubuntu is in the 1990s you claim
<zyga> tedg: and will be in 16.04
<tedg> Yes, and we're fixing that!
<zyga> tedg: no, we just look the other way
<zyga> tedg: are we sending patches anywhere?
<zyga> tedg: we're not fixing anything, we just say we don't support de-facto standards today
<ogra_> fgimenez, 15.04 and rolling should be identical now wrt that code ...
<tedg> zyga: Reality is that most projects provide environment variables to change almost all of those prefixes. We've even patched xcb where we needed it. For instance, all of the QML stuff is relocatable with the qml plugin. Those base libraries are all written in C.
<fgimenez> ogra_, ok thanks, i'm getting some errors in 15.04, i'll try to fix the install-test-initramfs script to make it work in both
<tedg> (well C++, but for this argument that's not important)
<zyga> tedg: and what environment variables those upstream projects we've patched are respected? those of snappy?
<ogra_> fgimenez, oh, note that i landed the final fixes only on the weekend, so make sure you have a recent image in use
<tedg> zyga: Nope, their own, we then set them up for snappy. http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/snapcraft/plugins/qml.py#L78
<fgimenez> ogra_, currently 147, is that ok?
<ogra_> yep
<ogra_> that should work
<ogra_> i did a plethora of fresh installs with 146 and 147 on actual x86 HW on the weekend here
<zyga> tedg: I still think this is totally counter productive, for all the low-level plumbing stuff that we don't ship anyone that needs to ship it has now to maintain a fork just to fix this non-issue (they gain nothing from this) or hardcode /apps/$name/$version and ignore side-loaded (or reverse, non-side-loaded) snaps:
<zyga> tedg: I understand what you are sying but I think it doesn't work for the long tail of things and doesn't help us in adoption today
<tedg> zyga: Sure, but there are very few opportunties that you get to make things better. We're trying to take one.
<zyga> sergiusens: would you oppose a snapcraft part that can install extra build dependencies?
<zyga> sergiusens: dynamically from the part itself
<zyga> sergiusens: and if not, what other approach should one take to handle, e.g., building bluez
<sergiusens> zyga, iirc, there's already a build-depends you can use with parts
<zyga> sergiusens: with parts yes, but what about listing those in the snapcraft.yaml itself
<zyga> sergiusens: not at the part type level, at a part _instance_ level
<sergiusens> zyga, don't use the word part so generically, it is confusing ;-)
<zyga> sergiusens: sorry, so, e.g. to build bluez
<zyga> sergiusens: I'd like to say that building bluez requires all the packags on the host
<zyga> tedg: bluez has 34 hardcoded instances of $prefix
<zyga> tedg: in executables alone
<zyga> tedg: a quick source search has 100 (exactly) matches for places that need to be patched
<zyga> tedg: can it be done? yes, it is useful? not for anyone consuming snappy
<zyga> s/consuming/targetting/
<tedg> zyga: Then use a chroot?
<zyga> tedg: how?
<tedg> zyga: Have the service start a script that does a chroot to the $SNAP_APP_PATH
<zyga> tedg: will it be able to access the hardware this way?
<zyga> tedg: e.g. /dev, /sys, /proc
<tedg> zyga: You might have to map some directories into the chroot.
<zyga> tedg: I assume netlink works
<zyga> tedg: how?
<zyga> tedg: do I mount --bind ? something?
<zyga> tedg: and still integrated with outer dbus
<zyga> tedg: if you add all those up, and it works, are we still making the world better?
<tedg> zyga: Getting closer ;-)
<zyga> tedg: (I'm using this as an example I work on right now, it's not made up on purpose to be evil)
<tedg> zyga: The reality is that no one will change unless they have a reason. If they see the environment for bluez on Snappy, they'll not use prefix as much, and eventually change.
<tedg> zyga: Change is a slow process.
<zyga> tedg: I won't do the bind mount, or anything else, I'll hardcode /apps/$name/$version.sideload because I don't have the time to research the other solution that is identical if it works
<zyga> tedg: well, I don't want /apps to change
<zyga> tedg: I just want to fix side-loading
<zyga> tedg: and I'm showing my case as an argument
<tedg> zyga: For instance, for frameworks it may change to /framework
<zyga> tedg: I'll gladly hardcode /framework and build a new snap, that's easy
<zyga> tedg: still .sideload will be a thorn
<tedg> You're fighting this. Just feel the force and blend with it. Lift the speeder out of the swamp. I know you can do it.
<zyga> tedg: I'll accept patches that make bluez relocatable ;)
<zyga> tedg: if you want to wade thorough 100 places that need this
<zyga> tedg: I'm like the model consumer of snappy
<zyga> tedg: they will just totally ignore this non feature
<zyga> tedg: and say you have to sideload / not sideload
<zyga> tedg: this is a non feature because all the value is for snappy developers and none for the snap developers that have to now do extra work
<zyga> tedg: also this: https://github.com/ninjasphere/ninjasphere-snappy/blob/master/docs/TESTING.md#known-issues
<zyga> tedg: third bullet point
<tedg> zyga: You're welcome to argue and dislike it, but the reality is that we're not going to hardcode the paths anytime soon.
<zyga> tedg: I'll argue otherwise at the sprint :-)
<tedg> Is there a way to add udev rules in a snap?
<sergiusens> mvo, Chipaca ideas? http://paste.ubuntu.com/12409199/
<beuno> tedg, wouldn't that break confinment pretty badly?
<sergiusens> tedg, no, only snappy hw-assign or through the gadget or oem snap
<Chipaca> sergiusens: sudo
<sergiusens> Chipaca, doh
<Chipaca> sergiusens: :)
<Chipaca> sergiusens: if you readd/write from priv'ed locations, check your EUID
<Chipaca> sergiusens: so you're more user gefriendly
<tedg> beuno: Well, we need some way to add new devices. i.e. my new cool USB device to go along with my software package.
<tedg> beuno: We can parse the file. We probably don't want to just copy the file somewhere.
 * beuno nods
<ogra_> tedg, isnt that what hw-assign actually does ?
<tedg> ogra_: Oh, does it? I didn't know how it worked. I figured it was apparmor magic.
<ogra_> i think it is both, apparmor and udev rule creation ... jdstrand would know :)
 * jdstrand reads backscroll
<jdstrand> tedg: is there a way to add udev rules to a snap> the oem snap is capable of doing this. I believe that is 'config'urable (/me points you to mvo for that)
<beuno> jdstrand, tedg here wants to do it from an app
<ogra_> evil evil :)
<beuno> because his app will use a device he built, lets say
<tedg> sergiusens: Seems that galileo doesn't use a requirements.txt, just setup.py
<jdstrand> so, the answer to that is 'no'
<jdstrand> a gadget could describe that
<beuno> burn!
<jdstrand> an app shouldn't
<beuno> well, lets think about it a bit
<beuno> so what if you ship a special USB device, lets say, a sensor
<jdstrand> I'm stating the current implementation
<beuno> over USB
<tedg> jdstrand: The specific use case was galileo who does Fitbit sync, and needs to add the USB IDs for the fitbit dongle.
<jdstrand> I know it is being reworked
<beuno> or tedg's real case
<beuno> ok
<beuno> good
<beuno> I don't think we have anybody on that atm
<jdstrand> I'm not sure who is reworking that
<beuno> actively working on it
<jdstrand> heh
<beuno> :)
<ogra_> but wasnt hw-assign actually meant to solve this
<ogra_> as least in a first shot ?
 * ogra_ doesnt see why it works for webcams or serial USB controllers but not for a fitbit gadget
<jdstrand> the real thing is that you don't want something that is untrusted (ie, an app) interacting with the system in ways that it can break out of confinement without some sort of user/admin interaction
<tedg> I'm not saying it is a today thing, but I do think we need some way to add USB IDs and Bluetooth, etc, etc.
<jdstrand> ie, an admin saying-- ok, you can access this device (fine)
<ogra_> right
<ogra_> and that is what hw-assign works for today
<beuno> so this is assign-and-describe
<tedg> I think that's not a way that the app controls the system as much as saying "if this exists, I'd like to know about it."
<beuno> we're missing the and-describe part, common for USB
<jdstrand> ie, snappy install allows declaring udev but not installing them without the admin (fine, not implemented, just saying a very simple idea)
<tedg> Where "if this exists" could include something the system didn't know about before.
<jdstrand> a gadget saying, this is all the stuff on the system, here are udev rules (fine, where I thought we were going, but being reworked)
<jdstrand> an oem snap saying, these are a bunch of udev rules and snaps that can use them without me doing anything (fine, cause the oem is special)
<jdstrand> but arbitrarily extending udev itself, that hasn't been discussed afaik
<tedg> I think that works for fixed devices that are in production. But it doesn't work for makers who are building something on a Raspberry Pi and want to add functionality.
<jdstrand> no, I understand where you are coming from
<jdstrand> again, just stating thoughts surrounding it
<jdstrand> it sorta sounds to me like a separate gadget snap
<tedg> K, anyway. I imagine that'll have to go on the backlog today. But it was something I just ran into.
<jdstrand> but, idk-- others are (re)defining this
<beuno> jdstrand, also, gadget and oem snap are the same thing, yes?
<jdstrand> well, oem is something that is implemented today. I thought gadget was an evolution of the oem snap
<jdstrand> but perhaps I am wrong on that point
<beuno> I... don't know
<beuno> :)
<beuno> I'm sure mvo does, he knows everything!
<jdstrand> I just hear occasionally that a gadget snap is being used in ways I didn't think an oem snap would be. sergiusens could comment further I'm sure
<jdstrand> yes, or mvo
<jdstrand> it might be possible with sufficient yaml/input validation/templated output to have an app snap declare udev rules for snappy to add to the system
<jdstrand> "these are the product ids" and snappy says "oh, ok, I'll add some stuff to udev so the system knows about it"
<Chipaca> mvo: the sideload framework issue is real
<zyga> Chipaca: which issue?
 * zyga is curious about that
<jdstrand> I would suggest getting p itti in on that conversation though
<mvo> Chipaca: hmmm
<Chipaca> zyga: https://bugs.launchpad.net/snappy/+bug/1493706
<ubottu> Launchpad bug 1493706 in Snappy "side-loading frameworks broken" [Critical,Triaged]
<mvo> Chipaca: is it because of the version number change?
<Chipaca> mvo: let's fix it :)
<mvo> Chipaca: that would be ideal indeed, I was just lazy^Wbusy
<Chipaca> mvo: I don't know where, but i must have forgotten to do the right thing with versions somewhere :)
<zyga> what is the _multi suffix? fat snaps?
<zyga> or just arbitrary string
<Chipaca> mvo: because, yes, it's trying to use a version number it should not know about
<Chipaca> mvo: however
<Chipaca> mvo: let me check wiht a simpler framework first
<Chipaca> mvo: it might be docker doing things wrong :)
<Chipaca> mvo: it's related to servcies
<Chipaca> mvo: "start" is also not doing the right thing, somehow
<Chipaca> mvo: here, you test it: https://public.apps.ubuntu.com/anon/download/canonical/hello-dbus-fwk.canonical/hello-dbus-fwk.canonical_1.0.1_multi.snap
<mvo> uhh
<mvo> ok
<Chipaca> mvo: so
<Chipaca> mvo: something is still taking the version from the package.yaml
<mvo> :(
<Chipaca> mvo: directly
<Chipaca> mvo: instead of through part.Version()
<Chipaca> mvo: found it
<Chipaca> maybe :)
<Chipaca> mvo: i'll have a branch up in a bit
<Chipaca> mvo: figured it out. It's down to origin being empty for frameworks, again
<Chipaca> the sooner we nuke that the better :(
 * Chipaca runs the tests
<Chipaca> mvo: you've got unreachable code in xgettext-go, and my vet complains :)
<mvo> Chipaca: what a crybaby
<mvo> Chipaca: let me fix that, vet gets cleverer each way
<mvo> each day
<Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/always-take-version-from-filesystem/+merge/270988
<Chipaca> mvo: if i were clever i would've noticed it the first time :)
<mvo> :)
 * mvo hugs Chipaca
<zyga> sergiusens: https://code.launchpad.net/~zyga/snapcraft/custom-plugin/+merge/270994
<zyga> sergiusens: early feedback please
<zyga> sergiusens: I've used this to build a few interesting bits
<zyga> sergiusens: most notably missing are build dependency handling
<zyga> sergiusens: and environment sucks (correct me if I'm wrong, this cannot be done without fixing many other things now)
<zyga> sergiusens: example snapcraft.yaml for it: http://paste.ubuntu.com/12410227/
<sergiusens> zyga, you can build a package that depends on snapcraft I guess, but I don't thing we want commands available to do this; the original snapcraft was like this fwiw
<zyga> sergiusens: can you be more explicit, I don't understand what you are saying
<zyga> sergiusens: that explicit commands are bad?
<zyga> sergiusens: or that something else is bad?
<sergiusens> zyga, explicit commands
<sergiusens> zyga, this can be driven by a Makefile in most cases, can't it?
<zyga> sergiusens: yeah, perhaps
<zyga> sergiusens: is there something I can do about the environment part
<zyga> sergiusens: the .replaces() thing is a bit terrible but I didn't find any better ways of doing it
<zyga> hmm, I'm seeing a weird low-level error
<zyga> aa_change_onexec failed with -1
<zyga> has anyone seen this, googling suggests its related to apparmor
<ogra_> well, do you see any apparmor messages in syslog =
<ogra_> ?
<zyga> ogra_: checking
<ogra_> anyway, ask jdstrand or tyhicks
<ogra_> definitely apparmor related
<tyhicks> zyga: you need the errno value set
<tyhicks> zyga: bah, I didn't phrase that correctly.... you need to figure out what errno is set to when aa_change_onexec() returns -1
<zyga> tyhicks: I'm not sure which part applies this, it happens when I run one of the unconfined executables
<zyga> yeah
<zyga> I understand
<zyga> trying to hek
 * zyga would love gdb now
<zyga> ogra_: nothing in syslog
 * jdstrand is guessing the profile isn't loaded without knowing the errno
<tyhicks> yes, that's most likely the problem ^
<jdstrand> zyga: what command are you running?
<zyga> hostapd_cli
<zyga> hostapd works _cli doesn't
<zyga> hostapd_2.4-1_amd64.snap
<zyga> on chinstrap in ~zyga/
<zyga> 333K
<jdstrand> zyga: can you paste what is in /apps/bin/hostapd_cli
<zyga> yep
<jdstrand> tyhicks: I'll take a first look at this
<zyga> (I'm doing this in kvm)
<tyhicks> ok
<zyga> http://pastebin.ubuntu.com/12410753/
<zyga> jdstrand, tyhicks: without the wrapper it works okay
<jdstrand> zyga: can you paste the output of cat /var/lib/apparmor/profiles/click_hostapd.sideload_hostapd_cli_2.4-1
<zyga> cat: /var/lib/apparmor/profiles/click_hostapd.sideload_hostapd_cli_2.4-1: No such file or directory
<jdstrand> zyga: also, please paste the output of: sudo aa-status|grep hostapd
<zyga> so that nails it
<zyga>    hostapd.sideload_hostapd_2.4-1
<jdstrand> well, maybe
<jdstrand> let me look at the snap
<zyga> http://pastebin.ubuntu.com/12410779/
<zyga> look at this, there's one hfor hostapd though
<jdstrand> zyga: http://paste.ubuntu.com/12410801/
<jdstrand> zyga: rename hostapd_cli to hostapd-cli
<jdstrand> I'm quite surprised that snappy build worked let alone snappy install
<jdstrand> seems there is an input validation issue there
<zyga> jdstrand: so the external binary must be hostapd.hostapd-cli
<zyga> jdstrand: and binaries with _ are not supported?
<jdstrand> '_' is not allowed in the pkgname, service/binary name or version
<zyga> jdstrand: ah, fun
<zyga> jdstrand: heh :)
<zyga> jdstrand: thanks!
<jdstrand> np
<zyga> sergiusens: ^^ nothing in snacpraft assemble complained
<jdstrand> tyhicks: fyi-- the outcome ^
<sergiusens> zyga, care to patch the validation thingy?
<sergiusens> zyga, the regex
<zyga> sergiusens: it might be doable in the schema
<zyga> sergiusens: or is there some other validation?
<sergiusens> zyga, it should, I have a regex there; it may be wrong
<sergiusens> and I suck at regex
<jdstrand> is snapcraft written in go?
<jdstrand> cause snappy I'm quite sure has the regex in there
<zyga> sergiusens: hehe
<zyga> sergiusens: no worries, it should be easy
<jdstrand> zyga: but snappy install didn't error?
<jdstrand> that is another bug
<jdstrand> (if it didn't)
<sergiusens> zyga, it is missing the regex for binary name and service name http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/schema/snapcraft.yaml#L46
<sergiusens> a bug or MP would be great
<tyhicks> jdstrand: there is a bug opened for that (I I think I debugged this same problem for someone once while you were on vacation)
<tyhicks> let me look
<jdstrand> sergiusens: fyi, snappy/click.go is wrong: const servicesBinariesStringsWhitelist = `^[A-Za-z0-9/. _#:-]*$`
<jdstrand> sergiusens: '_' should not be in that list
<sergiusens> jdstrand, right
<zyga> sergiusens: I'll do both in a sec, some IRL activities now
<jdstrand> neither should '#'
<sergiusens> zyga, I'll do it, jdstrand just gave me the regex ;-)
<zyga> jdstrand: nope, snappy install (remote) didn't catch it
 * jdstrand looks at click-apparmor regex
<zyga> sergiusens: ehe, okay :)
<zyga> I think there's another bug
<zyga> I'm trying to use exec: hostapd_cli and name: hostapd-cli
<zyga> and it's ignored
<zyga> it derives the name from exec all the time
<zyga> (for the wrapper)
<jdstrand> zyga: exec should point to the file on disk relative to the topdir of the unpacked source
<jdstrand> ah, then yes, that is a bug
<zyga> jdstrand: name with - is ignored?
<zyga> eh :)
 * zyga digs deeper
<jdstrand> I'm saying if snapcraft is handling the '_' to '-' for exec vs name, that is an issue
<jdstrand> isn't*
<zyga> yeah _wrap_binaries is broken
<zyga> jdstrand: it's more than that
<zyga> jdstrand: it's not handling it, it's not checkign it and if you try to tell it explicitly to rename it, it ignores it
<jdstrand> I don't doubt there is more than that
<zyga> jdstrand: so what exactly cannot have _ in it?
<zyga> jdstrand: the wrapper script, the target executable or both?
<jdstrand> 'name'
<zyga> jdstrand: ok
<jdstrand> in either the service or binary yaml
<zyga> jdstrand: so when I have name 'hostapd-cli' and the generated executable wrapper is hostapd_cli.wrapper is that good or bad?
<zyga> it seems bad
<zyga> hmm, but it works
<zyga> weird
<jdstrand> zyga: it probably depends. in and of itself, it is neither-- 'name' is specifically there to reference the binary by another name
<jdstrand> exec is optional
<zyga> sergiusens: http://paste.ubuntu.com/12410981/
<jdstrand> so if you nave: name: bin/foo, then you get /apps/bin/pkgname.foo
<zyga> sergiusens: this is the patch that "fixes" it for me
<zyga> sergiusens: but it's weird
<zyga> sergiusens: and the if makes no sense anymroe
<jdstrand> but if you use exec, you can do this:
<jdstrand> name: foo
<zyga> jdstrand: no, because then name is totally ignored
<jdstrand> exec: bin/foo.wrapper
<jdstrand> and then you get /apps/bin/pkgname.foo
<zyga> jdstrand: I just tried that, but I didn't want to provide my bin/foo.wrapper
<jdstrand> I'm saying how it is supposed to work
<jdstrand> with snappy itself
<zyga> mmm
<zyga> yeah, I understand
<jdstrand> I don't know what snapcraft is trying to do
<zyga> eh, ignore me sergiusens
<zyga> I'm tired
<jdstrand> sergiusens: so the other bug is that snappy install didn't complain when the profile wasn't generated. your regex change will sideste that and I think any other fixes can wait until snappy absorbs click-apparmor
<jdstrand> sidestep*
<jdstrand> $ sudo aa-clickhook -f
<jdstrand> ERROR: Could not parse click manifest. Skipping 'hostapd.sideload_hostapd_cli_2.4-1.json'
 * jdstrand notes 'hostapd_cli' with the '_'
 * Chipaca puts on his chef hat and goes shopping
<jdstrand> sergiusens: ok, so click-apparmor itself isn't terribly picky except for:
<jdstrand> out = n.split("_")
<jdstrand> if len(out) != 3:
<jdstrand>     raise...
<jdstrand> so getting rid of the '_' alone should be ok
<tyhicks> sorry, I got sidetracked with another irc conversation
<tyhicks> yes, that split() was the problem that I debugged, as well
<jdstrand> this all gets back to the application id
<jdstrand> https://wiki.ubuntu.com/AppStore/Interfaces/ApplicationId
<tyhicks> hmm.. I found the old debugging session but it doesn't look like a bug was ever filed :/
<jdstrand> which is something that is pretty deeply ingrained in the system. we could support '_' in the service/binary, pkgname, version if we escaped it. but that would have to be done quite carefully
<jdstrand> tyhicks: well, so, the system is implemented very specifically. snappy isn't handling that right
<sergiusens> tyhicks, jdstrand there https://bugs.launchpad.net/snappy/+bug/1495662
<ubottu> Launchpad bug 1495662 in Snappy trunk "Services and binaries allow _ #" [High,New]
<tyhicks> https://bugs.launchpad.net/snappy/+bug/1470265
<ubottu> Launchpad bug 1470265 in Snappy trunk "Binary with an underscore fails to produce an apparmor profile" [High,Confirmed]
<jdstrand> sergiusens: note, https://wiki.ubuntu.com/AppStore/Interfaces/ApplicationId has regexes
<tyhicks> there are two bugs
<jdstrand> sergiusens: those regexes are in the context of touch of course
<sergiusens> jdstrand, should I keep #?
<zyga> sergiusens: can we resume daily builds on https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily
<zyga> sergiusens: some people are bloked by this
<sergiusens> zyga, in a bit
<jdstrand> sergiusens: I was surprised to see it. it won't break apparmor
<jdstrand> at least, it shouldn't :)
<zyga> sergiusens: what do you mean?
<jdstrand> sergiusens: so, your call
<sergiusens> jdstrand, the tools block it, right?
<sergiusens> jdstrand, if so I will, as it should be safe (store side won't have uninstallable packages)
<sergiusens> click-review-tools that is
<jdstrand> that's true. I'm quite sure they will
<jdstrand> give me a sec
<jdstrand> btw, why didn't the tools run for zyga?
<sergiusens> jdstrand, not sure
<jdstrand>  - lint:hooks_valid:hostapd#cli
<jdstrand> 	malformed application name: 'hostapd#cli'
<jdstrand> so, yes, the review tools will complain
<jdstrand> $ sudo aa-clickhook
<jdstrand> ERROR: Could not generate AppArmor profile for 'hostapd.sideload_hostapd#cli_2.4-1.json'. Skipping
<jdstrand> sergiusens: please remove '#'
<sergiusens> jdstrand, got it
<jdstrand> I bet that regex is coming from easyprof
<jdstrand> yes
<jdstrand>  if re.search(r'^[a-zA-Z0-9][a-zA-Z0-9_\+\-\.:~]+$', s):
<jdstrand>     return True
<jdstrand> return False
<sergiusens> jdstrand, the regex in click.go allows spaces too :-/
<jdstrand> sergiusens: we should remove that too
<jdstrand> not that the regex in easyprof isn't caring about APP_ID
<jdstrand> click-apparmor cares about APP_ID
<jdstrand> (which is correct)
<jdstrand> (ie, easyprof and click-apparmor are at different layers and their respective checks are valid for their respective layers)
<jdstrand> sergiusens: alright, rather than going through all this, how about you fix it and ask me to review?
<jdstrand> sergiusens: fyi, easyprof is as strict as it is to ease quoting and avoid shell metachars
<jdstrand> apparmor itself can have much more in the profile name. if we want to talk about letting other stuff in later, then we can have a discussion about that
<jdstrand> '_' will always have to be handled carefully
<jdstrand> (cause of APP_ID)
<jdstrand> anyhoo
 * jdstrand -> writing docs
<tedg> sergiusens: so to be able to use stage-packages in my plugin I need to add it to /plugin/foo.yaml. Do we want that? Or do we want to include the global stuff automatically?
<sergiusens> tedg, you missed my collisions branch
<tedg> sergiusens: Sorry, never ran into it.
<sergiusens> tedg, https://code.launchpad.net/~sergiusens/snapcraft/collisions/+merge/270942 :-)
 * tedg rimshot
<sergiusens> tedg, more like a sad trombone ;-)
<tedg> LOL, oh, ouch! :-)
<sergiusens> tedg, I also have this which I just noticed I need to wrap into the wrap exe stuff https://code.launchpad.net/~sergiusens/snapcraft/config/+merge/270989
<tedg> sergiusens: Is there some way we can share schema with snappy?
<tedg> sergiusens: Seems like we should be "all they have plus"
<sergiusens> tedg, once we add code to support schemas inside snappy we can
<tedg> Ah, okay. Just want to ensure we don't have more keys like this.
<tedg> Should be able to add them in one place.
<tedg> This setup.py is now using 2.5GB of RAM. Not sure when I should call it.
<tedg> Oh my, it wasn't hung.
<sergiusens> tedg, what are you building?
<tedg> sergiusens: nova
<tedg> But it seems to be hardcoding the path to the python interpreter.
<tedg> Which surprised me.
<tedg> I'll have to play with it more later though. Need to go play the trophy husband for a bit.
<pindonga> hi, I have built a snap package that is failing automated reviews, but some of the checks contradict the docs (eg, snappy-systemd_package_yaml_ports_lp_format)
<pindonga> anyone around to help me understand how to improve the snap package?
#snappy 2015-09-15
<fgimenez> good morning
<dholbach> good morning
<mvo> fgimenez, Chipaca, ricmm: image r152 should be good for testing
<fgimenez> mvo, ok thanks, on it
<fgimenez> mvo, 147 for armhf, right?
<mvo> fgimenez: I have not build a armhf image with the latest snappy for 15.04 yet, I started that some minutes ago, wanted to verify on amd64 first
<mvo> and there were a bunch of integration issues, but hopefully all good now
<fgimenez> mvo, ok
<mvo> fgimenez: there a some version (r151, r150) that are broken and will not work with system-image-cli correctly, just fyi when you do rollback testing
<fgimenez> mvo, ok, should it work from r149?
<mvo> fgimenez: yeah, that sounds good, from the latest you have faith in :)
<mvo> fgimenez: to r152 or later and it should be good
<fgimenez> mvo, :) ok i'll let you know how it goes
<mvo> thanks
<Chipaca> mo'in, whippersnappers!
 * Chipaca adds a "whipper" subcommand
<mvo> hey Chipaca - new 15.04 is ready
<Chipaca> mvo: so i hear :) congrats
<Chipaca> mvo: i also hear it's been painful
<mvo> thanks, was a hard fight
<Chipaca> mvo: there is go generate in 1.4
<Chipaca> mvo: 15.04 has go 1.3
<Chipaca> oh dear
 * Chipaca is pedantic today
<mvo> yeah
<mvo> meh
<JamesTait> Good morning all; happy Tuesday, and happy International Dot Day! ð
<Chipaca> mvo: wait, it worked with xreadPassword and not with readPassword?
<Chipaca> or am i misunderstanding somehting
 * ogra_ notes that mvo did quite some imae builds :)
<mvo> Chipaca: yes
<mvo> Chipaca: thats exactly it, I still have not tracked that down, but will soon
<fgimenez> mvo, rolling back from 153 to 149 doesn't seem to work http://paste.ubuntu.com/12416211/
<mvo> fgimenez: hrm hrm hrm
 * mvo tries to reproduce
<ogra_> mvo, more kids ? oO
<Chipaca> JamesTait: â¡§â¢¼â¡®â¢µâ¡¯â¡¯â¢±â   â£â â¢â¡±â¢¹â â ®â¡²â¡
<ogra_> (and you really dont need to tell us)
<JamesTait> Impressive, Chipaca!
<Chipaca> JamesTait: sorry for not even trying to write "international" :)
<Chipaca> ogra_: maybe we should tell him about getting off irc for that, also
<ogra_> Chipaca, true true ... germans ... tsk
<Chipaca> ogra_: ooh! did you know "tsk" and "tut" are american and british ways of writing the same ("dental click") sound?
<ogra_> hah, nope :)
<Chipaca> me neither
<Chipaca> https://en.wikipedia.org/wiki/Dental_clicks
<ogra_> heh, that page makes me wanting to do a handstand to read it
<ogra_> all that phonetic upside down stuff :)
<mvo> fgimenez: r152->153->152 seems to work, I'm downloading 149 now
<ogra_> looks like my amd64 installed system  has properly updated from 148 to 151 via autopilot over night :)
<fgimenez> mvo, ok i'll try that path too, the integration suite is passing on 153
<fgimenez> but including fake updates, i'll try it now with real updates and executing from a rollback
<Chipaca> mvo: we don't need https://code.launchpad.net/~mvo/snappy/15.04-services/+merge/270965 now do we?
<mvo> Chipaca: indeed, no
<Chipaca> mvo: https://code.launchpad.net/~mvo/snappy/snappy-lp1490574-systemd-type-forking/+merge/270142 could use a bit of love
<mvo> fgimenez: I think I found the issue, for some reason the boot-ok job seems to have not triggered
<mvo> Chipaca: will do once I found the root cause for the rollback problem
<Chipaca> ayup
<mvo> pitti: did anything change between vivid and wily re "After=multi-user.taget"? I changed the ubuntu-snappy.boot-ok.service to have after=multi-user.target and that appears to be fine in wily (I can see that the service gets started and the output in wily but on vivid I don't see it starting, just that its active
<pitti> mvo: "active" means that it started -- perhaps you mean "enabled"?
<pitti> mvo: nothing wrt. After=, Requires= or enablement changed, but maybe the enablement link somehow got dropped in vivid?
<mvo> pitti: http://paste.ubuntu.com/12416363/ is what I see on vivid
<pitti> mvo: can you pastebin the journal?
<fgimenez> mvo, great! thanks :) the rest of tests seem to be fine so far
<pitti> mvo: that's not affected by the "too late bind mounting" issue, right? (as /etc/systemd/ gets bind-mounted in initramfs already0
<mvo> pitti: yeah, it gets bind mounted early
<mvo> pitti: http://paste.ubuntu.com/12416373/
<pitti> mvo: systemctl cat ubuntu-snappy.boot-ok.service
<pitti> mvo: find /etc/systemd -name '*boot-ok*'
<pitti> mvo: nevermind
<pitti> Breaking ordering cycle by deleting job ubuntu-snappy.boot-ok.service/start
<mvo> pitti: ohhh
<mvo> pitti: \o/
<pitti> mvo: so cat'ing the unit would help
<ogra_> pitti, just FYI https://launchpadlibrarian.net/217937303/initramfs-tools-ubuntu-core_0.7.7~ppa6_0.7.7~ppa7.diff.gz
<mvo> pitti: http://paste.ubuntu.com/12416384/ <- its the wantedby=gettey, right?
<mvo> hm, no
<pitti> ogra_: nice!
<ogra_> pitti, i'm considering moving all the bind mounts to that next iteration
<mvo> ogra_: I was wondering about this too, I don't think it matters much but why have two places if one is sufficient
<ogra_> right
<pitti> mvo: ah, yes indeed -- getty.target wants boot-ok, but this runs after multi-user; maybe newer versions accept this kind of mixed wants/after cycle, but not yet vivid's?
<pitti> mvo: or do you get a different cycle on wily, and it's just pure luck?
<ogra_> and who knows what other races we might cause by mounting half of them later
<mvo> pitti: yeah, now I just need to figure out what Install synatx to use instead of getty.target
<pitti> ogra_: do we have fsck of the /writable partition in initramfs?
<pitti> mvo: multi-user.target doesn't work?
<mvo> we do
<mvo> pitti: simply wantedby=multi-user.target ? or removing the wantedBy entirely?
<ogra_> pitti, yeah, a few lines before the function above gets called
<pitti> mvo: no, WantedBy=multi-user.target instead of getty.target (not sure why it's getty)
<mvo> cool, will do
<mvo> probably a historic accident
<mvo> i.e. not talking to the right people :-D
 * mvo hugs pitti
<ogra_> pitti, http://paste.ubuntu.com/12416406/ ... handle_writable_paths does the mounting
<ogra_> the mount/umount to speed up e2fsck is a funny trick
<ogra_> (and works really well)
<dholbach> tedg, do you know what's happening here? https://bugs.launchpad.net/snapcraft/+bug/1495525
<ubottu> Launchpad bug 1495525 in Snapcraft "qml plugin: example is broken" [Undecided,New]
<mvo> Chipaca: I woder if the rollback issue could be releated to the new static grub.cfg
<Chipaca> oh!
<Chipaca> maybe?
 * mvo looks deeper
<Chipaca> mvo: i'd suggest waiting for sergio on that one, as he'd know without looking :)
<Chipaca> it's possible we said "no rollback from this change"
<Chipaca> but i think the new static grub should deal with it as long as there's a versionless symlink
<Chipaca> which there used to be, at leastr
<mvo> Chipaca: hmm, looks like we have the old non-static grub.cfg in /boot/grub/grub.cfg :(
<Chipaca> mvo: woo :-p
 * guest42315 aw-food
<mvo> Chipaca:  http://paste.ubuntu.com/12416556/ <- not looking great
<ogra_> mvo, uuh Bug 1495688 i see that too here (seems we have more fish to fry )
<ubottu> bug 1495688 in Snappy "system-image-cli tool fails on rolling/edge; missing file '/etc/system-image/config.d/00_default.ini" [Undecided,New] https://launchpad.net/bugs/1495688
<Chipaca> ogra_: there's a dangling symlink
<ogra_> hmm, not related to recent changes though ... my RPi image from sept. 2 has it too
<ogra_> Chipaca, yes, but why
<ogra_> it should ship client.ini
<ogra_> aha
<ogra_> should come from system-image-common
 * ogra_ checks the manifest 
<mvo> Chipaca: so we may need this services backport branch afterall
<ogra_> hmm
<ogra_> system-image-common is installed in the latest image
<ogra_> oh
<Chipaca> mvo: D:
<ogra_> my phone only has system-image 2.5.1 ... snappy has 3.0.1 ... (both on vivid)
<Chipaca> mvo: can we ship an override to update-grub that does something useful?
<Chipaca> ohh
<Chipaca> mvo: we're calling the _old_ update-grub on update?
<Chipaca> or are we calling the new one?
<mvo> Chipaca: we call the new one, maybe this could work http://paste.ubuntu.com/12416613/
<mvo> Chipaca: or simpler, we make the new update-grub write the static config and loose the ability to rollback (because the kernel will not be in /boot/grub/b
<mvo> )
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/fix-for-empty-stage_packages-in-plugins/+merge/271090
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/small-typo/+merge/271086
<Chipaca> mvo: maybe we can make a release note about rollback not working
<mvo> Chipaca: just making 09_snappy write the new static conf and stop would be ideal, least risky option but no rollback
<ogra_> mvo, oh ... do we need to seed system-image-snappy-common ?
<mvo> ogra_: why?
<ogra_> mvo, system-image-common does not ship any client.ini file anymore
<ogra_> and i also assume we want the client.ini for snappy, not the phone one
<mvo> ogra_: we can ship it in ubuntu-core-config then
<mvo> ogra_: and we actually should do that already as 20_snappy iirc
<ogra_> fine with me too ... currently system-image-cli only throws exceptions
<ogra_> (on 15.04 edge that is)
<mvo> ogra_: system-image-cli -v work for me on 154 (I also see the broken symlink)
<ogra_> mvo, and -i ?
<mvo> ogra_: that explodes indeed
<ogra_> -v gets me a ton of permission denied errors (it shoudlnt)
<ogra_> hmm, ignore that ... happens on the phone too
<ogra_> i thought that uses the dbus backend so it doesnt need sudo
<fgimenez> mvo, should i file a bug about the rollback issue?
<mvo> fgimenez: a good question, I think its understood, the hard questions is now what to do about it
<sergiusens> dholbach, thanks for the branches!
<sergiusens> dholbach, btw, have you read the new intro? I hope it is to your liking ;-)
<ogra_> workarounds for bug 1495688 and bug 1495683 uploaded
<ubottu> bug 1495688 in Snappy "system-image-cli tool fails on rolling/edge; missing file '/etc/system-image/config.d/00_default.ini" [Undecided,New] https://launchpad.net/bugs/1495688
<ubottu> bug 1495683 in Snappy "Drop /etc/profile.d/Z99-cloud-local-test.sh from Cloud target" [Undecided,New] https://launchpad.net/bugs/1495683
<sergiusens> ogra_, they are called fixes ;-)
<ogra_> lol
<dholbach> sergiusens, the google doc or updated docs in the branch?
<sergiusens> dholbach, http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/docs/your-first-snap.md
<dholbach> sergiusens, great - I'll check it out - thanks a bunch!
<sergiusens> dholbach, I need to add a config walkthrough and extend that more (to get a bit more of a complicated example) ;-)
<sergiusens> dholbach, but it has all the new stuff trunk has already
<dholbach> sergiusens, what's still on your list for the 0.2 release?
<sergiusens> dholbach, I think we are good to switch already
<sergiusens> dholbach, well, I want my config branch in and to extend the docs
<dholbach> ok cool
<ogra_> mvo,  triggering an image to make sure the file removals worked
<dholbach> just asking to get an idea of what's planned :)
<sergiusens> dholbach, soon after comes an interesting feature ;-)
<dholbach> sergiusens, which one
<dholbach> ?
<Chipaca> anybody got a snap with an invalid yaml lying around?
<Chipaca> wanting to test some error reporting
<Chipaca> elopio: fgimenez: you, by chance? ^
<sergiusens> Chipaca, just unpack and repack ;-)
<Chipaca> sergiusens: how do i repack? trying with "ar" i can never get it to work
<fgimenez> Chipaca, there's an integration test for that, but iirc it generates the wrong yaml on the fly, let me check
<Chipaca> and snappy build won't let me build a broken one :)
<ogra_> Chipaca, ar and snappy build indeed
<ogra_> oh
<Chipaca> i'm wanting to build a snap with an *invalid yaml* :)
<Chipaca> snappy build is not down with that
<ogra_> yeah, only read the last line after typing
<Chipaca> i can build subtly broken ones, but not "aiee yaml parser kaput" broken ones
<Chipaca> and that just happens to be an error case unlike others
<sergiusens> Chipaca, I thought dpkg-deb would do the trick
<Chipaca> in that it's a 500 error, from a yaml, in an async handler
<Chipaca> trying dpkg-deb...
<fgimenez> Chipaca, sorry nope, the test just check that actually you can't build it http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/tests/build_test.go#L75
<Chipaca> fgimenez: sergiusens: ogra: dpkg-deb -R, and dpkg-deb --nocheck -b, do the trick
<Chipaca> http://pastebin.ubuntu.com/12417202/
<Chipaca> \o/
<Chipaca> ^ that's what the rest api thinks of you having a fortune instead of yaml
<Chipaca> (that's with my still in-progress "give context to errors" branch)
<sergiusens> Chipaca, \o/
<ogra_> hmm
<ogra_> neither /etc/system-image/config.d/00_default.ini nor /etc/profile.d/Z99-cloud-local-test.sh seem to exist at build time (i see the sccript to remove them being executed during build but it doesnt rm any files)
<ogra_> i wonder where they come from if not the build
 * ogra_ twiddles thumbs waiting for the importer 
<dholbach> davidcalle, which articles were you working on?
<dholbach> davidcalle, is there any stuff which should go into the individual branches? or will it be just for developer.u.c?
<Chipaca> darn, yesterday i was able to make the yaml parser panic, but today i can't reproduce it
<Chipaca> should've written down the yaml
<davidcalle> dholbach, not me directly, but some new snappy doc being written. Just duc :)
<dholbach> ok
<davidcalle> not *by me
<tedg> dholbach: No, are you on vivid? Perhaps things changed in wily.
<dholbach> tedg, I'm on wily, yes
<dholbach> tedg, would it make sense to let qml snaps just depend on ubuntu-sdk-libs?
<tedg> dholbach: No, not really. The SDK requires a lot more than we can support today.
<dholbach> ok, I was just wondering it we could simplify the list of packages in snapcraft/plugins/qml.py somehow
<rickspencer3> does anyone know what I need to do figure out what to hw-assign so that my snap can use gpio pins on the rpi2?
<rickspencer3> jdstrand, ^ ?
<rickspencer3> apparmor only reports net_admin getting denied
<ogra_> sigh !
<mvo> sergiusens, Chipaca: do you think https://code.launchpad.net/~mvo/snappy/snappy-all-for-15.04 covers the bases? I want to tidy it a bit more and I think its good but a second opinion from an expert would be great
<ogra_> (amd64)ogra@aleph2:~$ ls -l /etc/system-image/config.d/00_default.ini
<ogra_> lrwxrwxrwx 1 root root 13 Sep 15 15:26 /etc/system-image/config.d/00_default.ini -> ../client.ini
<ogra_> (amd64)ogra@aleph2:~$
 * ogra_ doesnt get where it comes from, it doesnt seem to exist at rootfs build time 
<sergiusens> mvo, you don't like asking questions with simple answers, eh? :-)
<Chipaca> mvo: i agree, we need an opinion from an expert.
<Chipaca> mvo: we're going to have to go find one
<mvo> lol
<ogra_> do we have spare headcount to hire one ?
<ogra_> job description "expert"
<mvo> I think its good, it just needs its own (blocking) systemd-job to ensure everything is in place before the user can hit the commandline
<ogra_> GRRR ... so calling [ -e ... ] on a dangling symlink isnt the cleverest of things
<tedg> dholbach: I think it does make sense to do some sort of meta-package, but the SDK has too much other stuff in it.
 * ogra_ switches to -L
<mvo> ogra_: if you have spare cycles, system-image.ubuntu.com//pool/device-f6dbcd89372ad1bd2b6a37df25b2e02fae38530d92c9ebd541bf327c27048794.tar.xz has also some danling symlinks in assets/vmlinuz
 * mvo dives back into grub
<dholbach> tedg, I thought ubuntu-sdk-libs was just the stuff phone apps could know to expect around
<ogra_> ARGH !
<Chipaca> mvo: that code seems correct, but i'd test it all the ways
<ogra_> copy pasting a filename with typo out of a bug report isnt so clever either
 * ogra_ should take the day off 
<tedg> dholbach: Sure, but we don't want all of those things for a QML snap. We can't provide all the services that they require. That's gotta be provided by the U8 framework.
<dholbach> ok
<rickspencer3> jdstrand, could you take a look and let me know why I am seeing the denial here, considering what is in my apparmor profile?
<rickspencer3> http://pastebin.ubuntu.com/12417599/
<jdstrand> rickspencer3: sorry, in a meeting
<jdstrand> be bak in a minute
<rickspencer3> k
<jdstrand> ok, back
<jdstrand> rickspencer3: instead of /sys/devices/platform/soc/3f200000.gpio, use /sys/devices/platform/soc/3f200000.gpio/**
<ogra_> ok ... since all good things in life are three ...
 * ogra_ triggers the third image for that file removal stuff
<rickspencer3> ok, I'll try that
<rickspencer3> jdstrand, the only difference is the *?
<rickspencer3> because I am still seeing the denial
<rickspencer3> jdstrand, I just added /* to the app armor profile and reparsed it
<rickspencer3> I didn't do hw-assign again
<ogra_> it is /** not /*
<jdstrand> rickspencer3: use '**'. not '*'
<jdstrand> s/\.//
<rickspencer3> oops, text wrapping in xchat :/
<jdstrand> but yes
<jdstrand> the /sys/devices/platform/soc/3f200000.gpio/** means 'everything under (but not including) /sys/devices/platform/soc/3f200000.gpio'
<mvo> pitti: I assume "before=multi-user.target" and "wnatedby=multi-user.target" is safe and will ensure my service has finished before a user can login?
<fgimenez> ogra_, with these changes https://code.launchpad.net/~fgimenez/snappy/resize_test2/+merge/271131 the resize test works (and passes) on 15.04, r155 :)
<ogra_> fgimenez, yay
<mvo> ogra_: http://paste.ubuntu.com/12417786/ should hopefully fix the broken symlinks in assets/ that I saw earlier. its basicly just a forward port of the wily code, but a second pair of eyes would be great
<ogra_> mvo, can we copy the config too if we copy abi  and System.map ?
<mvo> yeah
<ogra_> mvo, looks fine otherwise
<ogra_> i still fight with /etc/system-image/config.d/00_default.ini :(
<ogra_> i dont get why
<pindonga> mvo, hi there, remember that bug about supporting forking services in systemd unit files? I saw the mp pending review... is there anything blocking that?
<mvo> just lack of tme, shoud land rsn
<pitti> mvo: before/wantedby is the usual combination indeed
<pitti> mvo: but stuff in multi-user.target can happen after gettys; if you strictly want "before users can log in", you want Before=systemd-user-sessions.service (WantedBy=multi-user.target is still okay)
<pitti> mvo: the thing that seems to cause loops/trouble is if you order (After=) a service *past* a target it's wanted in; before is always fine
<mvo> thanks
<clobrano> hi there, I'm looking for info sources about installing udev rules in snappy (other than using hw-assing). Any suggestion? :)
<pindonga> mvo, ack, thx
<sergiusens> Chipaca, mvo dholbach https://code.launchpad.net/~sergiusens/snapcraft/wiki/+merge/271140
<fgimenez> ogra_, on bbb i'm getting this while executing the resize test http://paste.ubuntu.com/12417958/
<fgimenez> ogra_, this is the script used http://bazaar.launchpad.net/~fgimenez/snappy/resize_test2/view/head:/_integration-tests/scripts/install-test-initramfs
<ogra_> fgimenez, thats not the initrd
<ogra_> you want the one under /boot/uboot
<fgimenez> ogra_, ok i'll fix that, thanks! :)
<dholbach> sergiusens, replied
<sergiusens> dholbach, thanks, replied (I wasn't part of the discussion either fwiw) :-)
<dholbach> :)
<dholbach> sergiusens, the summary of the example package is still a bit weird, but apart from that it looks good to me
<sergiusens> dholbach, oh, if you have a better suggestion; just go ahead :-)
<dholbach> maybe I just don't understand it :)
<dholbach> sergiusens, is it meant to say "downloader"?
<dholbach> or "downloaded"?
<dholbach> I mean I'm nitpicking - the rest looks fine AFAICT :)
<sergiusens> dholbach, yeah, the package name is downloader and it downloads from the wiki to create it
<sergiusens> dholbach, I should of not worked on a downloader snap for this I guess :-)
<sergiusens> dholbach, oh, but now I see the typo
<dholbach> <3
<sergiusens> :-)
<sergiusens> dholbach, now that's fixed
<dholbach> sergiusens, approved
<fgimenez> Chipaca, is this a good source of info for integration tests of the api http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/daemon/api_test.go ? is there anything else not covered there?
<mvo> pitti: hi, sorry for bothering you again, I added a new service to snappy, its configured exactly like the boot-ok service and yet http://paste.ubuntu.com/12418278/
<pitti> mvo: any cycle in the journal? can you please cat the unit?
<mvo> ogra_: more ininitramfs troubel it seems, /etc/systemd/system is a writable path, it contains a symlink in getty.target.wants to boot-ok which I removed from the image but because its a writable path with transition the file is never removed
<pitti> mvo: ah, but this one is disabled too -- did you actually systemctl enable (or update-rc. enable) it?
<mvo> pitti: http://paste.ubuntu.com/12418301/ is the journal
<ogra_> mvo, yeah, what i said during the meeting :)
<ogra_> we dont have any way to remove such files yet
<mvo> ogra_: I bet thats the same issue for migrate-grub, its a new file in multi-user.tar.get.want but its not copied up too
<pitti> mvo: ah, so I suppose that's related to "can't remove symlinks"?
<mvo> pitti: http://paste.ubuntu.com/12418313/
<pitti> mvo: I suppose you just didn't enable this then?
<mvo> pitti: yeah, I think its exactly this, /etc/systemd/system/multi-user.target.wants is in mode "transitional" but after the initial copy I think it never updates new files or deletes files so we are lost
<mvo> pitti: it should be enabled via the deb, let me double check
<ogra_> \o/ ...
<ogra_> ok, the most recent rootfs only has 20_snappy.ini in the system-image/conf.d dir
<mvo> pitti, ogra_: so the image has the new ubuntu-snappy.grub-migrate.service but the bind mount over it hides it. thats pretty terrible if we can not add or change job and that we can't fix bugs like that there is a wrong getty.target.wants
 * mvo scratches head
<ogra_> hmm, did you try setting the dir to sync instead of transition ?
<ogra_> (and reboot)
<mvo> ogra_: I cross all fingers that I have
<ogra_> well, else we need a hack in initrd
<ogra_> actually it might be cool if we could use rsync instead of cp in that code ... that might fix some issues
<mvo> ogra_: no, synced does not help at all :/
<ogra_> :(
<seb128> mvo, you noticed that the snappy update in wily is depwait on goget-ubuntu-touch which depwait on golang-uboot-go-dev?
<mvo> ogra_: hm, looking at the source synced should work, it should at least make my files appear
<ogra_> yes
<ogra_> mvo,  even transition should work
 * ogra_ doesnt get it 
<ogra_> i wonder if we could force it with an extra "cp -u $redaonly-dir $writable-dir"
<mvo> ogra_: so /etc/systemd/system/getty.target.wants/ubuntu-snappy.boot-ok.service needs to go and /etc/systemd/system/multi-user.target.wants/ubuntu-snappy.{grub-migrate,boot-ok}.service must appear
<ogra_> mvo, yeah, not sure how we should do that ... it seems to never update anything actually
<ogra_> mvo, if i unmount the dir i also see a webdm service that got never copied
<mvo> ogra_: yeah, I'm not suggesting to hack it, jsut do document the issue
<mvo> ogra_: pretty alarming
<ogra_> yes
<cyphermox> ogra_: ricmm: could you please let me know when we have a rolling image with fwupdate included?
<cyphermox> we'd shoud probably include fwupd too.
<cyphermox> zomg, I can't type.
<ogra_> whats that ?
<ogra_> (firmware ? firewall ? )
<ogra_> (funny witches)
<cyphermox> firmware.
<cyphermox> disregard fwupd for now since it's not even in Debian.
<ogra_> heh
<ogra_> cyphermox, thats for bluez ?
<cyphermox> no. it's for firmware updating magic in the EFI specification
<cyphermox> as in, permanent updates :)
<ogra_> ah, shudder ,... you said EFI
<cyphermox> it's the future.
 * ogra_ pets uboot 
 * cyphermox kicks uboot :)
<ogra_> hey !
<ogra_> :)
<ogra_> our grub setup is closer to uboot than to anything else nowadays :)
<sergiusens> \o/
<ogra_> \o/
 * ogra_ joins the yoga class
<cyphermox> ogra_: you can do some very cool magic with grub and EFI.
<ogra_> nah, i cant :)
<ogra_> but i can do some very cool magic with uboot :)
<cyphermox> ok then, I can :)
<ogra_> heh
<ogra_> yeah, and i'm happy i know whom to poke if it comes to grub ;)
<ogra_> tough in regard to snappy ...
<ogra_> (amd64)ubuntu@localhost:~$ wc -l /boot/grub/grub.cfg
<ogra_> 54 /boot/grub/grub.cfg
<ogra_> we dont really have much there :)
<ogra_> (static file btw)
<cyphermox> feel free to ask me
#snappy 2015-09-16
<dholbach> good morning
<fgimenez> good morning
<mvo_> hey fgimenez, good morning
<fgimenez> hi mvo_
<mvo_> no new good image yet that fully does the upgrade,rollback,upgrade dance, but except for this the most recent one should be good to test
<mvo_> and a new image is in the works that hopefully fixes upgrade/rollback/upgrade/rollback
<p_lorenz> hi - is there a way to redirect the snappy cli tool to an own server infrastructure? i work for a company which would like to host own snaps and system updates
<fgimenez> mvo_, ok thanks, i'll execute the tests against the latest one
<clobrano> good morning
<clobrano> I was looking for info about installing udev rules in snappy (other than using hw-assing). Any suggestion? :)
<clobrano> a link to any kind of documentation will be great
<Chipaca> mo'in
<Chipaca> clobrano: i don't think that exists; what's your use-case? (that is: what do you want to achieve?)
<clobrano> Chipaca, in our application, we often create symlink to device nodes that respect some regex
<clobrano> like matching vid/pid pair
<clobrano> I saw that the example here https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ that include a udev rule in the package.yaml, is there something already available for other udev rules?
<Chipaca> clobrano: I don't think there is, at the app level, something for that. I suspect what you want to do goes in a gadget snap, not an app snap
<Chipaca> clobrano: ogra_ probably knows more, but he was up very late fighting with some regressions in the next release :)
<clobrano> Chipaca: ok, do not worry :) you already gave me a starting point; I didn't know about "gadget snap" :D
<mvo_> fgimenez: r165+ should be ok, I did a 165->166->165->166 successfully now
<p_lorenz> Chipaca: thanks for your mail :) which nickname does MartÃ­n have in IRC?
<fgimenez> mvo_, ok thanks i'll try that now
<mvo_> thanks
<Chipaca> p_lorenz: beuno
 * mvo_ tries a full upgrade instead of delta now too
<p_lorenz> Chipaca: thanks a bunch!
<Chipaca> p_lorenz: no worries
<zyga> mvo_: I'd like to add snapcraft --version
<zyga> mvo_: would you merge that?
<Chipaca> zyga: snapcraft, or snappy?
<mvo_> zyga: sure, unless sergio disagrees thats fine
<Chipaca> zyga: if snapcraft, ask sergiusens :)
<Chipaca> zyga: also probably not today
<zyga> Chipaca: snapcraft
<zyga> Chipaca: what's going on today?
<Chipaca> zyga: busy busy busy
<Chipaca> zyga: like yesterday, but more so
<mvo_> Chipaca: more so? *meeeh*
 * ogra_ phears that 
<Chipaca> mvo_: same pressure, more tiredness -> more mistakes -> moar busy
<ogra_> moaning :)
<zyga> Chipaca: I know the feeling
<ogra_> clobrano, there is no way to "ship" a udev rule, the rule you see in the example is generated by the hw-assign command
<mvo_> Chipaca: logical. flawlessly logicalâ¦
<Chipaca> mvo_: https://www.youtube.com/watch?v=THNPmhBl-8I&t=1m55s
 * Chipaca links to the punchline of a very long joke
 * Chipaca is obviously also not in tip-top form today :)
<mvo_> Chipaca: hehe
<clobrano> ogra_: ok, so is there a way to add custom udev rule? Or is it something yet to be added to snappy?
<JamesTait> Good morning all; happy Guacamole Day! ð
<ogra_> i dont think that is planned ... the hw-assign tool will be expanded and perhaps also changed ... and you can define a device (and a snap it uses) in the gadget (today it is called oem) snap
<clobrano> ogra_: uhm, I understand. Well, it will be great if hw-assign would be flexible enough to allow symlinks too :)
<ogra_> clobrano, worth filing a bug i guess :) so the implementers know about that
<clobrano> ogra_: I was more in the mood of contributing if possible :D, btw I will start with the feature request ;), Thank you, I understood that you all are very busy those days :)
<ogra_> clobrano, hw-assign is maintained by our security team, talk to tyhicks or jdstrand once they are around (i think both are in US timezones)
<ogra_> i agree it would be nice to be able to define a symlink name via hw-assign so you can use self picked device names in your snap
<clobrano> ogra_: yep, that was what I thought :)
<davmor2> hey guys in wily trying to create a snappy personal image is failing http://paste.ubuntu.com/12425581/  I'm assuming that the issue is it doesn't wait for everything to be downloaded before it starts the image creation process.
<ogra_> davmor2, it can do that in parallel ... what it creates is an empty image, then it copies stuff inside
<ogra_> so the order shouldnt matter
<ogra_> do you have enough free diskspace ? IIRC personal is quite big
<davmor2> ogra_: 756GB of free space and it installed fine on vivid only had this issue since I tried using it on wily
<ogra_> ah, u-d-f 0.30 landed yesterday ... that might have broken it ... try going back to 0.29
<ogra_> ricmm, ^^^ :)
<ogra_> might be that the image needs some extra changes to work with the new u-d-f
<ogra_> blame sergio ;)
<ricmm> ah :) indeed
<ricmm> davmor2: sadly will need to wait for sergio to wake up
<ricmm> davmor2: wait that error is something else
<ricmm> davmor2: reboot your machine ;)
<ricmm> and try again
<davmor2> ricmm: will do after this meeting
<dholbach> sergiusens_, can we turn off the plainbox tests which need internet access during the build?
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/1496363/+merge/271285
<sergiusens_> dholbach, yeah, we need to make those autopkg ones
<Mikaela> dholbach: you might be interested in https://freenode.net/sasl
<dholbach> mh
<dholbach> sergiusens_, in which cases is the wiki plugin going to be used?
<sergiusens_> dholbach, when used in 'after' and the ref'ed part is not there
<dholbach> sergiusens_, ok... I was just surprised how often during the build wiki.u.c was trying to be opened: http://people.canonical.com/~dholbach/tmp/snapcraft_0.2_amd64.build
<sergiusens_> dholbach, or when a part is there but doesn't specify a 'type'; for which the full part definition will be pulled from the wiki and the local definition would overlay it (in python part_from_wiki.update(part_local)
<sergiusens_> dholbach, hmm, should be only once; maybe I can initialize it earlier
<dholbach> sergiusens_, shall I file a bug?
<sergiusens_> dholbach, sure
<dholbach> cool will do
<sergiusens> Chipaca, what is the python way for http://golang.org/pkg/sync/#Once.Do ?
<dholbach> https://bugs.launchpad.net/snapcraft/+bug/1496381
<ubottu> Launchpad bug 1496381 in Snapcraft "wiki.u.c is opened a lot during the build" [Undecided,New]
<Chipaca> sergiusens: a "once" decorator
<sergiusens> Chipaca, of course :-)
<Chipaca> sergiusens: http://pastebin.ubuntu.com/12426544/
<Chipaca> sergiusens: definitely not this: http://pastebin.ubuntu.com/12426580/
<sergiusens> Chipaca, no, I prefer easily readable code
<Chipaca> :)
<sergiusens> thank you very much
<sergiusens> :-)
<sergiusens> Chipaca, the write less characters thing is only for play :-P
<Chipaca> sergiusens: disadvantage of the decorator is that the decorated function won't complain about bad number of args
<Chipaca> sergiusens: that is
<Chipaca> if f(a)
<Chipaca> and the first time you call f(1)
<Chipaca> and the second, f(1,2)
<Chipaca> the second will just work
<sergiusens> Chipaca, that's fine, it's an internal decorator
<Chipaca> k
<jdstrand> ogra_: fyi, I wouldn't say the security team is maintained by us-- we didn't even implement it :) we did have input to get something going, but others are refining it. the only thing we care about is that hw happens, somehow, in a separate step
 * ogra_ notes down ... the security team isnt maintained by the security team
 * ogra_ grins 
<jdstrand> as for symlinks, that will be interesting because apparmor resolves symlinks (it must)
<jdstrand> haha
<jdstrand> s/the security team/hw-assign/ :)
<ogra_> you mean hw-assign i guess :)
<ogra_> jdstrand, well i think it might be convenient to allw hw-assign to have options like --symlink-name ... or --exec-script (which would be a script running under confinement inside your snap indeed)
<jdstrand> but actually, we are using cgroups for hw-assign currently
<ogra_> you dont generate the udev rule anymore ?
<jdstrand> I'm happy to review the mp
<jdstrand> there are different parts of it
<clobrano> jdstrand: hi, I was the one interested in symlinks :D, any hope to have the ability to create some? :)
<jdstrand> it has not changed since april
<jdstrand> oem snaps (gadgets) may provide udev rule snippets via the 'assign' yaml which can tag devices
<jdstrand> that tag is then used to add the device to a cgroup
<clobrano> jdstrand: yep, I saw something in the webcam example
<jdstrand> otoh, I don't see why snappy in this situation: 'snappy hw-assign foo /dev/symlink' couldn't resolve the symlink and tag the device in the same manner
<clobrano> interesting
<jdstrand> someone would 'just' need to implement that
<jdstrand> (fyi, you can read about the current implementation here: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Cgroups)
<clobrano> how open is the project for contribution from outsiders? :)
<clobrano> I mean, I can try and do that?
<jdstrand> I suggest filing a bug. Note, how hw assignment works is bieing redone aiui, but I don't know who is doing it
<jdstrand> clobrano: it is completely open :)
<clobrano> Nice to hear that, I've already filed a bug (https://bugs.launchpad.net/snappy/+bug/1496319) and I think I'll have a look at that feature
<ubottu> Launchpad bug 1496319 in Snappy "Could not create custom udev rules" [Undecided,New]
<jdstrand> clobrano: I'm going to direct you to mvo_ for how to contribute processes, but essentially, check out a branch, do your work and then push it to launchpad and request an mp. perhaps a patch on the list would be accepted
<jdstrand> lp:snappy
<jdstrand> https://launchpad.net/snappy
<jdstrand> https://code.launchpad.net/~snappy-dev/snappy/snappy
<clobrano> perfect, thank you
<jdstrand> I'll comment in the bug
<clobrano> jdstrand: great
<dholbach> sergiusens, shall I file a separate bug for separating tests from build? (https://launchpadlibrarian.net/218099126/buildlog_ubuntu-wily-amd64.snapcraft_0.2-0~168~ubuntu15.10.1_BUILDING.txt.gz)
<sergiusens> dholbach, sure
<dholbach> will do
<jdstrand> clobrano: to get the full picture, you might also want to look at https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk, but I don't think you'll need to change anything there (since it only looks at the tags to add things to the device cgroup-- so if snappy adds the right udev rule, it should all just work)
<dholbach> https://bugs.launchpad.net/snapcraft/+bug/1496392
<ubottu> Launchpad bug 1496392 in Snapcraft "Separate tests from build" [Undecided,New]
<clobrano> jdstrand: ok, I'll have a look at it
<lool> mvo: just wanted to double-check if I got that right: the way to set network config for eth0 is to set ubuntu-core/network/interfaces -name: eth0 -content: /some/path/name to an ifupdown config?
<sergiusens> lool, just run snappy config ubuntu-core on the latest image and it will be clear ;-)
<lool> sergiusens: haha right
<lool> sergiusens: how would be transition to a non-ifupdown spec?
<sergiusens> lool, oh, you are the architect ;-)
<lool> sergiusens: tsss
<sergiusens> lool, I'm just the snapcraft software guy now ;-)
<lool> sergiusens: I'm mostly concerned about upgrades; we could keep compat with ifupdown for a while though
<sergiusens> Chipaca, https://code.launchpad.net/~sergiusens/snapcraft/1496381/+merge/271299
<sergiusens> or dholbach ^
<ricmm> lool: whats the problem? most things that configure network try to parse ifupdown first in case theres something they should avoid
<ricmm> we could also consider that network-admin caps can only be given to one snap
<ricmm> if ifupdown is being used, os-snap should have that assigned
<lool> ricmm: I wonder how we'd transition to something not defined by ifupdown snippets
<ricmm> if it doesnt have it, ifupdown is a no-op
<lool> ricmm: e.g. systemd-network
<lool> (for simple networking)
<ricmm> you mean a seamless translation from ifupdown files to *-network ?
<mvo_> lool: ups, sorry, missed the earlier question. yeah, tying ourself into ifup is a concern
<ricmm> well we are not tying ourseslves, we are exposing it as an option
<ricmm> we are just tying ourselves to provide the option
<zyga> https://code.launchpad.net/~zyga/snapcraft/gitignore/+merge/271313
<mvo_> yay, r156 ready for armhf
<elopio> good morning team
<elopio> so what needs testing?
<elopio> fgimenez: ^
<sergiusens> elopio, all the things
<fgimenez> elopio, more testing! even the tests need testing! :) how was your holiday
<elopio> it was gooood.
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/1496392/+merge/271319
<dholbach> ^ let me know if the test bits make sense like this and if the one test is expected to fail
<dholbach> sergiusens, replied
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/lp1496070/+merge/271167 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~kyrofa/webdm/autorestart_services/+merge/268120 | No reviews (32 days old)
<nothal> https://code.launchpad.net/~chipaca/snappy/precommit/+merge/271290 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/resize_test2/+merge/271131 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/udf-revision/+merge/271081 | No reviews (less than a day old)
<Chipaca> @dance for us
<nothal> Chipaca: No such command!
<sergiusens> dholbach, oh my; will fix
<elopio> sergiusens: have you seen this with the udf from tools-proposed?
<elopio> http://paste.ubuntu.com/12427656/
<sergiusens> elopio, no
<elopio> sergiusens: just happened 2 out of 3 times here. I'll report a bug.
<elopio> fgimenez: ah, that makes sense. The comment says that the config is changed after the reboot.
<fgimenez> elopio, yep, that's for grub
<elopio> I was trying to be extra smart, and made a mess, as always. I can remove the check.
<fgimenez> elopio, but now failover tests are trying to modify kernel files on a, have you seen that?
<elopio> let me give it another try, because I am now wondering what I tested.
<elopio> fgimenez: no.
<fgimenez> elopio, ok give it a try
<elopio> fgimenez: so the change of Next is all wrong?
<fgimenez> elopio, i don't think so, it works fine on bbb, but maybe because of the problem that mvo_ mentioned with the delta upgrades we are seeing this issues now
<ogra_> sergiusens, elopio, davmor2 reported the same issue today (the kpartx one)
<ogra_> and i dont think he was using proposed ... that must be something older
<elopio> davmor2: link?
<davmor2> elopio: http://paste.ubuntu.com/12425581/
<davmor2> seems to be working this time for what it is worth
<elopio> ogra_: the message is not the same.
<ogra_> yeah, i just noticed
<elopio> davmor2: can you please file a bug for that one?
<davmor2> elopio: I did an upgrade and rebooted at lunch time now it seems to be working
<elopio> davmor2: ok, if you happen to see it again, please let us know.
<ogra_> and send our greetings too
<ogra_> :P
<elopio> the typical joke from this side of the world would be: and what do I tell him if I don't see him?
<ogra_> :)
<slangasek> ricmm: did the fwupdate seeding for 15.10 happen today?
<ogra_> slangasek, cyphermox pinged me about it last night and then noticed it wasnt in the archive yet
<ogra_> is it now ?
<slangasek> ogra_: that's not correct, fwupdate has been in wily for weeks
<ricmm> ogra_: fwupdate should be in wily yea
<ricmm> ogra_: could you do that rq if it doesnt interfere with the other stuff?
<ogra_> oh
<ogra_> <cyphermox> disregard fwupd for now since it's not even in Debian.
 * ogra_ notes thats a different package 
<ogra_> i didnt catch that last night, sorry
<ogra_> do we actually have seeds ?
<ogra_> (up to now all changes for adding new packages were in livecd-rootfs)
<ogra_> i see https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily but are they actually used (we dont have a meta)
<ogra_> slangasek, added to the seed, not sure if i have to do any subsequent actions though since we dont have a meta
<slangasek> ogra_: the core seed is in the ubuntu.wily seed pod...
<slangasek> ogra_: the system-image seed.  You've been hard-coding packages in livecd-rootfs?! ugh
<ogra_> slangasek, for 15.04, yes
<ogra_> i wouldnt know how i can retroactivly add anything to it
<slangasek> ogra_: ah because tasks
<ogra_> yeah
<ogra_> hmm, so the seed isnt actually the one i linked above ?
<slangasek> ogra_: no, it's not
<ogra_> eek ...
 * ogra_ reverts the last commit then 
<slangasek> ogra_: and yes, you're right, for 15.04 putting it in the seed doesn't help because task fields don't get regenerated
<ogra_> right
<elopio> fgimenez: I'm on kvm, and I see snappy_mode=try on /boot/grub/grubenv
<ricmm> mvo_: ^
<ricmm> elopio: you probably hit the issue mvo just fixed
<ricmm> where the update process didnt finish correctly so flags werent set right
<elopio> ricmm: yes, that was fgimenez' suspicion. I was just giving it a try.
<Chipaca> elopio: bug 1496486 is also fixed by my branch
<ubottu> bug 1496486 in Snappy "trunk fails go vet: i18n/xgettext-go/main.go:93: unreachable code" [Undecided,In progress] https://launchpad.net/bugs/1496486
<elopio> Chipaca: oh, sorry.
<elopio> Chipaca: which branch?
<elopio> you have like 3000, give or take.
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/lp1496070/+merge/271167 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~kyrofa/webdm/autorestart_services/+merge/268120 | No reviews (32 days old)
<nothal> https://code.launchpad.net/~elopio/snappy/fix1496486-go_vet_unreachable/+merge/271343 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/precommit/+merge/271290 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/resize_test2/+merge/271131 | No reviews (less than a day old)
<Chipaca> elopio: ^
<elopio> got it.
<Chipaca> ok, time for me to go make dinner
<mvo_> elopio: what scenario was that that you ended up with try mode?
<mvo_> elopio: and is that image/machine still available? the sudo systemctl status ubuntu-snappy.boot-ok would be good
<elopio> mvo_: I called snappy update. So I expected the try mode, and it worked.
<mvo_> elopio: aha and it worked, thats nice, I like that
<elopio> full of success :D
<mvo_> heh :) a bit worn down from all the testing/fixing actually
<fgimenez> elopio, mm was a it a delta upgrade? i've seen the issue from 168 to 169, for instance
<mvo_> I was able to reproduce from 168->170 on kvm/amd64
<mvo_> (and I verified the fix there)
<elopio> fgimenez: 167 to 175.
<elopio> using snappy-from-branch from trunk.
<fgimenez> elopio, the last line of the errored update output should be "can not find file /writable/cache/assets/vmlinuz", are you trying on 15.04?
<elopio> fgimenez: with that I was just checking that my test for try mode was valid.
<elopio> I have a 15.04 run in progress, but with the tests from the 15.04 branch.
<fgimenez> elopio, ok that makes sense, then when the fix land we should expect that the mode is try, right?
<elopio> fgimenez: right. And if it fails, that's good, we are catching an error.
<fgimenez> elopio, ok remember to remove http://bazaar.launchpad.net/~fgimenez/snappy/1504_validation/view/head:/_integration-tests/testutils/partition/bootloader.go#L80
<fgimenez> wait, i'll remove it
<elopio> mvo_: you also fixed this: https://bugs.launchpad.net/snappy/+bug/1496486 ^_^
<ubottu> Launchpad bug 1496486 in Snappy "trunk fails go vet: i18n/xgettext-go/main.go:93: unreachable code" [Undecided,In progress]
<elopio> crazy times.
<mvo_> elopio: I did? excellent, I don't even remember
<elopio> yeah, we have three branches for it.
<mvo_> oh, I think I fixed and never proposed :/ ?
<mvo_> well, a good reason to land one now
<elopio> mvo_: I'm trying Chipaca's fix now. Not a big deal, you have a lot more big things going on.
 * elopio just takes notes to support the slow release philosophy.
<mvo_> elopio: +10^100 from me for a slower release next time
<sergiusens> ogra_, elopio davmor2 i this is the case, it is most likely some open fds left over by snappy (rebuilt to use the latest)
<sergiusens> elopio, mvo_ fwiw, Chipaca has a branch that fixes that
<elopio> sergiusens: yup. We just found out.
<mvo_> we found 3 branches in total
<mvo_> :)
<elopio> that's how we roll. We will not just hit this release date, we will give you three fixes for everything!
<slangasek> ogra_: I see that fwupdate needs an MIR now ;)
<ogra_> how about faster release with less changes instead ?
<ogra_> slangasek, well, half of the stuff we ship needs a MIR :P ... once we are through that release chaos i'll take a look
<ogra_> (before EOW i hope)
<elopio> https://bugs.launchpad.net/snappy/+bug/1496515
<ubottu> Launchpad bug 1496515 in Snappy "15.04 fails go vet: helpers/helpers.go:399: result of fmt.Errorf call not used" [Undecided,New]
<elopio> I think nobody has fixed this one yet ^
 * elopio goes for it.
<tedg> I really don't understand this nova build. Sometimes it seems fast. Now it's at 90m and 5.8GB of RAM.
<sergiusens> tedg, heh
<sergiusens> tedg, can you add back return self.handle_source_options() to python2-project?
<sergiusens> tedg, how's the shebang issue treating you?
<tedg> sergiusens: Not well, trying to seperate out the build and install steps but it's not clear how the various parameters interact.
<tedg> sergiusens: Now trying with the default "build" directory to see if that will work.
<sergiusens> tedg, there's a build_scripts target as well fwiw
<tedg> sergiusens: Hmm, yeah, I haven't given up on this yet :-)
 * tedg has high hopes, he has apple pie, in the sky!
<atXyc0> hello, I am in the process of dd the RPi2 image
<atXyc0> it seems rather large
<atXyc0> Ctrl-t inidcates im not even 1/5 of the way done
<atXyc0> is that an ext4 partition for 4gb sdcard?
<ogra_> no, it is an SD card image with multiple partitions
<asac> atXyc0: should be 4 partitions with 3 being ext4 and one vfat for boot
<ogra_> asac, btw for the next release we should shrink writable to 10MB or so ... now that it can auto-grow
<ogra_> saves image size
<atXyc0> asac: that makes sense. do i need to expand the root partition to fill my 8gb sdcard?
<ogra_> if you wait 2 days you can get the new image that will auto resize on first boot
<ogra_> hmm, actually ...
<ogra_> just dd it and do the upgrade once the new image is out
<ogra_> it should then grow to full size automatically
<atXyc0> the dd is taking quite a long time
<ogra_> yeah, 4GB are a lot
<ogra_> for me it takes about 10-15min usually
<atXyc0> 30 minutes so far on a MBP
<atXyc0> 939524096 bytes
<asac> thats quite a long time
<ogra_> that doesnt look right
<asac> slow SD card or slow bus/writer
<asac> otherwise something fishy
<ogra_> whats the dd line you used ?
<atXyc0> dd if=ubuntu-15.04-snappy-armhf-rpi2.img if=/dev/disk2 bs=64m
<atXyc0> ogra_ ^
<atXyc0> sorry, of for the dev line
<ogra_> disk2 ?
<atXyc0> im on osx
<ogra_> you actually have a device named like that ?
<ogra_> oh
<atXyc0> dd works the same as gnu
<ogra_> yeah
<atXyc0> the bs type is different
<ogra_> well, if it doesnt finish soon i'd try a smaller blocksize ... like 4M or so
<ogra_> it should definitely not take that long
<atXyc0> not that it matters, what was the blocksize that the image was dd off of
<ogra_> hmm, no idea what blocksize ubuntu-device-flash actually uses when creating the image ... sergiusens ?
<atXyc0_> sorry d/c
<sergiusens> ogra_, based on code from ubi provided by cj watson
<ogra_> sergiusens, so you dont know :)
<ogra_> but i'd guess some typical disk blocksize
<sergiusens> ogra_,  don't remember, no
<sergiusens> and otp
<atXyc0_> 502245 bytes/second seems slow
<atXyc0_> i wonder if I got a crappy sdcard with this RPi2
<atXyc0_> i restarted with bs=4m
<asac> atXyc0: most likely bad sd... i had a similar slow one once, just trashed it and new one was on steroids
#snappy 2015-09-17
<sergiusens> care to do some code reviews? https://code.launchpad.net/~dholbach/snapcraft/1496392/+merge/271319
<sergiusens> elopio, ^
<sergiusens> elopio, and maybe this https://code.launchpad.net/~ted/snapcraft/python-pip/+merge/270959
<sergiusens> elopio, and not sure you know how, but tedg (and I scarcely tried as well) is trying to get rid of the shebang replacement.
<sergiusens> that setuptools does on 'scripts'
<sergiusens> well, not replacement, generation (we want the env python3 magic)
<dholbach> good morning
<fgimenez> good morning
<elopio> hello fgimenez
<elopio> fgimenez: I haven't found any blockers. Here's what I've been doing: http://pad.ubuntu.com/snappy-testing-2015-09-16
<elopio> I couldn't find the right data to send to package POST and config PUT. Could you please ask Chipaca when he wakes up and test those two methods?
<fgimenez> hey elopio, ok thanks a lot, let me send you the link to the rest api doc
<elopio> ah, that would have been useful.
<fgimenez> elopio, sorry, i didn't recall yesterday you would need it. i'll continue from here
<dholbach> elopio, I merged your dep8 branch into https://code.launchpad.net/~dholbach/snapcraft/1496392/+merge/271319 so it can benefit from both our work - one test is still failing - this is just a headsup - I know you're busy with testing right now
<elopio> fgimenez: well, looking at the doc I still don't fully get how the config works :p
<elopio> I'm not sure it would have been different.
<elopio> dholbach: hey, I saw your branch.
<elopio> actually, branches. Thanks a lot for your help. I hope I'll be fully on snapcraft tomorrow.
<elopio> dholbach: on my branch I also had one or two failures. This is a good time to dig on that. Thanks for merging them too.
<dholbach> I'll add you as a branch reviewer :)
<dholbach> ah, you already are :)
<elopio> fgimenez: your snapcraft branch will be affected by that too ^
<fgimenez> elopio, ok thanks i'll take a look
<elopio> uggh, I've just tried to roll back from #9 to #11 on the bbb, and it ended back on #11.
<elopio> now it worked. I should have gone to bed like 2 minutes ago :D
<fgimenez> elopio, go to bed anyway! i'll take care of that
<elopio> yes, the issue seems to have disappeared after closer inspection 8-)
<elopio> I'm leaving now. See you again soon o/
<dholbach> good night elopio!
<mvo> good night elopio and thanks for the testing
<Chipaca> elopio: fgimenez: ehlo. config works fine =)
<Chipaca> elopio: fgimenez: but if you could elaborate your question a little bit more, i might be able to give you a more helpful answer
<Chipaca> elopio: fgimenez: method 1 of 2 for POST to packages: POST -H "X-Allow-Unsigned: 1" http://localhost:8080/1.0/packages < /tmp/x.snap
<fgimenez> Chipaca, great thanks :) i'll try manually the put and post methods, will ping you if needed
<Chipaca> elopio: fgimenez: method 2 of 2 for POST to packages: POST -H "Content-Type: multipart/form-data" http://localhost:8080/1.0/packages < /tmp/mime-multipart-form-data-file
<Chipaca> elopio: fgimenez: alternative to method 2 of 2 for POST to packages: http://pastebin.ubuntu.com/12412149/
<Chipaca> elopio: fgimenez: make yer browser do the work ;)
<Chipaca> elopio: fgimenez: or you can have netcat listening on that port and copy the document body from the request
<Chipaca> elopio: fgimenez: PUT to config: echo -e "config:\n ubuntu-core:\n  autopilot: false\n" | PUT http://localhost:8080/1.0/packages/ubuntu-core.ubuntu/config
<JamesTait> Good morning all; happy Thursday, and happy Apple Dumpling Day! ð
<fgimenez> Chipaca, i'm getting this from the post to packages http://paste.ubuntu.com/12436434/ with the X-Allow-Unsigned: 1 header
<fgimenez> Chipaca, i've built the package from config-example in snappy-examples, let me try with another one
<ricmm> fgimenez: could you try with an html based multi-part upload as well instead
 * ricmm finds it
<Chipaca> ricmm: linked him to it already
<ricmm> oh ok
 * ricmm too slow
<ricmm> http://paste.ubuntu.com/12436497/ anyways...
<fgimenez> ricmm, yep, i'll try that now
<Chipaca> fgimenez: just tried it here and it worked
 * Chipaca tries something else
<Chipaca> so, yes it worked here
<Chipaca> let me try with curl
<Chipaca> curl gives me the same error as you get fgimenez
<Chipaca> oh
<Chipaca> fgimenez: curl doesn't read post data from stdin
<Chipaca> fgimenez: try --data-binary @filename
<Chipaca> fgimenez: or @- for stdin
<fgimenez> Chipaca, ok let me check
<fgimenez> Chipaca, yes, {"result":{"created_at":"1442482081293797","may_cancel":false,"output":"go-example-webserver","resource":"/1.0/operations/09cf305f-1a0d-19ea-a98d-7e7331e1e46a","status":"succeeded","updated_at":"1442482081729617"},"status":"OK","status_code":200,"type":"sync"}
<Chipaca> silly curl :)
<fgimenez> Chipaca, yep :)
<Chipaca> fgimenez: also this might come in handy for your testing:
<Chipaca> fgimenez: r=$( echo -e '{"action": "enable"}' | PUT http://localhost:8080/1.0/packages/hello-dbus-fwk/services   | jq -r .metadata.resource ); while ! (GET http://localhost:8080$r | jq .metadata.status | egrep 'succeeded|failed'); do echo .; sleep 1; done; GET http://localhost:8080$r | jq .
<Chipaca> fgimenez: snippet from my bash_history; adjust as needed :)
<fgimenez> Chipaca, ok thanks a lot. not only for today, it can also be adapted to the automated integration tests as well
<Chipaca> fgimenez: well.. perhaps. When the above fails during interactive testing it's not a big deal :)
<Chipaca> e.g. if the server crashes, it'll get stuck
<Chipaca> if it's for automated testing you need to guard against that
<fgimenez> Chipaca, yes that'll be covered, i mean the way to test a put to the services resource and how to check the status after that
<Chipaca> ah. ok :)
<atXyc0_> fdisk displays 4 partitions on the RPi2 image
<atXyc0_> but they don't add up to the total size of my sdcard, 8gb
<atXyc0_> how do I expand mmcvlk0p4 ?
<sergiusens> ogra_, did your writable expansion virus land in 15.04?
<ogra_> sergiusens, yes
<ogra_> but the RPi image is still one version behind
<atXyc0_> is there a listing of snappy packages that can be installed?
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/1496392/+merge/271319
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/1496789/+merge/271444
<ogra_> atXyc0_, point your browser to http://webdm.local:4200/
<ogra_> the store UI is running on the Pi
<elopio> fgimenez: fginther wanted to talk about the jenkins launchpad plugin.
<elopio> fgimenez: what you changed on your branch where only some branches that haven't landed yet, right?
<fginther> elopio, fgimenez, right. I'd just like to know what problems you ran into while setting it up
<fginther> so that we can determine if this can be utilized for future jenkins deployments
<fgimenez> elopio, fginther yes, i needed to make some changes, let me check
<fginther> fgimenez, thanks!
<fginther> fgimenez, I already found a couple, including the need to add the build token MP
<elopio> fgimenez: we have one big problem, but we can easily change it. Currently we have only one job that runs the test, not downstream jobs. So the comment that gets to launchpad is not too acurate.
<fginther> elopio, could you point me to an example?
<elopio> fginther: umm, maybe? Let me try to find it.
<elopio> fginther: and the other big problem I can see in our future is that we will have git branches.
<elopio> fginther: https://code.launchpad.net/~chipaca/snappy/schmideload/+merge/268498/comments/675267
<fgimenez> elopio, yes, but if we are going to split job for parallel execution we are going to have these downstream jobs anyway, what do you think?
<fginther> elopio, when it comes to git branches, there is likely some better support via jenkins plugins and jenkins-launchpad-plugin may no longer be necessary (but that's a bit of speculation)
<elopio> the $BUILD_URL issue is https://github.com/jenkinsci/docker/issues/138
<fgimenez> elopio, if we want to have a single complete execution it seems that we need to do some tweaking with the job definition for having that info in the messages with the current code
<fginther> elopio, have you tried setting the public url in jenkins?
<fginther> (it's on the main configuration page if you don't know where to look)
<fginther> fgimenez, were there any other setup and installation issues you encountered?
<elopio> fgimenez: yes to all you said. :)
<elopio> fginther: and yes, the url issue is that we need to manually save the config from the web. No way to do a clean deploy and get everything ready to go.
<elopio> still no big issue.
<elopio> fginther: we got it working, which is good. If we are going to stick with it, we can do some tweaks and upstream them.
<elopio> but I saw some branches ready to land that were never approved.
<elopio> are you maintaining this project?
<fgimenez> fginther, take a look at the branch history http://bazaar.launchpad.net/~fgimenez/+junk/jenkins-launchpad-plugin/changes/130?start_revid=130
<elopio> fgimenez: something left to test on snappy, or should I switch asap to snapcraft?
<asac> https://lists.ubuntu.com/archives/snappy-devel/2015-September/001041.html
<fginther> elopio, we're maintaining it for now, trying to get it in better shape to use it with the jenkins-as-a-service deployments
<fgimenez> elopio, i think we are done, didn't have time to reproduce tutorials/guides, but all seems to be fine
<fginther> elopio, the current effort is to fix any install and compatibility issues encountered
<fginther> fginther, thanks for that branch
<fginther> errrr!
<fginther> fgimenez, thanks for that branch
<ogra_> \o/
<fgimenez> fginther, yw :) let me know if there's anything unclear, that's all the changes i needed to make it work in our deployment (which includes a separate tarmac)
<fginther> fgimenez, thanks again. I'll look through those changes in detail and let you know if I have any questions
<sergiusens> elopio, mind looking at https://code.launchpad.net/~sergiusens/snapcraft/clean/+merge/271487
<elopio> sergiusens: ok.
<sergiusens> John reviewed on irc with me, but I guess he left already :-)
<elopio> sergiusens: what about adding it to the integration tests?
<sergiusens> elopio, like for every test possible?
<elopio> sergiusens: no, just one execution of clean.
<sergiusens> elopio, as in, for every test run in there?
<sergiusens> elopio, ok, I don't mind that :-)
<elopio> sergiusens: the parts directory is not removed.
<elopio> is that on purpose?
<sergiusens> elopio, yes; inside parts you can also have local plugins
<sergiusens> elopio, it's sort of a safe haven for things
<elopio> sergiusens: what about removing it if it's empty?
<sergiusens> elopio, so instead of removing everything I thought it be safer this way
<sergiusens> elopio, yeah, that can be arranged
<elopio> just feels weird to leave behind only one empty dir.
<sergiusens> tedg, found a small issue, which brings me to think an integration test for setup.py pypy would be good :-)
<sergiusens> elopio, clean branch up to date
<atXyc0> I fixed my issue
<atXyc0> it was OSX
<atXyc0> either dd, the userland filesystem driver, or the sdcard port on my MBP
<atXyc0> either way, ubuntu saved ubuntu
<sergiusens> hah, nice
<sergiusens> elopio, https://code.launchpad.net/~sergiusens/snapcraft/pypy-config-test/+merge/271528
<sergiusens> elopio, btw, do we have adt enabled for our snappy-dev ppas?
<sergiusens> elopio, scratch that, here you go https://code.launchpad.net/~sergiusens/snapcraft/pypy-config-test/+merge/271529
<elopio> sergiusens: I'm not sure how it works for ppas, don't they just run the test if they are present?
<elopio> or mabye we need something on the recipe.
<sergiusens> elopio, the feature is there, we just need to activate it
<sergiusens> for the PPA
<sergiusens> elopio, I'll be back in a bit; I hope you get to review by then ;-)
<sergiusens> :-)
<elopio> sergiusens: I don't get where are you using pypy in this branch.
<sergiusens> elopio, the pyyaml dep goes t pypy to fetch it
<sergiusens> oh
<elopio> sergiusens: to pypi?
<sergiusens> elopio, yeah :-P
 * sergiusens renames
<elopio> I felt stupid looking at the config code trying to understand that part :D
<elopio> sergiusens: maybe you can use the yaml summary and description to explain what's the purpose of the package.
<elopio> or a comment in jobs.pxu. Just pypi-config might not be clear enough to understand the intention.
<sergiusens> elopio, ok done, running tests and uploading
<sergiusens> Chipaca, btw ^
<sergiusens> elopio, btw, we won't find the same line as in the yaml; it is wrapped :-)
<elopio> sergiusens: yeah, just check for what you expect.
<elopio> that's good because we check also the wrapping.
<elopio> maybe all the env vars are not necessary to check.
<tedg> sergiusens: I think we might need to add something like config helpers. Map the snappy yaml into native formats, ini, xml, gsettings, etc.
<elopio> sergiusens: + description='config for webcam-webui',
<elopio> that's from the other example.
<sergiusens> elopio, yeha, but it is indeed a config for that and only that used here
<sergiusens> tedg, I agree and I want to be smart about it and do it in wiki parts
<sergiusens> elopio, branch pushed
<tedg> sergiusens: I think they're gonna have to be plugins, eh?
<tedg> sergiusens: Have to be able to override the config key in the meta directory
<sergiusens> tedg, I think they will, yeah; which is what demotivates me
<sergiusens> tedg, I don't want a swarm of plugins ;-)
<tedg> sergiusens: Good luck, the goals are only to snap all the software in the world. I'm sure it's fairly consistent :-)
<sergiusens> tedg, I can dream, can't I
<sergiusens> tedg, the world will be written in go soon  and this will be a non issue ;-)
 * tedg hands sergiusens a newborn so he can't sleep and therefore dream ;-)
<sergiusens> tedg, too late, already happened ;-)
<sergiusens> tedg, btw, did you see my pip branch comment?
<tedg> sergiusens: Yeah, not sure what is going on, it is odd to me that is complaining that the directory isn't in the path, and it is.
<sergiusens> tedg, this is the suspect, right? http://bazaar.launchpad.net/~ted/snapcraft/python-pip/revision/151 ?
<sergiusens> tedg, I'll hack in an 'env' inside that self.run to see how the env looks like
<tedg> sergiusens: I don't think so, since it would have gotten the variable anyway through the env=env part.
<tedg> sergiusens: I think it probably broke with the setuptools branch.
<sergiusens> tedg, hmm, but that webcam-webui is based on the setuptools branch
<tedg> Let me check trunk.
<tedg> It runs in trunk but seems to have the same environment.
<tedg> That was just an attempt to clean things up a bit. Nothing critical.
<tedg> I'm surprised it would have any effect.
<sergiusens> tedg, well now there is a simpler tests run during the integration tests
<tedg> K, werid though.
<sergiusens> tedg, PYTHONPATH is setup correctly
<tedg> sergiusens: Your test fails in the same way.
<tedg> Good I guess.
<tedg> elopio: Is there a way I can run one of the integration tests without running all of them?
<sergiusens> tedg, it is rather complicated with plainbox; you need to create a test suite :-/
 * tedg deletes all the other tests
<sergiusens> tedg, removing def env from python3.py makes it all work
<tedg> sergiusens: Adding it to the self.run() command?
<sergiusens> tedg, yeah, like it was before
<sergiusens> tedg, I guess it means we have a broken env story
<tedg> Err, that's fine to get things working. But it doesn't quite explain it. They should be identical.
<sergiusens> tedg, well none of your changes made sense of breaking per se ;-)
<tedg> Wonder if there's some other env var that gets lots.
<tedg> lst
<tedg> lost
<tedg> sergiusens: Are we doing the os.envir.copy() to start out?
<sergiusens> yeah
<sergiusens> tedg, but that alone isn't enough
<sergiusens> tedg, the env gets setup twice and is overriden
<sergiusens> tedg, export PYTHONPATH=/home/sergiusens/source/launchpad.net/snapcraft/integration-tests/data/pypi-config/parts/python3/install/usr/lib/python3/dist-packages
<sergiusens> export PYTHONPATH=/home/sergiusens/source/launchpad.net/snapcraft/integration-tests/data/pypi-config/parts/python3/install/usr/lib/python3/dist-packages
<sergiusens> tedg, http://paste.ubuntu.com/12441978/ (simple hack)
<tedg> sergiusens: But why would assemble_env() return different things each time?
<sergiusens> tedg, dunno, it's a global var
<tedg> That's not good...
<tedg> Both that it's a global and returning different things.
<sergiusens> tedg, in snapcraft.common
<tedg> sergiusens: Okay, I'm gonna have to come back to this, need to go start dinner.
<tedg> sergiusens: I'll get a revision up later.
<sergiusens> tedg, sounds good
<sergiusens> tedg, in any case, this resolves it http://paste.ubuntu.com/12442059/
<sergiusens> tedg, ensuring the local part can override any setting done by its dependencies
<sergiusens> tedg, but we need a better architecture for setting up the environment
<psanchez_> problem trying snappy and docker: The command "docker build -t my-container . " gives me the following error "Error checking context is accessible: 'can't stat '.''. Please check permissions and try again."
<psanchez_> https://bugs.launchpad.net/snappy/+bug/1412343  ... I tried building the docker image in $HOME/apps/docker but it also failed.
<ubottu> Launchpad bug 1412343 in Snappy "Command `docker build` is broken" [Medium,Fix released]
<psanchez_> So, how do I get the fix?
<psanchez_> I used "sudo snappy install docker"
<psanchez_> Launchpad ticket 1412343 says "status: Confirmed â Fix Released" I assume the fix went into ubuntu-core, since it seems to be appmor-related. Now:
<sergiusens> psanchez_, have you seen the last comment https://bugs.launchpad.net/snappy/+bug/1412343/comments/5
<ubottu> Launchpad bug 1412343 in Snappy "Command `docker build` is broken" [Medium,Fix released]
<psanchez_> $ snappy list
<psanchez_> Name          Date       Version   Developer
<psanchez_> ubuntu-core   2015-09-17 5         ubuntu
<psanchez_> docker        2015-09-17 1.6.2.003 canonical
<psanchez_> webdm         2015-09-17 0.9       canonical
<psanchez_> generic-amd64 2015-09-17 1.4       canonical
<psanchez_> Yes, the laucnhpad ticket says "Fix Released," but where is it? I believe I am running the latest ubuntu-core, where I thought the fix is located.
#snappy 2015-09-18
<psanchez_> hmm, ok, not a good start for snappy and docker ... -1 ... I'll ask again tomorrow.
<fgimenez> good morning
<davidcalle> Morning o/
<clobrano> good morning
<JamesTait> Good morning all; happy Friday, and happy Respect Day! ð
<clobrano> A basic question: how do you test changes in snappy itself? how can I install it?
<mvo> clobrano: if you modify snappy itself you can just copy in into our snappy system and run it via sudo ./snappy something
<clobrano> mvo: doesn't snappy need any particular permission? Can I run it just like that?
<ogra_>  sure
<clobrano> ok, thank you
<mvo> clobrano: one nice property is that its a single binary so for the most part this method of just copyign will work
<clobrano> mvo: great :)
<ogra_> if you want to test it deeper in the system you can also make the filesystem writable, copy it in place and switch back to readonly
<ogra_> i.e. to test something that happens during boot or so
<ogra_> the base system is still just a normal linux system ... just without traditional package manager
<clobrano> ogra_: how do I make the fs writable?
<ogra_> sudo mount -o remount,rw /
<ogra_> sudo mount -o remount,ro /
<clobrano> ogra_: oh sure, I was expecting something special :D
<ogra_> heh
<mvo> yeah, ogra_ made great suggestions. some stuff can only be tested by copying (snappy booted for example which is run by a startup job)
<clobrano> perfect
<davidcalle> mvo, ogra_, I need to do a small doc fix in the 15.04 branch, should I merge to snappy/trunk first, then snappy/15.04?
<mvo> davidcalle: easiest is probably to just do it 15.04 and then we merge the 15.04 change to trunk
<mvo> davidcalle: i.e. just do it on 15.04 and we will take care of the rest :)
<davidcalle> mvo, sounds good :) https://code.launchpad.net/~davidc3/snappy/oem-docs-formatting/+merge/271624
<davidcalle> mvo, ty
<longsleep> Hey folks, i noticed that my ODROID-C image does not have most of the firmware files in /lib/firmware - is that expected when a device tarball with system/.. tree is used?
<ogra_> longsleep, you need to ship it in the device tarball
 * ogra_ has the same issue on rpi
<ogra_> davidcalle, *next' release will bring official RPi support ...
<ogra_> we'Re not there yet :)
 * davidcalle adds a "don't open before christmas" label on the email
<davidcalle> ogra_, alright then :)
<longsleep> ogra_: sorry i got distracted, you say i have to ship all the firmware in the device tarball right?
<ogra_> yeah ... just unpack linux-firmware in the tree when you create it
<longsleep> ogra_: ok cool, thanks!
<asac> o/
<asac> my pi is on #5 :)
<asac> feels faster
<ogra_> heh
<ogra_> i bet thats subjective
<asac> guess thats just the excitement because i had to invest to get tehre
<asac> :)
<ogra_> yeah
<asac> and snappy list bails very quickly
<asac> https://bugs.launchpad.net/snappy/+bug/1497245
<ubottu> Launchpad bug 1497245 in Snappy "snappy list/remove bails on 15.04/stable #5 if invalid package.yaml is on disk (no vendor field)" [High,New]
<ogra_> you and your exotic packages :P
<asac> well, vendor field wasnt mandatory no?
 * ogra_ isnt sure
<ogra_> probably it is now
<asac> in any case, think for list and in particular remove we should be super robust against anything
<asac> i think its mandatory for 16.04 ... but not for 15.04
<ogra_> we backported trunk ...
<sergiusens> asac, vendor was always mandatory
<sergiusens> asac, the store at least booted you because of that, did you manually install?
<asac> sure
<asac> my beloved zigbee gateway :(
<asac> lol
 * asac goes and manually removes the app from /apps and the other prominent places
<sergiusens> asac, why didn't you upload it to the store ? sounds like an interesing app ;-)
<asac> yay what i love about snappy is that there is no cache/meta files
<asac> sergiusens: like most of our apps they are customer related as they prep for launching big devices :P
<asac> thats why in store we have like 2% of the existing snappy apps at best
<sergiusens> I was just punning :-)
<asac> i know
<asac> sergiusens: good that you are awake again
<asac> the call is cancelled...
<asac> NOT :)
<asac> lol
<sergiusens> asac, well, meetings! ;-)
<asac> will be there in 1 minute
<ogra_> huh ?
<ogra_> why the heck is the clinic a hangout
<ogra_> thats nonsense
<asac> ogra_: its a meeting
<asac> you coming?
<ogra_> asac, what for ?
<ogra_> asac, if we want to do a clinic it should be on IRC ... i.e. a special time where we help with specific developer problems
<zyga> ogra_: moar hangouts
<dholbach> I think https://code.launchpad.net/~zyga/snapcraft/gitignore/+merge/271313 and https://code.launchpad.net/~dholbach/snapcraft/1496789/+merge/271444 can be landed, right? :)
<ogra_> asac, mvo_, so i dont think there is any solution to the Pi update issue without actually releasing a stable #6 ...
<ogra_> i guess we should just release-note it that you have to manually copy the kernel pieces
<mvo_> ogra_: yeah, its really really hard :/ will the generic kernel not boot at all? or what will happen?
<ogra_> it hangs hard at "Starting kernel ..."
<mvo_> meh
<ogra_> doesnt even unpack it completely
<mvo_> yeah, that does not give us many options :(
<ogra_> right
<ogra_> we could hack something into the s-i process or some such ... but that would still require a #6 release
<ogra_> (at least for armhf)
<ogra_> we could indeed do an armhf only release ... at the cost of gettin the image numbers out of sync
<dholbach> thanks sergiusens
<mvo_> ogra_: yeah, I really have no good idea either, lets create the device thing on the server so that we are safe for the future, I talk to sil
<ogra_> yup. i see that :)
<ogra_> mvo_, the other question is ... why is there a kernel in /boot at all :) i thought we added code to remove it in livecd-rootfs
 * ogra_ wonders if that only went into rolling
<ogra_> ah, so it did
<plars> ogra_: heya, quick rpi2 question for you if you have a moment - We're seeing that our ethernet hwaddress changes on every boot, I'm guessing because it has the serial as all 0s in proc cpuinfo. Is there any way you know of to have it configure a serial or come up with a static hwaddress?
<ogra_> plars, seems you are using an outdated image
<ogra_> that was fixed a while ago
<plars> ogra_: well, I'm not booting to snappy yet, this is just an ubuntu image as a base, and we'll boot snappy from there. What was the fix?
<ogra_> changing uboot and reading the binary blob data into the kernel cmdline
<ogra_> the binary blob provides the actual MAC in a variable
<plars> ogra_: which binary blob is it reading, and how does it get passed?
<ogra_> the binary blob that boots your board
<ogra_> i.e. the graphics driver that acts as bootloader :)
<zyga> ogra_: we're all waiting for our nvidia overlords to boot our x86 pc
<ogra_> plars, i dont remember exactly, iirc you need to crate a cmdline.txt next to the config.txt
<ogra_> it needs to contain something ... then the args get handed over to the uboot env
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /boot/uboot/cmdline.txt
<ogra_> elevator=deadline
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv |grep ^args
<ogra_> args=dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2709.boardrev=0xa01041 bcm2709.serial=0x8b04db1c smsc95xx.macaddr=B8:27:EB:04:DB:1C bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  elevator=deadline
<ogra_> that is how my Pi expands the cmdline
 * ogra_ forgot if there were additional steps required
<plars> ogra_: weird, I actually copied the boot directory from snappy
<ogra_> from image #4 ?
<plars> ogra_: so I'm not sure what could be missing
<ogra_> that only landed in the last image
<plars> ogra_: from one I downloaded last night
<plars> ogra_: how recent was that?
<plars> ogra_: I just grabbed the prebuilt one
<mvo_> ogra_: yeah, that puzzles me too, on armhf we really do not need that in /boot
<ogra_> well, if it is the one from ~/platform thats the most recent one
<ogra_> mvo_, i think we just didnt pull the change into the PPA
<mvo_> ogra_: oh, ok
<mvo_> ogra_: that makes sense
<plars> ogra_: yes, that's the one
<ogra_> i see the right code in live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary in wily
<ogra_> plars, weird
<asac> ogra_: its fine
<ogra_> should definitely work then
<asac> ogra_: can you reply to the release thread explaining the workaround?
<ogra_> asac, will do
<asac> or togetyher with your release announce when the pi2 is there
<ogra_> there too
<ogra_> cant mention it often enough ;)
<asac> just say "becauyse pi2 is not officially consumed from channels you need to do these copies after snappy update
<asac> and done
<asac> yep
<ogra_> sergiusens, i'm looking at package.yaml for pi and BBB oem snaps ... i dont see where it would define generic_armhf vs raspi2_armhf
<asac> i think sergio forgot to add that optioon to the yaml
<asac> was an oversight. we discussed a while back to have another field
<ogra_> "architecture: armhf" is what i see in both currently
<asac> beyond architecture
<asac> channel:
<asac> or somethign
<asac> generic
<asac> pi2
<asac> etc.
<ogra_> i see platform ... but that only defines the default dtb
<asac> does the azure have an oem snap?
<asac> if so it might have that info
<asac> but guess it still is created with manual
<ogra_> if azure does it isnt in http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<asac> that much i know
<asac> but doesnt mean there isnt one
<ogra_> right
<asac> anyway, i know it was a missing field before 15.04 release and most likely we just didnt add it
<plars> ogra_: weird, I don't see it in the uboot environment, but I do see usbethaddr there, but I don't see it get used
<ogra_> plars, usbethaddr is wrong
<asac> but adding a new field with default "generic" shouldnt be a problem
<ogra_>  smsc95xx.macaddr is what you need
<asac> just remember to add cards etc.
<plars> ogra_: it's the one I ended up with when I booted snappy
<plars> ogra_: but not when I boot something else - then it's random even though I copied all the bootloader files and uboot from the snappy image
<ogra_> do you have uboot.env ?
<sergiusens> asac, ogra_ since we don't want to expose s-i in snappy so high up; it was never there; you can build with u-d-f passing --device with the channel (like for azure); but it might only work for azure (as we don't want to make it easy to go down a path we can't support)
<plars> ogra_: I do
<asac> sergiusens: platform: ?
<asac> that doesnt feel like surfacing something from si if we use that
<ogra_> plars, and is it used ?
<plars> ogra_: yes
<sergiusens> ogra_, http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/view/head:/ubuntu-device-flash/snappy.go#L123
<ogra_> (do you see it pload properly in the serial log)
<asac> architecture: + platform: (optional, default: generic)
<sergiusens> asac, we had platform; but in the end this would be in the kernel snap
<plars> reading uboot.env
<ogra_> sergiusens, deviceChannel ?
<plars> ogra_: yep :)
<sergiusens> ogra_, --device
<asac> sergiusens: wait, in OEM snap specifying what platform this is for makes sense
<asac> hmm
<ogra_> ah, s.device ... right
<asac> oor we just say kernel: pi2
 * ogra_ looked to far down
<asac> default: generic
<asac> doesbnt matter for OEM snap... we will revisit those fields for 16.04 anyway then
<sergiusens> asac, ok; makes sense
<plars> ogra_: surely it's pulling the serial from the board somehow and not from the image though, right?
<ogra_> plars, yeah, same thing
<ogra_> bcm2709.serial=0x8b04db1c
<ogra_> cmdline option
<ogra_> seeded from the binary blob
<ogra_> plars, if you intercept the boot, do you see "args" ?
<ogra_> in printenv
<plars> ogra_: no
<plars> ogra_: was there something in the kernel needed for this?
<ogra_> no
<ogra_> thats pre-kernel
<ogra_> but ...
<ogra_> mmcargs=setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot}"
<ogra_> and snappy_boot calls "run mmcargs" on first boot
<ogra_> plars, ah, and:
<ogra_> loadfdt=fdt addr 0x100; fdt get value args /chosen bootargs
<ogra_> try running that line
<ogra_> and then see if args= exists
<ogra_> if so, add it to your non snappy boot
 * ogra_ forgot you have to pull te dtb from ram in to have the values
<plars> ogra_: just "args"? no still not set
<ogra_> that was the bit :)
<plars> ah, I see
<plars> get value args /chosen bootargs
<plars> hang on let me try that
<ogra_> fdt addr 0x100
<ogra_> you need that first
<plars> ogra_: running loadfdt did it, thanks!
<ogra_> cool
<mvo_> ogra_: we have a raspi2_armhf platform now!
<ogra_> mvo_, yeah, i see that !!
<ogra_> mvo_, i'll triger an edge build to see of it imports fine
<asac> on rolling? nice ;)
<ogra_> no
<ogra_> https://system-image.ubuntu.com/ubuntu-core/15.04/edge/
<ogra_> on 15.04 edge :)
<ogra_> build running
<mvo_> I added it to rolling and 15.04 so we should be fine
<mvo_> now I guess we just update reference image and the upgrade problem is solved for good
 * mvo_ is happy
<ogra_> mvo_, the importer will now run 5min longer
<ogra_> or so
<ogra_> new arch means moar diffing
<mvo_> meh
<clobrano> I saw an unexpected (for me) behavior in hw-assign: each call to hw-assign overwrite the udev rule for the <snap>, while the list of write_path in <snap>.apparmor.json.additional is just updated
<clobrano> so that udev rule only contains 1 device node at a time
<asac> hmmm
<asac> http://paste.ubuntu.com/12448771/
<asac> Chipaca: mvo_: the above looks pretty garbled formatting wise
<asac> is it possible to improve the way we present multi-line yaml?
<asac> like the content: one for the network interface looks much nicer
<asac> jdstrand: see clobrano's questiona bout hw-assign... feels like a bug
<asac> 6 lines above
<jdstrand> yes, it does
<clobrano> http://paste.ubuntu.com/12448814/
<mvo_> asac: I think the problem is the \t it can only represented in the "" form. looks at the startup above, this is what it should look like
<jdstrand> clobrano: can you file a bug at https://bugs.launchpad.net/snappy/+filebug ? you might add a comment that it is (perhaps) hindering on your progress on the other bug
<clobrano> sure
<clobrano> well, it is not really hindering, I just saw that I had to change device name at each try :D
<dholbach> fgimenez, I'm not sure this helps a whole lot, but I thought I'd share what I was playing around with: https://code.launchpad.net/~dholbach/snapcraft/examples-tests/+merge/271649
<dholbach> fgimenez, great work on adding the examples test
<dholbach> tedg, the qmldemo example is still broken on wily - do you know how to fix it?
<fgimenez> dholbach, i'm looking into it right now, thanks a lot :)
<dholbach> <3
<sergiusens> pitti, you once told me, iirc, that we can enable autopackage tests on PPAs?
<pitti> sergiusens: that's the plan, yes
<pitti> not implemented yet because too many diversions and kernel testing having higher prio
<pitti> sergiusens: but I definitely want this too; might still be a few weeks, though
<sergiusens> pitti, oh, still on paper :-) ah, but sooner than I thought :-)
 * sergiusens puts a 1 month away reminder
<pitti> sergiusens: is this something important/critical for snappy development?
<tedg> dholbach: I think so, I just need to get a wily VM setup
<sergiusens> pitti, we just added lots of tests; we run them before merging but would be nice to run on package build as well
<sergiusens> pitti, so important, but not critical
<pitti> sergiusens: i. e. next week I need to work on prototyping the "run deb chroot on snappy" thingy for the snappy sprint the following week; if this is important, I'm happy to work on that on the sprint and have you test it :)
<sergiusens> pitti, I will defer to elopio on that ;-)
<sergiusens> pitti, sounds good!
<pitti> sergiusens: the mere act of running them is actually fairly simple; it's mostly how to trigger them and what to do with the results which is the interesting bit there
<tedg> jdstrand: Is there a permission to read/write the user's home directory?
<sergiusens> yeah, I hear you, integrating it all together is what mostly blocks things from getting done
<sergiusens> tedg, wrt question, I was thinking that the wrapper for binaries should cd to $SNAP_APP_DATA_PATH (the one in $HOME)
<clobrano> jdstrand: here it is https://bugs.launchpad.net/snappy/+bug/1497299
<ubottu> Launchpad bug 1497299 in Snappy "hw-assign overwrites existing udev rules" [Undecided,New]
<tedg> sergiusens: Why?
<sergiusens> tedg, there was a docker bug that affected that; but yeah; I guess it will break badly in most occasions
<sergiusens> tedg, although no binary can read outside its containment either
<tedg> sergiusens: I think we should probably have a conversation about how we expect UAL to work with core launcher.
<tedg> sergiusens: I'm curious if we want to seperate out "run as a user" and "run as root"
<tedg> sergiusens: For instance, setting the XDG* variables so that most things will "just work" with that being their only writable directory
<kickinz1> tedg, sergiusens docker is not allowed by apparmor to read data outside its own $HOME/apps/docker/version directory.
<tedg> sergiusens: mvo_: Do we have an idea how to finish off this branch? https://code.launchpad.net/~mvo/snapcraft/more-python-apt/+merge/270831
<sergiusens> tedg, I like it already, we just need to trim manifest.txt
<sergiusens> tedg, my brain will explode with this one https://code.launchpad.net/~ted/snapcraft/inception/+merge/271656 :-P
<tedg> sergiusens: Yeah, it's kinda fun. We should run all our tests in the snappy CI service :-)
<sergiusens> tedg, hah, this is rather useless though as we depend on build tools still but rather interesting in itself
<sergiusens> tedg, if we get rid of build tools we can certainly cater for this
<tedg> sergiusens: Yeah, it feels like something we should do. If we want other people to include a snapcraft.yaml in their repos.
<elopio> ev: can we talk about jenkins?
<ev> elopio: sure!
<elopio> ev: I played with the svn config sync plugin and it needs to push to git. For that we need to put the ssh public key of jenkins on launchpad.
<elopio> ev: is that ok for you?
<ev> elopio: I'm confused; what's the security risk you're eluding to?
<elopio> ev: no security risk. Just to push the config to the git branch in launchpad we need the key.
<ev> elopio: and while we're talking about Jenkins, can I ask that you guys focus on getting your Canonistack Jenkins driving daily testing of Snappy through SPI before all the time gets eaten up transitioning to Jenkins as a service?
<ev> I didn't realise this was going to require so much work for you guys, otherwise I wouldn't have suggested Jenkins as a service until we saw a steady stream of results in SPI.
<ev> elopio: can't you have a separate ssh key that you generate for the purpose?
<ev> something like http://superuser.com/a/232406
<ev> oh, I guess when we're dealing with public keys it really doesn't matter
<ev> so yeah, I think it's reasonable for you to put the public key in LP
<ev> +1 :)
<elopio> ev: I'm not sure if I can tell the plugin to use a different key.
<ev> yup, that's fine
<elopio> ev: ok, let me ask for it on an RT.
<ev> cool
<ev> please do CC me
<elopio> ev: what's taking long is that we had a release this week, and we have another next week.
<elopio> so we actually didn't touch ci at all this week.
<ev> elopio: is there anything I can do to help you guys get your tests running daily on SPI?
<elopio> ev: I think not, this was the last question I had. Let me give it another try after the snapcraft release.
 * ev nods
<Chipaca> asac: mvo_: tbh the file-contents-as-value-of-key thing is rather nasty, and i'd change it if we're going to do that long term
<Chipaca> asac: mvo_: ie treat values that are files differently, e.g. yaml points to /1.0/packages/{pacakge}/config/{uuid}, and you GET/POST to .../uuid to operate on the file
<tedg> pitti: Have you talked to the libertine container folks about running deb containers?
<pitti> tedg: libertine? no, I didn't (I don't even know what that is)
<pitti> tedg: running it as an actual container is fine; but AFAIUI sabdfl suggested running them in a chroot with shared processes
<mvo_> Chipaca: I don't follow, sorry. but I'm in a meeting rightnow so maybe I just need to re-parse this
<pitti> so that from within that you can "admin" snappy
<tedg> pitti: It does both, depending on kernel version
<pitti> this comes at quite a high cost and loss of reliability, though
<tedg> pitti: Basically it is the same feature for phones
<tedg> pitti: It would be nice if we had one set of this code :-)
<asac> Chipaca: yeah sounds reasonable
<asac> Chipaca: like a resource:// thingy
<asac> is there any yamnl extension that is standard for such?
<pitti> tedg: ah, https://launchpad.net/libertine ? thanks for the pointer, I'll look at that
<tedg> pitti: You should chat with ChrisTownsend about it some
<tedg> pitti: I think they're basically the same goals, it'd be nice if we converged on one solution for phone/snappy
<ChrisTownsend> pitti: tedg: Yeah, I'm here.  bregma too
<pitti> tedg: not sure -- this sounds like you actually want to containerize and isolate this
<pitti> tedg: but either way, I'll look at this and talk to ChrisTownsend, thanks
<tedg> pitti: It started more with containers, but because of the old kernels on the phones it grew chroot. So the description might not match the implementation in that regard.
<ChrisTownsend> tedg: Libertine supports both chroot and lxc.
<Chipaca> dunno
<ChrisTownsend> pitti: FYI, I'll be around today, but off next week.  bregma can definitely help too.
<pitti> ChrisTownsend: does this do anything like discovering sysv init and systemd jobs in the chroot and start them from the host, but properly chrooted?
<pitti> ChrisTownsend: that seems to be the most brittle/heuristic aspect of all
<pitti> ChrisTownsend: for what Michael and Mark have in mind, it's probably better to actually start the deb env as a proper container with all services and its own init, but then provide a mode to just chroot into it if you want to do snappy admin/devel
<pitti> that's the model which seems most robust to me and still reasonably fulfill the requirements
<ChrisTownsend> pitti: Wouldn't we want to use LXC instead of a chroot?
<ChrisTownsend> pitti: The chroot is only intended for kernels that don't support unprivileged LXC's.
<pitti> ChrisTownsend: with LXC you can't see/admin the host processes and bits; AFAIK this was the raison d'Ãªtre for this
<pitti> ChrisTownsend: oh, and it's certainly a privileged container
<dholbach> fgimenez, I could imagine that the problem has to do with the fact that the examples directory is not mentioned in setup.py anywhere, but I'm not 100% sure yet
<tedg> pitti: I was wondering if we could setup snappy-remote to make it so that it would know it is in an embedded situation.
<ChrisTownsend> pitti: Hmm, ok.  I really don't have any sense of your requirements, so I may be off base in my replies:)
<tedg> pitti: So then you could manage your snappy system, but it'd actually be using REST.
<pitti> ChrisTownsend: the idea of that was not to treat some debs as an "app", but to provide a "classic ubuntu" like environment for development and admin'ing snappy
<pitti> mvo_: ^ right?
<tedg> pitti: I think that sabdfl's concern was being able to manage the core system from the container.
<pitti> ChrisTownsend: well, neither have I, I'll mostly come to this as a consultant :)
<mvo_> pitti: yes, right, its a full environment to "sh" into
<ChrisTownsend> pitti: lol, ok
<pitti> tedg: right; so it can't be a container when you get a shell into it
<tedg> pitti: It could if the snappy tool used the REST interface transparently.
<pitti> tedg: that doesn't preclude actually booting it as a container, so that you have the .deb services running properly
<dholbach> fgimenez, or integration-tests/manage.py maybe
<mvo_> pitti: and one use case if e.g. install and run tcpdump on snappy
<mvo_> pitti: or install strace/gdb etc
<pitti> right
<tedg> Hmm, strace is trickey
<pitti> so for that mode you'd chroot into the root fs; you would see the snappy pids, but can't do /etc/init.d/apache2 restart (you need a "container shell" for that)
<tedg> mvo_: So it would have to be completely unconfined
<pitti> so it's always a bit weird
<pitti> yes, this isn't a security thingy -- you want full access
<tedg> mvo_: Is the concern that you'd need gdb/strace for things already installed as snaps, or for building debugging them?
<pitti> both I think
<ChrisTownsend> I'm thinking the way we make libertine containers may be too confining for this purpose.
<pitti> yeah, it's two rather different use cases
<ChrisTownsend> We make an unprivileged chroot and only bind mount a few necessary host dirs.
<mvo_> tedg: worth clarifying in budapest, but my understanding was that it is intended to troubleshoot a existing system
<pitti> ChrisTownsend: libertine basically is a snap for a bunch of debs, treated as an "app", right?
<tedg> pitti: Well the idea is that it maintains a container long term, so you end up apt-get'ing more over time.
<tedg> pitti: So it's not a one-shot type thing.
<pitti> well, I'll take a look at it either way
<pitti> I don't feel that this "deb env on snap" thing will be a lot of code, it's just getting the concept right
<pitti> thanks for your input! /me needs to leave now
<tedg> 'night pitti !
<elopio> sergiusens: tedg: could there be a way for a snapcraft.yaml to include another snap?
<tedg> Man I hate my wifi
<tedg> Oh, oh! An inception2 branch!
<sergiusens> elopio, crazy talk
<sergiusens> elopio, just use reusable parts ;)
<sergiusens> elopio, the snap as a binary or the snap layed out as an overlay?
<tedg> I mean we could decompress it and just copy the same files into the new snap.
<tedg> The potential use I could see is that someone wants to include a particular version of a framework.
<elopio> sergiusens, tedg: I don't know. I'm just thinking. Lets say I want to test hello-world.snap. Maybe I don't want to put the test binaries in the production snap because they import testtools and a lot of other stuff.
<elopio> so, maybe I could write a test snap that includes the production snap.
<elopio> then I install hello-world-test.snap. And it has both the production and test binaries.
<tedg> I was thinking that perhaps we could have a plugin you could add to your snapcraft that would do some testing things. Like run the bins under gdbserver.
<tedg> That's kinda how QtCreator does things. It builds a new click that has the gdbserver connection setup.
<tedg> Then it connects to that.
<elopio> that sounds cool. But not what I'm after here. I want a test that runs the binary and checks the output. And a test that starts the service and makes requests to it.
<tedg> Hmm, would you want that to be an external package then?
<tedg> foo.snap and foo-tests.snap
<elopio> tedg: maybe. For small tests that don't have a lot of dependencies, I can just add a binary foo-test to foo.snap.
<elopio> but for complex things, like a full suite on the docker snap. We probably want to import a testing framework, and testing helpers. For that I would like a docker-tests.snap.
<tedg> I wonder if we just make it super easy to make that foo-tests.snap and then you don't care how small/big it is.
<elopio> but that docker-tests.snap should have access to everything docker.snap has. And we don't have dependencies to say docker-test.snap depends on docker.snap, so I'm thinking we should bundle docker.snap inside docker-tests.snap, somehow.
<elopio> tedg: that foo-tests.snap it's super easy to make with snapcraft already, just a python project gives us everything we can possibly need.
<elopio> but how to call foo from foo-tests.snap?
<tedg> foo-tests.run
<tedg> It would have to export its own binary
<fgimenez> dholbach, mmm i think it has to do with the examples directory not being available from plainbox's ${PLAINBOX_PROVIDER_DATA}, the symlink at http://bazaar.launchpad.net/~fgimenez/snapcraft/build-examples-test/view/head:/integration-tests/runtests.sh#L40 is not properly created
<elopio> tedg: right, how to call foo.run from foo-tests.run if foo.snap is not installed.
<elopio> oh wait, I'm sorry. You are working on the release. I forgot I said we will discuss about this next week.
<elopio> tedg: sergiusens: I'll add a meeting to the calendar.
<tedg> elopio: Wait, why don't you install foo.snap ?
<dholbach> fgimenez, my last hypothesis was that the examples directory was missing because it wasn't mentioned in neither setup.py nor integration-tests/manage.py, but that might be my lack of understanding of plainbox
 * tedg wants to install all the foo's!
<dholbach> I need to go now though, dinner with the whole family
<dholbach> have a great weekend everyone!
<elopio> tedg: the runner would have to know that if you install foo-test.snap, you also need foo.snap installed. That maybe is not a big deal, but sounds like old world dependencies.
<elopio> tedg: and one thing I don't know is if foo-test.snap would be able to access the data files of foo.snap. And would it have permission to call foo.run?
<tedg> elopio: It wouldn't by default, but I think that foo-test.snap could be unconfined.
<tedg> elopio: We really don't need confinement there.
<elopio> tedg: we have used unconfined tests in nice ways on the phone. I like that.
<elopio> on the other hand, if you are confined to the same things that your test subject is, that will give you a view closer to the consumer of that subject. And you could push the tests to the store.
<tedg> Sure, I guess I feel the most important part is that the foo.snap stays in its natural confinment. Even if we peak in, we want it to run as closely to the real world as possible.
<tedg> As soon as we adjust its snap in anyway, we're getting away from that.
<elopio> that's true.
<elopio> and bundling it into another snap doesn't leave it untouched at all.
<sergiusens> elopio, tedg I would make snap testing at this stage more like blackbox testing in any case; check snappy [config|service|...]
<elopio> sergiusens: I want this to be blackbox, always. But how would you install those blackbox tests into the snappy board?
<elopio> ev: we don't know where the public ssh key is. Can you please give us a hand?
<sergiusens> elopio, composing the snap is not a good idea; you will most likely need to change apparmor rules and such
<sergiusens> elopio, drive it externally; use ciaas?
<elopio> sergiusens: yes, tedg made good points about that. I don't like it now.
<elopio> sergiusens: do you mean like we do for snappy? Use something like adt-run that will copy the tests into the testbed?
<elopio> or do you mean to write the tests using only snappy-remote and ssh?
<tedg> barry: So we want to be able to set "sys.executable" before running setup.py. Is there a good way to do that?
<tedg> barry: I was hoping I could use python3 -c, but that doesn't seem to get the order of operations right.
<tedg> I probably should use "right" since this is kinda a hack :-)
<plars> ogra_: https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2 is still correct on building rpi2 images? the oem and device bits especially?
<ogra_> plars, well, ther versions are outdated, but the rest is fine
<ogra_> http://people.canonical.com/~platform/snappy/raspberrypi2/ has the bits
<plars> ogra_: do you know when those will be in the store?
<ogra_> this will stay valid for another week or two until we start building automatically
<ogra_> the pi2 snap is in the store already
<ogra_> you can use that one as well (but it is the same)
<plars> ogra_: so you don't need to download them separately now?
<ogra_> the snap
<ogra_> you still need the device tarball ... we commited the first bits to system-image today for that bit
<plars> ogra_: ah, so that will still be needed for a while I guess? :(
<ogra_> well, next stable release will be fully integrated
<plars> cool
<barry> tedg: sys.executable gets set from argv0.  on linux i don't believe there's an easy way to override that before the runtime starts up (there is on osx)
<tedg> barry: Can I do it in some sort of wrapper script?
<tedg> barry: I'm looking at the import stuff and it seems to be all for importing modules.
<tedg> barry: Where I just want to import a script.
<barry> tedg: right, importlib is all about importing modules.  i think you could do it in a wrapper that calls exec with the intended argv0
<barry> tedg: but, why do you want to set sys.executable?  usually that just comes from the shebang line or the prompt
<tedg> barry: The problem is that setuptools is pulling it when we're building the snap, which then is the path to the build version and we want to to be the path of the installed version when on the final system.
<barry> tedg: did you see that setuptools supports --executable (iirc) which lets you set that explicitly?
<tedg> barry: In theory, but I couldn't get it to work really. It seems to be building the cmdline tools at install time instead of build time, and the parameter only works on build.
<tedg> barry: I don't get anything in usr/bin of the build directory
<barry> tedg: ah.  well, that's less than helpful ;)
 * barry thinks
<tedg> Hmm, doesn't seem subprocess allows setting arg0 to a different value.
<barry> tedg: right, i think you need to use os.exec*()
 * tedg takes the kid gloves off
 * barry digs through setuptools
<barry> tedg: http://stackoverflow.com/questions/28575431/setuptools-entry-points-console-scripts-have-specific-python-version-in-shebang
<barry> i haven't tried it but that's a new one for me
<sergiusens> barry, fwiw, I saw the sys.executable trick in a debian bug
<barry> sergiusens: "sys.executable trick"?  means setting that attribute early enough?
<sergiusens> barry, yeah, import sys\nimport setuptools\nsys.executable = 'path_to_exec'\nsetup(...)
<sergiusens> barry, here it is http://stackoverflow.com/questions/17237878/changing-console-script-entry-point-interpreter-for-packaging
<barry> sergiusens: oh that's cute
<sergiusens> tedg, btw, seem pyversions -r would solve the python3.4/3.5 issue
<barry> py3versions
<barry> but that doesn't take a -r
<sergiusens> -i I guess then
<barry> would you want the default python3 version? or will you allow people to select 3.4/3.5?  (note that wily can have both installed, and 3.4 is going away for X)
<tedg> Cool, good. That was next on my list of things to fix.
<tedg> barry: If they grab the default python3 plugin we'll grab what ever is default.
<barry> tedg: ack
<tedg> barry: But we allow people to grab any package they want, so eh, whatevs
<tedg> I really don't want to be writing a shell script to call a python script to call python.
<barry> tedg: i think writing/amending the setup.py is probably the better way
<barry> not great, but better
<barry> tedg: this seems like a possible upstream related bug: the
<barry> https://bitbucket.org/pypa/setuptools/issues/204/support-for-interpreter-argument-in
<tedg> Yeah, that seems related.
<tedg> console scripts is slightly out of the fold.
<asac> sergiusens: around?
<barry> tedg: https://bitbucket.org/pypa/setuptools/issues/272/generated-script-shebang-line
<tedg> Cool, thanks barry
<barry> tedg: jaraco is a local python dev and we've got a hackathon next week.  i'll ping him personally about it (if i can remember :)
<tedg> barry: We should be landing most of the python snapcraft bits today/early next week. It'd be interesting to get some feedback at the hackfest about it.
<tedg> barry: Those are the people we want to delight :-)
<barry> tedg: awesome!  i'd love to take a closer look.  will you be sending more details to the mailing lists, or is there a wiki i can look at?
<tedg> barry: We're working on docs. I think when those get real we'll spam the world.
<tedg> barry: As an example you can kinda see things with the examples
<barry> tedg: sounds great.  i will help spread the word
<tedg> barry: Heh, that was bad English
<tedg> barry: We have examples :-)
<barry> :)
<tedg> barry: I think the other thing that will be interesting for Python folks is that we're going to allow builds in LP, but that can pull deps from non-archive sources. So using pip or whatever.
<tedg> That's in progress, but a big change that folks have wanted.
<barry> tedg: that's *very* interesting
<tedg> Yeah, I'm super excited about it. But really cjwatson did all the work. I'm just being a fan boy.
<barry> we're all cjwatson fanboys here :)
<fgimenez> nice weekend everyone o/
<elopio> sergiusens: do you mean run clean twice in integration tests?
<elopio> or in unit tests?
<sergiusens> elopio, either or both ;-)
<sergiusens> elopio, just add snapcraft clean to the make-clean test
<elopio> sergiusens: I don't like this many mocks, so I'll do it in integration.
<elopio> sergiusens: yes, on it.
<elopio> sergiusens: pushed. Thanks for the suggestion.
<elopio> Â¿dÃ³nde estÃ¡n hablando de eso? No veo ninguna discuciÃ³n en IRC.
<elopio> *discusiÃ³n
 * beuno blinks
<elopio> wrong channel.
<beuno> :)
<sergiusens> elopio, who was that for :-P
<elopio> sergiusens: balloons. He's learning spanish.
<sergiusens> elopio, ah :-)
<tedg> We should have a snappy-es channel. I really need an excuse to have better Spanish.
<beuno> tedg, I think the plan of record is to slowly just start speaking in spanish and make english look out of place
<tedg> beuno: si, me gusta snappy
<tedg> Is their something similar to "our Spanish snappy overlords"? ;-)
<tedg> Never thought about it, but are their different memes for non-English languages? There must be.
<elopio> https://translations.launchpad.net/snappy
<elopio> galician is winning
<elopio> tedg: this is a good one for you https://s-media-cache-ak0.pinimg.com/736x/1c/ed/4c/1ced4cd96aef0fe01a4a240f9edeb606.jpg
<tedg> Heh, I always find most interesting what doesn't get translated. Like "2fa"
<tedg> elopio: I'm not sure what that woman has to do with the mob.
 * tedg is probably missing some context
<sergiusens> tedg, our standups have mostly spanish speaking people in them anyways ;-)
<sergiusens> we can switch from german to spanish every other day
<tedg> Ha, that won't be confusing.
<tedg> If there's one thing I can say, it is that my Spanish is better than my German.
<elopio> tedg: "that woman" https://en.wikipedia.org/wiki/List_of_El_Chavo_characters#Do.C3.B1a_Florinda
<tedg> Interesting, I had no idea.
<ev> elopio: the system public ssh key? You'll want to file an RT to get that
<elopio> ev: yes, look at the rt CCed to you. They don't know where it is either.
<ev> ha, having a look
<elopio> sergiusens: is this python config part going to be in the wiki?
<sergiusens> elopio, if it can, yes
<elopio> sergiusens: tedg: am I doing something stupid here? http://paste.ubuntu.com/12451892/
<elopio> I'm getting FileNotFoundError: [Errno 2] No such file or directory: '/tmp/socat/snap/./bin/snapd-socat.wrappeâ
<elopio> r'
<elopio> got it, I was missing my binary in the snap:
<elopio> now, what kind of apparmor should I put in this to work?
<sergiusens> elopio, that is an iteration ;-)
<sergiusens> tedg, you don't need the filename stuff for python2/3 plugins themselves?
<sergiusens> elopio, do you mind rechecking this one https://code.launchpad.net/~fgimenez/snapcraft/build-examples-test/+merge/270798 ?
<elopio> sergiusens: that one is not ready.
<tedg> sergiusens: ?
<sergiusens> tedg, I saw your MP; is it possible for pip installed things to provide scripts and us not taking care of that?
<tedg> sergiusens: They won't be binaries, right?
<tedg> sergiusens: It's only the first binary executed that needs it.
<sergiusens> tedg, ah, I can have my snapcraft.yaml be an integrator one that just has a requirements.txt and it installs a binary and and and
<sergiusens> tedg, it is a harder problem to solve though
<tedg> sergiusens: But then you don't have setup.py redoing the shebang
<sergiusens> well, at least not with this mechanism
<sergiusens> tedg, so when using pip the shebang thing is clean?
<tedg> sergiusens: Seems to be
<sergiusens> tedg, ok then; finally some good news :-)
<sergiusens> with python
<sergiusens> ;-)
<tedg> At least for the ones in nova, it seems most of the modules just don't have a shebang.
<sergiusens> btw, if you want to look https://code.launchpad.net/~sergiusens/snapcraft/organize/+merge/271702
<sergiusens> elopio, maybe too ^
<tedg> K, should it delete the copy plugin?
<sergiusens> tedg, not sure we want to yet, do we?
<sergiusens> tedg, if we remove the copy plugin we need to drive everything through a makefile
<sergiusens> tedg, or of what type would the project be?
<tedg> Hmm, yeah... not sure.
<sergiusens> this was the question that I accidentally skipped from my notes earlier today
<tedg> Was thinking the non-specified type, but we kinda play tricks with that right now.
<sergiusens> tedg, yeah, no type means something different now
<sergiusens> tedg, we can have the 'nothing' type ;-)
<tedg> 'notnull'
<sergiusens> hmm, 'nop'
<sergiusens> :-)
 * tedg gets with the program 'nada'
<sergiusens> nada is good :-)
<sergiusens> tedg, hmm, moot to remove the copy plugin though; as we move, not copy
#snappy 2015-09-19
<ogra_> sigh
<ogra_> (amd64)ogra@aleph2:~$ sudo htop.htop
<ogra_> aa_change_onexec failed with -1
<ogra_> . errmsg: No such file or directory
 * ogra_ doesnt get it 
<ogra_> sergiusens, do we have any example how to use multiple bits with the ubuntu plugin ? i always end up with "Error: parts spamassassin and postfix have the following files in common:" (followed by a list of files both use)
<ogra_> perhaps my snapcraft.yaml is wrong though http://paste.ubuntu.com/12467912/
<sergiusens> ogra_, use ppa:snappy-dev/tools-proposed and http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/docs/your-first-snap.md
<sergiusens> ogra_, might be better off ;-)
<ogra_> sergiusens, well, the readme is identical to the doc
<ogra_> https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/
<ogra_> oh, i use the snapcraft daily PPA
<ogra_> hmm
#snappy 2015-09-20
<ogra_> yay
<ogra_> bip from a snap ^^
<ogra_> hah, snappy update works like a charm too :D
<ogra_> hello snappy-bip !!!
<ogra_> :)
<ogra_> ok, now on to integrate the package with snappy config ...
<ogra_> sergiusens, does snapcraft alerady have integration for meta/hooks/config ?
<sergiusens> ogra_, yes, look at the example in webcam-webui
<sergiusens> ogra_, https://code.launchpad.net/~sergiusens/snapcraft/config/+merge/271752
<sergiusens> ogra_, it is basically config with relative path to runnable and args
<ogra_> ah, cool, thanks
<sergiusens> np
<sergiusens> snappy-bip, who are you?
<sergiusens> :-)
<ogra_> my bip server in a snap :)
<ogra_> not fully functional yet
<sergiusens> nice
<sergiusens> well I'm off to a family lunch, I'll bbl :-)
<snappy-bip> moo
<ogra_> yay
<ogra2> hrm
<ogra_> https://code.launchpad.net/~ogra/+junk/ircproxy
<ogra_> :D
#snappy 2016-09-19
<mwhudson> mcphail: according to the mailing list it's supposed to be $SNAP_USER_COMMON but it doesn't work right now
<mwhudson> mcphail: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1611063
<mup> Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1611063>
<notadeveloper> is video acceleration available in snappy
<mup> Bug #1624963 opened: pulseaudio interface (still) missing permissions <Snappy:New> <https://launchpad.net/bugs/1624963>
<mup> PR snapd#1939 opened: Update documentation on testing snapd <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1939>
<mup> Bug #1602752 changed: Add support for timezone-read interface <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1602752>
<mup> PR snapd#1939 closed: Update documentation on testing snapd <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1939>
<mup> PR snapd#1937 closed: image: ensure local snaps are put last in seed.yaml  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1937>
<mcphail> mwhudson: thanks!
<dholbach> hey hey
<stub> When I say 'Snap Store' in my documentation, what URL should I be linking to?
<mup> PR snapd#1938 closed: asserts: check that validation assertions are signed by the publisher of the gating snap <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1938>
<mup> PR snapd#1940 opened: asserts: define a bit less terse Ref.String <Created by pedronis> <https://github.com/snapcore/snapd/pull/1940>
<zyga> mwhudson: hey :)
<zyga> mwhudson: I'll work on release today :) happy to finally reach this point
<mup> PR snapd#1932 closed: add HACKING.md and move content from README.md over <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1932>
<zyga> jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/147
<mup> PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147>
<zyga> lool: https://github.com/snapcore/snap-confine/pull/147
<mup> PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147>
<mwhudson> zyga: oh yeah, you'll need to find a DD to do the thing that lets you upload the package
<zyga> mwhudson: I need to refresh my memory on the process
<zyga> mwhudson: I'll do a sdist release without tagging as soon as 147 lands and do a round of packaging and distro testing
<zyga> mwhudson: then officially tag and start pushing downstream
<mwhudson> zyga: https://wiki.debian.org/DebianMaintainer#Granting_Permissions
<mwhudson> zyga: sounds good
<zyga> thank you!
<mup> PR snapd#1920 closed: --lazy is only available with -l in trusty <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1920>
<mup> PR snapd#1873 closed: interfaces: disable auto-connect in libvirt interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1873>
<mup> PR snapd#1940 closed: asserts: define a bit less terse Ref.String <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1940>
<ogra_> cjwatson, looks like LP tries to upload the .manifest files now (thanks for publishing them !) ... i got mails from tonights auto-builds: " __all__: The upload does not appear to be a valid package."
<ogra_> mvo, could you approve https://myapps.developer.ubuntu.com/dev/click-apps/5912/rev/3/ ? and give me upload access to the beagleblack gadget (i have a working beagle image here)
<mvo> ogra_: we probably need to republish the beaglblack under a different publisher, e.g. beagleblack.ogra ? or just beagle.ogra or something
<ogra_> mvo, ok, i can do that
<mvo> ogra_: great, thank you
<lool> zyga: thanks for adding secure_getenv; wanted to do it over the week-end but ended up debugging other things
<zyga> matteo: hey
<matteo> hi zyga
<zyga> matteo: would you mind doing a quick test build of snap-confine from this branch https://github.com/snapcore/snap-confine/pull/147/files
<mup> PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147>
<zyga> matteo: I will do a release shortly, I just want to make sure it works outside of glibc
<matteo> you mean with MUSL?
<zyga> yes
<matteo> I'm using glibc on OpenWrt, but I can rebuild the toolchain
<zyga> matteo: hmm, I thought that openwrt used musl
<zyga> lool: ^ where did you end up using musl?
<matteo> sure, by default
<lool> zyga: I can do a build with musl
<matteo> but I switched to glibc to be sure that it works
<lool> after lunch
<zyga> lool: thanks
<zyga> matteo: I see, thanks
<zyga> matteo: I guess lool will do the check
<matteo> zyga: I didn't want to add extra entropy to the system :D
<zyga> hehe :)
<zyga> is openwrt ususally using musl?
<timothy> openwrt can also use uclibc
<ogra_> mwhudson, in bug 1624329 i dont want you to fix firstboot ... thats mvo's job i guess :) but i want the network device to work after i plugged in a cable (it doesnt, even if i cancel console-conf to have it start over from scratch)
<mup> Bug #1624329: snapd firstboot setup fails constantly when rebooting before console-conf has finished <Snappy:New> <snapd (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1624329>
<mwhudson> ogra_: that's super odd
<mwhudson> (the device not appearing)
<matteo> timothy: time ago, now it's dropped it for most architectures
<timothy> you can still choose it from make menuconfig
<matteo> it's the default on archs unsupported by MUSL
<mwhudson> ogra_: to get the devices it just does (roughly) pyudev.Context().list_devices(subsystem='net')
<ogra_> it appears but i cant configure it
<mwhudson> ogra_: there's nothing cached between invocations...
<matteo> yes, you can choose it if you really like broken C libraries
<ogra_> weird
<mwhudson> ogra_: i finally dug my dragonboard out today so i can experience some of your pain more faithfully tomorrow :)
<ogra_> hah, great
<ogra_> i'm just playing with a beaglebone image here ... thats even more odd
<mwhudson> i have a pile of hardware that i think strictly speaking belongs to linaro
<mwhudson> a panda, beagleboard xm, arndale
<ogra_> (beautiful oopses on boot and no network device at all ... )
<ogra_> (on second boot all is fine ... but then firstboot is already in a wonky state)
<mwhudson> ogra_: how do you connect to dragonboard serial?
<mwhudson> i have a fdti thing but i never got it to work
<ogra_> with the mezzanine board that got shipped along :P
<mwhudson> ah heh clearly i bought mine too early
<ogra_> well, the company bought mine
<mwhudson> well yes, mine too
<mwhudson> but it was before that sort of thing was available
<mwhudson> ogra_: this one? https://www.seeedstudio.com/96Boards-UART-p-2525.html
<ogra_> yep
<zyga> mwhudson: it's fiddly
<zyga> mwhudson: I had mine but it's easy to make it not work
<zyga> mwhudson: as a quick test, check if the daughter board works by itself
<zyga> mwhudson: I also found that the board has to be aligned properly vertically, it can easily bend back and forth and this makes the connection fail
<mwhudson> zyga: can't possibly be more fiddly than the http://www.digikey.co.nz/product-detail/en/ftdi-future-technology-devices-international-ltd/TTL-232RG-VIP-WE/768-1069-ND/2441358 i was trying to use before
<ogra_> mvo, http://paste.ubuntu.com/23202066/ ... could we make the firstboot service run after console-conf somehow ?
<zyga> mwhudson: heh, well, you can always use those simple ftdi cables with female connectors
<mwhudson> ogra_: that's netplan segfaulting?
<mwhudson> zyga: ?
<ogra_> mwhudson, thats a kernel oops of the NIC ... my prob is that firstboot is from then on broken, even if i have a boot without oops
<zyga> mwhudson: a usb serial from ftdi where each connector is a separate cable with female connector, just plug those over and it should work
<zyga> mwhudson: (just make sure not to fry the board)
<mwhudson> zyga: huh i didn't see that one when i was looking ~15 months ago
<mwhudson> anyway i'll try the one i have and order a mezzanine if i can't make it work
<zyga> mwhudson: http://www.aliexpress.com/store/product/USB-to-TTL-Serial-Cable-Adapter-FTDI-Chipset-PL2303HX-USB-Cable-Computer-Cable/1180713_1889042442.html
<zyga> mwhudson: something like this
<mvo> ogra_: hm, that would make sense, this way we have ntp hopefully
<mwhudson> zyga: the dragonboards connectors are themselves female aren't they?
<zyga> hmmm, are they? sorry I don't have one in front of me
<zyga> (there are male variants of the thing as well)
<ogra_> mvo, well, i dont care that much about ntp ... more about having network at all
<ogra_> ppisati_, http://paste.ubuntu.com/23202086/ ... beaglebone (with linux-generic xenial)
<ppisati_> cking: ogra_ :O
<ppisati_> ops
<ppisati_> ogra_: :O
<ogra_> yeah :/
<cking> ?!
<ogra_> i blame pitti .... netplan tries to start the network :)
<ppisati_> ogra_: yeah, put the blame on pitti
<ogra_> hehe
<ogra_> let me build a public image so you can tinker with it
<ppisati_> ogra_: ta
<ogra_> (gimme 10-15min)
<ppisati_> ogra_: is that a beaglebone black?
<ogra_> yep
<ppisati_> k
<ogra_> with 4.4.0-36-generic
<ogra_> it works better on subsequent boots btw ... on first boot i always get the oops, reliably ... on subsequent ones it only happens very random
<ppisati_> weird
<ogra_> yep
<ogra_> ppisati_, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has the beagle image now
<mup> PR snapd#1941 opened: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <https://github.com/snapcore/snapd/pull/1941>
<ppisati_> ogra_: cool, i'll give it a spin
<ogra_> mvo, hmm, looks like it would just help if firstboot.go wouldnt create an empty state.json file when there is no network ...
<ogra_> mvo, if i do: "sudo rm /var/lib/snapd/state.json && sudo systemctl restart snapd.firstboot.service && sudo reboot" it works fine
<cjwatson> ogra_: Hm, that exact message doesn't appear in the LP source tree.  URL to the failing build?
<ogra_> i have four of them ... one sec ...
<ogra_> https://launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/5109
<mvo> ogra_: yeah, three are some easy wins here
<ogra_> equally 5107, 5108 and 5110
<cjwatson> ogra_: Ah, right.  Please file a bug against LP itself - we'll need to be more selective about which files we upload to the store
<ogra_> cjwatson, yep ... it is blocking all upload apart from ppc64el and s390x now it seems ... i assume these two dont generate manifests
<ogra_> *uploads
<cjwatson> ogra_: Dropping the manifest temporarily will work around it.
<ogra_> k
<cjwatson> ogra_: But I should be able to fix it reasonably quickly.
<ogra_> thats good enough :)
<ogra_> ok
<ogra_> cjwatson, Bug #1625117 for you
<mup> Bug #1625117: store uploads fail since os snaps publish manifest files <Launchpad itself:New> <https://launchpad.net/bugs/1625117>
<cjwatson> Ta
<mup> PR snapd#1942 opened: Initial support for download deltas (via SNAPPY_DELTA_DOWNLOAD_FORMATS) <Created by absoludity> <https://github.com/snapcore/snapd/pull/1942>
<mup> PR snapd#1943 opened: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1943>
<mvo> seb128: https://github.com/snapcore/snapd/pull/1943 this is what you asked for last week, right?
<mup> PR snapd#1943: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1943>
<mectors> how do I use the content plug to allow a snap to read the directory /root/.certs/?
<ogra_> you would need a snap that provides /root i guess (no, thats not possible)
<ogra_> and i doubt you will have any access to "dot" dirs anyway ...
<mectors> ogra: thanks
<mectors> ogra: how do I execute a script to change a file so I can rewrite the directories?
<mectors> basically execute a sed s/root/$SNAP_DATA/
<ogra_> mectors, i'D use a wrapper script
<morphis_> niemeyer: was about to try the spread snap, how is that supposed to work for local backends like kvm or lxd?
<morphis_> getting errors like: 2016/09/19 14:33:36 Cannot allocate qemu:ubuntu-16.04: cannot launch qemu qemu:ubuntu-16.04: exec: "kvm": executable file not found in $PATH
<mectors> ogra: how does a wrapper script work?
<tenaciousmv> hi. I'm trying to get the nodejs-plugin-based shout demo working: https://github.com/snapcore/snapcraft/tree/master/demos/shout   when I build and install it locally, i don't see anything in /snap/bin afterward
<tenaciousmv> but when i run `snap install shout` instead it works
<tenaciousmv> i used --force-dangerous for the local install
<tenaciousmv> snapcraft v 2.17
<ogra_> mectors, https://github.com/ogra1/laidout ... look at snapcraft.yaml and wrapper.sh there ... thats a very simple wrapper script
<mectors> ogra: thanks
<fearing> found this in my history just seeing what this is
<zyga> jdstrand: hello
<ogra_> ppisati_, btw, bug 1625177
<mup> Bug #1625177: OOPS on beaglebone on boot of 4.4.0-36-generic under snappy ubuntu core xenial <linux (Ubuntu):New> <https://launchpad.net/bugs/1625177>
<jdstrand> zyga: hi!
<zyga> jdstrand: hey, I merged secure_getenv improvement, I noticed your NAK in the morning
<zyga> jdstrand: I'd appreciate a post-merge review of this 3 line function
<zyga> jdstrand: just to be on the safe side :)
<zyga> jdstrand: I'd like to file the bugs for apparmor issues we found last week
<zyga> jdstrand: do you have a preference? is launchpad oka?
<sergiusens> can't you just command do `command: desktop-launch $SNAP/usr/bin/laidout "$@"`?
<sergiusens> err, without the $@
<ogra_> sergiusens, yeah, that snap is super old ... from a time where the desktop-launcher stuff was still in development
<ogra_> and it was only a proof of concept to show someone that i can make a snap from an upstream binary in less than 10min
<jdstrand> zyga: thanks for fixing that. I'll take a look. I filled the apparmor bug already
 * jdstrand looks for it
<ogra_> sergiusens, effectively the wrapper is nonsense there ... at least nowadays (and i doubt with the new laucnehrs it wouldnt even build anymore)
<jdstrand> zyga: https://bugs.launchpad.net/apparmor/+bug/1624497
<mup> Bug #1624497: complain mode blocks access to nsfs (/proc/self/ns/*) without exec rule <AppArmor:Confirmed> <https://launchpad.net/bugs/1624497>
<sergiusens> zyga are you aware of any missing interface work to get tray icons to work? My telegram snap has the forbidden icon since forever and I know that kyrofa has some snaps in that state too
<zyga> sergiusens: no, is there a bug report for this somewhere?
<zyga> sergiusens: I'll check out your snap later today so that I can perhaps see this myseld
<sergiusens> zyga hmm, kyrofa or seb128 I guess would know
<seb128> sergiusens, zyga, could be bug #1600136
<mup> Bug #1600136: App indicator does not show icon for Qt apps <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1600136>
<seb128> it's trying to use /tmp to share the icon
<didrocks> sergiusens: that's what we discussed during the heidelberg sprint (and the bug seb128 referenced). Main issue is this /tmp thing in appmenu-qt
<zyga> jdstrand: one tiny unrelated issue, the base profile doesn't allow xdg-open
<zyga> jdstrand: and the executable in the core snap (which is probably out of date anyway) is in /usr/local
<zyga> jdstrand: I was thinking about adding it to the main template
<zyga> jdstrand: to /usr/bin/xdg-open xi,
<jdstrand> zyga: I would think that the unity7 interface would make more sense. it is only for desktop applications, no?
<zyga> jdstrand: well, I don't know
<zyga> jdstrand: perhaps
<zyga> jdstrand: though at the same time, I don't know
<jdstrand> "xdg-open is for use inside a desktop session only. It is not recommended to use xdg-open as root."
<jdstrand> from it's man page
<zyga> jdstrand: in any case we need to have it somewhere and document it
<jdstrand> please use unity7 for now. we can move it to default if required, but I don't think we will
<jdstrand> also, yeah, moving out of /usr/local would be good too
<jdstrand> I'm not sure how that would work on an actual desktop though...
<zyga> jdstrand: on the desktop there's snapd-xdg-open
<zyga> jdstrand: we need to keep things in sync as AFAIK they drifted apart now
<zyga> jdstrand: I'll try to untangle it
<jdstrand> well, now I'm confused
<jdstrand> ok, so snapd-xdg-open is what snapd provides, not xdg-open?
<didrocks> jdstrand: snapd-xdg-open is the service on the desktop side answering to our fake xdg-open requests over dbus
<didrocks> (and snapd-xdg-open calls the real xdg-open on the desktop)
<jdstrand> so why is zyga requesting we add xdg-open to the policy?
<ogra_> there is one xdg-open *inside* the ubuntu-core snap ... thats the one in /usr/local ... on the desktop side there is /usr/lib/x86_64-linux-gnu/snapd-xdg-open which (as i understand) is supposed to talk to the oone inside the snap
<ogra_> and this is all along with the default xdg-open you have installed on a desktop anyway
<jdstrand> shouldn't the one in /usr/local go away then?
<jdstrand> (in the all snaps image)
<ogra_> well, it should surely move to /usr/bin
<seb128> that one is our small wrapper doing the dbus call
<zyga> jdstrand: yes
<jdstrand> and people just use snapd-xdg-open?
<zyga> jdstrand: I don't know how it managed to get there TBH
<seb128> snapd-xdg-open is on the host
<seb128> not in the snap
<zyga> jdstrand: no, people use xdg-open
<jdstrand> man, this is confusing
<ogra_> ah, well, i dont know if snapd-xdg-open? doesnt need the one inside the snaps
<zyga> jdstrand: that talks to snapd-xdg-open in the distro
<seb128> that's the service listening to the dbus call
<jdstrand> so on all snaps, we call it xdg-open, but it is really a wrapper. on desktop it is snapd-xdg-open cause the real xdg-open is not snapd-xdg-open
<jdstrand> let's back up
<seb128> can't parse that
<jdstrand> what are snaps supposed to use?
<seb128> define snaps?
<zyga> no, it works the same way everywhere
<zyga> or actually
<zyga> no
<jdstrand> a snap of type: app
<seb128> you mean what is a desktop snapped app supposed to use?
<didrocks> jdstrand: you basically have: xdg-open (fake, in /usr/local), called by the snap app <------ dbus --------> snapd-xdg-open (service, activated by fake /usr/local) which execs real xdg-open
<zyga> on classic the core snap has 'xdg-open' that talks over dbus to snapd-xdg-open
<didrocks> the first one is inside the snap/ubuntu-core
<didrocks> the second part of the array is on the destkop
<ogra_> zyga, http://paste.ubuntu.com/23202842/  ... its a buuld time hack
<ogra_> *build
<seb128> didrocks, to be exact that uses gio and doesn't execs the real xdg-open ;-)
<jdstrand> with didrocks explanation, why do we need to add anything to the policy-- the xdg-open that talks to snapd-xdg-open is in the snap
<didrocks> seb128: indeed, to keep the service running :) :p
<seb128> well apparently snapd denies /usr/local/xdg-open to be exec
<jdstrand> seb128: what is the system /usr/local/xdg-open supposed to be used by?
<seb128> random code
<jdstrand> to do what?
<seb128> open an url
<ogra_> /usr/local/bin/xdg-open FWIW :)
<jdstrand> meh
<seb128> random admin script, desktop apps, command line apps do "xdg-open http:...."
<jdstrand> I'm not trying to be obtuse, I'm trying to be very specific. there are several things called xdg-open. zyga wants to adjust the policy. I want to know how the pieces fit together
<seb128> we also associate that wrapper with "http:"
<didrocks> for instance, Qt openUrl() is wrapping qtsubprocess.call("xdg-open url") (or whatever is the correct syntax)
<seb128> jdstrand, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-create-xdg-wrapper.binary
<jdstrand> seb128: so why wouldn't that snap ship xdg-open like snaps on classic do?
<seb128> code might be easier than words
<jdstrand> but that is on classic
<ogra_> that is why i posted it above :P
<seb128> I don't understand that question
<seb128> that wrapper is part of the ubuntu-core image
<seb128> why would snap need to ship it?
<jdstrand> look
<didrocks> seb128: I think jdstrand is asking, why aren't we asking every snap app using xdg-open to ship it as part of the code
<seb128> because it's easier to have it in the base image?
<jdstrand> I understnad what snappy's xdg-open is supposed to do. I'm trying to reconcile classic and all snaps
<didrocks> jdstrand: am I right on your question? ^
<jdstrand> didrocks: you are
<didrocks> I think shipping it on runtime snaps might make sense
<jdstrand> and if it is right to be in the base image, why are we doing things different between classic and all snaps?
<didrocks> as the usage of xdg-open is often by the toolkit
<didrocks> not directly or in a awareness-way by the app
<seb128> that's not true
<seb128> if you look on codesearch.debian.net you can see it's used by stack of random command line tools
<seb128> like mutt
<seb128> or mc
<seb128> or backup script things
<didrocks> yeah, cli ones might do itâ¦
<jdstrand> what is interesting about xdg-open on all snaps is there is no desktop by default
<jdstrand> so shipping it is kinda weird
<seb128> doesn't need to be a desktop for it to work
<seb128> it's just a wrapper to call the appropriate handle
<seb128> that could be links
<jdstrand> the man page for xdg-open says it needs to run in a desktop session
<seb128> we are not using xdg-open though
<jdstrand> but we are meant to replace it
<seb128> we are diverting the command to call our handler that opens a browser
<jdstrand> and a browser isn't on all snaps
<sergiusens> didrocks seb128 thanks
<seb128> how is "open an url" supposed to work on all snaps?
<jdstrand> that's a great question
<jdstrand> I don't think anyone defined that
<ogra_> yeah, thats future work
<jdstrand> (which is what I'm really getting at)
<seb128> can we get the cheap trick we currently have to work then?
<seb128> until that proper job is done
<jdstrand> how would it work?
<seb128> on classic I mean
<jdstrand> you call xdg-open and nothing happens
<zyga> jdstrand: (offtopic): https://github.com/snapcore/snapd/pull/1941
<mup> PR snapd#1941: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <https://github.com/snapcore/snapd/pull/1941>
<seb128> well what we currently have would make urls work on classic
<seb128> if snap-confine wasn't blocking the xdg-open exec
<jdstrand> seb128: yes, of cousre we want it on classic. which is why I suggested unity7, but then didrocks said that snaps on classic should ship it
<zyga> (that's snapd, snap-confine just does what it is told to do)
<jdstrand> seb128: which brings us full circle-- why do we need to allow it in the policy if apps are meant to ship it
<zyga> jdstrand: we don't want snaps on classic to ship xdg-open
<seb128> I disagree with having every app to ship it
<didrocks> I didn't say that, I said if we don't want to ship it on ubuntu core snap, maybe having it as part of the toolkit makes sense
<zyga> jdstrand: because then we are stuck with the interface forever
<didrocks> but seb128 has some good arguments about cli apps
 * jdstrand doesn't care where it is shipped-- just trying to find the right place
<jdstrand> /usr/local is not the right place btw
<jdstrand> that is for admins, not system installed software
<didrocks> I think attente shipped it there because he didn't want to conflict in case we have a "personal snap" shipping the system version
<seb128> that's also where we have you fake "apt" that tells you that apt is not supported
<didrocks> but my memory could be skewed :)
<didrocks> and good point seb128 ;)
<seb128> you->our
<jdstrand> that is an abuse of /usr/local
<seb128> but the reason is probably what did said
<jdstrand> anyway
<seb128> I'm not going to discuss that, it was not my doing but mvo's
<seb128> I'm happy for it to change location
<mvo> jdstrand: /usr/local/bin/{apt,xdg-open} should change location? sure
<jdstrand> that's kinda a side discussion, but it did add to my confusion
<seb128> so summary is
<jdstrand> fyi, nothing in snap-confine mounts /usr/local from the os for classic for that to work anyway (afaics)
<seb128> well, that dir is part of ubuntu-core
<seb128> I didn't try in recent weeks but the fake "apt" command was in the snaps last time I tried
<jdstrand> it is. I'm thinking through what should be done
<seb128> so the ubuntu-core /usr/local/bin was available inside the snaps
<ogra_> but is it in PATH ?
<seb128> yes
<jdstrand> I guess it probably should be in the core snap, but since nothing in all snaps uses it, that makes me slightly uncomfortable, but I guess there is nothing better that can be done
<jdstrand> especially if there is defined future work for making it work on all snaps
<jdstrand> so for now, leaving it in the core snap (but please move it to /usr/bin so we are using the correct locations and for avoiding confusion in the future) and add '/usr/bin/xdg-open ixr,' to the unity7 interface makes the most sense. at least that way if someone on all snaps tries to use it we are suggesting that it isn't supported yet
<jdstrand> that's my opinion. does that make sense to others? ^ (seb128, didrocks, zyga, mvo)
<seb128> jdstrand, that wfm, though it's a crossdesktop thing and used by command line tools often so unsure unity7 is the right interface
<seb128> jdstrand, like mutt would probably end up using it to open an url
<seb128> unsure how much of a big hammer it is to recommend those to use unity7
<jdstrand> seb128: because today the thing it is replacing is documented as requiring a desktop session and because we haven't defined what it should look like without a desktop session
<seb128> right, it should need one
<jdstrand> when we do, it can be moved/added to somewhere else, perhaps the default policy
<seb128> but unity7 give you quite some things
<seb128> but I guess fair enough for now
<jdstrand> it could be a separate interface
<jdstrand> I'm uncomfortable adding it to the default policy because it requires dbus
<mup> PR snapd#1941 closed: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1941>
<seb128> I see
<didrocks> jdstrand: wfm as well
<seb128> well unity7 should do for now
<mup> PR snapd#1944 opened: many: validate refreshes against validation assertions by gating snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/1944>
<jdstrand> zyga: so, sounds like adding it to unity7 is the way to go for now since we only support it on classic desktop atm (a comment saying as much would be good). it sounds like mvo may move it from /usr/local. not sure if that is something you would want to do as part of this
<zyga> jdstrand: OK
<zyga> jdstrand: will do
<jdstrand> zyga: if it would help, I could do it. I always have a list of miscellaneous updates :)
<zyga> jdstrand: if you want to, sure go ahead :)
<zyga> jdstrand: I'm looking at snap-confine SRU paperwork now
<mvo> jdstrand: I can look into the move to /usr/bin later, probably tomorrow morning
<jdstrand> mvo: ok, I'll just add the access to /usr/local and mention in the PR it should be adjusted when it is moved
<mvo> jdstrand: great, thank you
<tenaciousmv> sergiusens: do you know of a nodejs-based snap that works when locally built and installed? See my comment above about shout working only when installed from snapcraft store
<sergiusens> tenaciousmv see your comment where?
<sergiusens> and yes, it works, our tests make sure of that (shout is in demos)
<kyrofa> sergiusens, zyga I'm not sure where was ever a bug filed since we never really got to the point where we knew what was causing the bug. didrocks said it needed some love from the desktop team. I was planning on starting an email thread once I had enough spare brainpower for it
<tenaciousmv> sergiusens: repasting comment: hi. I'm trying to get the nodejs-plugin-based shout demo working: https://github.com/snapcore/snapcraft/tree/master/demos/shout  when I build and install it locally, i don't see anything in /snap/bin afterward
<tenaciousmv> sergiusens: i'm glad the tests pass :) i wonder what i could be doing wrong. I just built, installed (with --force-dangerous) and shout is not in /snap/bin
<seb128> mvo, sorry I forgot to reply to your ping earlier, unsure that's best, I would rather not have to modify the upstream .desktop, what sergiusens suggested and sounded nicer was to have that snapcraft.yaml define the .desktop name and let you override the exec and do the sed-ing for you
<kyrofa> tenaciousmv, the app is a service, which means it generates a systemd unit file instead
<kyrofa> tenaciousmv, it won't put anything in /snap/bin/
<mvo> seb128: works for me, just copy/paste this comment in the PR and I will close it
<tenaciousmv> kyrofa: after snap install shout, i see it in /snap/bin
<tenaciousmv> though `which snap` return /usr/bin/snap
<tenaciousmv> is the verion of shout in the store the one built from the snapcraft.yaml in demos?
<kyrofa> tenaciousmv, no idea. Who is the publisher?
<seb128> mvo, k
<tenaciousmv> kyrofa: sergiusens
<kyrofa> tenaciousmv, I'm not sure what he has there. All I know is that this: https://github.com/snapcore/snapcraft/blob/master/demos/shout/snapcraft.yaml will not put anything in /snap/bin/
<tenaciousmv> kyrofa: right, exactly
<tenaciousmv> kyrofa: so how would you run the shout from the demos after installing it?
<kyrofa> tenaciousmv, it should already be running-- it's a daemon
<kyrofa> (once you install it, obviously)
<kyrofa> I'm not sure about the port, though
<tenaciousmv> kyrofa: so i should be able to see it in service --status-all then no?
<tenaciousmv> kyrofa: thx for helping btw
<kyrofa> tenaciousmv, now sure what the `service` command does nowadays, but you should be able to see if with `systemctl status snap.shout.server.service` I think
<kyrofa> s/if/it/
<tenaciousmv> kyrofa: indeed, i see it!
<tenaciousmv> kyrofa: is there an example of a nodejs app (not a daemon)?
<kyrofa> tenaciousmv, not that I know of off the top of my head, but you could make the shout one an example if you simply remove the `daemon: simple` line
<tenaciousmv> kyrofa: ah, duh. Thanks!
<mup> PR snapd#1943 closed: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1943>
<sergiusens> tenaciousmv that demo doesn't setup anything to be in snap/bin
<tenaciousmv> sergiusens: yea, kyrofa explained it to me. I missed the daemon line in the snapcraft.yaml
<sergiusens> tenaciousmv shout on the store is in my repo, not in the demos
<tenaciousmv> sergiusens, ok will check it out
<mup> PR snapd#1945 opened: Spread out to trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1945>
<mup> PR snapcraft#811 opened: Support deb files as sources <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/811>
<sergiusens> ogra_ ^ for you
<sergiusens> morphis and maybe you too ;-) ^
<ogra_> bug 1604669
<mup> Bug #1604669: Support Installing a local deb package in the snapcraft <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1604669>
<ogra_> ah
<sergiusens> ogra_ ;-)
<ogra_> :)
<jdstrand> seb128: fyi, http://paste.ubuntu.com/23203145/. the all snaps one is more justification that this should still be in unity7 for the moment. the second is on my desktop with snapd 2.14.2
<seb128> k, makes sense
<seb128> jdstrand, your desktop doesn't have snapd-xdg-open installed right?
<seb128> (we don't depends/recommends it afaik)
<jdstrand> no
<seb128> that's something we should change
<jdstrand> perhaps we should on classic?
<seb128> yes
<seb128> mvo, ^ would you be the right person to add snapd-xdg-open to the snapd recommends?
<jdstrand> snapd-xdg-open doesn't appear to be a package in xenial
<seb128> it's in universe
<seb128> https://launchpad.net/ubuntu/+source/snapd-xdg-open
<seb128> oh, in xenial
<seb128> it's in xenial-proposed only
<jdstrand> I see
<seb128> the SRU verification relies on having the wrapper in the ubuntu-core image and working
<mhall119> lool: did you say there wouldbe RPi3 images of snappy ubuntu core today?
<tedg> I'm trying to put a slot on a snap, but it doesn't seem to show up in "snap interfaces" list
<tedg> Does anyone have a snapcraft.yaml of putting a slot on a snap that I could crib from?
<lool> mhall119: at least pi2; I'd hope pi3 as well
<lool> zyga: FTBFS with musl: http://paste.ubuntu.com/23203170/
<lool> zyga: missing include probably?
<lool> I'll double check I have the right version pulled from the build
<jdstrand> pcoca: hi!
<jdstrand> pcoca: do you have a moment to talk about bug #1613572 ?
<mup> Bug #1613572: sandbox denials for snaps on BTLE device <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1613572>
<mup> PR snapcraft#805 closed: Refresh discharge macaroon if necessary <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/805>
<mhall119> lool: when and where will those be available?
<lool> zyga: http://paste.ubuntu.com/23203191/
<tedg> Huh, seems that mongo22 doesn't have a slot either.
<lool> zyga: right, you missed #include secure-getenv.h in sc-main.c
<ogra_> mhall119, dailies (built from the edge channel) are at  http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ .. and beta releases are just being announced by mvo
<ogra_> http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
<mhall119> thanks ogra_
<tedg> bluez does, cribbing from there
<lool> zyga: adding the #include is enough to fix build http://paste.ubuntu.com/23203216
<lool> it fails in other components later
<lool> zyga: http://paste.ubuntu.com/23203233/
<popey> mhall119: https://lists.ubuntu.com/archives/snapcraft/2016-September/001166.html :)
<mhall119> literally 10 minutes ago, that's timing :)
<zyga> lool: looking
<zyga> lool: oh, indeed
<zyga> lool: thanks, I'll put that into the relase
<zyga> lool: pushed
<lool> zyga: lovely, thanks
<lool> updated my openwrt feed to point at it
<lool> mhall119: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
<lool> ah too late
<ogra_> lool, yeah, and lame too ... http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has so many more exciting bugs
<mhall119> lol
<diddledan> I've reordered the list on https://github.com/ubuntu/snappy-playpen/wiki/SandPit to be alphabetical (also added my attempt at corebird to the list)
<oparoz> Hello, what's the difference between mvo's all-snaps images and the ones available at cdimage?
<ogra_> oparoz, the cdimage ones are official beta images
<ogra_> the mov all-snaps ones are obsolete
<ogra_> *mvo
<oparoz> Thanks ogra_ . Does that mean that zyga's script to built images can be updated to point to the beta images? https://github.com/zyga/devtools/blob/master/ubuntu-image
<ogra_> oparoz, use http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ or if you like to live on the edge use http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<ogra_> everything else is dead beef and not supported anymore
<oparoz> :)
<ogra_> since they would be using  the wrong creation tool
<oparoz> wrong creation tool?
<dduffey> hi, I've tried various snappy 16 pi3 images but they all hang at the 4-rasberry screen
<dduffey> lool, ^^^ what image are you using/
<lool> dduffey: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current is latest
<lool> dduffey: you want serial console rather than console
<lool> but I suppose console should work
<ogra_> yeah
<ogra_> dont use embedded boards without serial
<ogra_> general rule of thumb
<dduffey> lool, okay
<tbr> +1 for UART
<tbr> those things are dirt cheap
<ogra_> yeah
<ogra_> oparoz, sudo snap install ubuntu-image --devmode --edge ... then you need to create a signed model assertion and have a proper new gadget.yaml following the new format
<dduffey> lool, thanks ... I am using that image ... normal for it not to hit the network until I plug in a serial console and setup networking, correct?
<ogra_> dduffey, you need to run through the console-conf tool, yes
<ogra_> else you dont have a user either
<lool> dduffey: yes
<oparoz> Thanks ogra_ . I think I'll just wait for you guys to provide the pi2 gadget and updated partitioning script to use an external HD :)
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/ is up to date ... regarding the gadget :)
 * ogra_ calls it a day
<oparoz> Thanks ogra_
<ogra_> np
<mup> PR snapcraft#812 opened: New plugin: jhbuild <Created by attente> <https://github.com/snapcore/snapcraft/pull/812>
<mup> PR snapd#1926 closed: tests: add https_proxy into environment as well <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1926>
<mup> Bug #1625279 opened: cmd_run.go:179: WARNING: cannot create user data directory: cannot create "/home/$USER/snap/$SNAP/$VERSION": mkdir /home/$USER/snap/$SNAP: permission-denied <Snappy:New> <https://launchpad.net/bugs/1625279>
<tyhicks> zyga: congrats on the release :)
<sergiusens> so jdstrand or zyga is there a plan of action for LP #1600136 ?
<mup> Bug #1600136: App indicator does not show icon for Qt apps <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1600136>
<jdstrand> sergiusens: not from me. I gave several ideas on how the desktop team/someone familiar with the technologies could pursue
<jdstrand> sergiusens: but no one responded
<jdstrand> ultimately, the snaps are putting things in /tmp and that isn't the same /tmp that the system would see
<sergiusens> jdstrand oh really, it might be a communication breakdown problem then as I suspect the desktop folk were pointing the other way
 * sergiusens checks the bug report
<jdstrand> well, I'm happy to discuss ways forward, but this is basically the same as all the stuff going into the desktop part. trying to make traditional applications that aren't designed for application isolation work
<jdstrand> I suspect upstreams would be interested in patches because this would affect any sandboxing mechanism that uses a private /tmp (which is all of them afaik)
<sergiusens> jdstrand I am going to play with my preload part and see what I can do; but patching upstreams would be ideal ;-)
<sergiusens> in the case of telegram they already fork and patch Qt so I will try and see if they can take one more patch
<mup> Bug #1625291 opened: ConnectedSlotSnippet not invoked when connecting two snaps <Snappy:New> <https://launchpad.net/bugs/1625291>
<kyrofa> sergiusens, jdstrand at the sprint we realized the applications were sending icon blobs
<kyrofa> sergiusens, jdstrand in dbus I mean
<kyrofa> We couldn't figure out why they weren't showing up
<jdstrand> kyrofa: I thought they were sending icon urls that were in /tmp. so the app puts it in its /tmp, but the system sees a different /tmp
<mup> Bug #1623589 opened: No icons anymore <Snappy:New> <snapweb:Confirmed> <https://launchpad.net/bugs/1623589>
<sergiusens> kyrofa wait, this isn't in the bug report
<sergiusens> if it's blobs it should just work however inefficient that is
<sergiusens> doesn't surprise me given other uses of bus I've seen :-P
<tenaciousmv> sergiusens: another q about the nodejs plugin
<tenaciousmv> sergiusens: running npm install as root sometimes has issues
<kyrofa> jdstrand, sergiusens yeah that's what we all thought, but in heidelberg that didn't appear to be what was happening. I personally didn't update the bug because I was incredibly confused at that point :P
<tenaciousmv> because of the way npm tries to downgrade privileges or sth
<tenaciousmv> sergiusens: is there a way to run npm install not as root?
<tenaciousmv> sergiusens: another technique people use is npm install -g --unsafe-perm <package>
<tenaciousmv> sergiusens: to prevent user/group switching during the installation
<jdstrand> kyrofa: ah, well, then perhaps more digging simply needs to be done then documented in the bug and we can go from there
<kyrofa> jdstrand, indeed
<mhall119> zyga: is there a way to specify environment variables in snapcraft.yaml yet?
<tvoss> niemeyer: o/
<niemeyer> tvoss: Heya
<tvoss> niemeyer: hey, welcome back :)
<niemeyer> tvoss: Glad to see your PRs coming up :)
<niemeyer> tvoss: Thanks
<niemeyer> tvoss: A few comments in one of them.. also, would just like to highlight the fact we have a convention on the summary
<niemeyer> Please have a look at the list here to get an idea: https://github.com/snapcore/snapd/pulls
<tvoss> niemeyer: yeah, let me rename them
<dch> I'm packaging couchdb via snappy. It's important we have a migration story for our 1.6.x debian-style packages to a snappy-based one, and often they have very large databases 500GB upwards, so we can't "just" copy files around.
<tvoss> niemeyer: working through your comments now
<niemeyer> tvoss: Thanks again
<dduffey> okay I have pi3 booting and visiable via usb serial ... it seems to be taking some time after "Stated update resolvconf for Networkd DNS." .. but no login prompt, etc.
<dch> is it possible to allow a snap to access specific parts of the old existing filesystem, like /var/lib/couchdb or /etc/couchdb/*.ini ?
<dch> I'm also interested in making the snap available for centos & redhat too, this looks very cool
<mhall119> sergiusens: snapcraft is stripping quotes out of the "command:" parameter for my daemon, how can I stop that?
<sergiusens> tenaciousmv don't run snapcraft as root
<sergiusens> mhall119 it may just be a bug
<kgunn> jdstrand: hey, so took strace of amd64 and arm64, they are strikingly similar...so i don't quite see why amd64 succeeds confined and arm64 gets a hard denial
<kgunn> one of the few differences i see is that the system call signatures are similar but not same...e.g. amd64 open is openat on arm64
<kgunn> and stat on amd64 is newfstatat on arm64
<kgunn> likewise access on amd64 is faccessat on arm64
<mup> PR snapd#1879 closed: debian: adjust installation to account for deputy systemd on trusty <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1879>
<mup> PR snapd#1927 closed: tests: account for different PWD handling on trusty <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1927>
<tenaciousmv> sergiusens: good idea! thanks
<mup> PR snapd#1923 closed: tests: replace realpath with readlink -f for trusty support <Created by vosst> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1923>
<mup> PR snapd#1913 closed: daemon,store: move store login user logic to store <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1913>
<mup> PR snapd#1946 opened: interfaces: allow xdg-open in unity7, unity7 cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1946>
<jdstrand> kgunn: syscall numbers are architecure-dependent
<kgunn> jdstrand: yeah, these arent' the numbers, these are the names of the calls listed in the strace
<kgunn> jdstrand: but i'm kinda lost on what to do next
<jdstrand> glibc might implement things differently depending on the arch too
<kgunn> jdstrand: so do i simply need to add "openat" in my list of mirPermanentSlotSecComp
<kgunn> ?
<kgunn> in order to cover both archs?
<jdstrand> kgunn: I suggest comparing /etc/passwd, /etc/group, /var/lib/extrausers, and compare the file and directory ownerships from / to SNAP_DATA, etc, etc
<jdstrand> kgunn: do you have a seccomp denial? you shouldn't. openat is allowed
<jdstrand> kgunn: ie, the policy should already cover both archs for common stuff like that
<kgunn> jdstrand: lemme look again, i have to drag out all my dragonbaord and cables :)
<jdstrand> kgunn: the 3 you mentioned are already allowed
<kgunn> ah k
<kgunn> i'll double check the exact denial again...i forgot to note it down
<dduffey> if I have xenial snappy installed, how do i search --edge
<dduffey> 'snap find --edge"
<zyga> re
<jdstrand> kgunn: you are still talking about dac_override, no? or did you get new denials?
 * zyga gets back to work
<jdstrand> morphis: fyi, I approved udisks2, but I think you need to press the publish button
<mhall119> sergiusens: this is my snapcraft.yaml: http://paste.ubuntu.com/23204318/
<mhall119> but snapcraft snap turns the exec line into:
<mhall119> exec "env" ERL_FLAGS="-couch_ini ${SNAP_DATA}/default.ini ${SNAP_DATA}/local.ini" ${SNAP}/bin/couchdb "$@"
<mhall119> wait, that's my modified one
<mhall119> exec "env" ERL_FLAGS=-couch_ini ${SNAP_DATA}/default.ini ${SNAP_DATA}/local.ini ${SNAP}/bin/couchdb "$@"
<mhall119> ^^ that's what it does
<mhall119> so  ERL_FLAGS=-couch_ini and then it tries to execute  ${SNAP_DATA}/default.ini
<mhall119> I think i found a way around it
<kgunn> jdstrand: ok, interesting, i just rebuilt snapd with only the inclusion of the new
<kgunn>  /run/udev/data/c13:[0-9]* r,
<kgunn>  /run/udev/data/+input:input[0-9]* r,
<kgunn> ...and that seemed to cure the dac_override need
<kgunn> jdstrand: only other thing i can think, is i got my dragon into a weird state that a reboot cured?
<kgunn> at any rate... jdstrand you were ok with me adding those to the mir interface right ^?
<jdstrand> kgunn: yes
<jdstrand> kgunn: glad that doc_override went away
<kgunn> will clean up and submit a pr
<kgunn> ug... jdstrand getting denial now...this is odd... i'll ping back if i get some consistency....
<mwhudson> snappy sure makes reading the output of mount to e.g. find your sdcard harder :-)
<mwhudson> (lxd and schroot, too)
<mup> PR snapd#1946 closed: interfaces: allow xdg-open in unity7, unity7 cleanups <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1946>
<mup> PR snapcraft#813 opened: [WIP] "snapcraft validate" and "snapcraft gated" commands <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/813>
<kgunn> jdstrand: dang i just got it figured out! ... so i got tired of the screen blanking on dragon, so i added a setterm to my bash
<kgunn> that was screwing with it, so all good now...
 * kgunn makes note of setterm being a not good idea with mir testing
<kgunn> i had kinda forgotten i even added that....
<jdstrand> huh
<jdstrand> nice find!
<mhall119> is there any way to pre-populate $SNAP_DATA without resorting to a wrapper script?
<mhall119> twice now I've had snaps that don't need a wrapper except for doing the initial $SNAP_DATA setup
<mup> PR snapd#1858 closed: interfaces: add stub selinux backend <Reviewed> <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1858>
<mup> PR snapd#1947 opened: interfaces/builtin: add initial docker interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1947>
<mup> PR snapd#1619 closed: interfaces/builtin: add initial docker interface <Blocked> <Created by tianon> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1619>
<tianon> jdstrand: would it be helpful to just put you directly on the collaborators list for https://github.com/docker-snap/docker ? :)
#snappy 2016-09-20
<mwhudson> is there a getting started guide to snappy on the dragonboard?
<mwhudson> oh, it works!
<mwhudson> slowly
<mwhudson> and i still don't have serial
<mup> PR snapd#1700 closed: add mir to implicit for running gui snaps on unity8 classic desktop <Created by kgunnfront> <Closed by kgunnfront> <https://github.com/snapcore/snapd/pull/1700>
<mup> PR snapd#1948 opened: add run/udev/data paths to mir interface <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1948>
<mwhudson> blargh
<mwhudson> where is the/a dragonboard model assertion?
<mwhudson> ah http://people.canonical.com/~vorlon/official-models/
<slangasek> mwhudson: right, obviously ;)
<mwhudson> slangasek: where else could they possibly be!
<mwhudson> slangasek: actually the hardest part was remembering your unix username
<slangasek> hahaha
<zyga> o/
<dholbach> hey hey
<didrocks> good morning dholbach
<dholbach> happy snappy playpen day: https://daniel.holba.ch/blog/2016/09/get-your-software-snapped-tomorrow/ :-)
 * zyga works on snap-confine SRU paperwork
<seb128> hey dholbach, happy snappy day to you ;-)
<dholbach> and the same to you seb128!
<dholbach> nice to see we have a bunch of new bits added to the sandpit: https://github.com/ubuntu/snappy-playpen/wiki/SandPit
<dholbach> ^ can you add your almost-fully-working snaps to that list too?
<mup> Bug #1624963 changed: pulseaudio interface (still) missing permissions <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1624963>
<dholbach> seb128, is https://github.com/wandrewkeech/snappy-playpen/blob/gimp-git/gimp-git/README.md easy to fix? do you know?
<dholbach> diddledan, does corebird work with devmode?
<seb128> dholbach, no idea sorry, I didn't try to use gobjectintrospection in snaps
<dholbach> ok
<mwhudson> ogra_: hey i pushed a new probert / subiquity into the canonical-foundations/ubuntu-image ppa today
<mwhudson> ogra_: copy to snappy-dev/image?
<mwhudson> quite a lot of fixes
<diddledan> dholbach: I can't remember. I'll need to check this evening
<dholbach> cool, thanks diddledan
<zyga> mwhudson: I'm pushing through the 1.0.41 SRU process, that will probably take all my day; As a part of that I will have to upload it to yakkety
<zyga> mwhudson: do you think you could do the yakkety upload?
<mwhudson> zyga: you don't want to upload it to debian and wait until we can sync it, i guess?
<zyga> mwhudson: no, because we're running out of time
<mwhudson> zyga: ok
<zyga> mwhudson: mainly on the SRU overhead
<zyga> mwhudson: I pushed packaging to git.launchpad.net/snap-confine
<zyga> mwhudson: the master branch there can be merged into the 16.10 branch for yakkety
<mwhudson> zyga: want to put the 1.0.41 release on github?
<zyga> mwhudson: it's there already
<mwhudson> oh wait you did
<zyga> mwhudson: yep :)
 * mwhudson pokes uscan with a stick
<zyga> hehe
<zyga> mwhudson: fedora has a live system where it detects the tag and files an update bug
<zyga> it's pretty damn impressive
<zyga> s/damn/darn/
<zyga> but fedora will be more complex as I need to work on the /snap move there as well and this needs some more handholding
<mwhudson> zyga: oh, there's no snap-confine-1.0.41.tar.gz
<mwhudson> zyga: just the 1.0.41.tgz
<mwhudson> zyga: do you usually do a make dist & upload that or something?
<davidcalle> dholbach: I'm writing a snap that uses autotools and doesn't have an install step, how do I get everything in parts/<part>/build into the snap?
<zyga> mwhudson: oh? that's odd
<zyga> mwhudson: oh right!!!
<zyga> mwhudson: let me upload it, I forgot :/
<dholbach> davidcalle, custom plugin and copy over? :-(
<dch> mhall119: ping
<dholbach> dch, mhall119 lives in the US to it might take a while until he responds
<dch> aha
<dholbach> anything anyone else could help with?
<davidcalle> dholbach: hmmm, I already did one to get rid of the Install step of the default autotools... Yeah, I guess that's the way to go
<dch> dholbach: thanks. I'm one of the committers for apache couchdb & am working on the debian packages as well atm. so I'm quite interested to pair up wrt snaps. I'm pretty sure I can save him quite a bit of time with questions
<zyga> mwhudson: done
<dch> mhall119: ^ I'm in EU time zone but will be online tonight ~ 20h00 UTC if we can cross paths. I'm usually in #couchdb-dev of course
<dch> dholbach: one of the questions I did have was is it possible to allow a snap to access data dirs from the previous debian-style package
<kasper> hello, i would like to install Niagara Supervisor on Ubuntu Core. Supervisor need librariers with dependencies, how i can do use APT manager or can i use another manager?
<dholbach> dch, nice! did anyone of the two of you start the snap journey for couchdb yet?
<dch> specifically /var/lib/couchdb/ and /var/log/couchdb and /etc/couchdb/
<dch> dholbach: apparently he is already underway
<mwhudson> zyga: so there's no non-trivial packaging changes this time?
<dch> I have a customer who does medical appliances, so snaps are a little *too* new for them -- updates are very very hard to do, the whole thing needs re-certification. But I hope we can get the community underway very soon.
<dholbach> dch, yes, that sounds like a good plan :)
<dholbach> dch, http://snapcraft.io/docs/reference/env explains the world view of a snap quite well
<zyga> mwhudson: no, it should be a relatively smooth ride
<zyga> mwhudson: there's a new executable
<zyga> mwhudson: but nothing else
<zyga> mwhudson: oh wait
<zyga> mwhudson: maybe there is
<zyga> mwhudson: I believe we need to bump our dependency on apparmor
<mwhudson> zyga: that doesn't seem to be in your packaging?
<mwhudson> zyga: debian/patches/0001-Don-t-shellcheck-files-spread-prepare-script.patch can be dropped i take it
<zyga> mwhudson: the packag contains it automatically, no change was required
<mwhudson> oh ok
<zyga> mwhudson: (spread tests ran against this packaging all the time so if it wasn't packaged it would not be possible to test it)
<dch> dholbach: the main issue is /var/lib/couchdb as people have 100gb upwards in these and "just" copying them around is dangerous & slow. from what I've read so far, I've not seen anything about making that possible to access.
<mwhudson> zyga: heh
<zyga> mwhudson: since I change spread to use packaging and real dist tarballs releases should be relatively painless
<zyga> mwhudson: let me grep for the right apparmor version to depend on
<mwhudson> zyga: and 0001-Stop-using-deprecated-readdir_r.patch too?
<zyga> mwhudson: all patches are dropped
<mwhudson> cool
<zyga> mwhudson: 17:44 < tyhicks> zyga: you should depend on 2.10.95-0ubuntu2.2 or newer
<zyga> mwhudson: please merge that change into master if you can
<zyga> mwhudson: do you have commit access to git.launchpad.net/snap-confine?
<mwhudson> zyga: i doubt it
 * zyga looks
<mwhudson> zyga: 'master' ?
<mwhudson> in my tree master is upstream master
<mwhudson> there is a debian branch, and i guess i'm about to create one called ubuntu, or ubuntu-yakkety or something like that :)
<zyga> mwhudson: you need to request access https://launchpad.net/~snappy-dev
<zyga> mwhudson:
<mwhudson> zyga: restricted team, i can only be added
<zyga> mvo: ^ can you please add mwhudson there
<dholbach> dch, I'm not quite sure - I'll ping the snapd guys to get an answer on this one. :)
<zyga> mwhudson: so that repo is a bit weird; it contains just the debian directory and has branches for each distro version
 * mwhudson updates his schroots
<zyga> mwhudson: I found this easier to work with than a few separate repos for the "traditional" approach
<mwhudson> ah ok
<zyga> mwhudson: I'm happy to change it as long as we can also use it in spread
<zyga> mwhudson: note that spread just branches the appropriate branch and builds the package against the debian directory there and the tarball
<zyga> mwhudson: if we had the full git tree it would probably work as well but might be less obvious that only the debian directory is relevant
<zyga> mwhudson: and no dedicated tooling seems to work with this approach
<mwhudson> zyga: uupdate?
<zyga> mwhudson: (because it is uncommont to maintain many distro revisions in the debian world; I suspect)
<zyga> uupdate?
<mwhudson> you could use that with the debian branch from alioth i think
<mwhudson> bah i have too many chroots
<zyga> mwhudson: I want to include debian in this repo
<zyga> mwhudson: and merge those
<zyga> mwhudson: (those repositories)
<mwhudson> yes, makes sense
<zyga> mwhudson: ideally there'd be one repo with a branch per release and master where all new things get added
<zyga> mwhudson: we can keep it on alioth, that's perfectly fine, I just need to finally do that paperwork for it
<mwhudson> zyga: branch per distro, surely?
<zyga> mwhudson: yes
<mwhudson> good :)
<zyga> mwhudson: branch per distro*release
<mwhudson> well distroseries, in launchpad terminology
<mwhudson> yeah
<zyga> mwhudson: nice :)
<mwhudson> zyga: what i do for go (and i don't know if this really makes sense here) is to have the debian bits on alioth but i only push the ubuntu bits to git.lp.net
<mwhudson> (except occasionally when i screw up and have to delete 10s of tags from alioth)
<zyga> mwhudson: I guess we might do that, it is per-branch after all
<zyga> :D
<mwhudson> zyga: where are the spread bits that make the packages?
<mwhudson> zyga: ok, builds fine in my yakkety and sid chroots, just waiting on that apparmor version :-)
<zyga> mwhudson: ^
<mwhudson> zyga: oops
<zyga> mwhudson: I pasted it above
<zyga> sorry, on a call
<zyga> mwhudson: in snap-confine master, look for spread-prepare.sh
<mwhudson> zyga: i guess i'll depend on >= 2.10.95-0 for the debian upload
<mwhudson> er -1
<mwhudson> actually no, the ubuntu version should be fine there
<mwhudson> no sense carrying a delta for no reason
<ara> zyga, lost you :)
<mwhudson> zyga: ok, ready to upload, do you want to look at a debdiff or do you trust me? :)
<mwhudson> zyga: http://paste.ubuntu.com/23206344/
<zyga> re
 * zyga looks
<zyga> mwhudson: I trust you but I can review it :)
<mwhudson> :)
<zyga> ouch :)
<zyga> I stopped at ~1000
<zyga> let's get it in
<mwhudson> zyga: heh maybe search for debian :)
<mwhudson> but ok
<mup> PR snapd#1911 closed: snap: add additional checks for snap run symlinks <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1911>
<mup> PR snapd#1774 closed: tests: add test for current snapd with ubuntu-core/edge interactions <Decaying> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1774>
<mwhudson> zyga: uploaded to yakkety & sid
<zyga> mwhudson: woot, thank you
<ypwong> when I install a snap that I packaged and uploaded some time ago on the latest image, I got this error:
<ypwong> - Fetch and check assertions for snap "shadowsocks" (5) (cannot verify snap "shadowsocks", no matching signatures found)
<ypwong> what does that mean?
<kalikiana> Try --force-dangerous
<ypwong> trying now
<ypwong> kalikiana, doesn't work :(
<zyga> ypwong: upload it again to the store
<zyga> ypwong: store will sign it now
<ypwong> zyga, thx, will try that
<mup> PR snapd#1949 opened: ensure http{,s}_proxy is defined inside the fake-store <Created by mvo5> <https://github.com/snapcore/snapd/pull/1949>
<mwhudson> zyga: ftbfs https://launchpadlibrarian.net/285513548/buildlog_ubuntu-yakkety-amd64.snap-confine_1.0.41-0ubuntu1_BUILDING.txt.gz
<mwhudson> zyga: possibly old kernel on the builders?
<zyga> mwhudson: possibly
<zyga> mwhudson: hmm
<zyga> mwhudson: but perhaps not
<mwhudson> zyga: only failed on intel fwiw
<zyga> mwhudson: intel as in i386?
<mwhudson> zyga: i386 & amd64
<mwhudson> zyga: https://launchpad.net/ubuntu/+source/snap-confine/1.0.41-0ubuntu1
<zyga> mwhudson: NSFS_MAGIC is taken from an include file, I don't hardcode it
<zyga> mwhudson: hmm hmm, thanks, let me see if I can reproduce it
<mwhudson> zyga: kernel version is just my go-to blame target when a build fails on the builders but not my machine
<zyga> mwhudson: but it builds for you in sbuild, right?
<mwhudson> yes
<mwhudson> just building again to be sure...
<zyga> mwhudson: right, so I'm not going crazy
 * zyga does the same
<mwhudson> zyga: well, not for this reason anyway
<mwhudson> yeah, built fine here again
<zyga> mwhudson: what kind of options do we have?
<mwhudson> zyga: the failing kernels are much older, 3.13 vs at least 4.2 for the others
<zyga> mwhudson: disable that test or .. dunno?
<mwhudson> zyga: i guess disabling the test for now if uname -r < whatever
<zyga> mwhudson: can you please look at the test and tell me if the code there makes sense to you?
<mwhudson> zyga: i hear people want snappy to work on trusty, so some lucky person gets to figure out if this matters :-)
<zyga> mwhudson: that's tvoss but the solution is to use new kernels
<fgimenez> hey ogra_ :) i'm not able to boot the latest dragonboard beta image http://paste.ubuntu.com/23206434/ it hangs in the last line, is this a known issue?
<mwhudson> ah ok
<zyga> mwhudson: as for 3.1X for devices, lots of backporting I guess
<zyga> mwhudson: so wait, what is the kernel version on the builders?
<cjwatson> we have a ticket open to upgrade builders to xenial, but it will take a while
<cjwatson> zyga: it's on the third line of the build log mwhudson pasted above
<mwhudson> zyga: it's the first or second line in the build log
<zyga> mwhudson: Kernel: Linux 3.13.0-96-generic amd64 (x86_64)
<zyga> is that i?
<zyga> it
<cjwatson> yes
<mwhudson> yeah
<zyga> okay, that might explain it
<zyga> let me try that kernel locally
<zyga> that's trusty kernel with xenial/yakkety chroot?
<cjwatson> yes
<cjwatson> yakkety, in this case
<zyga> perfect
<zyga> mwhudson: I guess we'll need a patch but let me explore it first
<mwhudson> NSFS_MAGIC changing between kernel versions would be ... something
<zyga> mwhudson: can you fild a bug for tracking this with the relevent part of the log
<mwhudson> maybe older kernels just didn't set it at all or something
<mwhudson> zyga: on github or lp?
<zyga> mwhudson: on launchpad please
<mwhudson> 40864 seems to be PROC_SUPER_MAGIC
<mwhudson> zyga: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1625565
<mup> Bug #1625565: 1.0.41-0ubuntu1 ftbfs on amd64, i386 <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1625565>
<zyga> mwhudson: thanks
<mwhudson> and NSFS_MAGIC was only added to the kernel in a commit from Sat Nov 1 10:57:28 2014 -0400
<mwhudson> so that's not going to be in the 14.04 release kernel
<mwhudson> 3.19+
<zyga> mwhudson: so even the kernel headers have that macro, the relevant files in the kernel don't use it?
<mwhudson> zyga: well the kernel headers you are building against are from yakkety presumably
<zyga> mwhudson: yes, I just checked that :/
<zyga> mwhudson: the mount namespace file in the kernel is indeed procfs
<zyga> mwhudson: I guess this test needs to be skipped
<zyga> mwhudson: and we might need a separate check for this in snap-confine proper
<zyga> so that if we open and see PROC_SUPER_MAGIC we can die()
<zyga> mwhudson: I'll work on a patch, can you still upload it in ÃÂ£30 minutes?
<zyga> ~
<mwhudson> zyga: getting pretty late, i'm sure you can find another core dev
<zyga> ok
<zyga> thanks, I'll talk to you tomoror  :)
<zyga> tomorrow :)
<mwhudson> zyga: ttyl!
<zyga> o/
<ogra_> mvo, how hard would it be to make snap prepare-image alo print the revision number when printing the "Fetching $package" ?
<ogra_> *also
<ogra_> (that would really help regarding getting the manifest)
<jgdx> possible to use a ppa in addition to whatever snapcraft uses to install debs?
<ogra_> yes, just have it in your hosts sources.list
<jgdx> ogra_, okay, that's great
<ogra_> (not sure how you do it with cleanbuild though, i guess you need a pre-made lxc image for that)
<jgdx> ogra_, what uses cleanbuild?
<mvo> ogra_: I like the idea
<ogra_> you ?
<ogra_> mvo, i'll file a bug
<jgdx> ogra_, I use $ snapcraft
<ogra_> jgdx, to build a snap you can call "snapcraft cleanbuild" ... while a normal call of snapcraft will just use the host, cleanbuild does the build inside a clean lxc container
<jgdx> good to know, thanks
<ogra_> ppisati, hmm, more OOPS fun on bbb ... http://paste.ubuntu.com/23206676/
<ogra_> it seems to hang in resizing the disk and eventually oopses after a few min
<ypwong> To install a snap locally, do I always need to provide --force-dangerous argument?
<zyga> mwhudson: if around by any chance: https://github.com/snapcore/snap-confine/pull/150/files
<mup> PR snap-confine#150: Skip tests that require Linux kernel 3.19+ <Created by zyga> <https://github.com/snapcore/snap-confine/pull/150>
 * zyga needs a reviewer for a simple patch ^^
<ogra_> ypwong, the option will soon change to just be --dangerous ... and --devmode selets it automatically ... if you install a local snap you always need it (but dont need to specify it when using --devmode)
<ypwong> ogra_,
<ypwong> ogra_, will plugs be automatically connected?
<ypwong> seems when i use --force-dangerous, it doesn't
<ogra_> the auto-connect ones will, sure ...
<ypwong> hmm
<ypwong> strange, let me dig deeper then
<ypwong> I use network and network-bind, these should be auto-connect
<ogra_> yes
<ogra_> though i'm not sure actually ... zyga should know if --dangerous kills auto-connect
<zyga> ogra_: I don't think so but let me grep
<ogra_> mwhudson, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has the latest probert/subiquity
<zyga> ogra_: no, it has no inpact on this
<ogra_> thought so ...
<ogra_> thanks
<ogra_> ypwong, ^^^^
<ypwong> ogra_, zyga: thx, i will investigate what's wrong
<ppisati> ogra_: i'm looking into the previous one
<ppisati> ogra_: i stuck some debug code in the sysfs code, but i still can't find where it writes
<ogra_> ppisati, heh, yeah, i was just hoping that brings perhaps more hints
<ppisati> ogra_: my bet is that it removes all the network devices
<mup> PR snapcraft#808 closed: Don't litter /tmp with test artifacts <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/808>
<ppisati> i've seen quite some fixes about PM code and TI device removal
<ppisati> so i'll give that a shot too
<ppisati> but this one is new
<ppisati> doh!
<ppisati> :P
<ppisati> ogra_: btw, is is so difficult to roll a new image for BB?
<ogra_> you need a signed assertion and the snap that you want to replace locally
<ogra_> ppisati, see pm
<ppisati> ogra_: ok, i'll give it shot later on
 * ppisati is accumulating later shots
<zyga> jdstrand: hey
<zyga> jdstrand: could you please add a comment to https://github.com/snapcore/snap-confine/pull/97 that confirms you are okay with the change that lowers the restriction on encrypted home directory (we drop the owner stanza)
<mup> PR snap-confine#97: Restore creation of $SNAP_USER_DATA <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snap-confine/pull/97>
<zyga> jdstrand: just some paperwork for SRU
<zyga> jdstrand: I recall you +1'd it but I need a paper trail for the whole process
<zyga> jdstrand: and I cannot see that +1 on the pull request there
<jdstrand> zyga: I don't recall ever giving a +1 on that. I recall a +1 on the 'new-style encrypted $HOME'
<jdstrand> zyga: why doesn't owner match work? shouldn't we have already dropped privs to the user when creating SNAP_USER_DATA?
<zyga> jdstrand: beuse we run as root via sudo
<zyga> *because
<zyga> jdstrand: this is just for the sudo case
<zyga> the bug https://bugs.launchpad.net/snap-confine/+bug/1612291 has a lot more details now
<mup> Bug #1612291: cannot create $SNAP_USER_DATA when using ecryptfs and sudo <verification-done> <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1612291>
<zyga> (this is in xenial for a while FYI)
<ogra_> OH GEEZ !!!!!
<zyga> ogra_: ?!?
<ogra_> so i wasted a full day trying to fix a prob that wasn't actually one, just because i missed that the store did unset the channel for a manually published snap !
<ogra_> (well, it was actually auto-published, but failed the review ... seems the manual review approval auto-unsets the channel that had been originally selected for the package)
<ogra_> so the uploaded fix never made it into the image ... since it caused snap list to not work i couldnt actually find out that the fixed snap was a revision behind ...
<ogra_> what a mess
<jdstrand> niemeyer: let me know if I am not using the 'Reviewed' tag correctly. I see you like to mark things 'Reviewed' after you leave feedback. If I respond to your feedback, I remove 'Reviewed'. If the process is different, please let me know
<zyga> jdstrand: the reviewed tag is gone now
<zyga> jdstrand: with new github features it is not required
<zyga> jdstrand: same as blocked
<jdstrand> zyga: well, maybe, but it showed up with a review from last night/this morning
<pedronis> zyga: no, after futher thinking, we are still using the labels
<pedronis> zyga: you don't see the other stuff in the PRs list for one
<zyga> pedronis: yes?
<zyga> pedronis: I think gustavo wrote about this yesterday but perhaps I didn't see a follow-up that undoes it
<jdstrand> zyga: right, so I read that bug but I think this is just papering over the larger issue of sudo creating things in the user's dir rather than /root
<pedronis> zyga: he wrote something else, we are using the features and we are using the labels
<pedronis> the discussion about the labels was in chat
<zyga> jdstrand: that's interesting, I think we could consider switching to /root when sudo is used but I don't think we made that choice yet
<zyga> pedronis: ah, that explains it, I only read my mail about that
<zyga> pedronis: thanks!
<jdstrand> zyga: I maintain we should not be doing that. HOME should be set to the root user if run under sudo because we will never get the permissions right in the user's directory cause half the time we will be right and half the time wrong regardless of the decision, but if creating in /root at least it is consistent
<jdstrand> zyga: I was literally just going to ask if an architect took a definitive stance on that
<jdstrand> I thought someone did, and I thought it was for /root, but I may be misremembering
<zyga> jdstrand: I think we did that for /root and *services*
<jdstrand> 'it is consistent and we aren't creating permissions problems for the user'
<zyga> jdstrand: well, FYI this is in xenial :/
<zyga> jdstrand: I'm just massaging the paperwork now
<zyga> jdstrand: I think there's a strong distinction between servies and sudo
<zyga> jdstrand: but still, regardless, I wonder how to proceed now
 * zyga is *sure* we talked about this
 * ogra_ grumbles and files bug 1625605
<mup> Bug #1625605: manual review should not unset the channel for auto-uploaded snap <Snappy:New> <Software Center Agent:New> <https://launchpad.net/bugs/1625605>
<zyga> perhaps that was tyhicks
<mup> Bug #1625605 opened: manual review should not unset the channel for auto-uploaded snap <Snappy:New> <Software Center Agent:New> <https://launchpad.net/bugs/1625605>
<jdstrand> zyga: I gave a +0 that at least gives you a "won't block" from the security team
<jdstrand> zyga: (see comment in the PR)
<zyga> jdstrand: thank you
<zyga> jdstrand: I'll raise this today with gustavo
<zyga> jdstrand: I'm happy to change it if we so desire though I wonder if we should just change sudo
<zyga> jdstrand: after all, this is sudo's code that preserves HOME
<jdstrand> there is a bug on that
<zyga> jdstrand: and that was a vert conscious choice on our end (our == ubuntu)
<jdstrand> yes
<zyga> jdstrand: can you share the bug please?
<zyga> s/vert/very/
<jdstrand> the difference is that in ubuntu running the sudo command, the command most often does not create files in the user's home dir (it is highly application dependent). in snappy, running a snap command 100% of the time creates the directories and files with root ownership
<jdstrand> (when they don't already exist)
<ogra_> mvo, bug 1625607 for you
<mup> Bug #1625607: snap prepare-image should print the revision used in the "Fetching $package" output <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1625607>
<zyga> jdstrand: that's true though I'd say that "it is application dependent" is very common
<mup> Bug #1625607 opened: snap prepare-image should print the revision used in the "Fetching $package" output <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1625607>
<jdstrand> zyga: https://bugs.launchpad.net/snappy/+bug/1466234/comments/6
<mup> Bug #1466234: Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root <Snappy:Fix Released> <ubuntu-core-launcher (Ubuntu):Invalid> <ubuntu-core-security (Ubuntu):Fix Released by jdstrand> <ubuntu-snappy (Ubuntu):Fix Released> <https://launchpad.net/bugs/1466234>
<jdstrand> zyga: in fact, it looks like we decided on option #1 (using /root) but no one implemented it
<jdstrand> zyga: seems it was undone at some point
<zyga> jdstrand: interesting, I wasn't aware of it
<jdstrand> zyga: so yes, it came up, options were presented, one was decided on, it was implemented, then reintroduced later
<jdstrand> s/then reintroduced/then the issue was reintroduced/
<zyga> cjwatson: crazy idea, let launchpad bugs affect snap names
<zyga> cjwatson: like packages in a distro or upstream projects
<ogra_> zyga, awesome idea ... but would indeed only work for snaps that are built in LP
<zyga> ogra_: no, why?
<cjwatson> Conceptually useful, but we'd have to model the snap names somehow, which is complex since LP doesn't own them.
<zyga> ogra_: just any snap
<cjwatson> ogra_ is incorrect
<zyga> cjwatson: I bet we can eventually figure it out
<cjwatson> If we did this we'd do it by syncing snap names from the store
<zyga> cjwatson: just realized that more and more of what I do will be fixed in a given revision of a given snap
<ogra_> cjwatson, well, you just said yourself that LP doesnt own them ... except for a snap LP builds, there it knows the store name
<cjwatson> ogra_: See the last thing I said.
<cjwatson> It doesn't own them, but it could know them.
<zyga> ogra_: launchpad doesn't own other things it can track
<ogra_> right, i was just referring to the ones it already knows :)
<cjwatson> It won't be soon, but by all means file a bug.
<zyga> cjwatson: with pleasure
<jdstrand> pstolowski: ok, I gave my +1 on the kmod backend, but think you want to have niemeyer take a quick look. that could happen in the PR if you prefer
<cjwatson> It might be easier to do if we didn't try to overlap the namespace with the existing "ubuntu", though.
<jdstrand> pstolowski: I can't help wanting to not require the json file, but understand why you have it and can't come up with a cleaner solution that doesn't introduce parsing metadata in /etc/modules-conf.d
<jdstrand> or loading modules twice
<zyga> cjwatson: https://bugs.launchpad.net/launchpad/+bug/1625617
<mup> Bug #1625617: Allow bugs to affect snap (snap names) <Launchpad itself:New> <https://launchpad.net/bugs/1625617>
<zyga> jdstrand: json?
<zyga> pstolowski: where's the pull request?
<jdstrand> zyga: https://docs.google.com/document/d/1-kSrNGLxIeSHJOZJBdumAL8QQIt0DBa_TLMzYDQEPM4/edit#
<jdstrand> zyga: no pull request-- design doc
<zyga> pstolowski: This database is persistent and stored in /var/lib/snapd/kmod-state.json (restored on startup).
<popey> ogra_: got a pi handy with classic enabled? libssl-dev seems broken on arm:- libssl-dev : Depends: libssl1.0.0 (= 1.0.2g-1ubuntu4.2) but 1.0.2g-1ubuntu4.3 is to be installed
<zyga> pstolowski: why do you think this is needed?
<jdstrand> zyga: see my comments
<pstolowski> jdstrand, thanks for your time!
<jdstrand> (in the doc)
<ogra_> popey, only half eaten pi's here (all broken atm) ... but i'll check once i get to one ... which image is that ?
<jdstrand> zyga: basically, it boils down to disconnect
<jdstrand> zyga: if two snaps are connected and one isn't, you need to know if other snaps are connected
<zyga> pstolowski: this database is redundant information, it is completely derived from connections, am I missing something?
<zyga> jdstrand: snapd knows all of this
<jdstrand> that didn't come out right
<popey> ogra_: previous beta (not yesterdays)
<popey> ogra_: with classic enabled.
<jdstrand> zyga: if two snaps are connected and one of those is later disconnected, you need to know if other connections are available
<ogra_> popey, there was an issue that we used to build ubuntu-core against -proposed which got fixed after first beta
<popey> ok
<jdstrand> s/available/still in effect/
<popey> am about to try yesterdays
<popey> with a pi3
<ogra_> popey, well, snap refresh should theoretically just get you all the latest snaps
<ogra_> theoretically there is no need to ever reinstall
<zyga> jdstrand: to be more accurate, since we restore this on startup we can just keep this in memory
<zyga> jdstrand: so no computational overhead on disconnect
<ogra_> (practically there are differences in the setup process ... but not in the runtime)
<zyga> jdstrand: unless someone proves me wrong I'd -1 the extra json file
<jdstrand> zyga: so, if I snap disconnect foo:firewall-control, then snapd will be able to know that bar is still connected and make decisions? where is an example of that, cause I only see the snap name in current code
<zyga> jdstrand: yes
<zyga> jdstrand: specifically snapd knows about all the backends and all the connections
<zyga> jdstrand: we need a channel to convey this to the backend
<jdstrand> zyga: hey, I'm fine without the json file-- I don't like it :)
<popey> ogra_: well, i was gonna test the new one anyway, so neat to have them side by side to compare
<zyga> jdstrand: but the extra json file does not help there
<zyga> pstolowski: ^^
<popey> if i can find my pi 3
<pstolowski>  i'm happy to get rid of it too
<zyga> pstolowski: look at the startup sequence in overlord/ifacestate
<pstolowski> jdstrand, zyga need to digest that
<ogra_> ogra@anubis:~/datengrab/images/snappy$ LC_ALL=C df -h /dev/sdc1 /dev/sdc2
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/sdc2       475M  -32T   33T    - /media/ogra/writable
<ogra_> /dev/sdc1       127M   23M  104M  19% /media/ogra/system-boot
<ogra_> wow ...
<ogra_> -32T
<zyga> pstolowski: think about it, perhaps I am missing something but if not we just drop some complexity
<ogra_> (thats definitely not what they printed on  this SD card)
<zyga> ogra_: that's a nice SD card you have there
<ogra_> yeah !
<zyga> ogra_: care for a copy of the internet?
<ogra_> haha
<zyga> don't foret to unmount before ejecting
<zyga> ;D
<ogra_> right ... on the beaglebone i use it in ...
<ogra_> seems it doesnt really get along with SDXC
 * ogra_ tries to find out if he even actually owns plain old SD ones still 
<zyga> ogra_: to quote hrw "no sata, meh"
<ogra_> LOL
<jdstrand> zyga: so you are suggesting that pstolowski use getConns() from helpers.go to see if there are still connected interfaces. if so, on connect, do nothing, on disconnect, do nothing?
<jdstrand> zyga: something along those lines?
<zyga> jdstrand: without any deeper understanding the json file can be just maintained in memory
<pstolowski> zyga, all I need is to know if I should rmmod module(s) or not, depending on whether there are other connected interfaces needing them
<pstolowski> jdstrand, ^
<zyga> jdstrand: this is all an in-memory problem
<pstolowski> jdstrand, zyga also, note there may be overlapping modules for different interfaces
<pstolowski> jdstrand, zyga interfaceA needs module1 & module2, interfaceB needs module2
<ogra_> pstolowski, please "modprobe -r" not rmmod ... else the dependencies stay in ram
<jdstrand> pstolowski: well, you need to know if to rmmod and to update the file in /etc/modules-conf.d to remove the modules
<zyga> pstolowski: just track this on connect/disconnect, the persistent file gains you nothing
<pstolowski> jdstrand, yes, sure
<pstolowski> ogra_, noted, thanks!
<zyga> pstolowski: and if you need persistent state you have one already, the extra file will be likely NAKed by gustavo
<jdstrand> zyga: ok, so you can either reconstruct the 'json file' in memory on startup like you said, or you could query the state of interfaces connections (getConns()(?)) each time
<zyga> jdstrand: yes
<zyga> jdstrand: in either case the file is redundant and overlaps in responsibilty with state.json
<jdstrand> ok cool
<zyga> jdstrand: state tracks connections today
<zyga> jdstrand: (that's why they exist on restart)
<zyga> jdstrand: the interface repository has in-memory representation of this
<jdstrand> I think that querying getConns() each time will be easier to implement than trying to maintain a global map
<jdstrand> (a separate global map)
<zyga> pstolowski: FYI, you will probabl have to introduce some changes as currently backends are stateless
<jdstrand> ie, no need to recreate the map if we can query an existing one
<zyga> pstolowski: so either make them stateful (perhaps not desired) or let them peek at the state (easy)
<mhall119> dch: pong, and good morning :)
<pstolowski> zyga, jdstrand one bit i'm missing with getCons() is that i'm actually interested in their security snippets
<zyga> pstolowski: if you want I can talk to you about this after the standup
<pstolowski> zyga, okay
<jdstrand> pstolowski: well, are you? consider the firewwall-control interface. you need only ask getConns() if anything other than you is using the interface. then maintain a file called /etc/modules-conf.d/snapd-firewall-control.conf. then for the ppp interface, you ask what else is using the ppp interface and maintain a file called /etc/modules-conf.d/snapd-ppp.conf. that said, do talk to zyga-- he has thought about it more than I
<ogra_> sigh ... so setting up the store account on the bbb takes almost 20min
<ogra_> this is below sub-optimal
<dch> mhall119: hey
<zyga> ogra_: cpu bound? ram bound? ?
<ogra_> zyga, python bound i bet ... (which indeed boils down to only single core CPU and 512MB
<ogra_> )
<ogra_> remember why we re-wrote snappy from python initially ? :)
<ogra_> great ... and it seems console-conf was still busy in bg, even though it had "finished"
<ogra_> [  937.295627] systemd-shutdown[1]: Remounting '/' read-only with options ''.
<ogra_> [  937.304326] systemd-shutdown[1]: Remounting '/writable' read-only with options 'data=ordered'.
<ogra_> [  937.314808] systemd-shutdown[1]: Unmounting /writable.
<ogra_> [  937.320368] systemd-shutdown[1]: Could not unmount /writable: Device or resource busy
<popey> ogra_: tried pi3 image, it just sits at 4 raspberrys and heartbeat blinks at me... should it take a long time first boot?
 * ogra_ has about 1000 lines of that on the console now
<ogra_> popey, whats on the serial ?
<popey> serial?
<popey> i only have ethernet and hdmi connected
<ogra_> yes, you are using an embedded board ... so i expect you to have a serial console attached :P
<popey> hahah, olde ogra_
<popey> hello, welcome to 2016
<ogra_> this is really essential
<popey> le sigh
<ogra_> (how else would i get any debug info from you :P )
<zyga> ogra_: from python!? really?!
<zyga> ogra_: wow
<zyga> ogra_: I didn't know this
<ogra_> zyga, we dropped the pythjon based snappy back then because even installing a package could take 20min on the bbb (which back then was still an official target)
<popey> ogra_: this is the first time I have ever had someone ask me about a serial cable on the pi.. ever.
<zyga> ogra_: ouch
<zyga> ogra_: lesson learned
<popey> so forgive me if I don't own onw :(
<popey> *one
<ogra_> popey, well, because the pi foundation makes you think that this embedded board is a PC :P
<zyga> ogra_: that board is x100 faster than linus' first pc
<ogra_> popey, anyway, you can hack cmdline.txt on the sysstem-boot partition of the SD ... and change the console= arg tp point to tty1
<ogra_> though i would suggest doing a fresh flash first ... the beta images are no safe against rebooting before console-conf finished (thats fixed in the dailies)
<popey> it is a fresh flash
<popey> from 20 mins ago
<ogra_> did you power on the pi with the SD plugged in ?
<ogra_> (then it is tainted if you were not able to finish console-conf)
<popey> ok
 * popey reflashes
<ogra_> the dailies are already miles ahead (new console-conf today) but well ... use edge ...
<popey> will flash, edit cmdline.txt and try again
<pstolowski> jdstrand, i think we need more awareness, down to individual modules, because some modules can be used by different interfaces and we need to know when it's safe to unload them from kernel. i'm happy to get rid of the persistent json file but I need to derive this information from somewhere else (all connections + their list of modules returned by SecurityKMod snippet).
<mup> PR snapd#1641 closed: interfaces/builtin: implement systemd-control <Decaying> <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/1641>
<csutherl> mhall119, hi
<zyga> pstolowski: that sounds good
<zyga> pstolowski: I'm not disputing the data that is needed to complete this
<popey> ogra_: tried that, now I get perma green and red light and no display :(
<popey> gonna try again after meetings, but any other suggestions welcome
<ogra_> i dont have any
<ogra_> it works fine to run it without HDMI on a serial console
 * zyga finished paperwork for 1.0.40 update
<zyga> https://launchpad.net/snap-confine/+milestone/1.0.40
<jdstrand> pstolowski: or you could skip the modprobe -r altogether... starting to think that it might always fail cause of modules that depend on those
<zyga> now time for 1.0.41 :/
<zyga> jdstrand: hmm, good point
<jdstrand> pstolowski: always in practice that is.
<zyga> jdstrand: so just modprobe
<zyga> jdstrand: and just reboot to alter
<jdstrand> eg, firewall control will for sure
<zyga> jdstrand: the module might not be possible to remove perhpas
<jdstrand> yeah
<mhall119> hello csutherl
<ogra_> jdstrand, the kernel shoudl know which deps are stiull in use and modprobe -r should actually leave them alone
<zyga> pstolowski: ^^ I think simplifies your problem a lot
<pstolowski> zyga, it does but i'm not convinced :/
<zyga> ogra_: should we fail when modprobe -r fails?
<ogra_> i'd check if the module you called -r on is still there ... and then fail ... but only then
<pstolowski> no, i'd say we try to unload modules, but never fail
<jdstrand> why?
<ogra_> well, or warn
<jdstrand> who cares if it doesn't unload
<pstolowski> exactly
<pstolowski> and there may be users of the modules outside of snap world. we don't know
<jdstrand> yes, good point
<csutherl> mhall119, i figured it's probably easiest for me to talk to you in real time :) im a bit busy, but im always on irc
<jdstrand> perhaps the admin add a file to /etc/modules-load.d that happens to overlap
<csutherl> mhall119, i created a snap from your config, but haven't tested it or anything yet. the idea of snaps seems similar to containers, right?
<jdstrand> added*
<mhall119> similar in spirit, not in implementation
<jdstrand> then we just go and unload it
<jdstrand> that wouldn't be good
<mhall119> snaps are run on the local host, but confined with apparmor (and selinux in the future)
<pstolowski> jdstrand, hmm, that's a valid point & case
<jdstrand> mhall119: s/and/or/ (nitpick, but it won't ever be both at the same time)
<pstolowski> jdstrand, zyga no unloading then? that simplifies it quite a lot
<jdstrand> pstolowski: I think I just convinced myself no unloading
<ogra_> mhall119, csutherl, well, a container means your snap would actually be installed in / and run against a VM or chroot or some such ... snaps dont do that, there is no such path mangling like in chroot or VM environments
<csutherl> ogra_, ah. thanks for the explanation. i haven't had much time to look into it other than to install and run snapcraft :)
<ogra_> the paths are actually all underneath $SNAP ...
<csutherl> interesting
<jdstrand> csutherl: snaps integrate with the system and with each other and we use some container technologies to do that
<csutherl> neat
<csutherl> so why would i use a snap instead of docker, for instance?
<csutherl> im just trying to get an overview of use cases
<ogra_> right, but we do not make it look like $SNAP/usr/bin is actually /usr/bin ... which a container does
<zyga> csutherl: it is easier to let one snap to work with other snaps and with the system
<zyga> csutherl: and the snap might be smaller as it re-uses the core snap
<ogra_> there is strict separation in our setup
<jdstrand> csutherl: it depends on what you want. with docker, you manage the app with docker and it doesn't integrate with the system (maybe that is your workflow, that's fine). with snappy, normal tools like ps, top, ls, etc all work as expected for the snap and that snap might connect to another snap-- eg, download the bluez snap and then another snap that uses it
<zyga> csutherl: snanps also integrate better with regular users on the system and allow them to have per-user state
<jdstrand> csutherl: that is harder to do with docker
<jdstrand> csutherl: it just depends on what you want and what your workflows are
<csutherl> gotcha
<csutherl> jdstrand, zyga ogra_ thanks for the responses :)
<ogra_> :)
<jdstrand> you're welcome :)
<csutherl> mhall119, ok. back to you. what exactly were you looking for help with ? just testing your snap or something more?
<jdstrand> pstolowski: do you have everything you need at this point?
<pstolowski> jdstrand, yes! thank you for feedback!
<jdstrand> pstolowski: you're welcome and thanks to zyga for reminding me that the state is right there at your fingertips :)
<pstolowski> jdstrand, fyi.. i've already made some progress on the impl (well, it's 90% ready the way I described it in the doc with persistent state). so now i only need to rework it a bit ;)
<mhall119> csutherl: I'm really looking for help testing and improving the snap right now, and getting it upstream once it's in a good state
<pstolowski> jdstrand, so I hope to have something ready for review this week
<jdstrand> pstolowski: nice!
<csutherl> mhall119, what does 'getting it upstream' mean?
<csutherl> i dont know anything about the infrastructure, etc atm, so assume i know nothing :)
<mhall119> in the not to distant future I wanted to make it possible to deploy .war files as snaps that connect to the tomcat snap, or to make tomcat a snapcraft "part" that developers could use to bundle it with their webapp
<mhall119> csutherl: getting the snapcraft.yaml into the upstream source code, and building snaps as part of the normal CI process rather than as a one-off manual task
<csutherl> mhall119, upstream as in asf tomcat or some snap store type thing?
<mhall119> asf tomcat
<csutherl> b/c asf afaik doesn't generally accept distribution stuff :)
<csutherl> which is why im the only person that responded to you
<csutherl> i maintain fedora/rhel tomcat
<mhall119> who could then upload it to the snap store or make it available as a download (or both)
<mhall119> csutherl: it would be more inline with asf project packages for windows or mac, rather than distro-specific
<csutherl> mhall119, you can always give it a shot and see
<mhall119> since the snap could be installed on to Arch or Debian, for example
<csutherl> yep
<mhall119> csutherl: if you can help me figure out why the JSP views aren't working, that would be a huge help :)
<mhall119> my guess is that it's trying to write the compiled pages somewhere that is read-only, but I've forgotten where Tomcat tries to do that
<csutherl> mhall119, gotcha. sure
<csutherl> mhall119, it writes the compiled jsps into the work dir (or temp, i dont remember)
<csutherl> mhall119, do the example apps fail?
<mhall119> only on the JSP side, the servlet works fine
<mhall119> it's created $CATALINA_BASE/work/Catalina/localhost/sample just fine
<mhall119> so maybe it's trying to use a temp directory it doesn't have
<csutherl> probably
<csutherl> ill pok earound with it when i get freed up later today
<mhall119> thanks csutherl
<csutherl> mhall119, np
<mup> PR snapcraft#814 opened: Make source-depth a parameter and opt-in <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/814>
<mup> PR snapd#1949 closed: tests: ensure http{,s}_proxy is defined inside the fake-store <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1949>
<mup> PR snapcraft#809 closed: make plugin: improve artifact copying (LP: #1624798) <Created by jaymell> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/809>
<mup> PR snapcraft#792 closed: Fix `git clone` when transport is http and it does not support --depth <Created by ehbello> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/792>
<mup> PR snapcraft#802 closed: Add the TEST_STORE environment variable to the travis script <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/802>
<ppisati> ogra_: FYI, i think i fixed the BB panic
<ogra_> awesome !
<ogra_> what was it ?
<mup> PR snapcraft#761 closed: Remove dangling symlink from JDK plugin <Created by gnuoy> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/761>
<ppisati> ogra_: the PM code tried to suspend (IOW access) a device that was already removed
<ppisati> and kaboom!
<ppisati> but i'm running another test now
<ogra_> lovely !
<ppisati> fingers crossed
<ogra_> sadly i didnt get much firther with console-conf on the bbb nor with making the FS resize operate at a bearable speed :/
<ogra_> using a 64GB SDXC card takes about 30min to resize the writable partition :/
<ogra_> it works all fine using something like a 4GB SD though
<ogra_> though the fact that console-conf is python bites badly :( setting up the user account is also in the tens of minutes
<ogra_> but if you can live with the inital slowness the board works quite well after the first setup :)
<mup> PR snapd#1871 closed: snap: lessen annoyance of implicit interface tests <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1871>
<dholbach> Ubuntu Community Q&A with Michael Vogt starting in 15m (15 UTC) on http://ubuntuonair.com
<zyga> ooo
<zyga> way to go mvo! :)
<mup> PR snapd#1950 opened: store,snap: initial support for delta downloads <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1950>
<Saviq> hi all, any idea about http://pastebin.ubuntu.com/23207400/ ? I'm trying to follow https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ but can't even create the image... grub-install is obviously there on my machine
<ogra_> grub-install ???
 * ogra_ reads the paste
<ogra_> hmm, if it would open
<sergiusens> Saviq migt want to tell kgunn to update that guide to use ubuntu-image
<Saviq> sergiusens, ~same args?
<ogra_> Sano, completely diffferent
<ogra_> *Saviq
<Saviq> yay
<sergiusens> Saviq I have been completely decoupled (finally) from image building :-) \o/ !!!
<Saviq> where do I get ubuntu-image? snap find doesn't yield anything
<ogra_> sigh .. so this was 12min waiting for console-conf to set up the user ... go python
<sergiusens> use --edge
<ogra_> Saviq, see PM ... though whats the reason to actually create an image instead of using either the beta or daily ones that we already have ?
 * ogra_ points to http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ (for beta) and http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ for dailies
<ogra_> there shoudl really be no reason to build your own image
<niemeyer> jdstrand: Super easy one (I hope), for when you have a few seconds: snapd#1948
<mup> PR snapd#1948: interfaces/builtin: add run/udev/data paths to mir interface <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1948>
<Saviq> ogra_, I suppose to give it more space or something?
<jdstrand> yeah, that is. we discussed it
<jdstrand> niemeyer: fyi, pushed the docker change
<niemeyer> jdstrand: Thanks!
<Saviq> dunno, really - will try with the published image
<ogra_> Saviq, well, the beta ones have 3.8G ... the dailies around 3G ...
<Saviq> ogra_, ack, trying the daily
<ogra_> (at least for kvm ... )
<Saviq> 500 kBps on a 600Mbps link... why, oh why!?
<mup> PR snapd#1948 closed: interfaces/builtin: add run/udev/data paths to mir interface <Created by kgunnfront> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/1948>
<niemeyer> jdstrand: Don't see the docker change..?
<ogra_> there is a new PR
<ogra_> (for docker)
 * ogra_ noticed it in the mail spam ... 
<niemeyer> ogra_: That's the one we're discussing, I think/hope
<popey> ogra_: tried both pi 2 and pi3 images from http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ and neither gives any output on HDMI
<ogra_> ah
<popey> i set console=tty1 and nothing
<ogra_> popey, they do for me
<Saviq> kgunn, do you know if we still need the self-built image for https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ ? ogra_'s proposing either http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ or http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
<Saviq> ah d'oh
 * Saviq needs to read better, is all
<ogra_> popey, i always test using HDMI for one of them to run the console-conf wizard ... (and the other i test purely via serial)
<ogra_> usually alternating between them for each test ...
<ogra_> it might be that the boot stalls if there is no serial at all though ... i doubt anyone of us has ever tested without serial attached
<dholbach> how do I resolve something like this?
<dholbach> daniel@daydream:~/dev/snappy/snappy-playpen$ snap remove sayonara
<dholbach> error: cannot remove "sayonara": snap "sayonara" has changes in progress
<dholbach> daniel@daydream:~/dev/snappy/snappy-playpen$
<ogra_> dholbach, snap changes
<ogra_> find the change in progress
<ogra_> then "snap abort $changenumber"
<dholbach> nice one
<dholbach> thanks
<dholbach> let's see how this goes
<popey> ogra_: it brings up IP and no hdmi, but ssh with ubuntu@ the password 'ubuntu' fails. I don't understand this
<ogra_> popey, there is no ubuntu user anymore
<popey> ok, can i ssh in at all? before any setup?
<ogra_> no
<popey> ssh is running though
<ogra_> well, the network setup is also interim
<popey> so, what's a way forward here?
<ogra_> you only get proper configs in place after you ran through console-conf ...
<popey> I am using an announced image on commodity hardware and I get nothing on the screen
<niemeyer> jdstrand: There's probably a push missing on the docker branch
<ogra_> popey, it is an IoT image ... use it in this context ... really ...
<jdstrand> oh, I did!
<ogra_> (read: there will most likely *not* be any 20" HDMI screen on top of your robot or drone)
<popey> this is quite possibly the most frustrating I have felt for some time.
<popey> I give up
<jdstrand> niemeyer: ok, pushed for real
<ogra_> well, i cant really help you if you dont use a serial cable
<niemeyer> jdstrand: Thanks!
<popey> don't worry, I'll put them in a box and forget they exist
<ogra_> how am i even supposed to knwo whats going on without you being able to give me any debug info from the console
<popey> this worked with a previous image
<popey> my expectations clearly need a reset
<ogra_> it works every day here on my Pi's
<popey> I am happy for you.
<ogra_> and i cant tell if your SD has issues or anything if i cant get your serial output
<popey> the sd card worked fine, then i had to reflash because of the libssl issue I mentioned earlier
<popey> I have tried two sd cards and two generations of pi
<ogra_> do you see the rainbow square on screen when waiting for it to come up ?
<popey> no
<popey> nothing
<ogra_> then it just idles
<popey> i see heartbeat and network flash
<popey> and ssh on that port
<ogra_> how big is your SD ?
<popey> 32GB
<ogra_> hmm, that should take less than a minute to resize
<dholbach> ogra_, have you seen anything like this before? http://paste.ubuntu.com/23207556/
<ogra_> dholbach, oh, nope,. thats new
<popey> dholbach: yes, i have, make sure you kill all shells in that directory
<popey> dholbach: probably a bash running or something in there
<dholbach> ok, I'll restart after the hangout :)
<ogra_> popey, you can try something else and completely dumb down HDMI ... edit config.txt on the system-boot partition and add  hdmi_safe=1 ... see if that helps in any way
<ogra_> and as before ... if you dont use the daily image, re-flash before first boot
<ogra_> else the setup is likely messed up
<popey> ok
<ogra_> (or just use the daily, thats way more robust)
<ogra_> (and 10x faster to flash)
<popey> where is the pi3 daily image please?
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<popey> before I flash, here's the syslog http://paste.ubuntu.com/23207584/
<popey> fwiw
<mup> Bug #1625698 opened: console-conf on beaglebone takes unbearable long <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1625698>
<dduffey> matteo, morphis : i am using the current xenial pi3 image and when it boots i configure the network (just accept the defaults, it gets a dhcp address on eth0), and then enter my david.duffey@canonical.com.  I then can ssh into the pi3 ... but as soon as i reboot it goes back into "configure" first boot and then fails to create the existing user
<ogra_> popey, looks all fine ... it is most likely sitting theer waiting for input on the console
<ogra_> Sep 20 14:52:52 localhost systemd[1]: Started Ubuntu Core Firstboot Configuration tty1
<ogra_> that is what i see close to the end
<dduffey> matteo, are you using the current pi3 for your openwrt testing, or daily / edge?
<matteo> I made an image witu ubuntu-device-flash
<mup> PR snapcraft#742 closed: Handle missing source type packages in the parser <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/742>
<ogra_> dduffey, is that daily or the beta image from cdimage ?
<dduffey> ogasawara_, the beta image from cdimages
<ogra_> hmm
<dduffey> ogasawara_, dates sept 19
<ogra_> yes
<dduffey> ogasawara_, it may have something to do with on first boot it doesn't see wlan0
<dduffey> and then when you reboot it finds wlan0
<ogra_> (you should use three chars for your autocompletion ... though i guess leann is happy to collect pings)
<dduffey> ogasawara_, sorry
<ogra_> dduffey, yes, most likely ... that should be a bit better in the daily image ...
<dduffey> ogra_, the daily image pulls snap from the edge channel, right?
<ogra_> but even if the wlan0 issue is at fault, it should never bring you back to the config screen
<ogra_> yep
<ogra_> there landed a new console-conf today in the ubuntu-core snap in edge
<ogra_> so todays daily might not have that issue anymore (i havent tested pi's today, so ui cant really tell)
 * ogra_ was battling with the beaglebone images ... 
<dduffey> ogra_, okay, I will try ... another question ... in the past the snappy list -v showed all the snaps (including the prior installed snap) ... what is the 16 equivalent
<ogra_> snap list ...
<ogra_> but i dont think it shows former snaps ...
<ogra_> but the new snap keeps logs ... you can check with "snap changes"
<dduffey> I ask because on this image yesterday a "snap refresh" downloaded an ubuntu-core, today it said there was no updated but i think that is because it already snap refreshed on it's own ... I just want to verify
<dduffey> cool
<ogra_> and you can see details with "snap change $number"
<ogra_> (with the number listed in "snap changes")
<dduffey> you read my mind ... thanks!
<dduffey> yes, i see that it did update ubuntu-core on it's own
<popey> ogra_: so, cmdline.txt:- dwc_otg.lpm_enable=0 console=tty1,115200 elevator=deadline
<popey> right?
<popey> (also hdmi_safe)
<dduffey> ogra_, so this is where you would recommend downloading from? (and I'm assuming this will move out of your account someday): people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<ogra_> popey, yeah, that should work ... and in config.txt you set the hdmi option from above
<popey> yeah
<ogra_> dduffey, yeah, for the dailies use that url for now ... once infinity has set up dailies on cdimage i will shut that place down
<popey> ogra_: i get output!
<ogra_> great
<popey> thanks.
<ogra_> sadly the Pi will now never read your EDID :)
<ogra_> or any useful info from your monitor
<dduffey> matteo, once I try the pi3 daily, what do you recommend I do before installing the openwrt snap ... i.e during the first boot config ... dhcp on eth0 (so service it an ip address and browse to luci) ... and what about wlan0 setup?
<popey> ogra_: now it's been sat at "random: nonblocking pool is initialized" for 3 mins
<matteo> when you start openwrt it will always configure eth as wan interface, and wlan as lan
<matteo> so, dhcp on eth0
<matteo> an access point will bringed up on wlan0
<dduffey> matteo, okay thanks ... should i pre-setup a static config at first boot ... it seems like ubuntu core doesn't let me leave wlan0 "unconfigured" (i.e. it wants me to fill out the ssid)
<ogra_> popey, whats above that ?
<popey> ogra_: it finally finished :)
<ogra_> (there should be some info abnout resizing ... that might take a few mins)
<popey> was doing the resize for aaaaaaaaaaaaaaaaaaaaages
<ogra_> yeah, 32GB ...
<ogra_> the image is only like 300MB ...
<popey> and now I have lots of space :)
 * popey presses enter to configure, as told
<ogra_> it seems to only be that slow on non GPT installs ...
<ogra_> i wonder if we could switch the Pi's to GPT
<ogra_> but i guess that will make the proprietary bootloader fall over
<popey> I *love* this console setup thing
<popey> properly LOVE it
<popey> who made it?
<ogra_> yeah, it is great if it works :P
<ogra_> (still has a good bunch of issues, but getting better with every release)
<ogra_> popey, thats mwhudson ... and a bit cyphermox
<ogra_> "subiquity"
<popey> even if the keyboard layout isn't right :)
<popey> (i saw the thread)
<ogra_> the new installer
<ogra_> well and it cant realyl be right
<ogra_> we dont ship any keymap
<ogra_> s
<ogra_> the advantage is that the current install is only 160MB big :) ... and given you always only log in via ssh, the console keymap only kicks in at the config tool
<ogra_> ssh will use your hosts keymap and we dont set up local logins
<popey> but first setup the layout is wrong, for logging into the store
<popey> so I get my password wrong
<popey> although this time wasn't needed I guess because it recognised my device from last time?
<ogra_> your password ?!?
 * ogra_ has never seen a password prompt
<popey> it used to ask for pw/2fa?
<popey> or am I imagining that?
<ogra_> well, if it does, it has not asked me since i know that tooL (about a month now and i use it daily)
<ogra_> it should only ask for your LP email ...
<popey> ok
<popey> pretty sure I typed my 2fa in at least once
<ogra_> which means the @ is an issue
<popey> will see on the pi3, which I haven't ever setup like this
<ogra_> it really shouldnt ask for anything
<popey> ok
<ogra_> are you on the daily now or on beta still ?
<popey> daily
<ogra_> good
<ogra_> and the pi3 where you think you saw that, was that an official release or something rolled with ubuntu-device-flash
<popey> daily from same place
<popey> i havent set that up yet, doing now
<ogra_> btw bug 1621378
<mup> Bug #1621378: console-conf should tell the user that the keyboard is US only <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621378>
<cyphermox> well, we'll actually make it do proper keyboarding
<popey> ta
<ogra_> cyphermox, how ?
<cyphermox> US only is bad for the fr_FR
<cyphermox> there is a way to pick keyboards, and to apply keyboard settings
<ogra_> we dont have any keympas, locales or other language related bits on the image ...
<ogra_> deliberately
<cyphermox> I'm sure you have enough
<ogra_> pretty much zero
<cyphermox> or I'll find out that I'm wrong and cry myself to sleep
<cyphermox> :)
<ogra_> not sure, can you generate one on the fly ?
<cyphermox> or let mwhudson to do all that, if it happens that I'm pulled into somethign else
<ogra_> without any of the ablev
<cyphermox> I'm not sure
<ogra_> *above
<cyphermox> I need to go steal code from console-setup to do that
<ogra_> well, even that has input files
<cyphermox> my problem :)
<popey> ship a free US keyboard with every image
<ogra_> well, if you grow by more than 1MB it becomes mine :P
<cyphermox> I mean, US-only keyboard is really bad when your keyboard keys really don't have anything to do with US
<cyphermox> ogra_: I don't think it will have to grow by that much
<ogra_> i'll quote you on that :)
<cyphermox> from what I see right now, maybe 22k?
<ogra_> oh, thats good
<popey> bet ogra_ is sucking air over his teeth now... "oooh.. 22k.. can't do that guv"
<cyphermox> that's assuming I need all that console-setup currently needs, which is probably not quite true
<ogra_> haha
 * ogra_ looks around fro the hidden mic
<cyphermox> the truth is, I don't know right now how much we'll need, so we'll have to do some testing to find out
<ogra_> well, d-i doesnt need much either ... i guess you can steal from there
<cyphermox> yeah, that's the initial plan, I would say
<ogra_> that should be even less than console-setup
<cyphermox> well, it *is* console-setup
<ogra_> unless it switched to it nowadays
<cyphermox> console-setup-udeb; but still console-setup, minus some weight
<ogra_> (i remember there were times before console-setup )
<ogra_> yeah, that should be fine
<cyphermox> I think I can get away with a subset of that, where we don't deal with as many corner-cases and migration from old things
<cyphermox> and probably no keyboard detection
 * ogra_ is just scared to having to add locales back or some such
<cyphermox> it doesn't include locales
<ogra_> no, "... now that we have proper keyboard support, couldnt we also have localized firstboot setup ?"
<ogra_> this is the line that scares me :)
<ogra_> and boom, the install is back from 160MB to 500 or so
<ogra_> ogra@localhost:~$ df -h /writable
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/mmcblk0p2  3.5G  168M  3.1G   6% /writable
<ogra_> ogra@localhost:~$
<ogra_> :D
<ogra_> i really like that :)
<cyphermox> heh
<cyphermox> what can you do really
<ogra_> (and there is still stuf ui could rip out)
<cyphermox> or we can decide that it should just be US-only and that's it
<cyphermox> but this is a policy decision that is not mine to take
<ogra_> right, but we need a note on screen if we do that
<cyphermox> yes
 * ogra_ guesses if he would be super-size-nazi we could go down to half of the above 
<cyphermox> my question is, is this just an appliance thing, so we don't need to care much about the keyboard and ssh and VT access ?
<ogra_> i.e. *really* rip out everything that is not used
<ogra_> well, it is an IoT image ...
<ogra_> but ...
<cyphermox> or is it already targetting more hands-on access where the keyboard matters more?
<ogra_> it migth be the base for other stuff
<cyphermox> sure
<dduffey> ogra_, morphis just an update that I tried the daily and don't see the same issue (first boot config comes up a second time after reboot)
<cyphermox> but we can ship keymaps and locales as separate snaps later
<ogra_> if there is a unity8 snappy image for the dragonboard one day, it might use the current image underneath
<cyphermox> ie. we can later have a french pack that give you all the magic.
<ogra_> dduffey, awesome to hear ... does the IP setup persist too ?
<ogra_> cyphermox, yeah, and given the image sitze we could perhaps even have per-country images :)
<popey> ogra_: pi 2 and pi 3 all setup, thanks for the help, sorry for the grumpyness
<ogra_> popey, well, you are totalyl correct to be grumpy ... after all kgunn wants to run mir on all these boards one day
<cyphermox> ogra_: who would make that policy decision on keyboard?
<dduffey> ogra_, yes ... although first boot did not show wlan0, there is a similar bug already filed (you pointed to it in your announcement)
<ogra_> popey, i'm pondering to use hdmi_safe by default, but i am scared we lost to much on proper monitors then
<ogra_> cyphermox, dunno, lets bring it up at the sprint
<ogra_> s/lost/lose/
<popey> ogra_: is there a new way to enable classic?
<ogra_> cyphermox, given that mark ran into it, it will surely get some more attention :)
<dduffey> ogra_, it looks like your daily is actually using the stable store (had to snap install --edge snapweb)
<cyphermox> ogra_: is that a sprint I'm going to? do you need to get this by email or something so that it's not forgotten?
<ogra_> popey, sudo snap install classic --devmode --edge && sudo classic
<popey> ta
<ogra_> cyphermox, the le hague sprint in oct ... i would expect you to go there ... its also the final snappy sprint
<ogra_> before final release
<cyphermox> ogra_: is this a subjet you could bring up for us? I don't think I or mwhudson are going.
<ogra_> hmm
<ogra_> you realyl should be there, given you work on an essential part of snappy
<cyphermox> or tell me if I can put it down somewhere so it comes up
<ogra_> well, feel free to abuse bug 1621378 for it
<mup> Bug #1621378: console-conf should tell the user that the keyboard is US only <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1621378>
<ogra_> as a whishlist item
<ogra_> i guess we could wlak on from there
<ogra_> *walk
<cyphermox> ack
<ogra_> yeah, i dont see you on the attendees list ... not even slangasek ... but infinity is listed (without any dates thoguh)
<seb128> ogra_, yeah, foundations are not in UES anymore so not invited
<seb128> invited->included
<ogra_> seb128, well, given it is the final snappy sprint before we release golden images i was expecting anyone who works on snappy related bits to be invited alongside
<seb128> no p_itti either
<ogra_> paolo is there as well ... semmingly as the only kernel team person ...
<lucacome> hello
<lucacome> quick question, does snap use LXD?
<ogra_> normally not, but they can
<ogra_> i.e. there is an lxd snap that you supposedly can use in your snap through an interface ... and also a docker snap ... both would need special setup for your snap though ... by default snaps dont use any container technology
<lucacome> thanks ogra_
<lucacome> I was reading "is confined from the OS and other apps through security mechanisms"
<lucacome> but it's not very detailed :)
<nacc> lucacome: https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ might have more details
<ogra_> i thihnk there is some online docs ...
<ogra_> ah, nacc is fast :)
<lucacome> :)
<lucacome> thank you
<ogra_> wow, compared to the sikipages we had in 15.04 that became a "rainy sunday afternoon reading"
<ogra_> *wikipages
 * ogra_ EODs --- 
<mup> PR snapcraft#815 opened: Replacing deprecated API for searching snaps <Created by cprov> <https://github.com/snapcore/snapcraft/pull/815>
<mup> PR snapcraft#791 closed: Enable crosscompilation for dump and copy plugins <Created by ehbello> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/791>
<mup> PR snapcraft#816 opened: Report the proper line number on bad yaml errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/816>
<Ishu> Can we install snappy on rpi3?
<Is> Can we install
<Is> Snappy on rpi3
<Is> ?
<Is> Can i install snappy on raspberry pi 3?
<Is> ?
<mup> PR snapd#1951 opened: interfaces/builtin: improve testability and add regression test for LP: #1625291 <Created by zyga> <https://github.com/snapcore/snapd/pull/1951>
<zyga> launchpad seems to fail on writes for me
<mup> Bug #1625291 changed: ConnectedSlotSnippet not invoked when connecting two snaps <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1625291>
<zyga> jdstrand: hey, do you think you could add something here https://bugs.launchpad.net/snap-confine/+bug/1621624
<mup> Bug #1621624: /dev/pts/# denial when running snap-confine under sshd configured for pam-apparmor <Snappy Launcher:Fix Released by jdstrand> <https://launchpad.net/bugs/1621624>
<zyga> jdstrand: speciically to the [Test Case] section, this is a part of the SRU paperwork
<jdstrand> zyga: the test case requires a pretty advanced setup. I think so long as the policy compiles and you can login via and use hello-world, then you are good. I can then do the pam-apparmor testing on my system to mark it as verification done
<jdstrand> login via ssh*
<zyga> jdstrand: thanks I'll think of something
<jdstrand> zyga: well, I'm trying to save us time :)
<mup> PR snapd#1942 closed: store,snap: initial support for delta downloads <Reviewed> <Created by absoludity> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1942>
<mup> PR snapd#1950 closed: store,snap: initial support for delta downloads <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1950>
<zyga> eh, three more bugs to describe
<zyga> this is a _lot_ of work
<jdstrand> zyga: all it does is expand access in a corner case configuration. all that is needed for that with SRUs is to prove it didn't regress
<jdstrand> zyga: that's how we normally do apparmor policy SRUs
<jdstrand> zyga: if it compiles and you only added access, the SRU is fine. ping me when verification-needed and I'll verify it works for my configuration
<zyga> jdstrand: thanks :)
<zyga> one bug to describe left
 * zyga is starving, brb
<zyga> I left the hardest bug till the end
<zyga> jdstrand: I'm EOD now but if you want to add anything to https://bugs.launchpad.net/snappy/+bug/1611444 please do
<mup> Bug #1611444: Cannot share a namespaces created with 'ip netns' between apps in a devmode SNAP <snapd-interface> <Snappy Launcher:Fix Released by zyga> <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1611444>
<zyga> jdstrand: I've added SRU information to each bug in the 1.0.40 and 1.0.41 milestones and I will see what's the next step tomorrow
<zyga> jdstrand: I suspect I need a version of snap-confine from yakkety that has a long changelog entry that includes two dozen bug numbers
<zyga> jdstrand: and have someone upload that
<zyga> mwhudson: (perhaps you can do that?)
<zyga> jdstrand: I've done my part for today, I really need to take a break now
<jdstrand> zyga: thanks!
<jdstrand> zyga: I think I'll treat that bug the same as the other and demonstrate that ip netns works when it gets the verfication-needed tag
<jdstrand> zyga: enjoy your evening :)
<niemeyer> Spread has been updated. Please report any fires.
<mup> PR snapd#1925 closed: tests: adjust regex after changes in stat output <Reviewed> <Created by vosst> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1925>
<diddledan> just informational: corebird snapped by github.com/diddledan/corebird-snap in devmode launches but cannot open browser windows to login to twitter with error: Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files
<mup> PR snapd#1930 closed: many: support snapctl -h <Reviewed> <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1930>
<mup> PR snapcraft#817 opened: lxd: use built-in image streams <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/817>
<mup> PR snapd#1872 closed: tests: use in-tree snap{ctl,-exec} for all tests <Reviewed> <Created by mvo5> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1872>
<mup> PR snapcraft#816 closed: Report the proper line number on bad yaml errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/816>
<mup> PR snapcraft#811 closed: Support deb files as sources <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/811>
<mup> Bug #1625805 opened: arm64 kernel panic for l2 mmu with unity8 session snap <Snappy:New> <https://launchpad.net/bugs/1625805>
<mup> Bug #1625813 opened: hardware-observe does not allow reading temperatures <Snappy:New> <https://launchpad.net/bugs/1625813>
 * mwhudson waves at zyga
<mup> Bug #1625817 opened: Document snap prepare-image options <Snappy:New> <https://launchpad.net/bugs/1625817>
<Chipaca> ogra_, you around?
<Chipaca> ogra_, n/m, nothing urgent, i'll pester you tomorrow if i have a chance :-)
<oparoz> Hello, have people tried to snap dockers yet?
<zyga> mwhudson: hey
<zyga> mwhudson: I did some untold number of SRU paperwork bug updates, if you want to collect them in a xenial upload that would help me a lot
<zyga> mwhudson: each bug from 1.0.4{0,1} qualifies, some are already in xenail and I marked them as such
<kyrofa> oparoz, might be worth emailing the list
<oparoz_> kyrofa, you're probably right
<mwhudson> argh does the systemd journal not persist between boots on snappy systems?
<mwhudson> zyga: so you want me to write the changelog entry and upload?
<mup> PR snapd#1952 opened: configstate,hookstate: add snapctl set <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1952>
<zyga> mwhudson: you'd have to mkdir /var/log/journald AFAIK
<zyga> mwhudson: yes, please add a changelog entry, link to the gazillion bugs and upload if you can
<mup> PR snapd#1785 closed: many: add vendoring of dependencies by default <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1785>
<zyga> mwhudson: we'll fight the SRU dragon :)
<mwhudson> zyga: ok
<mwhudson> heh i seem to spend a lot of time doing that
<mup> PR snapd#1862 closed: tests: add tests for the classic dimension <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1862>
<mup> PR snapd#1640 closed: tests: add gsettings interface spread test <Decaying> <Reviewed> <Created by fgimenez> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1640>
#snappy 2016-09-21
<mcphail> Does snap confinement affect dlopen() calls at all? My library is not getting found despite being in the LD_LIBRARY_PATH directory
<nacc> mcphail: is it in the snap's squashfs?
<mcphail> nacc: yes. Also trying using "snap try" in uncompressed filesystem
<mcphail> code as per http://paste.ubuntu.com/23209466/ with the libglide2x.so file within the same directory with all the other libs, as per the LD_LIBRARY_PATH variable. Works OK when I set the same variable but run outside snap confinement
<mup> PR snapcraft#815 closed: Replacing deprecated API for searching snaps <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/815>
<mup> PR snapcraft#817 closed: lxd: use built-in image streams <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/817>
<mup> PR snapcraft#814 closed: Make source-depth a parameter and opt-in <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/814>
<mdye> "snapcraft keys" reports that my default key is not enabled. I've somehow managed to botch registering it by attempting to register multiple keys. Is there a UI or API I can use to de-register or replace keys registered with the store?
<mwhudson> zyga: uploaded the thing
<cjwatson> mdye: Unfortunately not yet, though registering multiple keys should work fine.
<cjwatson> mdye: 2am here, so maybe send mail to the snapcraft list if you can't disentangle it?
<mdye> cjwatson: alright; I've tried this "snapcraft -d register-key" after generating a new default key and snapcraft failed to register: snapcraft.storeapi.errors.StoreKeyRegistrationError: Key registration failed: Failed to save account-key-request assertion for account_id JmtGtPclFB8St7FNhFmDZ3ijMqEQIbl8: Unexpected response while processing assertion: {"detail":"could not add assertion (revision 0 is already the current
<mdye> revision)","error_list":[{"code":"invalid-revision","message":"invalid revision: could not add assertion (revision 0 is already the current revision)"}],"status":409,"title":"invalid revision","type":"assertions:v1:invalid-revision"}
<mdye> happy to post to the list if that seems like the right place to ask given the time
<cjwatson> Wow that's an ugly error.  Suggests it's already registered, though.
<mdye> right, 409 conflict; I assumed b/c of the name? (default), not b/c of the GPG key's ID
<cjwatson> Unless it doesn't like it being called default.
<mdye> right
<cjwatson> You could always call it something else.
<mdye> so can I generate my own key (instead of using snapcraft for it), register that, then still use the snap tools to sign with it?
<cjwatson> You can just use "snap create-key some-other-name", "snapcraft register-key some-other-name".
<cjwatson> (from memory)
<mdye> great, thx
<mdye> and thx for the tools, guys. (zyga, others)
<cjwatson> We'll have revocation soonish, but still needs some design work (outside of emergency handling)
<mup> PR snapd#1953 opened: Pass through screenshots from snap store <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1953>
<zyga> mwhudson: o/
<zyga> mwhudson: thank you, I will work on getting it verified
<freelock[m]> Hi
<freelock[m]> I'm wondering if a snap package is a good fit for a problem I'm trying to solve... the problem is, I have a bunch of older PHP (Drupal sites) to manage, and a CLI tool to manage them (drush), but this is not happy on Ubuntu 16.04
<freelock[m]> I run the actual sites in Docker containers, with an older version of PHP bundled in that Drupal 6 can handle -- these sites have way too many deprecated function calls that have been removed in PHP 7, which is in 16.04
<freelock[m]> that all works great, but when I go use the shell tools, running those under php 7 fails completely. I know I can bundle my shell tools in single-run Docker containers, but I was wondering if a snap package might be a good alternative
<freelock[m]> can you easily bundle older (or newer) versions of things like PHP (or gtk bindings, for another problem I'm trying to solve) in a snap package?
<mwhudson> zyga: well you need to get an SRU team member to release it first :)
<mup> PR snapd#1954 opened: Add store.requestOptions.ExtraHeaders so that individual requests can customise headers <Created by absoludity> <https://github.com/snapcore/snapd/pull/1954>
<zyga> mwhudson: hmm? I don't fully recall the process but AFAIK it gets into proposed and then is verified to be pushed to updates
<dholbach> good morning
<didrocks> good morning dholbach
<dholbach> salut didrocks
<mcphail> Does snap confinement affect dlopen() calls at all? My library is not getting found despite being in the LD_LIBRARY_PATH directory
<dholbach> zyga, is https://github.com/ubuntu/snappy-playpen/pull/205 something you wanted to take a look at or validate? it looks like Cemil pinged you as well.
<mup> PR ubuntu/snappy-playpen#205: Mesa demos <Created by camako> <https://github.com/ubuntu/snappy-playpen/pull/205>
<zyga> dholbach: looking
<dholbach> cool, thanks
<mup> PR snapd#1955 opened: docs: fix formating of HACKING.md "Testing snapd" <Created by mvo5> <https://github.com/snapcore/snapd/pull/1955>
<subh94> I am getting error: cannot find signatures with metadata for snap while installing any snap package build on my system, System Information: Snapcraft Version: 2.17, Ubuntu 16.0.1. Even Demo Snap are also not working. Any help with how to resolve this issue.
<mvo> subh94: can you please try "sudo snap install --dangerous snap-file.snap" ?
<mcphail> subh94: you now need to pass the --force-dangerous flag
<mwhudson> zyga: it doesn't get into proposed immediately, it sits here first: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
<mup> PR snapd#1244 closed: snap: show snapname before the progress download <Decaying> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1244>
<techtonik> what is the status of support on fedora?
<dholbach> zyga, I think it's good to go from a playpen perspective
<mvo> techtonik: zyga wil know the details but AFAIK its available in the fedora devel series
<mup> PR snapd#1956 opened: many: show snap name before the download progress bar <Created by mvo5> <https://github.com/snapcore/snapd/pull/1956>
<fgimenez> hey didrocks :) have a minute?
<didrocks> fgimenez: I can make a minute :-)
<fgimenez> didrocks, great :) i'm trying to write a test for the gsettings interface, this is what i have so far https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1
<mectors> I get the following app armor problem when running an updated version of the nodered snap. Did not have this with the version that did not have nodes installed. What is this? Sep 21 07:56:24 ubuntu ubuntu-core-launcher[17194]: STARTING NODE-RED - /snap/nodered/x1/bin/node-red /snap/nodered/x1/settings.js /root/snap/nodered/x1
<mectors> Sep 21 07:56:25 ubuntu kernel: [56451.987557] audit: type=1400 audit(1474444585.481:4450): apparmor="DENIED" operation="open" profile="snap.nodered.red" name="/run/resolvconf/resolv.conf" pid=17199 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<fgimenez> didrocks, the idea is to install a test snap declaring a plug on gsettings, try to read/write a value with the plug connected and do the same with the plug disconnected, checking the error in that case
<didrocks> fgimenez: ok, making sense
<didrocks> I see that you are aware you need the home interface to be able to read the changed value
<fgimenez> didrocks, so far no luck however, i'm not sure if the test snap is properly defined, could you please take a look?
<didrocks> (otherwise, you only get defaults)
<didrocks> oh? I quickly browsed, and it seems okâ¦
<didrocks> what doesn't work?
<didrocks> you don't need the export in set/get if you are using the desktop-launcher normally
<fgimenez> didrocks, i'm getting this in the read operation http://paste.ubuntu.com/23210600/, this value seems to come from inside the snap because outside the value of that key is different
<fgimenez> didrocks, ah ok thanks good to know
<fgimenez> didrocks, what is worst is that the get operation works with the plug disconnected
<didrocks> fgimenez: yeah, it's using the default
<didrocks> ok, let me try to build the snap
<fgimenez> didrocks, ok thanks a lot
<joc_> mvo: hi, do you have any suggestions for how i might validate a snap.yaml file for a gadget snap?
<ogra_> mvo, what happened to your pastebinit snap, would be really helpful to have it on images again
<ogra_> joc_, you coudl show it to someone how knows them ;) (like me)
<joc_> ogra_: ha, the manual approach
<didrocks> fgimenez: same with glib-compile-schemas, you don't need them, the launcher does it for you on first run
<fgimenez> didrocks, ok thanks, i was getting "No schemas found" without it, maybe the exports were meesing things up
<ogra_> joc_, in general the snap.yaml is pretty empty nowadays http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/meta/snap.yaml
<ogra_> all valuable info moved to the gadget.yaml
<joc_> ogra_: yeah this is really a slots issue i think, but it is tricky to validate the yaml if the slots are for interfaces that are Core or Gadget snap only
<didrocks> fgimenez: you are missing dconf-gsettings-backend stage package
<ogra_> oh, yeah
<didrocks> fgimenez: I didn't add it by default as I'm unsure about adding it in the glib-only profile, then some people like ogra tells the launcher is pulling too many dependencies :)
<didrocks> and glib-only is really minimal for that purpose
<didrocks> the rest is ok
<ogra_> didrocks, i didnt say that since agess :P
<didrocks> ahah, you told it enough for a whole year at least! :)
<fgimenez> didrocks, ah ok, let me try that
<ogra_> well, i still think it is overkill in cases where i only want font support to pull in a whole toolkit :)
<didrocks> glib isn't a toolkit
<ogra_> well or a library stack ... whatever
<ogra_> Chipaca, hey
<ogra_> you pung ?
<joc_> ogra_: on the subject of gadget yaml, if you wanted to add some "content:" to the generic pc gadget (all snaps image) and you wanted the target to be a file under /etc that should be visiable when everything is mounted, how would you modify the gadget.yaml file to do that?
<ogra_> joc_, i fear you cant ... the gadget will copy everything under /boot/$bootloader/ currently (thats a bug i think)
<ogra_> iirc mvo wanted to bring that up with niemeyer (omeone else had that prob too iirc)
<ogra_> +s
<joc_> ogra_: it might have been woodrow, i was trying to help workout how to get a watchdog config file in to place
<joc_> sounds like content in the gadget yaml won't be able to do that
<ogra_> joc_, well, on that one i have to defer to mvo
<ogra_> right, but it shoudl
<joc_> ack
<ogra_> but that means "snap prepare-image" (which ubuntu-image calls) needs to support this
<joc_> yeah understood, i was wondering if we needed to add some explicit spec of the writable partition to the gadget.yaml and try copying in to there
<joc_> assume the tools dont support that though
<ogra_> not sure if you could try a relative path ... like "target: ../../writable/system-data/etc/foobar.conf"
<mup> PR snapd#1957 opened: many: add support for installing/removing multiple snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/1957>
<ogra_> but i guess snap prepare-image will reject that ...
<fgimenez> didrocks, ok, i've pushed the fixes to the test snap https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, rebuilt and reinstalled, but something seems to be missing yet http://paste.ubuntu.com/23210700/
<Chipaca> ogra_, hey, i pung
<ogra_> so you did :)
<Chipaca> ogra_, just idle thoughts to poke at the python slowness on bbb
<ogra_> replace it with a small shell script ?
<ogra_> :P
<didrocks> fgimenez: /home/fgimenez/.last_revision -> did you install your snap properly? It seems you are setting $HOME to real user home
<didrocks> you shouldn't export any variable
<didrocks> or compile schemas
<Chipaca> ogra_, yeah :-) no wait it was actually trying to see if running it with -SI made it faster, and having you run it with -vv to see if it was imports slowing it down
<mcphail> Does anyone know if dlopen() calls get changed or intercepted within snap confinement? I'm trying to work out why a library under LD_LIBRARY_PATH isn't being found
<ogra_> Chipaca, ah ... well, the binary and startup scripts are inside the squashfs ... that's some work to set up ... but good idea ... perhaps mwhudson could add it to the package for a while (and drop it before next beta)
<fgimenez> didrocks, i think so, no more export nor compile schemas, the source is at https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, after "snapcraft clean && snapcraft" i install it with "sudo snap install --dangerous ./test-snapd-gsettings-consumer_1.0_amd64.snap"
<didrocks> fgimenez: ~/.last_revision, is what the launcher is using
<didrocks> fgimenez: snap run --shell test-snapd-gsettings-consumer.get
<didrocks> $ echo $HOME
<didrocks> /home/didrocks
<didrocks> -> it seems that $HOME isn't set to SNAP_USER_DATA anymore?
<didrocks> fgimenez: zyga: do you know about this? ^
<Chipaca> ogra_, wrt -vv, is there a better way to timestamp stderr than, from bash, 2> >(while read l; do printf "%s %s\n" "$(date -uIns)" "$l"; done) ?
<Chipaca> ogra_, you could run it by hand once the system is booted and lets you log in, surely?
<ogra_> not sure ... i know it falls over when a user exists .. but only later ...
<Chipaca> ogra_, answering myself wrt better way: yes, redirect the while loop to /tmp/stderr makes things a lot better
<Chipaca> i.e, python3 -vv /path/to/thing 2> >(while read l; do printf "%s %s\n" "$(date -uIns)" "$l"; done > /tmp/stderr)
<Chipaca> tadaa, timestamped import log
<ogra_> we have a timestamped log ... but that only starts writing stuff once the app started ... we need omething in the systemd that writes a start timestamp
<ogra_> *in the systemd unit
 * ogra_ hass to dig into the setup of the subiquity package ... i think there is a wrapper script somewhere that replaces getty 
<joc_> didrocks: i noticed that $HOME change too, i was confused as to why our checkbox snap was storing .config/.cache folders outside of snap folder suddenly
<didrocks> yeah, it's weirdâ¦ I think that's known thanks to our testsuite? :)
<mup> PR snapd#1958 opened: snap: remove extra newline after progress is done <Created by mvo5> <https://github.com/snapcore/snapd/pull/1958>
<mvo> joc_: yeah, what ogra_ said, its not possible to populate anything outside of the boot partition currently with gadget.yaml
<mvo> joc_: if that is something we need it should be raised with niemeyer (just for context for niemeyer, the question is if gadget.yaml could support content outside of the boot partition, e.g. to setup bits in /etc)
<mvo> ogra_: re keymap> if the keyboard-configuration package is enough that only adds ~600kb or so to the image (unless there is more missing but it looks ok from a quick glance)
<ogra_> mvo, yeah, if thats enough, then i'm fine ... as long as it doesnt pull in megabytes of font encodings and whatnot
<mvo> ogra_: worth a shoot IMO, if its more than that we can pull it out again
<joc_> mvo: thanks for the summary
<mvo> ogra_: so how am I supposed to add keyboard-configuration now? via the system-image seed ?
<mvo> ogra_: IOW via bzr ?
<ogra_> mvo, we will definitely need to be able to add files ... i.e. some USB NICs (like the onboard one on the beaglebone) require sysctl files that are board specific to make the NIC work right
<ogra_> mvo, just grab the ubuntu-core-meta packagefrom the PPA
<ogra_> then add it to the different system-image-$arch files
<mvo> ogra_: oh, manually? ok
<ogra_> mvo, yeah, no way to edit the seed
<mvo> ogra_: I'm not sure that is really progress if I need to add that now N times instead of a single time
<mvo> ogra_: anyway, uploaded, lets see how bad the resulting size increase is and we can revert if it is too terrible
<ogra_> well, it is the only way
<ogra_> mvo, we could perhaps do an out-of-distro seed to centralize it and keep it editable, but i dont know if germinate would like that, thats a cjwatson question
<cjwatson> I don't know what an "out-of-distro seed" would be
<ogra_> some random bzr branch under snappy-dev
<ogra_> our seed currently lives inside the official ubuntu one
<ogra_> as "system-image"
<cjwatson> You can run germinate (specifically in this case germinate-update-metapackage) from whatever input you like; it doesn't care
<mvo> ogra_: well, its fine for a one-off edit, but when I need to touch this next I will write some script and a system-image.common thing that includes all the common things so that I only need to touch a single file
<mvo> (or do something else, but not edit N files again :)
<ogra_> well, i'm happy with anything you do, just tell me about it :)
<mvo> ogra_: heh :) nothing for now until I touch this next time
 * ogra_ is kind of used to doing it that way, we do it on the phone since years
<ogra_> mvo, but perhaps moving to a separate seed file makes more sense ...
<mup> PR snapd#1959 opened: many: use unique plug/slot names in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1959>
<ogra_> Chipaca, so using -SI makes it fall over with imports ... i guess i need to do a bit more here
<ogra_> Chipaca, btw, running 'time python -v -c ""' (i.e. just firing up the interpreter) already takes 2sec
<Chipaca> ogra_, that's python2, not python3
<ogra_> err, sorry ... wrong paste ... i actually called python3
<Chipaca> ogra_, what does 'time python3 -v -c ""' say, and what does 'time python3 -IS -v -c ""' say
<ogra_> https://bugs.launchpad.net/snappy/+bug/1625698/comments/5
<mup> Bug #1625698: console-conf on beaglebone takes unbearable long <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1625698>
<Chipaca> ogra_, also, the -v there is skewing your metric
<ogra_> Chipaca, -IS cuts it by half
<Chipaca> ogra_, :-)
<ogra_> but if i add it to the shebang in the script it doesnt find any of its imports
<ogra_> so i guess there is more needed
<ogra_> also ... i'm not sure thiss will help at all,. given the CPU alone is saturated for a min or two still ... working on bg processes while the script tries to start
<ogra_> we can surely catch some low hanging fruits here when poking at it on the idle board ... but i guess the boot context will still make it super slow ... we only have one core and that is under high load when it runs in its real context
<ogra_> (after ten years of battling with python on arm32 i'm rather pessimistic)
 * mwhudson hands ogra_ a nickel
<mwhudson> buy another core!
<ogra_> lend me your soldering iron too !
<ogra_> (and some pliers)
<mwhudson> heh
<mwhudson> ogra_: i guess if you boot the bbb and let it sit there for 10 minutes before hitting enter, it all happens much more smoothly?
<ogra_> i'll have to try, but i bet so too :)
<mwhudson> seems like it really is down to the single core
<mwhudson> hum
 * mwhudson goes to bed rather than trying to be useful
<ogra_> should we just add a "sleep 6000" ?
<ogra_> :)
<ogra_> mwhudson, we had similar probs with the old snappy that was written in python ... insstalling a nap with it on the bbb took minutes ...
<ogra_> *a snap
<ogra_> it went down to seconds with the initial switch to the go binary
<mwhudson> ogra_: well maybe we'll do that here, i'm not signing up to get it done by GA though!
<ogra_> yeah, i know :)
<mwhudson> ogra_: also snap create-user takes 15 mins and that's written in go
<ogra_> true
<ogra_> but thats also generating keys, no ?
<mwhudson> er no, misread
<mwhudson> several minutes, let's say
<ogra_> yes
<mwhudson> ogra_: no, it's just making an api request and calling adduser & friends
<ogra_> the log is a bit tricky regarding the timetamps because it get a new ntp time in the middle
<ogra_> oh, i thought it also put a public key in place
<ogra_> for the store
<mwhudson> also the timestamps are at minute resolution ffs
<mwhudson> ogra_: no, it puts stuff in ~/.ssh/authorized_keys but it's not generating anything
<ogra_> ah, k
<mwhudson> unless that's changed since i last looked but i don't think it has
<Son_Goku> zyga: ping
<jdstrand> mectors: you need to 'plugs: [ network ]' in your 'red' command
<niemeyer> mvo, joc_: That sounds slightly strange, but it'd be good to clarify what these bits are to be sure..
<mectors> jdstrand, I have the following:   red:
<mectors>     daemon: simple
<mectors>     command: bin/launch
<mectors>     plugs:
<mectors>       - network-bind
<mectors>       - network
<mectors>       - network-observe
<mectors>       - bluez
<mectors>       - bluetooth-control
<mectors>       - pulseaudio
<ogra_> niemeyer, typically files in /etc/sysctl.d (we discussed them at the sprint even iirc), additional ystemd job files etc
<niemeyer> In general, we don't want images to diverge in what they contain based on arbitrary bits inserted into the filesystem out-of-band
<mectors> jdstrand, https://github.com/mectors/nodered.snap
<niemeyer> ogra_: Yeah, that sounds like content that should go through official means, inside a snap
<ogra_> niemeyer, i wanted to put them into the kernel snap and you said they should rathetr be a gadget thing
<ogra_> especially the sysctl bits are very board specifc
<jdstrand> mectors: does 'snap interfaces' show it as connected?
<ogra_> i.e. USB NICs might need per board cache sizes you can manage via a sysctl value
<ogra_> (and awfully enough the majority of arm boards uses builtin USB NICs)
<mectors> jdstrand no
<niemeyer> ogra_: This might be handled as configuration, which the gadget snap can ship as a default system configuration
<niemeyer> ogra_: handled as kernel configuration, that is
<ogra_> niemeyer, right, i think that were your words at the sprint too ;)
<niemeyer> or core configuration, actually
<jdstrand> mectors: ok, so that is your problem. however, I don't know why it wasn't autoconnected, cause it should have been. curious, did you install this via a gadget snap?
<niemeyer> ogra_: Ah, I'm glad there's agreement between me and myself.. sometimes that's not the case
<ogra_> you cant handle that in the kernel if the NIC needs different values per board and you dont want tio maintain a kernel for each board
<mectors> jdstran, no via snap install --force-dangerous
<ogra_> i.e. not via a compile time config
<mectors> jdstrand, no via snap install --force-dangerous
<ogra_> our generic kernel supports something like 20 boards currently ... i'D like us to have gadgets in the store for them in the long term ... using the same kernel snap
<jdstrand> mectors: I suggest filing a bug. give 'snap list' output, the snapcraft.yaml you used and how you installed it, show snap interfaces output and that you expected it to be autoconnected
<ogra_> but for that runtime tweaking needs to be possible
<ogra_> niemeyer, where would that core config live ? not in the gadget snap ?
<niemeyer> ogra_: We can if it's a kernel _config_.. but I think core is better nevertheless
<niemeyer> ogra_: The configuration option/setting/handling would live in the core
<ogra_> but we dont have that today
<niemeyer> ogra_: The gadget will have the ability to ship default configurations for all snaps in the system
<ogra_> ah, k
<niemeyer> ogra_: Not today, no.. we're working on it
<ogra_> well, that doent sound like GA though
<ogra_> is that on the plan ?
<ogra_> (for GA)
<niemeyer> ogra_: Yes, I hope it is
<niemeyer> ogra_: (ready by then..)
<niemeyer> ogra_: With some luck, in the next two weeks
<ogra_> especially that watchdog thing is a requirement i think ... we just talked these guys into using systemd watchdog and dropped the universe watchdog package ...
<jdstrand> mectors: and indicate if snap connect nodered:network ubuntu-core:network works around the issue
<ogra_> ok, then we're fine i guess
<niemeyer> We're _hopefully_ fine ;)
<ogra_> heh
<ogra_> niemeyer, mvo, another thing iss the GL stuff ... we need to discuss where that lives and how we handle it in regard to the arm boards
<ogra_> i imagine the libs should go into the kernel snap ... but we dont support that today
<ogra_> (and some bind mount love to put them into ,... what was it ? /usr/lib/gl ? )
<ogra_> (for later (regarding ubuntu-pd) i guess we also need to ship the android container inside the kernel snap and put the right bits in the right places)
<ogra_> (not sure what the exact plans are for that one)
<ogra_> but i guess the latter bit is something we can talk about at the sprint ... not that urgent
<mup> PR snapd#1959 closed: many: use unique plug/slot names in tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1959>
<mup> PR snapcraft#818 opened: Fix trunk <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/818>
<Son_Goku> zyga: ping
<mup> PR snapd#1951 closed: interfaces/builtin: improve testability and add regression test for LP: #1625291 <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1951>
<mup> PR snapd#1954 closed: store : add requestOptions.ExtraHeaders so that individual requests can customise headers <Created by absoludity> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1954>
<mup> PR snapd#1960 opened: revert 'allow mmaping pulseaudio buffers' <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1960>
<jdstrand> zyga: fyi ^
<jdstrand> zyga: oh, you are fast :)
<mup> PR snapd#1961 opened: many: avoid snap.InfoFromSnapYaml in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1961>
<popey> trying to install dekko from the store...
<popey> sudo snap install dekko.dekkoproject --channel=edge
<popey> error: cannot install "dekko.dekkoproject": snap not found
<popey> any idea what's going on there?
<popey> it's published, in the edge channel
<mup> Bug #1626082 opened: Fedora 24 install fail with snapd 2.14 <Snappy:New> <https://launchpad.net/bugs/1626082>
<mup> PR snapd#1955 closed: docs: fix formating of HACKING.md "Testing snapd" <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1955>
<sergiusens> popey maybe snap install dekko --edge
<sergiusens> popey .<developer> is a store artifact
<popey> error: cannot install "dekko": snap not found
<sergiusens> popey do you have the link to the store for the snap?
<DanChapman> snap install --devmode --edge dekko just worked for me.
<popey> https://myapps.developer.ubuntu.com/dev/click-apps/5980/review/rev/5/
<popey> wat
<popey> that works here too
<popey> i can haz dekko
<popey> \o/
<sergiusens> popey oh right, if it requires devmode it needs to be stated
<kalikiana> There is a dekko snap? Nice. I can stop fixing my build errors in my snapcraft.yaml then :-P
<kalikiana> Tho I'd be curious how you got oxide working
<mup> PR snapd#1962 opened: interfaces: drop ErrUnknownSecurity <Created by zyga> <https://github.com/snapcore/snapd/pull/1962>
<DanChapman> kalikiana, I just disabled oxide's sandboxing `export OXIDE_NO_SANDBOX=1`. Not ideal but at least there is still some protection from snap confinement
<kalikiana> Oh, good find
<jdstrand> pcoca: hi! do you have a moment to work through bug #1613572 ?
<mup> Bug #1613572: sandbox denials for snaps on BTLE device <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1613572>
<mup> PR snapd#1960 closed: revert 'allow mmaping pulseaudio buffers' <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1960>
<pcoca> jdstrand, OTP. Is OK to talk in 40 min?
<mup> PR snapd#1958 closed: snap: remove extra newline after progress is done <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1958>
<diddledan> dholbach: (replying from yesterday) corebird snapped by github.com/diddledan/corebird-snap in devmode launches but cannot open browser windows to login to twitter with error: Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files
<dholbach> diddledan, that's probably 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>
<diddledan> dholbach: ok, I'll test the proposed snapd to see if that fixes it
<dholbach> *cross fingers*
<diddledan> ok, it still fails after installing snapd. I am going to reboot to ensure the state is updated fully.
<diddledan> right, it still fails after a reboot. shall I mark the verification-failed tag on the bug or just comment with my attempt?
<dholbach> diddledan, yeah, best to just comment - let me see who to ping about this
<dholbach> attente, ^ here's probably a test-case for 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>
<diddledan> thanks dholbach
<dholbach> anytime
<diddledan> I love our community :-)
 * diddledan cuddles "the community"
<dholbach> haha :-)
 * dholbach hugs diddledan back :)
<diddledan> \o/
<Chipaca> dholbach, diddledan, you're aware that we know that's broken in current snapd and is fixed on master?
<dholbach> Chipaca, I thought that's what diddledan tested(?)
<Chipaca> dholbach, diddledan, that's what https://lists.ubuntu.com/archives/snapcraft/2016-September/001173.html blathers on about
<diddledan> Chipaca: I was following the comment in the bug that said xenial proposed had a potential fix to be tested
<Chipaca> sorry, I might be misunderstanding :-) did a very quick scan of the backlog
<Chipaca> but it sounded like you were saying that you were going to mark the sru of snapd-xdg-open as verification-failed
<diddledan> Chipaca: oh, I think I might have tested the wrong package
<diddledan> Chipaca: thanks for pointing out my mistook :-p
<diddledan> I installed snapd
<Chipaca> snapd-xdg-open is the thing that should be providing the dbus service
<diddledan> not snapd-xdg-open
 * diddledan tries again
<Chipaca> and your snap either needs to be in devmode, or you need to have an unreleased snapd
<Chipaca> (as it's fixed on master but not in 2.14)
<diddledan> ok, that's working correctly then.
<diddledan> I installed snapd-xdg-open (0.0.0~16.04)
<diddledan> now browser windows open correctly \o/
<Chipaca> huzzah
<diddledan> ok, so corebird in devmode works fine then with that package installed
<Chipaca> diddledan, excellent. As of 2.15.3 (if we cut that) or 2.16, if the snap uses the unity7 interface, it shouldn't need devmode for this
<Chipaca> diddledan, are you marking it verification-done then :-D
<Chipaca> anyway, i need to run. ttfn!
<diddledan> Chipaca: yes, I can do that :-)
<sergiusens> jdstrand hey, since the snap-confine thing landed in yakkety all our tests are returning with "Segmentation fault"
<ogra_> mvo, FYI, your keymap addition grew the snap by ~1M in average
<jdstrand> zyga: ^
<ogra_> mvo, i think thats bearable ... now cyphermox and/or mwhudson need to write a UI for that :)
<sborovkov> pitti: hello
<pcoca> jdstrand, I am done with the call. Do you have time now?
<jdstrand> pcoca: let's see if we can get through it, though I have to leave in a bit
<jdstrand> pcoca: in your snap, can you remove 'plugs: [network-bind]' then start the snap and give me the denial in syslog?
<pcoca> jdstrand, sure, should I then use just the bluetooth-control plug, right?
<jdstrand> pcoca: yes
<mup> PR snapcraft#818 closed: Fix trunk <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/818>
<mup> PR snapd#1947 closed: interfaces/builtin: add initial docker interface <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1947>
<pcoca> jdstrand, Sep 21 15:21:56 NUC kernel: [25426.260711] audit: type=1400 audit(1474467716.721:142): apparmor="DENIED" operation="create" profile="snap.sensortagbtle.sensortag" pid=21988 comm="bluepy-helper" family="bluetooth" sock_type="seqpacket" protocol=0 requested_mask="create" denied_mask="create"
<jdstrand> pcoca: can you add to /var/lib/snapd/apparmor/profiles/snap.sensortagbtle.sensortag: 'network blutetooth,' and then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.sensortagbtle.sensortag
<jdstrand> pcoca: then try again
<tachyons> Hello
<tachyons> I am trying to make a snap plugin for ruby
<pcoca> jdstrand, Is not working either. But now I don't see that DENIAL
<tachyons> everythings works except downloading script download part
<niemeyer> jdstrand: For future interfaces, please note the small change in convention in #1962
<niemeyer> snapd#1962
<mup> PR snapd#1962: interfaces: drop ErrUnknownSecurity <Created by zyga> <https://github.com/snapcore/snapd/pull/1962>
<jdstrand> pcoca: do you see other denials? perhaps a syscall denial?
<tachyons> using download() method from file base , But shows value out of range
<pcoca> jdstrand, I added 'network bluetooth,' (The middle t of bluetetooth is a typo, right? (just in case))
<pcoca> jdstrand, I got this on the syslog: http://pastebin.ubuntu.com/23211617/
<jdstrand> pcoca: yes, that was a typo
<jdstrand> pcoca: can you add 'bind' (without the quotes) to /var/lib/snapd/seccomp/profiles/snap.sensortagbtle.sensortag and restart the program, pasting syslog
<Fl1nt> Hi guys!!
<pcoca> jdstrand, http://pastebin.ubuntu.com/23211625/
<jdstrand> pcoca: can you do the same but with 'getsockopt'
<jdstrand> pcoca: I'm going to have to leave for an appt. you can continue this process by looking at 'syscall=55' in the denial and running 'scmp_sys_resolver ##'
<jdstrand> pcoca: and report back what you needed. I'll circle back so don't worry if you get stuck
<Fl1nt> Guys, I'm thinking of building a snapd scheduler or at least a prototype to be able to manage a swarm of snapd available devices. From what I read, a program can manage the snapd daemon through its REST API (Unix socket for now, I noticed that), but I'm wondering if a snaped apps would be able to do it or if I need this scheduler to be run by an uncontainerized app?
<pcoca> jdstrand, now it works :)
<Fl1nt> if a snaps is able to manage the snapd daemon on containerized mode, how am I supposed to bind it to the REST API using a containerized context? I thought to use the interfaces (plugs/slot) but I need this snaps to use the network-bind and network interfaces. Are those interfaces enough?
<pcoca> jdstrand, I will update the bug info
<Fl1nt> anyone?
<joc_> Fl1nt: i think you are looking for the snapd-control interface
<Fl1nt> oh, nice, I'll take a look at.
<Fl1nt> nop, snaps-control is just able to control the snaps, I want my snap to be able to reach the snapd API as in: https://github.com/snapcore/snapd/blob/master/docs/rest.md and so retrieve and manage informations that the snaps-control interface is not able to provide.
<Fl1nt> %s/snaps-control/snapd-control/
<joc_> it does provide access to the socket
<Fl1nt> are you sure? because the reference doc on this is not really clear on this: http://snapcraft.io/docs/reference/interfaces
<mup> PR snapd#1857 closed: snap/snapenv, tests: use root's data dirs when running via sudo <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1857>
<joc_> yeah the docs are poor, you might need network-bind too, but then you should have access to the api
<Fl1nt> joc_: another one, if those interfaces are not auto-connect and that I don't want my users having to proceed manually, is there a way to do that? throught an image provisioning system for example?
<Fl1nt> joc_: I plan to use Ubuntu Core for information.
<joc_> i believe that will be supported that via assertions for particular devices, i don't have any more details right now though
<Fl1nt> I don't understand what you call "Assertions for particular devices" do you mean building an image with a gadget?
<zyga-ontheroad> mwhudson: hey, apparently snap-confine on yakkety explodes, I'm looking at why now
<joc_> yes you would need a gadget snap built using a model assertion for your devices
<pstolowski> jdstrand, hey! can you have a look at https://github.com/snapcore/snapd/pull/1832/files when you've a moment? this is a new interface for unity8/system settings
<mup> PR snapd#1832: interfaces/builtin: time-date-control for org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832>
<zyga-ontheroad> jdstrand: hey
<Fl1nt> joc_: OK, perfect :D Thanks for your informations, helped a lot ^_^
<mup> PR snapd#1933 closed: store: add "ready to buy" method <Reviewed> <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1933>
<mup> PR snapd#1963 opened: daemon, overlord: add ReadyToBuy API to snapd <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1963>
<zyga-ontheroad> jdstrand: hey, can you please restore sanity to my mind and see if snap-confine crashes on startup on 16.10
<zyga-ontheroad> jdstrand: sergiusens reported that all snapcraft tests explode right now, I updated a 16.04 box to 16.10, installed snap-confine from the archive and ... nothing explodes
<zyga-ontheroad> jdstrand: I also rebooted to use yakkety kernel
<zyga-ontheroad> Linux ubuntu 4.8.0-11-generic #12-Ubuntu SMP Sat Sep 17 20:00:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
<zyga-ontheroad> jdstrand: all with ns sharing and everything;
<zyga-ontheroad> jdstrand: if it also works for you I'll stop panic mode and look at this carefully at home
<mcphail> Does anyone know if dlopen() calls get changed or intercepted within snap confinement? I'm trying to work out why a library under LD_LIBRARY_PATH isn't being found
<zyga-ontheroad> mcphail: they are not affected by snap confinement
<zyga-ontheroad> mcphail: but ... it depends on what you expect
<zyga-ontheroad> mcphail: can you tell me more about your setup?
<zyga-ontheroad> mcphail: note that snap-confine is setuid root; that probably ignores LD_LIBRARY_PATH and LD_PRELOAD AFAIR
<zyga-ontheroad> mcphail: so if you set that inside the wrapper of your application it will be respected
<zyga-ontheroad> mcphail: but if you want to set it on the outside that will not take any effect
<zyga-ontheroad> mcphail: you should also be aware of the "chroot" that snap-confine is using (snap-confine is the thing that helps in starting snap apps)
<zyga-ontheroad> mcphail: you can read more about it here: http://www.zygoon.pl/2016/08/snap-execution-environment.html
<mup> PR snapcraft#819 opened: Release changelog for 2.18 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/819>
<zyga-ontheroad> mcphail: (if I dissappear just keep talking to zyga, I'll check my messages back home)
<mhall119> is there a docker image that contains snapcraft and it's dependencies already?
<kyrofa> mhall119, I seem to remember a mailing list thread about that
<kyrofa> Don't remember what the outcome was, but you might take a look
<mhall119> how about an LXC image?
 * zyga-ontheroad runs again, ttyl
<kyrofa> mhall119, I don't remember hearing about that
<mcphail> zyga: Thanks for that link. I'll read it and ping you later if I have more questions. I was wondering whether something was running setuid root to stop LD_LIBRARY_PATH being read. Thanks for the info
<joc_> sergiusens: i would like some advice related to the new python plugin, i notice it modifies it all the shebangs in scripts
<joc_> sergiusens: most of my snaps have multiple parts that have python deps from stage packages with other plugins - particularly plainbox-provider plugin
<joc_> sergiusens: so now i have files that are different between parts
<joc_> sergiusens: what would you suggest is the best solution?
<elopio> jdstrand: ping. We have a bug here that zyga says needs your attention. It's with the latest snap-confine in yakkety: https://bugs.launchpad.net/snap-confine/+bug/1626121
<mup> Bug #1626121: snap-confine causes Segmentation fault <Snappy Launcher:New> <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1626121>
<elopio> I can reproduce it, but I'm not sure what other useful information to attach.
<sergiusens> joc_ the old python plugin also did this fwiw
<sergiusens> joc_ python deps from stage-packages have this general problem and this may mean we need to move this to the `repo` module
<sergiusens> joc_ do these stage-packages provide runnables? A quick solution is `command: python3 /usr/bin/my-command`; if they are exec'ed from some other component it might be tricker
<sergiusens> mhall119 kyrofa snapcore/snapcraft on dockerhub
<Chipaca> ogra_, what image do you use for bbb, btw?
<joc_> sergiusens: i was basically just wondering whether i have to add filesets to all parts to filter out clashes or if they some better way
<sergiusens> joc_ oh, filesets is the way
<balloons> zyga, snap-confine is still old on xenial. Any hope of SRU'ing 1.41 now?
<mcphail> zyga: I'm still having trouble. I set the correct LD_LIBRARY_PATH in my run script in my snap, and all the libraries are seen when my binary runs. However, dlopen() does not see the library it needs to open. I've tried moving the library to $SNAP/lib and $SNAP/usr/lib but it still doesn't work. The code fragment is at http://paste.ubuntu.com/23209466/ . How can I get around this?
<ogra_> Chipaca, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ note that you need an USB NIC though ... the onboard NIC cuses a kernel oops currently (and you should plug in the USB one after the boot finished)
<ogra_> *cusews
<ogra_> bah
<mhall119> thanks sergiusens
<mup> PR snapd#1964 opened: tests: add missing quotes in security-device-cgroups/task.yaml  <Created by mvo5> <https://github.com/snapcore/snapd/pull/1964>
<jdstrand> tyhicks, jjohansen: hey, so yakkety is seeing this denial: audit: type=1400 audit(1474474584.561:68): apparmor="DENIED" operation="file_mmap" profile="snap.mosquitto.subscribe" name="/usr/lib/snapd/snap-exec" pid=4525 comm="snap-exec" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
<jdstrand> oh, jj left
<jdstrand> tyhicks, jjohansen: hey, so yakkety is seeing this denial: audit: type=1400 audit(1474474584.561:68): apparmor="DENIED" operation="file_mmap" profile="snap.mosquitto.subscribe" name="/usr/lib/snapd/snap-exec" pid=4525 comm="snap-exec" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
<tyhicks> jdstrand: 4.8 kernel?
<jdstrand> tyhicks, jjohansen: in the 4.8 kernel, when would I expect to see policy needing 'm'?
<jdstrand> tyhicks: "I can reproduce this in a yakkety machine started by adt-run in scalingstack."
<jdstrand> I'm guessing "yes"
<jjohansen> jdstrand: yes, this is the semantic change in the kernel I have been warning about
<tyhicks> I can't answer this question OTOH - jjohansen maybe has a better idea since he did the 4.8 port
<jjohansen> the location of the mmap check in the binfmt_elf loader changed, and along with it the cred that is used for the check
<jjohansen> specifically commit 9f834ec18
<jdstrand> jjohansen: ok, thanks
<tyhicks> jdstrand: also, you'll want to be aware of seccomp bug 1626194 - I'm sending a quick fix to the kteam in a few minutes
<mup> Bug #1626194: Seccomp actions are not audited in the 4.8 kernel <linux (Ubuntu):In Progress by tyhicks> <https://launchpad.net/bugs/1626194>
<jjohansen> jdstrand: so basically on the exec, the m is falling under the profile instead of the old
<jdstrand> jjohansen: I see. ok, thanks
<jdstrand> this is with a chnage_onexec call
<jdstrand> tyhicks (cc ratliff): fyi, I'm going to need to chase this bug down
<tyhicks> jdstrand: shouldn't have much to do with change_onexec() but has more to do with the exec() that snap-confine is doing
<jdstrand> (ie, adjust the policy in snapd so yakkety tests are clear again)
<tyhicks> jdstrand: ack
<jdstrand> sure
<mup> Bug #1626121 opened: snap-confine causes Segmentation fault <Snappy Launcher:Invalid> <Snappy:New> <snap-confine (Ubuntu):Invalid> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1626121>
<jdstrand> we have a change_onexec to another profile with the exec being on snap-exec
<jdstrand> this all is consistent with jjohansen's explanation
 * tyhicks agrees
<jjohansen> jdstrand: yeah, lacking the m does cause a segment fault, basically that part of the elf doesn't get mapped, and the exec starts and blows up immediately
<ratliff> got it, jdstrand
<jdstrand> fun! :)
<jdstrand> zyga, elopio: I've responded in the bug and assigned to me
<elopio> jdstrand: thank you.
<jdstrand> pcoca: thanks!
<pcoca> jdstrand, thank you! :)
<mup> PR snapd#1965 opened: asserts: support for maps in assertions, <Created by pedronis> <https://github.com/snapcore/snapd/pull/1965>
<sergiusens> thanks jdstrand
<csutherl> mhall119, hey. is what you provided the latest version of your snap for tomcat?
<csutherl> mhall119, i had to chmod run.sh before building the package to get it to work. and i see that it can't find conf/tomcat-users.xml already
<jdstrand> pcoca: fyi, I responded in comment #11 and am back now
<popey> ogra_: my pi just auto updated and rebooted and it's now no longer on the network
<popey> and I can't login because i have no password
<mhall119> csutherl: yeah, emailing run.sh stripped the permissions, I didn't even think about that
<mhall119> csutherl: is tomcat-users.xml in /snap/tomcat/current/conf/ ?
<popey> (pi 2, daily image)
<mhall119> that should be $CATALINA_HOME/conf/tomcat-users.xml
<csutherl> mhall119, yeah
<mhall119> csutherl: is that where it's looking for it?
<mhall119> maybe you need to copy it into $CATALINA_BASE/conf/
<mhall119> which would be /var/snap/tomcat/current/
<mhall119> ./conf/
<csutherl> hm
<csutherl> it isn't in there
<csutherl> /var/snap/tomcat/current/
<csutherl> just the server.xml
<mhall119> no, I only have it copying the server.xml
<mhall119> that was the minimum needed to make it start
<csutherl> ohoh. gotcha
<csutherl> let me try that
<mhall119> if you want to copy more in, just duplicate the line in run.sh that copies the server.xml
<mup> PR snapcraft#820 opened: Fixed bug LP: #1607294 snapcraft search returns results in different order <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/820>
<mup> PR snapd#1962 closed: interfaces: drop ErrUnknownSecurity <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1962>
<mup> PR snapd#1966 opened: many: avoid snap.InfoFromSnapYaml in tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/1966>
<popey> ogra_: nvm, reboot 'fixed' it :)
<mup> PR snapd#1961 closed: many: avoid snap.InfoFromSnapYaml in tests <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1961>
<mup> PR snapd#1964 closed: tests: add missing quotes in security-device-cgroups/task.yaml  <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1964>
<mup> PR snapd#1890 closed: tests: add spread test for snap create-key/snap sign <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1890>
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Do you have a moment for a quick look on this one liner:
<niemeyer> snapd#1875
<mup> PR snapd#1875: interfaces/builtin: allow /dev/net/tun with network-control <Created by cmars> <https://github.com/snapcore/snapd/pull/1875>
<mup> PR snapd#1875 closed: interfaces/builtin: allow /dev/net/tun with network-control <Created by cmars> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1875>
<jdstrand> niemeyer: it has been on my list. I've been ambivalent about where this rule should go since the PR came in, but I decided just now and commented in the PR (with a +1)
<jdstrand> niemeyer: also, I've gotten the other pings and they are also on my list. now that docker landed I can look at them after bug #1626121
<mup> Bug #1626121: strict mode snaps crash with Segmentation fault on 16.10 <Snappy Launcher:Invalid> <Snapcraft:New> <Snappy:In Progress by jdstrand> <snap-confine (Ubuntu):Invalid> <snapd (Ubuntu):Triaged by jdstrand> <https://launchpad.net/bugs/1626121>
<mup> PR snapd#1966 closed: many: avoid snap.InfoFromSnapYaml in tests <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1966>
<diddledan> has anyone managed to get gstreamer-using apps actually using gstreamer libraries? my corebird seems unable to find the gstreamer plugin libraries
<diddledan> output from attempting to display a video: http://paste.ubuntu.com/23212993/
<mcphail> diddledan: I don't know how gstreamer opens its libraries but I wonder if you're hitting the same problems with dlopen() that I am with my snap?
<diddledan> aah, yeah, my very limited knowledge of shared objects suggests to my memory banks that dlopen works funky compared to LD?
<diddledan> might be a case of snap just not having dlopen overrides implemented yet
<mup> PR snapcraft#819 closed: Release changelog for 2.18 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/819>
<mcphail> diddledan: I can't seem to put a library anywhere a snapped binary can dlopen() it. I'm trying to find out if this is a bug, an error or my part or a "feature"
<diddledan> well if we're on the same issue then I hope it's a case of "haven't got that far in implementatino yet" :-D
<mcphail> :)
<diddledan> yey for progressive improvements
<mcphail> iteration rules
<mup> PR snapd#1967 opened: interfaces: allow 'm' in default policy for /usr/lib/snapd/snap-exec <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1967>
<grahams> Hi, I'm curious to see how easy it would be to create a snappy package from a Arch AUR package, are there any guides on that?
<grahams> My package is very simple, 1 python script and 3 dependencies
<kyrofa> Hey grahams, no guide that I know of, but indeed should be quite simple to snap
<grahams> Thanks, is snapcraft the way to go? I see it in the Arch Aur
<kyrofa> grahams, typically snapcraft is used to make snaps, yes, but it's pretty tied to Ubuntu right now
<kyrofa> (e.g. it'll pull debs for dependencies)
<kyrofa> You can use it in a VM or container if you want to use it
<grahams> Yes looks like other ran into issues building snap under Arch. Easy enough to spin up a VM
<mup> Bug #1625813 changed: hardware-observe does not allow reading temperatures <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1625813>
<mup> PR snapd#1968 opened: interfaces: adjust bluetooth-control to allow getsockopt (LP: #1613572) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1968>
<zyga> that moment when you want to double tap to zoom in but you update bug statsu to in-progress
<oparoz_> I don't understand how SNAP_USER_COMMON is supposed to work since sudo is required to install snaps
<nacc> oparoz_: SNAP_USER_COMMON, iirc, is just user-specific data for that snap, e.g. ~/snap/<name>/common
<oparoz_> nacc, yes, but since snaps are installed as root, then the path is /root/snap/etc. which isn't accessible to the user installing the snap
<qengho> SNAP_USER_DATA is a user-writable directory that is versioned across snap versions. You can roll back to previous data too there. SNAP_USER_COMMON is one that persists.
<nacc> oparoz_: not sure i follow, the snap wrapper is root:root, but you can still run it as your user?
<oparoz_> qengho, yes, but SNAP_COMMON is the one that persists within the SNAP. I thought SNAP_USER_COMMON would give the user access to a persistent directory within his home folder
<nacc> oparoz_: i don't believe SNAP_COMMON is "within the SNAP"
<nacc> oparoz_: well, in classic, at least it's in /var/snap
<qengho> It does. Or it should. There's a bug with a recent version of snapd.
<oparoz_> nacc, it's in snap/yoursnap/common
<nacc> oparoz_: on classic, SNAP_COMMON is /var/snap/<name>/common, iirc
<nacc> oparoz_: in which case, it's not in the squashfs (which is what hte snap itself is, imo)
<oparoz_> nacc, in this sense, yes, I meant it's still namespaced, but it also is in the home folder, just a different root
<qengho> "Within the snap" could only mean "within the execution environment and defined in the environment you receive upon running".
<nacc> oparoz_: sorry, i'm confused, SNAP_COMMON is not in the "home folder", as home is tied to a user, and SNAP_COMMON is not
<nacc> oparoz_: unless you meant SNAP_COMMON_USER
<qengho> nacc: You dropped "USER" when you said "SNAP_COMMON". Don't do that. THey're different.
<oparoz_> qengho, so how is the user determined? Is there a USER variable stored at install time?
<nacc> qengho: i did not, oparoz_ did
<qengho> oparoz_: At run time, you're handed it in environment.
<nacc> oparoz_: it's in the wrapper script, afaict, it uses $HOME
<oparoz_> qengho, OK, so it must be the bug you mentioned then
<qengho> I meant the literal letters U, S, E, and R. Not a variable called USER.
<nacc> qengho: yes, i understand what you meant, I think. oparoz_ said "SNAP_COMMON is the one that persists withinthe SNAP", to which i replied, "i don't believe SNAP_COMMON is "within the SNAP""
<qengho> See what your snapd defines.  $ hello-world.env |grep _COMMON
<nacc> qengho: ah perhaps that was not directed at me (the literal letters)
<oparoz_> The startup script is using: $SNAP_USER_COMMON/downloads. And the log says: Failed to open directory "/root/snap/snapname/common/downloads
<nacc> oparoz_: are you running the snap as root?
<qengho> oparoz_: Then you're running it as root. A recent snapd doesn't let the program create $SNAP_USER_COMMON .
<oparoz_> nacc, you have to use sudo to install
<nacc> oparoz_: install and running are not hte same thing
<nacc> oparoz_: ie., you use sudo apt-get install <pkgname>; you don't (unless you want to run as root) do `sudo <application from pkgname>`
<oparoz_> Hmmm... I thought snapd was a system service
<qengho> oparoz_: Outside, to work around snapd bug   $ sudo mkdir /root/snap/snapname/common
<nacc> oparoz_: i'm still confused on exactly what the issue is, but it seems like qengho has a better handle on helping you :)
<oparoz_> qengho, yes, but then the user doesn't have access to that folder
<nacc> oparoz_: are you having an issue with snapd or a specific snap?
<qengho> nacc: snapd as of a few days ago doesn't let the app wrapper create the user common dir.
<nacc> qengho: ah ha
<oparoz__> nacc, I don't remember having done anything special to run snapd, just installed it and it's running as root, which I would expect
<nacc> qengho: but it shouldn't need to create it for root, unless running the snap as root, right?
<nacc> oparoz__: right, but snapd isn't any of your snaps, per se
<qengho> nacc: Right.
<nacc> qengho: ok, thanks for confirming that, still confused on the root issue here, then :)
<qengho> oparoz_: Let's back up and find out why you're typing "sudo". Explain that part.
<oparoz__> sudo snap install transmission
<qengho> Yes. That makes sense.
<qengho> oparoz_: Where else are you typing "sudo"?
<oparoz__> qengho, nowhere else
<nacc> oparoz__: how are you running transmission then?
<qengho> oparoz__: Okay, so it's installed. How do you run transmission?
<oparoz__> I have a start-stop script which launches transmission-daemon
<qengho> oparoz__: And that runs as root?
<oparoz__> Yes, because I was told all scripts in a Snap are run as root
<oparoz__> So in the list of arguments, there is $SNAP_USER_COMMON/downloads
<oparoz__> But I would expect that variable to be determined at install time
<qengho> oparoz__: All "daemons" that you tell the snap system to manage are run as root.
<nacc> oparoz__: $SNAP_USER_COMMON by definition is determined at runtime -- how else would it be tied to a specific user?
<qengho> oparoz__: Is your start-stop inside the snap, or outside, running a snap app?
<nacc> ah good question
<oparoz__> the start-stop is inside the Snap
<qengho> oparoz__: Okay, then yes, it's running as root, and there's no way to change it from doing so. And its data will be written to a location that you get when you run your snap app and use a environment variable that does not have _USER_ in the middle.
<oparoz__> qengho, snapcraft.yaml https://paste.ubuntu.com/23213684/
<qengho> oparoz__: If you're running a daemon, you should only have it use something like SNAP_COMMON, and not SNAP_USER_COMMON.
<oparoz__> qengho, OK, so there is no way to store the downloads in an easily accessible location
<qengho> oparoz__: it is easily accessible, from anything defined in the snap.
<qengho> oparoz__: Where do you expect the data to be going?
<mup> PR snapd#1967 closed: interfaces/apparmor: allow 'm' in default policy for snap-exec <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1967>
<qengho> Or want it to.
<oparoz__> I want the data to be accessible outside the Snap, without having to ship Samba in the snap
<qengho> Where?
<oparoz__> qengho, /media per example
<qengho> oparoz__: There is no way to get that with only "snap install", but you could symlink "/var/snap/yoursnap/common" to "/media".
<oparoz__> qengho, the problem is that not all environments are going to be the same, so I thought the /home folder of the user who installs the snap would be a good idea
<qengho> oparoz__: That's fine too, but you can't make the thing a snap service. You can make it a regular app that the user runs.
<qengho> ...and then you could ask for plug "home".
<oparoz__> qengho, Actually, I think I'll do the opposite and define a slot so that other apps can retrieve the data
<oparoz__> I need to look into how to mount the slot I connect to I guess
<oparoz__> But at least now I know that $SNAP_USER_COMMON doesn't work in that context. Thanks for you help nacc and qengho
<qengho> welcome!
<kyrofa> oparoz__, not "all scripts" in a snap run as root, only services
<kyrofa> oparoz__, non-service apps run as the user who ran them
<oparoz__> kyrofa, do you have an example of a non-service app bundled in a snap?
<kyrofa> oparoz__, yeah, nextcloud :P
<kyrofa> oparoz__, the mysql-client or occ apps, for example
<oparoz__> Ah, but that's command
<oparoz__> Just like in a standard system
<kyrofa> Right. There are only two things: services and non-services
<oparoz__> I just thought the snap env would have some memory about who installed it
<kyrofa> Nope
<oparoz__> ;(
<kyrofa> Snaps are installed system-wide-- what use would there be in keeping track of who installed it?
<oparoz__> I'll just have to mount the slot/folder in Nextcloud
<oparoz__> Well, some apps are installed for the current user only, if required
<kyrofa> oparoz__, "some apps" ?
<kyrofa> I'm not sure I follow
<oparoz__> If I install an app in my home folder, it's only available to me
<kyrofa> oparoz__, there's no such thing for snaps
<oparoz__> I guess it's not much of a problem for desktop snaps, since the user can always define folders for storing information, etc.
<nacc> oparoz__: do you mean if you 'install locally' in ~/bin/ or something?
<oparoz__> Yes nacc
<nacc> oparoz__: yeah there's nothing like that in snaps, but it should be less necessary, in theory too
#snappy 2016-09-22
<liuxg> does anyone know how to use snapweb?
<mup> PR snapd#1969 opened: Update HACKING.md <Created by niedbalski> <https://github.com/snapcore/snapd/pull/1969>
<mup> Bug #1626359 opened: Cannot authorise quotactl syscall <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1626359>
<mup> PR snapd#1970 opened: Adds ptrace capabilities to the system_trace interface <Created by niedbalski> <https://github.com/snapcore/snapd/pull/1970>
<tachyons> How do I replicate same error message in snap store in local snap review ?
<tachyons> In automated review in store , I got follwing error
<tachyons> package contains external symlinks: gems/ruby-2.3.1@global, rubies/default lint-snap-v2_external_symlinks
<tachyons>  0 Warnings
<tachyons>  31 Passes
<tachyons> But this error is not appearing in local when I run snap review
<elopio> tachyons: install click-reviewers-tools, and then run click-review
<tachyons> elopio: already done , But this error is not coming in my local system
<elopio> tachyons: then probably the reviewers tool used in the store is not the same version
<elopio> tachyons: I think that error means that in your snap you have a symlink to a path outside.
<tachyons> elopio: which version should I try , I tried the version in 16.04 as well as trunk in bzr
<elopio> you can ls -l in the prime directory to search for the links.
<elopio> tachyons: I don't know what's the right version.
<tachyons> elopio: yes there are symlinks , but those are not outside snap package
<elopio> tachyons: can you paste the ls -l of those two files?
<tachyons> wait
<tachyons> total 8
<tachyons> lrwxrwxrwx 3 tachyons tachyons   86 Sep 21 21:02 default -> /home/tachyons/projects/snappy-playpen/hello-ruby/parts/ruby/install/rubies/ruby-2.3.1
<tachyons> drwxrwxr-x 6 tachyons tachyons 4096 Sep 21 21:03 ruby-2.3.1
<tachyons> default is symlinked to ruby-2.3.1
<tachyons> elopio: Is that fine ?
<elopio> tachyons: I think it should be a relative path, not an absolute one.
<elopio> when you mount that snap in a system, it will try to find /home/tachyons.
<tachyons> elopio: Means I have to write a script to convert absolute path to relative path in build script?
<elopio> tachyons: yes. Some other plugins are probably doing the same, but kyrofa is our link man and he's EOD.
<elopio> you can send an email to the list.
<tachyons> EOD means?
<elopio> end-of-day. He's sleeping.
<mup> PR snapd#1971 opened: interfaces/builtin: add rcvfrom for client connected plugs to mir interface <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1971>
<tachyons> elopio: Thanks , https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/go.py#L120 Is this what you meant ?
<tachyons> I don't have much idea about python stuff
<elopio> tachyons: more like this, I think: https://github.com/snapcore/snapcraft/blob/97742500ac64d44f9251983a7ac93b128901fdfa/snapcraft/plugins/dump.py#L62
<elopio> I don't have much idea of this part of snapcraf.t
<tachyons> elopio: Thanks :-) , Let me try
<mup> Bug #1598657 changed: No error id for username/password error returned from snapd <Snappy:Fix Released by chipaca> <gnome-software (Ubuntu):Fix Released> <https://launchpad.net/bugs/1598657>
<mup> PR snapd#1969 closed: Update HACKING.md <Created by niedbalski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1969>
<mup> PR snapd#1972 opened: tests: increase timeout for key generation in create-key test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1972>
<dholbach> good morning
<zyga> good morning
<mvo> ogra_: good news everyone! we have what lookds like a working "loadkeys"
<tachyons> elopio: Thanks , it is working for files , but directories are not being copied correctly
<tachyons> It shows empty directory instead
<mvo> ogra_: total cost is ~3mb it seems, not great, not too terrible either
<didrocks> mvo: hey, have you seen fgimenez's issue today? It seems that $HOME isn't anymore $SNAP_USER_DATA, but real $HOME, am I correct?
<didrocks> (maybe when people adds the home plug?)
<mvo> didrocks: I did not see that, that sounds like a regression
<didrocks> mvo: yeah, I guess fgimenez can show you an easy reproducer
<didrocks> (desktop-launch is using ~/.something) and ~ is expanded to /home/<user>/
<fgimenez> didrocks, mvo yep, is in the test snap used in this in progress branch https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, the commands try to open files on ~/
<mvo> fgimenez: is that with master?
<didrocks> mvo: I did get the issue on a released snapd version on my side
<mvo> didrocks: what version?
<didrocks> mvo: ah, sorry, I'm wrong, I still have your ppa version :)
<didrocks> snapd   2.14.2~16.04+ppa227-1
<didrocks> the one with revert --devmode
<mvo> didrocks, fgimenez: https://github.com/snapcore/snapd/blob/master/snap/snapenv/snapenv.go#L91 looks correct, let me add a spread test
<didrocks> mvo: so, basically, we have here: command: desktop-launch <something>
<didrocks> and desktop-launch is doing cat ~/.something
<didrocks> and we can see (with the home slot plugged, don't know without that), that ~ is expanded to /home/user
<ogra_> mvo, hmm, thats a lot, but you didnt use the d-i bits, right ? just the normal desktop packages
<ogra_> i guess using the bits from the udeb would be a lot less
<mvo> ogra_: yeah, just the regular packages
<mup> PR snapd#1973 opened: tests: ensure HOME is also set correctly <Created by mvo5> <https://github.com/snapcore/snapd/pull/1973>
<mvo> didrocks: -^ for you
<didrocks> fgimenez: ^
<didrocks> mvo: don't you think we could have some special expansion as the use case is slightly different (~ expansion from a command line application wrapped, but started from another shell?)
<fgimenez> mvo, didrocks cool thanks a lot
<fgimenez> didrocks, in the previous version of the test snap we were exporting HOME and pointing it to SNAP_USER_DATA in the launcher script https://github.com/snapcore/snapd/commit/358fcd544b059fc864cef93af67e7d1e7c3be40c#diff-e2c74cafe2ea8aff71bac730ee1bf0f9R10, wouldn't that have the same effect as HOME being set up from snapd?
<mvo> ogra_: hm, just had a quick look, killing python would be huge if we want to reduce the size
<mvo> ogra_: vim.tiny is also 1mb, systemd-analyize, perl
<didrocks> fgimenez: yeah, but that's not needed, mvo confirms that HOME should already point to SNAP_USER_DATA
<morphis__> mvo, ogra_: did you guys release a new beta OS snap?
<didrocks> but as we are using ~ expansion, I really wonder if the mvo's test makes sense
<ogra_> morphis__, not that i'm aware
<morphis__> mvo, ogra_: saw it changing from 526 to 658
<mup> PR snapd#1974 opened: snapd: kmod backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/1974>
<ogra_> mvo, killing python would get us 10MB snaps :P
<didrocks> zyga: see you are approving, but did you read above? ^
<ogra_> (yes, i'm exaggerating ... but it would freee a lot)
<mvo> ogra_: I think we can kill libstdc++6 from the image, its only needed by apt afaik
<morphis__> ogra_: snap prepare-image --channel beta .. gives me 658 now where edge has 695
<mvo> ogra_: hm, no, sorry
<mvo> ogra_: silly me, we would still have to include it for classic
<ogra_> yeah
<mvo> ogra_: /usr/share/local/* might be worth a shot
<morphis__> mvo, ogra_: any a snap refresh --beta ubuntu-core on my desktop gives me 660
<mvo> morphis__: same architecture?
<ogra_> mvo, we purge the lcle package at the end of the build
<ogra_> *locale
<ogra_> that should only be empty dirs
<ogra_> ugh
<morphis__> mvo: ah right
 * ogra_ shakes fist at maintainer scripts
<morphis__> mvo: but that still doesn't explain why the armhf one goes from 526 to 658
<ogra_> ogra@bbb:~$ du -hcs /usr/share/locale/
<ogra_> 7.2M	/usr/share/locale/
<ogra_> woah
<morphis__> mvo: can you check in the store what should be the latest for the beta channel?
 * ogra_ is just looking
<ogra_> 656-661 are in bet
<ogra_> a
<morphis__> beginning of last week I got 526 and now 658
<morphis__> ogra_: you see when they were published?
<ogra_> well, i didnt release anything to beta ... regarding the date ... http://people.canonical.com/~ogra/ubuntu-core-builds/ (unless they were mnul builds they will show up theere)
<mup> PR snapd#1975 opened: tests: add test benchmark script <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1975>
<ogra_> hmm, looks like thery were manual :/
<ogra_> but i'd say 19th
<ogra_> yeah, the store says "2016-09-19 12:25 - 2 days, 20 hours ago"
<morphis__> ogra_: wait, we released an upgrade beta snap after the beta announcement?
<ogra_> ask mvo ... he handles the beta releases ... but why wouldnt we
<morphis__> ogra_: as it breaks stuff
<ogra_> well, thts indeed bad, but there is no reason to not release  beta if it doesnt :)
<ogra_> whaat does it break ?
<morphis__> ogra_: there is no reason against that but you easily miss that if you nowhere get an announcement for that or so
<morphis__> ogra_: however, console-conf seems to be updated and now doesn't work anymore with our manually put in place ifupdown config
<morphis__> mwhudson: ping
<ogra_> oh ? are you sure ?
<ogra_> you mean you define a fixed IP and dont get that IP ?
<ogra_> or what does not work ?
<ogra_> (note that the device comes up automatically before console-conf ... systemd-networkd default to try DHCP)
<ogra_> *defaults
<morphis__> ogra_: address assignment works well, the box gets the IP via dhcp and is manged by ifupdwon but console conf still complains that "network cofngiuration failed"
<morphis__> it shows the detected IP configuration which ifupdown put in place
<morphis__> ogra_: no networkd here,
<mvo> morphis__: it breaks stuff?
<morphis__> mvo: console-conf has a regression somewhere
<mvo> morphis__: right, thats (obviously) bad did you talk to mwhudson about it yet?
<morphis__> and actually I was expecting beta to stay the same until we have the next announcement for an updated beta release or so
<morphis__> mvo: just ping'ed him
<mwhudson> hi
<mvo> morphis__: there was an anncounement: https://lists.ubuntu.com/archives/snapcraft/2016-September/001166.html
<morphis__> oh ...
<morphis__> my bad then that I missed that .. sorry :-)
<mvo> no worries
<morphis__> mwhudson: hey!
<mwhudson> er is it possible to figure out the console-conf versions in the good and bad versions?
<morphis__> mwhudson: let me first explain the problem I see right now
<mvo> morphis__: I'm keen to learn more why this makes you concerned. it seems the fact that we spot the regression is a reaosn to release betas more often so that we find the bugs sooner (rather than later). but lets talk after the console-conf issue got debugged
<morphis__> mvo: my only conern was because I missed the announcement
<morphis__> so releasing to beta more often to fix bugs is fine for me
<morphis__> mwhudson: so the problem I have right now is the following:
<morphis__> mwhudson: we can't really use networkd here as it just fails badly on our 3.4 kernel
<morphis__> mwhudson: to workaround this (its just a proof-of-concept) we put a config file into /etc/network/interfaces.d which configures the ethernet port via dhcp
<mwhudson> morphis__: 3.4!!
<morphis__> mwhudson: with the previous beta release console-conf was ok with accepting whatever ifupdown assigned to the interface and just let us go through the process
<morphis__> mwhudson: now with the second beta release it shows the IP address ifupdown assigned but fails with "Network configuration failed; please verify your settings" when trying to proceed with the wizard
<morphis__> mwhudson: yeah, 3.4
<mwhudson> morphis__: ok, hm, so i'm not really sure why that would have changed, but i can't remember how old the old beta was
<mwhudson> morphis__: can you get at the logs by pulling an sd card or activating a debug shell or something?
<morphis__> mwhudson: yes, I am already doing that
<mwhudson> morphis__: pastebin /var/log/console-conf/subiquity-debug.log pls
<mwhudson> (filename might not be quite right)
<morphis__> mwhudson: hm, there is no console-conf log
<mwhudson> morphis__: nothing in /var/log/console-conf at all?
<morphis__> nothing
<mwhudson> special
<morphis__> https://paste.ubuntu.com/23215029/
<mwhudson> morphis__: initramfs?
<morphis__> yeah, can't get into the system otherwise
<mwhudson> oh right
<morphis__> this is flashed on the internal flash memory
<mwhudson> that doesn't look like a system that's booted a snappy image?
<mwhudson> does it?
<mwhudson> maybe, i can't remember how all this works
<morphis__> ah
<morphis__> mwhudson: my fault, found the log file
<mwhudson> morphis__: isn't it going to be /root/writable/system-data/... or something?
<morphis__> https://paste.ubuntu.com/23215037/
<morphis__> 09/22 09:10 subiquitycore.utils:130 run_command returning: {'err': 'Error in network definition //etc/netplan/00-snapd-confi
<morphis__> g.yaml line 9 column 6: p2p0: No access points defined\n', 'status': 1, 'output': ''}
<mwhudson> oh
<mwhudson> i've fixed that bug
<mwhudson> morphis__: can you try edge ubuntu-core?
<morphis__> so console-conf does not put any configuration in place and then netplan fails to apply that
<morphis__> mwhudson: sure
<mwhudson> i misunderstood a bit what netplan accepted
<mup> PR snapd#1944 closed: many: validate refreshes against validation assertions by gating snaps <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1944>
<morphis__> mwhudson: ah :-)
<morphis__> mwhudson: and another one where I saw a crash of netplan: https://paste.ubuntu.com/23215041/
<mwhudson> morphis__: looks like the same thing on first blush
<morphis__> mwhudson: see the: AttributeError: 'BackgroundProcess' object has no attribute 'proc'
<mwhudson> morphis__: oh, i fixed that too
<mwhudson> (without really understanding it :/)
<morphis__> great :-)
<morphis__> lets see how edge goes
<morphis__> mwhudson: ah, works again!
<mwhudson> morphis__: hooray, sorry for the bugs
<morphis__> mwhudson: no problem :-)
<mup> PR snapd#1976 opened: tests: skip some tests on non-amd64 architectures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1976>
<morphis__> mvo: is there an easy way how I can programatically determine the OS snap revision in a channel?
<morphis__> mvo: or via the snap command
<ogra_> only the installed snap version
<ogra_> and for the non-manually built snaps you can look up the info at http://people.canonical.com/~ogra/ubuntu-core-builds/
<ogra_> (i havent added manifests and changelogs yet ... that a weekend project)
<ogra_> *that's
<morphis__> :-)
<pedronis> morphis__: there's no command for that atm, you can query the store directly though
<morphis__> looks like I can abuse snap download --edge ubuntu-core for that
<morphis__> pedronis: you have a link to the store API?
<ogra_> i think you can also just check for upgradeability ...
<pedronis> morphis__: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Details
<morphis__> thanks
<ogra_> snap refresh --list
<ogra_> that shows if there is a newer core
<ogra_> "snap refresh --list --beta" actually :)
<pedronis> --list doesn't take channels atm
<pedronis> I think
<ogra_> ogra@bbb:~$ snap refresh --beta --list
<ogra_> error: --list does not take mode nor channel flags
<ogra_> yeap ... looks like you know the error msg :)
<pedronis> morphis__: something like this:  curl -H "X-Ubuntu-Series: 16" -H "X-Ubuntu-Architecture: amd64" https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=edge
<ogra_> but if the image is baseed on beta it will show the beta channel snaps i suppose
<morphis__> pedronis: thanks!
<pedronis> ogra_: yes
<pedronis> is just that if things are up-to-date
<pedronis> it will just say they are up to date
<ogra_> yeah
<ogra_> but you could turn off auto-refresh ... and then have a script to check with the above command before you decide to upgrade
<ogra_> (and first look up the changelog before you decide upgrdaing wont break your hacked up setup ;) )
<ogra_> thats probably better than having it auto-refresh over night and being greeted with a bricked device :)
<mup> PR snapd#1972 closed: tests: increase timeout for key generation in create-key test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1972>
<pitti> ogra_: did you strace -tt console-conf --help? does python3 --help also take that long?
<pitti> ogra_: i. e. is that really just python itself, or something specific to console-conf?
<pitti> (some expensive import or what not)
<ogra_> pitti, sorry, i had a ton of distracting things today, u'll get to the strase soon
<pitti> I cannot imagine that python takes an effing 20 seconds to start -- the hardware can't be *that* slow
<ogra_> *i'll get to the strace ...
<pitti> ogra_: no hurry, just overheard it on the ML
<pitti> it was more like curiosity/disbelief
<pitti> I cannot imagine that this can just  be attributed to hw slowness; there must be some bug somewhere
<pitti> maybe the RNG hits again :)
<ogra_> pitti, it has always been like that on embedded arm if you say python in a channel wheer mebedded people work you get laughed at ... single core arm and python have never gone well together
 * pitti saw several long startup delays due to that recently, like bug 1622893
<mup> Bug #1622893: NetworkManager takes very long to start, or times out, blocked on RNG <amd64> <apport-bug> <bootspeed> <regression-release> <yakkety> <Auto Package Testing:Fix Released by pitti> <gnutls28 (Ubuntu):Triaged> <network-manager (Ubuntu):New> <https://launchpad.net/bugs/1622893>
<pitti> ogra_: well, we've run apport on arm stuff for a long time, and while that's certainly expensive, it didnt take multiple seconds to start..
<ogra_> (this is why micropython exists)
<ogra_> pitti, we have always disable apport on devices like this ... we use apport on desktop class devices like phones, sure ... but on the old arm images it has always been disabled
<ogra_> (we never ran long-running python processes on the arm devboard images)
<ogra_> technically what we'd want would be https://micropython.org/ packaged in ubuntu-core ... instead of python3
<ppisati> where can i open a bug against ubuntu-image?
<ogra_> https://bugs.launchpad.net/ubuntu-image
<frederikkunze> Hello, i tried to flash Snappy on a Raspberry 3 but it ended in being stuck in the gpu-check screen of the raspi. I did read that the problem exists since a few month is there any solution for it? I could not find any.
<Son_Goku> morning all
<mup> PR snapd#1977 opened: interfaces/builtin: add netplan-observe interface <Created by morphis> <https://github.com/snapcore/snapd/pull/1977>
<mup> PR snapd#1965 closed: asserts: support for maps in assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1965>
<zyga> didrocks: didrocks I'm sorry, was this about $HOME?
<ppisati> $ cat pi2-tvoss.model | grep kernel
<ppisati> kernel: ubuntu-raspi2-kernel
<ppisati> $ sudo /snap/bin/ubuntu-image --extra-snaps ./ubuntu-raspi2-kernel_4.4.0_armhf.snap -c beta -o pi2-tvoss.img pi2-tvoss.model
<ppisati> $ unsquashfs -l ubuntu-raspi2-kernel_4.4.0_armhf.snap
<ppisati> ...
<ppisati> squashfs-root/lib/modules/4.4.19-xenial_raspi2+/modules.dep
<ppisati> squashfs-root/lib/modules/4.4.19-xenial_raspi2+/modules.dep.bin
<ppisati> ...
<ppisati> notice the version: 4.4.19-xenial_raspi2+
<didrocks> zyga: correct
<ppisati> $ unsquashfs -l /media/flag/writable/system-data/var/lib/snapd/snaps/ubuntu-raspi2-kernel_x1.snap
<ppisati> ...
<ppisati> squashfs-root/lib/modules/4.4.16-xenial_raspi2+/modules.builtin
<ppisati> squashfs-root/lib/modules/4.4.16-xenial_raspi2+/modules.order
<ppisati> ...
<ppisati> 4.4.16
<ppisati> so it's using a different kernel, and not the one i'm passing on the command line
<ppisati> can anyone explain why?
<Mirv> are you all on Rocket chat too or should I generally use IRC more?
<Son_Goku> zyga: ping
<Mirv> Mr. Newbie just has stupid questions
<zyga> Son_Goku: hello
<zyga> Son_Goku: what's up?
<Son_Goku> you're alive!!!
<Son_Goku> I've not heard from you nearly all month
<zyga> Son_Goku: yes, though my back hurts all day lately :/
<Son_Goku> :(
<Son_Goku> what happened?
<zyga> Son_Goku: back? just the way it is, weather, more work
<zyga> Son_Goku: test-snapd-tools
<zyga> hmm
<zyga> https://plus.google.com/+ZygmuntKrynicki/posts/fPj5PaDFbgk
<zyga> that's better
<zyga> that's why I was quiet for a while
<zyga> remember that "small thing I need to do in snap-confine", well that too NaN minutes to do
<Son_Goku> jeez
<zyga> Son_Goku: I could use a hand with designing one thing
<Son_Goku> hm?
<zyga> Son_Goku: we'll have to release snapd once again (hopefully today) before this is doable
<zyga> Son_Goku: but I could use a hand with /snap migration
<Son_Goku> yes
<zyga> Son_Goku: I realized that this is more tricky than initially assumed
<zyga> Son_Goku: all snap services need to be stopped
<zyga> Son_Goku: all units unmounted
<Son_Goku> oh dear
<zyga> Son_Goku: all units adjusted
<zyga> Son_Goku: all units renamed as systemd requires that the file name matches the internal path
<Son_Goku> it's essentially the same as doing an offline update
<zyga> Son_Goku: totally
<zyga> Son_Goku: and it's very explosive, I was just wondering how to even attempt that and test it sensibly
 * Son_Goku has flashbacks to UsrMove
<zyga> Son_Goku: my current plan is to use VM snapshots
<zyga> Son_Goku: and just code this defensively
<zyga> Son_Goku: and iterate a while until I feel it's good
<Son_Goku> probably an okay idea
<zyga> Son_Goku: this is obviously just for COPR
<zyga> Son_Goku: but it has to be there first
<zyga> Son_Goku: once copr is moved the rest is easy
<Son_Goku> well, for copr, it might not be as horrible as you think
<zyga> Son_Goku: if you have a VM handy I could use you do do some reviews and test migrations
<Son_Goku> you can move everything, and just create a symlink to /snap -> new location
<zyga> Son_Goku: ohhhh
<zyga> Son_Goku: hmm D:
<zyga> well, see, why didn't I think of that :D
<Son_Goku> that's what we did for UsrMove
<zyga> so still stop-the-world
<zyga> do a symlink
<Son_Goku> yep
<zyga> perhaps rewrite state.json (need to check)
<zyga> and bring it up
 * zyga ponders
<zyga> but how is the symlink useful then?
<Son_Goku> and I *think* this can also be conditionalized as a %pretrans that occurs only if older versions of snapd are detected
<zyga> apart from, maybe, just $PATH being still valid
<zyga> nah, thats irrelevant, I would keep this in COPR forever and stop updating it
<Son_Goku> ah
<zyga> Son_Goku: all subsequent updates would be in the repo
<Son_Goku> right
<Son_Goku> so you'd probably still want to apply a migration to all units and whatnot
<zyga> yes, I have to
<zyga> everything
<zyga> actually
<zyga> it might be easier to say this
<zyga> the migration removes all snaps
<zyga> and re-installs them
<zyga> keeping data (that could be a hack)
<zyga> well, no I still need
<zyga> man this is complex
<zyga> ...
<zyga> lots of moving parts
<Son_Goku> no one ever thought this might be a problem, which is extraordinarily surprising, given Ubuntu's upstream?
<zyga> ?
<zyga> moving stuff around is hard when it is live
<Son_Goku> the /snap path is a violation of Debian Policy
<zyga> that's why I'd rather not do it but that cat is out of the bag
<Son_Goku> so I was surprised that you guys even did it that way to begin with
<zyga> well, /magic would be too because that's a new thing. doesn't mean that policy is set in stone :)
<Son_Goku> well, it tends to be
<zyga> if that were the case /etc would still ship executables
<Son_Goku> I've not seen Debian Policy change significantly in the last decade or so
<zyga> and we'd be using vms or something
<Son_Goku> haha
<zyga> well, back to earth, I'll draft a migration script and share it
<Son_Goku> right
<zyga> I'm coming back to the light, I hope :)
<Son_Goku> I hope so too
<Son_Goku> we were nearing the "DEADREVIEW" state for all the stuff
<zyga> (yesterday, when I had to do some stuff away from home office I obviously had to break all of yakkety)
<Son_Goku> :)
<Son_Goku> mass rebuilds are good for the soul
<mup> PR snapd#1978 opened: interfaces/builtin: network-manager: allow access to netplan conf files <Created by morphis> <https://github.com/snapcore/snapd/pull/1978>
<mup> PR snapd#1979 opened: assertions: add system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/1979>
<ogra_> ppisati, have you tried -c edge instead ?
<sergiusens> Mirv the snapcraft team is on rocket, the snapd team isn't that is why you see kyrofa sometimes on or off
<kyrofa> Hahaha
<sergiusens> Mirv that said, I am the only snapcraft person dedicating day and night to it ;-)
<Mirv> ok :)
<ogra_> Mirv, all teams are kind of on IRC though
<ogra_> (reply times are sometimes slow since we started fragmenting everything across all possible chat tools though)
<Harshil> hello
<Harshil> I have a lenovo x201
<Harshil> which has a touch screen
<Harshil> does ubuntu 16 support touch screen?
<ppisati> ogra_: uhm nope
<ppisati> ogra_: i'll give it shot
<ppisati> ogra_: btw, where does the board dtb resided these days? kernel or gadget snap?
<ppisati> *reside
<ogra_> ppisati, you can pick ...
<ogra_> (and if LP wouldnt 503 on me i could show you an example :P )
<Harshil> is there any way i can  use tuch screen on ubuntu?
<ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems$ grep device-tree beagleblack/meta/gadget.yaml
<ogra_> device-tree: am335x-boneblack
<ogra_> device-tree-origin: kernel
<ogra_> ppisati, device-tree-origin: is either kernel or gadget ... with gadget being the default if you dont specify it at all
<ogra_> if it is gadget you need to ship it in /dtbs/ inside the gadget
<ogra_> Harshil, you mean snappy ? the snappy images do not have support for graphics yet ... and snappy on classic simply uses the input setup from the classic install for which you get support in #ubuntu
<morphis__> cyphermox: ping
<cyphermox> morphis__: hi
<morphis__> cyphermox: I was wondering if there are any patches you did for network-manager to support config files generated from netplan
<cyphermox> yeah, they're the few last I ever applied to NM
<cyphermox> to be able to read files in /run and /var/lib
<morphis__> cyphermox: ah, great
<morphis__> cyphermox: so https://git.launchpad.net/network-manager/tree/debian/patches/Read-config-from-run.patch and https://git.launchpad.net/network-manager/tree/debian/patches/Read-system-connections-from-run.patch ?
<cyphermox> that looks about right
<cyphermox> look through that same upload there may be more patches from pitti that go along with that
<morphis__> cyphermox: ok
<morphis__> cyphermox: thanks
<qengho> Is RPi2+ just impossible right now? My old image didn't survive upgrade, and the 6-Sept images are (I heard) broken.
<balloons> jdstrand, ping
<ogra_> they shouldnt be ... but nontheless there are sep 19 images :)
<ogra_> the sep. 6th images had an issue on the pi3 which is why we withdrew it ... pi2 was faine though
<ogra_> *fine
<qengho> Oh. My Pi3 won't work, I gues.
<oparoz> Can we still whitelist single syscalls in snapcraft.yaml?
<ogra_> qengho, that would surprise me ... the sept. 19 images should surely work on all arches we released for
<ogra_> (which includes pi3)
<balloons> zyga, just poking again about the snap-confine SRU. Did you get stuck trying to make one?
<ppisati> uhm
<qengho> ogra_: I'm dumb. Where are those images?
<ppisati> i'm pretty sure at this point that ubuntu-image caches the --extra-snap that you pass to it
<zyga> balloons: it's in progress
<zyga> balloons: I broke yakkety but we've learned and a new set of small releases will fix it today
<ogra_> qengho, http://cdimage.ubuntu.com/ubuntu-snappy/xenial/current/
<ppisati> and if you pass two times two different snap (but with the same)
<zyga> balloons: and hopefully eventually reach xenial
<balloons> zyga, wonderful to hear!
<balloons> zyga, ohh, nothing is in queue for xenial yet?
<ppisati> the image will be created using *always* the first snap with that name
<balloons> that's where I need it
<mup> Bug #1590219 changed: misleading error when the wrong command is passed with a flag <Snappy:Fix Released> <https://launchpad.net/bugs/1590219>
<ogra_> ppisati, probably time for a bug
<ppisati> ogra_: let me do another test
<jdstrand> balloons: hey
<balloons> jdstrand, howdy. I'm curious about your current thoughts on https://bugs.launchpad.net/snappy/+bug/1590767.
<mup> Bug #1590767: Support snap installed completion scripts <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1590767>
<balloons> jdstrand, it's the bash completion question :-) I know you had an idea that maybe it wasn't as crazy as it sounded for snaps
<jdstrand> balloons: all my ideas are captured in the bug. I'm not actively working on it
<jdstrand> balloons: I think it is probably possible, but it would need to be designed
<jdstrand> (not necessarily by me)
<ppisati> and while creating an image for rpi2/3, the dtbs aren't copied to the boot directory
<ppisati> so the gadget one are kept around
<ppisati> ...
<balloons> jdstrand, so it still needs design / proof of concept then. Sounds like the proposed idea of a confined helper to feed strings is the most promising then
<qengho> jdstrand: in case this was below your attention: "personality" syscall on armhf. https://bugs.launchpad.net/snappy/+bug/1614269
<mup> Bug #1614269: tor package on ARMHF crashes on filtered syscall "personality" <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1614269>
<qengho> I don't know what the argument to that syscall was, but I don't think we support more discrete filters anyway.
<jdstrand> qengho: I saw the bug. I have a feeling that you'd run into other problems, but maybe not. we do support seccomp argument filtering in snap-confine these days, but nothing is using it yet (I plan to change that as soon as I get through other high priority work)
<jdstrand> qengho: what happens if you add 'personality' to /var/lib/snapd/seccomp/profiles/snap.tor-middle-relay...
<qengho> jdstrand: I whitelist "personality" with "sudo -e" and it works great. No complaints.
<jdstrand> qengho: can you mention that in the bug. I suspect it is setting persona to 0xffffffff then
<qengho> I will
<jdstrand> thanks!
<mup> PR snapcraft#820 closed: Fixed bug LP: #1607294 snapcraft search returns results in different order <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/820>
<zyga> mvo: how do you feel about https://github.com/snapcore/snapd/pull/1847#pullrequestreview-1151064
<SamYaple> hmmm sergiusens bit of an issue with the python plugin
<mup> PR snapd#1847: many: discard preserved namespace after removing snap <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/1847>
<sergiusens> SamYaple what issue?
<zyga> mvo: I'd like to land it and do another release as this breaks people
<SamYaple> sergiusens: it appears that its not installing some things and im not sure why. just discovered it
<SamYaple> sergiusens: in a standard virtualenv on your machine, run `pip install dogpile.cache` youll notice it has more files than installing that in the snap
<SamYaple> specifically in the snap 'lib/python2.7/site-packages/dogpile' does not contain an __init__.py
<mvo> zyga: I would love to have niemeyer review on this branch too
<SamYaple> and that is needed
<mvo> zyga: but once its landed we can do a hotfix for yakkety
<niemeyer> mvo: Which one is that?
<niemeyer> #1847?
<mvo> niemeyer: yes
<sergiusens> SamYaple what if you `pip install --user dogpile.cache`?
<niemeyer> mvo: Looking
<balloons> mvo, might you be able to help out on getting a newer snap-confine into xenial? I've been poking zyga, but I don't think he has upload rights
<zyga> mvo, niemeyer: understood, thank you
<balloons> mvo, specifically the xenial version has the LXD issue which breaks juju, conjure-up, etc
<sergiusens> SamYaple and second question since I am mad troubleshooting something else, does the upstream provide that __init__.py?
<mvo> balloons: what bit exactly do you need? there is a pending update but its a bit delicate because it requires a new snapd and lock-step updates
<SamYaple> sergiusens: indeed it does (as well as other files, __init__.py missing is simply blocking the import)
<mhall119> nessita: are you on the Ubuntu rocket.chat ?
<SamYaple> sergiusens: i can't --user in a virutalenv. stil ltesting that
<balloons> mvo, https://bugs.launchpad.net/snap-confine/+bug/1613845
<mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1613845>
<nessita> mhall119, I'm not, how can I help you?
<balloons> mvo, the PR is linked in there if you wanted to cherry-pick. But I was assuming 1.0.40 (and now 1.0.41) would come back to xenial directly
<mhall119> nessita: Mirv had a question there about the new content interface and the store, let me copy it here
<sergiusens> SamYaple I am guessing virtualenv does some __init__.py magic (I saw the code for virtualenv, it is full of weird things to help you out)
<SamYaple> sergiusens: nah, its there with --user as well
<SamYaple> sergiusens: but like i said, there are other missing files too, like api.py
<mhall119> is there any recent documentation or examples on the content interface? I tried to add a similar slot configuration to geany-plugins to my package: https://github.com/ubuntu/snappy-playpen/blob/geany/geany-plugins/snapcraft.yaml - but when uploading to store I got "unknown attribute 'content' for interface 'content' (slots) lint-snap-v2_slots_attributes"
<SamYaple> specific to dogpile.cache
<mhall119> nessita: ^^ that was it
<sergiusens> SamYaple hmph, can you log a bug, I will look at it later
<SamYaple> sergiusens: sure. im still digging into it
<mvo> balloons: right, if we do a new snap-confine we need to also do a new snapd with a branch that is not even in master yet, I'm just saying if this is urgent a cherry-pick might be easier
<balloons> mvo, ack, makes sense. I would really appreciate a cherry-pick in that regards. I'm happy to help verify the SRU
<mvo> balloons: ok, I will keep that in mind, if the branch lands soon and we can unblock the current snapd sru the full release is probably a better option. but its two *ifs* in there
<mvo> pitti: silly question, snapd  2.15.2ubuntu1  is in xenial-proposed since ~21h but I  have not seen a autopkgtest run for it, is that expected? also not in the queue or anything. how is that scheduled?
<nessita> mhall119, hum, I don't have the details of each interface, let me see who can help you
<nessita> mhall119, the store until runs the click-reviewers-tools
<nessita> we don't have the logic of the checks themselves
<nessita> jdstrand, hi, would you know what the error that mhall119 printed above means: "unknown attribute 'content' for interface 'content' (slots) lint-snap-v2_slots_attributes"
<mhall119> click-reviewers-tools is used against snaps as well?
<nessita> mhall119, what app is this, so I look for it in the store?
<nessita> mhall119, yers
<nessita> yes*
<pitti> mvo: ah, we had a ginormous amount of cloud breakage again, I'll just kick it
<pitti> (to re-run again)
<mhall119> nessita: not sure, Mirv didn't share links to his files
<mvo> ta
<pitti> mvo: note that it fails in y (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd)
<nessita> mhall119, do you know the snap name?
<pitti> mvo: (so is stuck in -proposed anyway)
<niemeyer> zyga: Btw, if you are in a hurry, revert the changes
<niemeyer> zyga: We don't want to rush this in
<niemeyer> zyga: You are touching on the foundation of every single snap, and apparently there are issues.. let's take the time to do it right
<zyga> niemeyer: ack
<mhall119> nessita: I don't, sorry, and Mirv might be gone for the day already
<mhall119> I can't find his developer account in the store either
<Mirv> mhall119: nessita yes EOD but a quick link https://myapps.developer.ubuntu.com/dev/click-apps/5974/ -> 4 had the failure, in 5 the line is removed (and a new unrelated part added)
<Mirv> sorry must go
<niemeyer> zyga: review submitte
<niemeyer> d
<mhall119> thanks Mirv
<mvo> pitti: that is fallout from a bad snap-confine version but yeah
<nessita> Mirv, checking
<mvo> pitti: I'm keen on the autopkgtest output because the upload targets the failures specifically, I'm keen to learn if my fixe(s) are good enough
<mhall119> Mirv: looks like rev 5 passed, does that mean you've resolved it, or just reverted the changes from rev 4?
<jdstrand> nessita: I do. 'content' isn't an attribute of the content interface per https://github.com/snapcore/snapd/blob/master/docs/interfaces.md. the attributes should be read, write or target
<jdstrand> (depending on if slot or plug. in this case it is slot side so should be 'read' or 'write')
<mhall119> jdstrand: according to my understanding of the interface, the "content" attribute is needed to make sure the plug and the slot are both talking about the same thing
<jdstrand> there is no content attribute based on the docs
<jdstrand> let me look at the yaml
<jdstrand> jeez this thing is 400M
 * jdstrand really wishes that the store showed the snap.yaml...
 * jdstrand knows that is planned
<mup> Bug #1626617 opened: console-conf does not allow to set up dns for static ip <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1626617>
<mhall119> jdstrand: https://github.com/snapcore/snapd/blob/941e06e4f0eaece96e357b561013c8b7363e0068/tests/lib/snaps/content-slot/meta/snap.yaml lists a content parameter
<mhall119> maybe it's something planned but not implemented yet
<mhall119> https://github.com/snapcore/snapd/blob/941e06e4f0eaece96e357b561013c8b7363e0068/tests/lib/snaps/content-plug/meta/snap.yaml being the plug side
<SamYaple> sergiusens: the import problem still exists, however the missing __init__.py is not the problem. the file difference was due to different versions of dogpile.cache
<SamYaple> sergiusens: the fact remains that it is still an import problem and i dont know why
<oparoz> Do we still need to "connect" something if we whitelist a syscall?
<zyga> mhall119: hey, I need to skip the call as I have a conflict on sprint planning
<mhall119> zyga: no worries, we had the upstreaming work call earlier, we found some blockers that will get passed on to you or jdstrand but not much
<mhall119> jdstrand: who are you waiting for on the dbus interface review?
<jdstrand> mhall119: niemeyer
<jdstrand> mhall119: as for the content interface, just drop 'content: qt-ubuntu'
<mhall119> niemeyer: a number of desktop apps are waiting on the dbus interface, do you know when we'll have that available?
<jdstrand> mhall119: I checked the code and there is nothing in it that I can see that would honor the content attribute
<mup> PR snapd#1976 closed: tests: skip some tests on non-amd64 architectures <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1976>
<mhall119> Mirv: ^^ see jdstrand's fix above, it seems the 'content' parameter isn't used
<jdstrand> mhall119: your question to niemeyer isn't phrased quite right
<niemeyer> mhall119: After I get over the critical tasks for the impending deadlines
<niemeyer> mhall119: I don't know what the status of this is, to be honest.. we discussed that long ago
<jdstrand> mhall119: as you know, it was deprioritized for other high prioirty interfaces. that work is done, I came back around to it to get it in reviewable shape this week. now niemeyer and I need to iterate
<niemeyer> Ah, nice, so jdstrand is on top o fit
<mhall119> jdstrand: thanks, I didn't know it was deprioritized (though I did know other work was above it)
<jdstrand> niemeyer: yeah-- we can start iterating again-- but I gave a long answer and I suspect you'll want to give it a careful read and ponder
<jdstrand> mhall119: that is what I meant about deprioritized
<niemeyer> mhall119: It was not consciously deprioritized.. it was naturally deprioritized because we have way too much to do on not enough time
<balloons> should ~/snap/snapname/current exist? I only see ~/snap/snapname/buildnumber
<jdstrand> mhall119: again, it is difficult when everything is critical priority-- nothing is. it was behind other stuff. that other stuff is mostly done, but dbus-app got picked up again and we are moving forward as best we can considering the deadlines (as niemeyer indicated)
<jdstrand> mhall119: fyi, you are a subscriber to the trello card and I keep it up to date. not sure if those updates are getting filtered
<mhall119> jdstrand: I saw the update, but not the detail of who had the next task on it or when it might be done
<tachyons> successfully uploaded first ruby snap to store
<jdstrand> the next task is in the PR
<mup> PR snapd#1980 opened: tests: more debug around the create-key test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1980>
<jdstrand> I don't have a timeline since we need to iterate and other deadlines are there
<jdstrand> mhall119: note that devmode is still an option to unblock people. I realize that doesn't help with the stable channel.
<mhall119> yeah, it also doesn't let them work on building their snap "the right way" until they know what that right way is going to be
<mhall119> but I'm glad it's still active and getting near the top of the priority list now
<mup> PR snapcraft#821 opened: Make copies of remote parts to avoid ordering issues <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/821>
<Guillaume__> hello
<Guillaume__> when they say "Try Ubuntu Core running on bare metal x86 devices" does it mean that it can run on any computer ???
<ogra_> sure, you can dd the amd64 or i386 image onto a USB stick and should e able to boot it from there
<mhall119> as long as the hardware doesn't prevent you from booting a different OS, yes
<ogra_> indeed ...
<mhall119> sergiusens: can you do 1400 utc tomorrow to talk about cmake/cpack and snaps?
<mhall119> should only take 30 minutes
<Guillaume__> is there a recommanded hardware or limitation ? for example, does it run on any NUC ?
<Guillaume__> on bare metal, is there a recommanded hardware or limitation ? for example, does it run on any NUC ?
<Pharaoh_Atem> zyga: so have you figured out the migration step yet?
<SamYaple> sergiusens: oh. when did that get added? the problem is we are stripping the pth files
<SamYaple> sergiusens: we should absolutely not be doing that
<zyga> Pharaoh_Atem: I think so, I need to setup some representative env for testing though and script it all the way
<zyga> Pharaoh_Atem: though still working on https://github.com/snapcore/snapd/pull/1847
<mup> PR snapd#1847: many: discard preserved namespace after removing snap <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/1847>
<SamYaple> sergiusens: https://github.com/snapcore/snapcraft/pull/765 tsk tsk tsk it was you!
<mup> PR snapcraft#765: Use a recursive iglob for filesets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/765>
<jdstrand> niemeyer: hey, is there a way to retrigger travis checks? https://github.com/snapcore/snapd/pull/1968 failed for something unrelated to the PR
<mup> PR snapd#1968: interfaces: adjust bluetooth-control to allow getsockopt (LP: #1613572) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1968>
<niemeyer> jdstrand: Yeah, if you click on the "Details" link you'll see the three jobs.. some of them will likely have passed
<jdstrand> yes, two of the 3 did
<niemeyer> jdstrand: If the spread one failed, please restart just that one by clicking on it first
<niemeyer> jdstrand: That sounds like a real failure then.. doubt a restart will make it work
<jdstrand> ok, it was the one. it is tests/main/create-key
<niemeyer> jdstrand: Please note we have a low tolerance for flakiness.. if there's a test that is failing on and off, we need to fix it or remove it
<niemeyer> jdstrand: Ah, yeah, that's exactly this case then :)
<jdstrand> 2016/09/21 22:25:37 Failed tasks: 2
<jdstrand> - linode:ubuntu-16.04-32:tests/main/create-key
<jdstrand> - linode:ubuntu-16.04-64:tests/main/create-key
<niemeyer> jdstrand: mvo has been trying to stabilize this one
<jdstrand> ok, cool
<jdstrand> so if I click it, it might pass
<niemeyer> jdstrand: Yeah
 * jdstrand notices PR 1980 is being worked on
<mectors> How does the serial-port interface work when I want to use a snap that connects to a USB device? Do I add a slot with the usb-x parameters and what do I have to do with snap connect?
<niemeyer> mvo: any news on create-key?
<jdstrand> niemeyer: I think I'm clicking the wrong thing. if I click 'it' or the big 'x', it just shows me the log
<jdstrand> maybe I need to sign in
<niemeyer> jdstrand: It's a circular thing, and there's a label next to it at the top
<niemeyer> jdstrand: Yes, it needs to know who you are before it allows restarting a jbo
<mup> Bug #1626652 opened: ~/snap/<name>/current/ is missing <Snappy:New> <https://launchpad.net/bugs/1626652>
<jdstrand> niemeyer: ok, it took a while after I logged in before it should me the 'Restart build' button, but I clicked it. stuff seems to be happening :) thanks!
<jdstrand> showed*
<niemeyer> jdstrand: np.. again, if you click this thing too often, please let us know.. create-key we're already aware and are working on it
<mup> Bug #1626656 opened: something isn't quoting <bold>things</bold> <Snappy:New> <https://launchpad.net/bugs/1626656>
<mup> Bug #1626656 changed: something isn't quoting <bold>things</bold> <Snappy:Invalid> <https://launchpad.net/bugs/1626656>
<jdstrand> niemeyer: yep. I figure I'd always ask
<sergiusens> SamYaple you the content of the .pth be correct in any case?
<sergiusens> SamYaple we need some code that would normalize it
<modprobe_> Is there an easy way to include packages from a PPA in my snap? I'm trying to package an app which deps Qt 5.7
<SamYaple> sergiusens: i dont understand the question
<sergiusens> SamYaple hmm, I fail to see why we filter those out now
<sergiusens> SamYaple disregard me, I entered firefighting mode since I woke up today :-)
 * sergiusens skipped breakfast and lunch, and wondering if a late lunch would be a good idea
<SamYaple> sergiusens: ok i responded in the github comment, but im going to submit a patch to remove that filtering and see if anyone complains
<SamYaple> i really dont know why its filtered either
<sergiusens> SamYaple please do
<sergiusens> SamYaple oh, if possible in demos/snaps_tests it would be good to add a py package that maks use of pth files
 * qengho has trouble with first startup of published pi3 image. Four CPU fruits on black, timeout to black. Heartbeat light still blinks. numlock key toggles light! and ctrl-alt-delete reboots. Weird.
<SamYaple> sergiusens: without digging around, dogpile.cache does. ill see about adding that
<qengho> Only weird thing in text before starting kernel is "Unable to read uEnv.txt".
<ogra_> slangasek, ok, seems live-build is the bad guy here and removes *.pyc on all our images at build time with the exception of ubuntu-server and ubuntu-cpc ... i wonder why nobody ever sumbled over this
<sergiusens> ogra_ slangasek I am so happy it is not snapcraft :-)
<SamYaple> sergiusens: demos in the snapcore/snapcraft repo?
<ogra_> slangasek, since quantal actually ...
<sergiusens> SamYaple yeah, those get built AND their `apps/*/commands` run if specific to under snaps_tests as a real snap
<sergiusens> SamYaple which wouldn't be the case if adding an integration test
<ogra_> hmm, probably even longer ... cjwatson added the exception for ubuntu-server in quantal
<sergiusens> SamYaple if it is too much trouble that's ok
<slangasek> ogra_: probably because before now, "not ubuntu-server and not ubuntu-cpc" meant desktop, and the desktop live images were used on x86, and the byte compile penalty wasn't enough there to notice
<SamYaple> sergiusens: not to much trouble, just something new. ill look into it right now
<ogra_> slangasek, well, but that could explain why armhf has always been slow :) we always insisted to use the official build tools for our images :)
 * slangasek chuckles
<mup> PR snapcraft#822 opened: Don't filter .pth files in python plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/822>
<slangasek> ogra_: will you make the change to live-build to fix this, then?
<ogra_> slangasek, i'll just add ubuntu-core to the exception code in livecd-rootfs for now
<slangasek> ogra_: wfm
<sergiusens> ogra_ mind if I reply with a short summary to the list?
<qengho> modprobe__: No, there isn't.  Maybe add what you think it should look like in your yaml. https://bugs.launchpad.net/snapcraft/+bug/1604671
<mup> Bug #1604671: snapcraft doesn't support arbitrary PPAs or apt sources <Snapcraft:New> <https://launchpad.net/bugs/1604671>
<ogra_> but we should probably consider simply ripping out that bit completely
<ogra_> slangasek, sure, go ahead, though i first want to see if that actually improves much :)
<ogra_> before i make a statement myself
<sergiusens> ogra_ oh, people say pyc is needed for this to improve, let's get them those pycs ;-)
<ogra_> sergiusens, yeah, there i'm not even a size-nazi  :P
<sergiusens> ogra_ riiiiight
<sergiusens> ogra_ also, check telegram ;-)
<sergiusens> ogra_ there is a treat for you
<ogra_> LOL
<ogra_> ohmy !
<ogra_> thats an oooold pic
<sergiusens> snappy fixed it ;-)
<ogra_> not yet :)
<ogra_> oh man , i look so slim ...
<zyga> ogra_: snaps make everything ... compressed ;-)
<ogra_>  hahaha
<modprobe__> qengho: Thanks, I've done that. :)
<mup> PR snapd#1981 opened: tests: add a test for core about device initialization and device registration and auth <Created by pedronis> <https://github.com/snapcore/snapd/pull/1981>
<qengho> I'm filing image bugs in snappy/snapd bug tracker. Hope that's okay.
<ogra_> well, filing them on the project is desired ...
<ogra_> (see topic)
<ogra_> dont file them against snapd though ... unless it is actually a snapd prob
<mup> PR snapd#1971 closed: interfaces/builtin: add rcvfrom for client connected plugs to mir interface <Created by kgunnfront> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/1971>
<dobey> ogra_: unless it's a problem in the app itself, isn't it always a snapd problem? i thought that was the whole point of snapd and forcing everything to go through it
<ogra_> well, a snappy image consiste of a lot more than snapd .. running a snap on a classic system uses snap-confine, ubuntu-core-launcher etc etc
<ogra_> *consists
<kyrofa> dobey, if it's image-related though, it could be ubuntu-image or a number of other things
<ogra_> and even on classic it can be a lot more
<kyrofa> Definitely
<kyrofa> There are a lot of pieces associated with snaps beyond just snapd
<ogra_> that is why we have the snappy project as catch-all bugtracker ...
<mup> PR snapd#1956 closed: many: show snap name before the download progress bar <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1956>
<pmcgowan> ogra_, hey, cant get my dragonboard to boot of the sd I made, will it work with a 2GB card?
<mup> PR snapcraft#821 closed: Make copies of remote parts to avoid ordering issues <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/821>
<ogra_> pmcgowan, i havent tried, but at least the dailies should not be to big for a 2G card
<ogra_> (the smallest i have ever tested was 4G)
<pmcgowan> ogra_, it errored when it reached the end of the card, when I insert it and boot I get the default android on mmc
<pmcgowan> I did change the dip switch to sd
<ogra_> pmcgowan, ah, well, the beta images are 3.8G ... they wont fit
<pmcgowan> oh
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<ogra_> grab one from there
<ogra_> thats 300MB
<ogra_> (uncompressed)
<pmcgowan> great thanks will try it
<pmcgowan> ogra_, btw whats the difference in the images besides the size
<pmcgowan> or is this just new and improved
<mup> PR snapcraft#823 opened: plainbox-provider plugin: rewrite python shebangs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/823>
<sergiusens> SamYaple any luck with the test?
<ogra_> pmcgowan, mine are untested daily builds from the edge channel (latest stuff and latest breakage) ... the cdimage ones are tested beta images
<pmcgowan> ogra_, will beta images get smaller? or do I need to buy a card
<ogra_> both ? :)
<pmcgowan> heh
<ogra_> i'm using ubuntu-image trunk whihc builds images only as big as their content
<ogra_> once trunk is released the beta ones will also be small
<pmcgowan> got it thanks
<mup> PR snapd#1981 closed: tests: add a test for core about device initialization and device registration and auth <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1981>
<sergiusens> mhall119 I can do one hour after or one hour before
<zyga> jdstrand: hey
<zyga> jdstrand: I wrote a small branch for snap-confine that I plan to cherry-pick into the release
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/151
<mup> PR snap-confine#151: Make snap-discard-ns fail gracefully <Created by zyga> <https://github.com/snapcore/snap-confine/pull/151>
<ogra_> slangasek, http://paste.ubuntu.com/23217393/ ... not much improvement
<ogra_> (and it wastes 5MB on the image)
<slangasek> ogra_: strace itself is doing a lot of I/O, I'd be more interested in 'time console-conf --help' + strace output :)
<slangasek> ogra_: is that 5MB of .snap size or within the filesystem?
<slangasek> anyway
<ogra_> the core snap got 5MB bigger
<slangasek> strace output please, so we can see what it's spending time on now that it's *not* spending it on byte compilation
<ogra_> (which is = filesystem size in our case)
<ogra_> slangasek, http://paste.ubuntu.com/23217404/
<slangasek> ta!
<ogra_> without strace the time output varies ...
<ogra_> between 12 and 5 secs
<ogra_> thats is noticeable better ...
<ogra_> i'll do a full install run with tomorrows image ... curious how that will turn out now
<slangasek> indeed
<ogra_> also interesting that it looks for the en_* locales ... the suystem has C.UTF-8 hardcoded
<slangasek> huh
<slangasek> ogra_: how's the entropy on the bbb?
<ogra_> oh ... LANGUAGE is actually unset
<slangasek> I notice the getrandom() in there
<ogra_> plain SW iirc
<ogra_> hmm, probably i'm wrong
<ogra_> ogra@bbb:~$ lsmod|grep rng
<ogra_> omap_rng               16384  0
<slangasek> ogra_: also it looks like we're missing .pyc for subiquity itself, and that will be a packaging bug on our side:      0.001296 stat64("/usr/share/subiquity/subiquitycore/ui/__pycache__", 0xbeecbe10) = -1 ENOENT (No such file or directory) <0.000174>
<slangasek> cyphermox, mwhudson: ^^
<slangasek> not sure if that's enough files to matter
 * ogra_ vanishes into the night
<SamYaple> sergiusens: im still going on it, got other work pulling me away at the moment
<cyphermox> slangasek: interesting, but I'm not overly surprised, I had all kinds of issues with packaging this
<zyga> slangasek: hmm
<zyga> slangasek: is that confined?
<zyga> slangasek: AFAIR there's a silent deny rule for __pycache__ in apparmor somewhere
<zyga> slangasek: (in the base template)
<slangasek> zyga: this was a problem of files actually missing from the image
<zyga> slangasek: ah, I see
<slangasek> and if they're there, no denial
<zyga> jdstrand: updated https://github.com/snapcore/snap-confine/pull/151 as requested
<mup> PR snap-confine#151: Make snap-discard-ns fail gracefully <Created by zyga> <https://github.com/snapcore/snap-confine/pull/151>
<mup> PR snapd#1982 opened: tests: disable broken create-key test <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1982>
<mup> PR snapd#1968 closed: interfaces: adjust bluetooth-control to allow getsockopt (LP: #1613572) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1968>
<mwhudson> slangasek: subiquity missing .pycs is not in the same league as missing them for the stdlib, i'd hazard
<zyga> woah
<zyga> "python slow"
<zyga> gentoo level
<mwhudson> heh funroll-loops.info seems to have died
<mup> PR snapd#1982 closed: tests: disable broken create-key test <Created by niemeyer> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1982>
#snappy 2016-09-23
<mup> PR snapd#1952 closed: configstate,hookstate: add snapctl set <Critical> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1952>
<mup> PR snapd#1983 opened: ctlcmd: add snapctl get <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1983>
<mup> Bug #1564076 changed: Can't launch snaps <gnome-software> <sdoc> <verification-done> <gnome-software (Ubuntu):Fix Committed by robert-ancell> <snapd (Ubuntu):Fix Released> <gnome-software (Ubuntu Xenial):New> <snapd (Ubuntu Xenial):Fix Released> <gnome-software (Ubuntu Yakkety):Fix Committed by
<mup> robert-ancell> <snapd (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1564076>
<mwhudson> er do tests pass with tip for people right now?
<mwhudson> go test github.com/snapcore/snapd/interfaces/builtin fails for me
<mup> PR snapd#1984 opened: daemon: add logging to help diagnose create-user slowness <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1984>
<Mirv> thanks mhall119 jdstrand nessita! that's what I thought, but it'd be nice to get an up-to-date playground example then like I doubt geany/geany-plugins is working at the moment. I guess that the plug and slot need to be named identically instead of specifying the content field.
<mup> PR snapd#1985 opened: progress: use New64 and fix output newline <Created by mvo5> <Conflict> <https://github.com/snapcore/snapd/pull/1985>
<mup> PR snapd#1973 closed: tests: ensure HOME is also set correctly <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1973>
<mup> PR snapd#1986 opened: tests: ensure HOME is also set correctly <Created by mvo5> <https://github.com/snapcore/snapd/pull/1986>
<dholbach> hey hey
<didrocks> good morning dholbach
<dholbach> salut didrocks
<zyga> o/
 * ogra_ -> dentist
<mup> PR snapd#1986 closed: tests: ensure HOME is also set correctly <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1986>
<mup> PR snapd#1984 closed: daemon: add logging to help diagnose create-user slowness <Created by mwhudson> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1984>
<Chipaca> mwhudson, o/
<mup> Bug #1626930 opened: Missing mount-observe slot in Core <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1626930>
<mup> Bug #1626930 changed: Missing mount-observe slot in Core <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1626930>
<oparoz> Hello guys. Is it or is it not possible to override seccomp by whitelisting syscalls? The documentation and tests in the snapcraft repo seem all wrong
<oparoz> Was looking in the repo of the fork... So it seems everything is gone. Too bad
<jacekn> hello. Im building snap and snapcraft prints warning: "grade" property not specified: defaulting to "stable". Where can I find documentation for this option? There is nothing here: http://snapcraft.io/docs/build-snaps/syntax
<mup> PR snapd#1987 opened: daemon,overlord/assertstate: support streams of assertions with snap ack <Created by pedronis> <https://github.com/snapcore/snapd/pull/1987>
<ogra_> mvo, bah, crap, did you note what keyboard-configuration all pulled in alongside ? (initscripts, debconf, lsb-base ... ) we really need to cut that down again
<morphis_> pitti: can you have a look at https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 ?
<pitti> morphis_: replied
<morphis_> pitti: the service name is sadly nothing I can influence
<morphis_> that is what snapd builds for it
<morphis_> also to avoid intersections with other snaps
<pitti> morphis_: right, hence adding Alias=
<morphis_> pitti: sure but that is still something snapd need to get from somewhere
<pitti> WDYM "get"?
<morphis_> pitti: snapd creates the service unit on the fly
<pitti> you just put it in the unit, and when it gets enabled, systemctl creates the alias symlink
<morphis_> we don't ship it as part of the snap so we can't modify it
<pitti> err
<morphis_> so we would have to add another key in meta/snap.yaml which then gets parsed by snapd and added in the .service unit
<pitti> if we are going to snap up core plumbing parts like NM, bluez, cups or whatnot, I suppose that's necessary indeed
<morphis_> pitti: something to argue with niemeyer about
<pitti> cluttering a lot of packages with snapd service aliases is a really bad design
<morphis_> pitti: I am currently just searching for a way to replace networkd in our images with network-manager which comes from the snap
<mup> Bug #1626986 opened: snapd should allows snaps to define systemd unit Alias names <Snappy:New> <https://launchpad.net/bugs/1626986>
<jdstrand> jacekn: I guess the documentation is out of date. grade can be one of stable or devel. aiui, if you set it to 'devel' it ensures it won't accidentally end up in the stable channel
<jacekn> jdstrand: and can stable end up in devel?
<jdstrand> jacekn: I think so
<jdstrand> sergiusens: can you comment? ^
<jacekn> jdstrand: sergiusens: I have some opinions here. For snapscraft.yaml building external code I have to maintain multiple branches with different "version" and "source-tag". This new options means yet another line that needs to be different between those branches
<jacekn> jdstrand: sergiusens: so really IMO warning is an overkill, I'd prefer not to have that option at all
<jdstrand> jacekn (cc sergiusens): we didn't design the feature. perhaps that would be a good question for the mailing list?
<jacekn> jdstrand: ack and good point!
<jdstrand> that way you'll get definitive answers on how things work and why
<jdstrand> and I know they are always looking for real world feedback
<qengho> lpotter: Your Pi (2? 3?) didn't display HDMI at boot? My pi3 did not either. I worry OG's "hdmi_safe" proposal isn't fixing the right thing. Want to help debug it?
<ogra_> qengho, you mean you dont see anything after the first boot (i.e. after 5min) apart from the raspberries even with hdmi:safe set ?
<ogra_> *hdmi_safe
<ogra_> qengho, also, which image do you use and how big is your SD ... (the daily image is a lot smaller and will talke longer to resize on a big SD)
<qengho> ogra_: correct, nothing displayed after 5 or 45, though I'm about to test scientifically and give you real data by end of day. I used the "release" images on a 32GB, fast microSD.
<ogra_> well, that should resize in 2-3min max
<ogra_> (likely faster)
<ogra_> i really cant reproduce it here ... i always get the "please press enter" under the raspberries
<qengho> ogra_: And I will want your help. I think the cmdline can have any number of console= lines. You could have serial AND tty0. I think.
<qengho> But I can't test the serial one.
<ogra_> no, then you dont get the actual boot data on serial
<ogra_> the first console= arg is used for early boot ... the second one is switched to after the kernel ... i.e. initrd and following
<ogra_> might be first and last (instead of first and second) if you have more than two ...
<ogra_> during development it is essential that users can give us the full boot log when something hangs ... i'm happy to change defaults for final release but not while we require debug data
<qengho> ogra_: In any case, perhaps that configuration tool can display on /dev/ttySwhatever AND /dev/tty0 .
<ogra_> it does !
<qengho> Oh. Hrm.
<qengho> Then something is wrong.
<ogra_> here at least ...
<mup> PR snapd#1974 closed: snapd: kmod backend <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/1974>
<qengho> ogra_: Okay, I'll test and let you know.
<ogra_> systemd always starts one agetty on each console by default ... console-conf intercepts agetty and displays the "please press enter" message one them
<ogra_> *on
<ogra_> qengho, i also dont undersatnd why people want to use HDMI at all. given we do not allow any login except ssh anymore
<ogra_> so defaulting to HDMI doesnt really make much sense
<qengho> ogra_: You connect another computer and *its* display to the computer, instead of just a display? That's dumb. That's why.
<ogra_> (having avahi and a network based conole-conf by default would make massively more sense)
<qengho> Yes, so much. I need some zeroconf.
<ogra_> well ... except that the image will then explode in size ... we're already way to big for embedded
<qengho> ogra_: OTOH, if you have an old DEC VT220 you're plugging in directly, then I apologize.
<ogra_> i just use the serial cable that was shipped with the board when i bought the "embedded developer" set
<ogra_> :P
<qengho> You sound scornful of it like you're saying "micro-" computer, and wisful of the days when a REAL computer took up several cubic meters. Computers get smaller. This is normal now. This is a real computer.
<ogra_> qengho, you dont really expect people to attach a monitor to their NAS, AP, router, IoT controller, do you ?
<ogra_> i'm not saying computer at all
<qengho> ogra_: When it comes with a video card and more than one USB port, I think you have to stop pretending it's only a lawnmower device.
<ogra_> we are targeting IoT here ... at most you will run a single purpose kiosk app in such a device
<ogra_> when you use HDMI at all
<ogra_> qengho, it isnt a desktop ... you wont actually use it as one ... beyond probably showing off to people that you can use it as such
<ogra_> i definitely dont know anyone who actually uses a pi as their default desktop system, sorry
<ogra_> i agree it makes sense to have HDMI for something like a kido system or any other single purpose kiosk setup thhough, no doubt here
<ogra_> *kodi
<ogra_> but after all our current target is IoT and embedded ... once we have a desktop session snap you will run on such a device you will also have a grephical firstboot tool to set it up ... and that wont run on the console at all
<morphis_> ogra_: ping
<ogra_> no need to ping me if i talked a line above ;)
<ogra_> just ask :)
<morphis_> ogra_: but you have the choice to pong when you're free :-)
 * ogra_ pongs 
<ogra_> heh
<morphis_> hehe
<qengho> ogra_: there are many many millions of RPis sold, and very few are that "embedded kit" version. Throw away your serial cable and become one of the 99.99% of owners for a few days.
<morphis_> ogra_: we put upgrade for netplan currently in the ppa to include them in the next core snap, right?
<tachyons_> https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/indicators.py#L33 , This approach of finding content length using content length header is making probelm when using http compression
<tachyons_> Eg github gist
<tachyons_> Lazy to file a bug in launchpad :D
<ogra_> qengho, yeah, its a sad fact that people picked a dead wood settopbox chip for that hype instead of something proper ...
<ogra_> morphis_, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra_> needs to end up there
<ogra_> morphis_, at least until pitti lands everything that netplan needs in xenial-updates proper :)
<ogra_> (which i hope is the case for GA, we need to be able to build stable without the PPA)
<pitti> ogra_: when is GA?
<ogra_> pitti, uh, not sure ... several weeks ... jamiebennett knows exact dates
<pitti> ogra_: I didn't yet backport it as we don't use netplan extensively yet, and thus it's still in the "find/add missing features" phase
<tachyons_> sergiusens:  cc
<pitti> ogra_: but we could certainly start to SRU the NetworkManager patches at least
<jamiebennett> pitti: GA = 2016-11-03
<pitti> thanks
<ogra_> now thats exact :)
<pitti> morning or afternoon? âº
<ogra_> *g*
<jamiebennett> 23:59
<jamiebennett> we need all the time we can ;)
<pitti> PST
<morphis_> ogra_: ok
<morphis_> pitti: ok, once I give you the go for that patch we talked about can to bring the new netplan package into the snappy-dev ppa?
<pitti> morphis_: it's your PPA, go wild :)
<morphis_> pitti: not really mine :-)
<pitti> it's not a long-term solution, but good enough for a beta/demo for sure
<morphis_> pitti: its for sure not a demo, it goes into production
<morphis_> pitti: but we can figure out a better solution and migrate to that at a later point
<pitti> *nod*
<pitti> and the PPA seems fine for those
<pitti> morphis_: maybe the snap yaml doesn't even need to be explicit about these aliases -- I mean, you slurp in packages (or upstream builds) that already *have* the systemd and dbus .service files, so it could just scan those and automatically provide aliases (if explicit declarations are unwanted)
<pstolowski> jdstrand, hey, thanks for the review of timedate control interface!
<morphis_> pitti: yeah another option, something we need to discuss with niemeyer
<ogra_> pitti, that would get tricky ... i have a bunch of snaps that use daemons, none of them can actually use their default init scripts or systemd units ... usually you need to re-define config paths and the like
<pitti> but in general, I don't understand why you wouldn't just take upstream .service files as they are, and instead rewrite them
<ogra_> so i doubt we could make that a generic thing
<zyga> jdstrand: hey
<pitti> well, then at least provide them under their original name
<ogra_> because i need a wrapper that creates an initial config, in a non standard place for example
<morphis_> ogra_: it would be just an alias we need to add to the files you say we're NetworkManager.service too
<pitti> they aren't co-installable with the corresponding debs anyway
<ogra_> pitti, hahaha ...
<ogra_> (we have nothing that prevents this)
<pitti> but it would just mean that dependencies, resource limitations, privilege reductions, aliases, etc. need to be duplicated in the yaml
<mup> PR snapd#1988 opened: Allow system bus access for screen-inhibit-control <Created by afrantzis> <https://github.com/snapcore/snapd/pull/1988>
<pitti> but anyway, that's a SEP :)
<jdstrand> zyga: hey-- so, how does leaving in hello-world cause ubuntu-core to get unmounted (ns discard latest commit). Or did I misread your comment?
<jdstrand> pstolowski: you're welcome :)
<zyga> jdstrand: it's not
<zyga> jdstrand: I just started realizing what is the problem
<zyga> jdstrand: I'm going to just get an ack from chipaca and release stuff
<jdstrand> zyga: heh, ok, cause I was starting to get worried :)
<zyga> jdstrand: it seems snapd is doing something crazy wrt cleanup now
<zyga> jdstrand: ubuntu-core is unmounted mid tests when some cleanup task fires
<jdstrand> zyga: ack. that is worrisome for other reasons, but glad that the ns discard wasn't causing it :)
<zyga> jdstrand: I need a few more changes in snapd (to redesign the branch a little, move the task to other manager) and I got +1 to merge it
<jdstrand> great :)
<sergiusens> tachyons_ we have a bug for that
<sergiusens> jdstrand I just answered an askubuntu question about grade around 30' ago
<jdstrand> zyga: I see you merged that-- should you uncomment the hello-world bit too?
<jdstrand> sergiusens: cool
<zyga> jdstrand: I evicted that commit
 * sergiusens goes back to writing unit tests
<zyga> jdstrand: it's not commented out anymore
 * sergiusens looks at joc_ and wonders how he got away with it ;-)
<jdstrand> zyga: ok cool. I didn't see that commit, only the one saying you were merging. thanks
<zyga> jdstrand: I rebased that commit away (the one that was commenting those bits out)
<mup> PR snapd#1987 closed: daemon,overlord/assertstate: support streams of assertions with snap ack <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1987>
<tachyons_> sergiusens:  link ?
<sergiusens> tachyons_ https://bugs.launchpad.net/snapcraft/+milestone/2.19
<om26er> Hello! Whats the update on diff based snap updates ?
<mup> PR snapd#1989 opened: tests: build once and install test snap from cache <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1989>
<om26er> Whats the password for all-snap image ? After I added my launchpad email, I am not able to login.
<sergiusens> SamYaple hey, I tried to this http://paste.ubuntu.com/23220251/ on an unpatched snapcraft and was able to do this http://paste.ubuntu.com/23220246/ (I am not sure how to expose the current .pth bug)
<sergiusens> om26er only ssh
<sergiusens> ssh in and set a passwd if you must
<ogra_> "sudo passwd $USER" after you sshed in ...
<sergiusens> ogra_ obviously :-P
<om26er> sergiusens, hmm, I think I can't remember my IP
<sergiusens> om26er cannot help you there
<ogra_> sergiusens, well, yu could just try "passwd" which wont work ...
<om26er> IP for the virt manager machine
<sergiusens> nmap might
<ogra_> so not *that* obvious
<sergiusens> ogra_ because current passwd is unset/unkown
<ogra_> yeah
<sergiusens> and sudo does the trick
<ogra_> right
<om26er> ogra_, sergiusens I am in. Had to re create the VM to know my IP :)
<zyga> jdstrand: there's a chance that the test failures we saw are caused by https://github.com/snapcore/snap-confine/blob/master/spread-tests/regression/lp-1599608/task.yaml
<zyga> exactly how I cannot explain yet
<morphis_> ogra_, pitti: so who should upload https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 as a patch to netplan to the snappy ppa?
<ogra_> mvo, slangasek, hmm, the small image size made resize2fs take significantly longer :/
<ogra_> i wonder why ...
<ogra_> (the 128GB card i currently use used to resize in 1-2 min before ... now its 10min and counting with a daily image)
<mup> PR snapcraft#823 closed: plainbox-provider plugin: rewrite python shebangs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/823>
 * ogra_ goes and tries the beta image instead 
<SamYaple> sergiusens: http://paste.ubuntu.com/23220481/
<sergiusens> SamYaple ah, so it is python2 that has the issue, got it
<ogra_> bah
<ogra_> resizes instantly
<ogra_> that wasnt even 20sec
<ogra_> i guesss that means that creating images at minimal size complicates resizing
<ogra_> :(
<SamYaple> sergiusens: for dogpile.cache, yes python2 is the issue
<slangasek> ogra_: er... impressive?
<SamYaple> sergiusens: but its on a per project bases. this same thing can happen on python3
<ogra_> slangasek, why ?
<SamYaple> *basis
<slangasek> ogra_: 10 minutes to resize?  It shouldn't matter that it's on 128GB.  But I'm assuming you don't want us to revert the change to make the image small ;)
<ogra_> slangasek, i assume with the minimal size the blocksize is not exactly a multiple of 512 or some such
<ogra_> slangasek, well, i gave up after 15min ... not sure how long it would actualyl have taken
<ogra_> but using the 3.8GB big beta image resizes absolutely instantly
<ogra_> slangasek, oooh, and since i'm testing on the dragonboard ... i'm now glaring since 2min at "Contacting server..."
<ogra_> o this slowness seem to not be arch specific at all
<ogra_> *so
<ogra_> *eems
<ogra_> bah !
<ogra_> (right after i typed that the screen changed, but even on the dragonboard it is slow at the user setup tep)
<ogra_> hmm, but why is the resize so slow, there are no errors in the resize log
<ogra_> (apart ffrom the one when i ripped out the card it seems resize2fs was chugging along happily)
<mup> PR snapcraft#822 closed: Don't filter .pth files in python plugin <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/822>
 * ogra_ rolls an image with extra added empty space 
<elopio> cwayne: you did atom, right? Can you help me with an electron snap?
<cwayne> elopio: yep, sure
<elopio> cwayne: I'm getting Error: spawn electron ENOENT
<elopio> have you seen that? I'm trying adding electron to node-packages, but I have no idea what I'm doing.
<cwayne> elopio: hm, not seen that, i had to usee a custom plugin to just call scripts that atom had, so there wasnt really much dealing with electron itself
<elopio> the docs don't help much, but I clearly have nothing called electron in my prime directory. Let's see how it goes.
<ogra_> slangasek, i must admit in the light of resize times that go into the 20min area (even with an image i made look like one of the former ones) i'm tending to say we should perhaps build them in 1GB size steps instead of "as small as possible" ... this is definitely not suitable
<oparoz> Can the snap web install beta apps?
<oparoz> ...which are using devmode
<ogra_> mvo, where is the ubuntu-image patch you used to create the 3.8GB betas (you obviously didnt use the latest from trunk but also not the default 4GB one)
<ogra_> (and i cant see any change related to this in your github tree either)
<slangasek> ogra_: or, if you think this is part of it, we can tune our mkfs.ext4 options to adjust block size / cluster size / bytes per inode / inode size
<slangasek> ogra_: maybe you want to experiment with those and see which flags might make a difference to the speed?
<mvo> ogra_: its not pushed, but its just 4Gb->3.9Gb, i can push the diff if you need it
<ogra_> slangasek, well, something makes the old images do instant resize ... and even the ones that mvo built as betas which dont use your latest change
<ogra_> mvo, that would be great ... i want the dailies to not take hours while people like qengho wait for something on HDMI ;)
<ogra_> i guess *that* is the actual problem
<ogra_> (regarding the console= discussion)
<slangasek> ogra_: yes, so since you have a case where you can reproduce slow resize (is this on the BBB?), can you tweak the ext4 filesystem when you build it and see what does or doesn't improve the speed?
<ogra_> slangasek, thats the dragonboard ... but i bet we'll have iot on all images
<slangasek> ogra_: I don't have a 128GB SD card to reproduce this with
<ogra_> (i test the bbb with a 4GB card ... the resize is neglectable there)
<ogra_> slangasek, well, a 256GB one will do as well :P
<slangasek> ogra_: also, 'tune2fs -l' output on the filesystem after the resize is done, please
<ogra_> ok, will do
<mup> PR snapd#1990 opened: many: allow use of the system user assertion with create-user <Created by mvo5> <https://github.com/snapcore/snapd/pull/1990>
<abeato> ogra_, why might I see this error when doing "snap prepare-image"? :
<abeato> error: cannot fetch and check prerequisites for the model assertion: assertion not found
<ogra_> how does your assertion look like ?
<abeato> ogra_, http://paste.ubuntu.com/23220732/
<ogra_> hmm, looks fine
<ogra_> and you specified the path to it correctly in the ubuntu-image command line ?
<abeato> ogra_, yes, this it the command that fails:
<abeato> $ sudo snap prepare-image --channel=beta --extra-snaps=network-manager_1.2.2-5_armhf.snap --extra-snaps=modem-manager pi3.model /tmp/tmpqfqroa0f/unpack
<abeato> pi3.model is in the folder
<ogra_> what is /tmp/tmpqfqroa0f/unpack supposed to be
<abeato> ogra_, the actual command that is executed is:
 * ogra_ has actually never used snap prepare-image directly ... 
<abeato> $ sudo /snap/bin/ubuntu-image --channel beta --extra-snaps network-manager_1.2.2-5_armhf.snap --extra-snaps modem-manager -o pi3.img pi3.model
<abeato> ogra_, but in the end what fails is the prepare-image step
<ogra_> hmm
<ogra_> does it work if you call it completely without --extra-snaps ?
<abeato> no, not in that case either
<ogra_> did you try with edge yet instead of beta ?
 * ogra_ wonders if self signed assertions somehow block building from non-edge
<abeato> ogra_, let me try
<elopio> alright, now I don't get any errors. But also I don't get any window :(
<elopio> any electron expert around?
<abeato> ogra_, I have
<sergiusens> elopio check if one of the threads is crashing (font-config for example), glib/gtk makes many assumtions and doens't fail cleanly
<abeato> ubuntu-core          16.04.1    423  canonical  -
<abeato> doing
<abeato> $ sudo snap install --channel=edge ubuntu-core
<abeato> error: cannot install "ubuntu-core": snap "ubuntu-core" already installed
<abeato> is that fine?
<ogra_> abeato, i thik 423 is the last stable
<elopio> sergiusens: ok, how do I check that?
<elopio> I have nothing about fonts or gtk, but I can copy them from atom
<abeato> ogra_, how do I install a new one? "sudo snap install --channel=edge ubuntu-core"does not work
<sergiusens> elopio strace in a snap shell
<ogra_> abeato, hmm, whats the error, it should
<elopio> ok! I've never done that, let me find the instructions.
<abeato> error: cannot install "ubuntu-core": snap "ubuntu-core" already installed
<abeato> ogra ^^
<ogra_> abeato, though edge is quite brave, i'd go with beta
<ogra_> weird
<ogra_> thsi is how i got mine onto edge back then
<abeato> hm...
<ogra_> but that should have no influence on ubuntu-image
<abeato> ogra_, ah... I must use "refresh" instead of "install" when installed, even when trying to use a different channel :)
<ogra_> ah
<abeato> 660 rev
<ogra_> yeah, beta is fine :)
<ogra_> geez ... this resizing thing is insane ... still going ...
<ogra_> i wonder why i havent hit it earlier
<elopio> sergiusens: am I doing this right? https://paste.ubuntu.com/23220881/
<elopio> it just  seems to do nothing.
<mup> PR snapd#1991 opened: overlord,store: clean up serial-proof plumbing code <Created by pedronis> <https://github.com/snapcore/snapd/pull/1991>
<mup> PR snapd#1992 opened: overlord/state: introduce cleanup support <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1992>
<ogra_> YAY !!!
<ogra_> so this was 50min for the resize
<ogra_> finally it moved
<mup> PR snapd#1993 opened: snap: move/clarify Info.Broken <Created by pedronis> <https://github.com/snapcore/snapd/pull/1993>
<ogra_> slangasek, http://paste.ubuntu.com/23220928/
<ogra_> slangasek, also, confirmed that resizing is slow on pi3 with the small images
<slangasek> ogra_: thanks.  interesting, you have there a block and fragment size that's smaller than what I saw locally in a pi2 image... which way did you create this with ubuntu-image? the snap, the yakkety deb?
<slangasek> (or is this the official image?)
<ogra_> slangasek, trunk calling ./ubuntu-image
<slangasek> ogra_: against what release?
<slangasek> are you using xenial or yakkety e2fsprogs?
<ogra_> on a xenial host with tghe PPA ext2fsprogs version installed
<slangasek> ok
<sergiusens> elopio track the forks and make it output to separate files, much easier
<ogra_> i havent checked an actual image yet, i'll do some builds with workdir so i can inspect the img files on the weekend ... currently my machine is busy actually re-building the dailies
<elopio> sounds easy, let's see if stackoverflow knows how to do it.
<ogra_> slangasek, oh, and here is the resize log http://paste.ubuntu.com/23220950/
<slangasek> ogra_: ok.  your block size, fragment size, blocks per group, fragments per group are all smaller than what I have in the last pi2 image I created here, *with* the size minimization; so that's definitely something different, I'll see if I can reproduce this
<mup> PR snapcraft#824 opened: Add `snapcraft create-key` <Created by cjwatson> <Conflict> <https://github.com/snapcore/snapcraft/pull/824>
<slangasek> ogra_: you said "the PPA" for e2fsprogs... which ppa? I don't see e2fsprogs in snappy-dev/image or snappy-dev/tools
<ogra_> slangasek, and the resize code http://paste.ubuntu.com/23220956/ ... perhaps i'm doing something unsuitable here
<ogra_> slangasek, your ubuntu-image ppa :)
<slangasek> ogra_: I think the problem is in your initial fs creation, which doesn't match the one we had here and that yes, will have poorer performance (not just during resize, but overall)
<slangasek> ogra_: ok, I didn't assume you were using our ppa ;)
<elopio> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1583259 can we have that in the next milestone?
<mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <verification-done> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:New> <click-reviewers-tools (Ubuntu):Fix Released>
<mup> <click-reviewers-tools (Ubuntu Xenial):Fix Released> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
<ogra_> well, i didnt want to blindly install the yakkety package here :)
 * zyga has unexpected guests for the past two hours, sorry for being laggy
<ogra_> zyga, how dare you to have a social life !
<slangasek> ogra_: that should definitely give me enough to try to reproduce the problem here, thanks.  One last thing, could you kpartx -a the original image and tune2fs -l that as well, just to confirm that the weird block sizes are in the source image?
<slangasek> ogra_: and are you using the official pi2 model assertion for this or another one?
<ogra_> slangasek, yeah, waiting for my machine to be done with the image build, then i'll do the kaprtx
<ogra_> slangasek, official but you are looking at dragonboard data there
<ogra_> not pi2
<ogra_> thje only non-official assertion i use is the bbb one
<zyga> ogra_: well, social life friends just flew in from spain, on their way elsewhere, with night overlap through warsaw :)
<zyga> ogra_: when stuff is on fire like it feels now I don't like having a social life TBH
<ogra_> zyga, well, you are around til 10pm on normal days and start at 8 ... and hang around here on weekends ...  if friends come you should simply end your day
<zyga> ogra_: .... are you saying I should re-consider having a social life for a change
<ogra_> at times :)
<zyga> ogra_: I'd like to, at least, finish the week knowing that I know how the fire started
<zyga> ogra_: otherwise I will just think about it all the time anyway
<ogra_> well, go and do the fire inspection then :)
<zyga> ay :)
<oparoz_> Does snap web work? Is there documentation for it? Can it install beta snaps? Does it support devmode?
<ogra_> slangasek, http://paste.ubuntu.com/23220991/ for the kpartx bit
<zyga> oparoz_: I know some people have been working on it again lately
<zyga> oparoz_: perhaps jamiebennett knows better
<oparoz_> Thanks zyga. I'm trying to figure out how to push new apps to users of the Nextcloud Box. I'm guessing the only way right now is to tell them to use SSH?
<zyga> oparoz_: push as in remotely install?
<zyga> oparoz_: I didn't try lately, does snapweb do anything useful after being installed?
<oparoz_> zyga, Well, more as in making it available somewhere so that they can push a button and install it
<oparoz_> zyga, I saw this screenshot and want my snaps to be on there: https://insights.ubuntu.com/2016/09/22/rocket-chat-a-new-snap-is-landing-on-your-nextcloud-box-and-beyond/
<mup> PR snapcraft#825 opened: Release changelog for 2.18.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/825>
<zyga> oparoz_: I think that's just the store, if your app is in the store and has the right meta-data it will show up like that in snapweb
<zyga> oparoz_: I know there's been a lot of work put into snapweb, I don't know if it is released as stable though
<oparoz_> zyga, thanks. I just don't understand how users will get to see that page with their installed snaps. I never had to register to be able to install snaps
<kyrofa> zyga, oparoz__ I think snapweb is only in edge right now. elopio or lool might know more
<oparoz__> So basically, the screenshot in that article is something which cannot be used by Box' at this stage
<oparoz__> kyrofa, or can you get this view by SSHing and manually connecting the Box to the store?
<oparoz__> And then install Snaps on the box via the store's "Add more snaps"
<kyrofa> oparoz__, yeah, SSH in and try this: `sudo snap install --edge snapweb`
<oparoz__> OK, done.
<kyrofa> oparoz__, I don't remember what port it's on... I want to say 4200
<oparoz__> :D
<kyrofa> netstat will help
<oparoz__> you were correct :)
<oparoz__> kyrofa, unfortunately, it only lists stable snaps, so not very useful :(
<oparoz__> I mean to ask users to help test snaps
<kyrofa> oparoz__, yeah, stable snaps are the only ones that are easily discoverable in the store
<kyrofa> oparoz__, like what?
<oparoz__> transmission
<oparoz__> But I guess it also filters by arch... and I haven't created the armh yet
<oparoz__> But snap web will be very cool once stable
<kyrofa> Yeah it'd be ideal to be able to say "show me unstable snaps" or something
<oparoz__> kyrofa, yeah, or just pick the minimum level of stability
<oparoz__> I'm OK with stable and beta per example
<kyrofa> Yeah, checkboxes for "show me these channels" even
<oparoz__> Especially since we can't put devmode snaps in stable
<mup> PR snapd#1977 closed: interfaces/builtin: add network-setup-observe interface <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1977>
<attente> kyrofa, elopio, hi
<elopio> hello attente o/
<attente> :)
<attente> i'm having issues with getting the integration test for the jhbuild plugin working under travis-ci
<mup> PR snapd#1991 closed: overlord,store: clean up serial-proof plumbing code <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1991>
<attente> mostly because the tests are run as a root user in a docker instance
<mup> PR snapd#1980 closed: tests: more debug around the create-key test <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1980>
<attente> but i also saw that the cleanbuild integration test that also uses lxc is specifically disabled
<attente> so i'm wondering if that's ok to do for the jhbuild plugin test as well
<attente> basically i'm in a world of hurt trying to get it working under root when it's only meant to be run unprivileged
<kyrofa> attente, hey there!
<kyrofa> attente, I don't know the specific answer to your question, but note that the launchpad builders all run as root as well. Ideally plugins would work under root
<sergiusens> attente I've been meaning to ask, how does your jhbuild plugin going to work when we switch to containers by default to build most things?
<elopio> attente: I thought it used lxc.
<sergiusens> elopio he's thinking lxc inside docker
<attente> sergiusens: yeah... i didn't realize that was the plan. you're switching to lxc containers? there's some support for nesting i believe?
<sergiusens> attente yes there is
<sergiusens> attente I am just waiting for the network setup dilemma in lxd to be solved
<elopio> sergiusens: https://paste.ubuntu.com/23221212/ Here's my strace. I see many errors, but I'm not sure what I'm looking for.
<elopio> It seems bad that many things in electron/dist are not found.
<mup> PR snapd#1983 closed: ctlcmd: add snapctl get <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1983>
<jdstrand> zyga: fyi, https://bugs.launchpad.net/snap-confine/+bug/1626019/comments/2
<mup> Bug #1626019: Docker snap cannot start containers in Classic (but does in Core) <Snappy Launcher:New> <https://launchpad.net/bugs/1626019>
<mup> PR snapcraft#826 opened: Do not depend on Content-Length when Content-Encoding is gzip <Created by tachyons> <https://github.com/snapcore/snapcraft/pull/826>
<lool> kyrofa: snapweb >> beta + edge actually (beta images, beta snapweb) - but I think it could happily be promoted
<kyrofa> lool, awesome!
<kyrofa> lool, would be great to have it in stable
<lool> kyrofa: yeah; I wish it wasn't too late to ping mvo about it, but I'm totally +1 on it; we could promote it monday
<lool> kyrofa: I'll be at Linaro Connect next week (Vegas), if you get the chance to discuss this with him, that'd be lovely
<lool> I can do it, but I wanted to touch base with mvo before doing so
<kyrofa> lool, making a note now, you got it
<lool> s/can do it/can do the actual promotion/
<lool> <3
<kyrofa> lool, I'll tell him you +1d it but wanted to double check with him first
<lool> yeah
<lool> thanks a ton
<kyrofa> Sure thing. Good luck at linaro!
<mup> PR snapcraft#825 closed: Release changelog for 2.18.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/825>
<lpotter>  qengho, ogra_ wait what? we dont allow normal console login on rpi?!?
<qengho> lpotter: We do! We do. Or, rather, we should. We want to.
<lpotter> I see the rpi as a convergent device, instead of mobile/desktop, its convergent embedded/desktop :)
<qengho> lpotter: If it doesn't give a config prompt on the display that is built-in, it is a bug.
<qengho> lpotter: I'm trying to figure out details of it now.
<jdstrand> lool: fyi, https://github.com/jdstrand/docker-snap/tree/snappy-interfaces (updated snapcraft.yaml for new interfaces) and https://github.com/jdstrand/docker-snap/tree/workaround-lp1626019 (make docker work on classic)
<lpotter> qengho: whats the login password?
<jdstrand> lool: the 2nd has everything from the first. You'll still want to upload in devmode I think until snapd with docker/docker-support lands in xenial-updates, but hopefully this helps
<qengho> lpotter: there is no password.
<qengho> lpotter: did you configure?
<qengho> lpotter: Your username is probably your launchpad id. l-p
<lpotter> I might need to reflash. never got to see the configure screen at first boot. shut it down, changed cmdline.txt
<lpotter> ahh,ok. so it sets up the user, and no user ubuntu now?
<nacc> lpotter: yeah, i think that's correct
<jdstrand> zyga: fyi, see the trello card and bug #1626019. I thought there was some talk with you and st graber on cleaning up mountinfo so that it only head relevant entries-- if that happened I suspect docker would work without the workaround. that said, with the workaround I think the urgency is not world-burning any more
<mup> Bug #1626019: Docker snap cannot start containers in Classic (but does in Core) <Snappy Launcher:Triaged> <https://launchpad.net/bugs/1626019>
<jdstrand> ratliff, tyhicks: ^
<slangasek> ogra_: in case you didn't see the mail, https://github.com/CanonicalLtd/ubuntu-image/pull/65 awaits your testing
<mup> PR CanonicalLtd/ubuntu-image#65: Avoid wrong block sizes for an fs we'll resize on first boot anyway <Created by vorlonofportland> <Merged by warsaw> <https://github.com/CanonicalLtd/ubuntu-image/pull/65>
<tachyons_> "CompressionError: unknown compression type 'xz' " I am getting this error when I am trying to install snapcraft
<tachyons_> I installed lzma package , But no luck
<nacc> tachyons_: installing snapcraft where?
<tachyons_> nacc: my laptop
<tachyons_> ubuntu 16.04 , 64 bit
<nacc> tachyons_: sorry, the release is what i meant, i assume `apt install snapcraft` ?
<tachyons_> nacc:  sorry , while installing from github
<nacc> tachyons_: ah
 * nacc doesn't know about that, unfortunately
<nacc> but you wouldn't need lzma but xz-utils, iirc
<slangasek> tachyons_, nacc: /usr/lib/python3.5/lzma.py is part of libpython3.5-stdlib, stock in 16.04; sounds like a corrupted python install?
<nacc> yeah, seems weird either way
<tachyons_> nacc: I installed xz-util too
<nacc> tachyons_: hrm, strange! as slangasek said, it should 'just work', sorry -- you'd have to dig into what is reporting that error
<tachyons_> I have libpython3-stdlib installed , should install 3.5-stdlib too ?
<nacc> tachyons_: libpython3-stdlib depends on libpython3.5-stdlib
<tachyons_> https://paste.gnome.org/p3gijqva3
<nacc> ah
<nacc> locally compile python?
<nacc> *compiled
<tachyons_> seems like error is from python2.7 , Is it an issue with pip ?
<tachyons_> nacc: No !
<nacc> tachyons_: you might need 'python-lzma'
<nacc> for 2.7 support
<tachyons_> nacc: Already instaled , no luck
<slangasek> python2.7> none of this should be using python2
<tachyons_> I am a ruby guy  and don't have much idea about python ecosystem :-)
<slangasek> don't know how you got things into a state that python2.7 is involved
<nacc> slangasek: that was goign to be my next q
<nacc> tachyons_: snapcraft is python3 based afaict
<nacc> https://github.com/snapcore/snapcraft/blob/master/HACKING.md seems to refer to only python3 deps
<tachyons_> slangasek:  Error message showing python 2.7 , that is why I asked about that
<tachyons_> I copied steps from Hacking.md
<kyrofa> tachyons_, you might consider simply installing snapcraft, which will pull in the right deps, then just run from source
<slangasek> yes, that is the shortest path to get you going with snapcraft on 16.04
<slangasek> however, I am worried that these python2 errors imply you have damaged your 16.04 system
<nacc> tachyons_: why is your pip local to your user?
<tachyons_> kyrofa:  I already have working snapcraft installed from repo , But I need snapcraft sourcecode for some hacks
<kyrofa> tachyons_, right, I understand. I'm just saying snapcraft from source and snapcraft in the archive typically have the same deps
<kyrofa> tachyons_, you could use build-dep if you have source archives enabled, too
<tachyons_> One doubt , command is pip3 is python3 and pip is for python2, right ?
<qengho> ogra_: have you ever booted your RPi3 with release image without your serial attached?
<slangasek> tachyons_: you seem to be right about that, indeed - so HACKING.md ought to be updated
<kyrofa> tachyons_, yeah, you can probably safely ignore the HACKING.md. Just make sure the right deps are installed and run path/to/src/bin/snapcraft directly
<kyrofa> No need to install it in a venv, etc
<tachyons_> replaced pip with pip3 , Now it is working
<tachyons_> Thanks
<mup> Bug #1627175 opened: RPi3 with only HDMI attached never shows subiquity <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1627175>
<qengho> lpotter: Check this bug to see if it matches your experiences. ^
 * qengho afk a while.
<mup> PR snapd#1993 closed: snap: move/clarify Info.Broken <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1993>
<dduffey> lool, slangasek how do you turn off autopilot ... I am using  custom kernel (for a demo) and the autopilot it causing it to loose the network
<dduffey> I used to do "snappy config", but I don't see a "snap config"
<lool> dduffey: you cant
<lool> dduffey: config was not readded yet for series 16
<mup> PR snapd#1992 closed: overlord/state: introduce cleanup support <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1992>
<mup> PR snapd#1989 closed: tests: build once and install test snap from cache <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1989>
<zyga> jdstrand: I'll check that card next week; what I remebmer about this is that we now properly detach the old root but because old root is still visible we cannot really umount or detach anything else
<zyga> jdstrand: offtopic, this branch was there to test if the unexpected unmount of the core snap is caused by the test that was fiddling with cgroups: https://github.com/snapcore/snap-confine/pull/152
<mup> PR snap-confine#152: Disable failing test <Created by zyga> <https://github.com/snapcore/snap-confine/pull/152>
<zyga> jdstrand: but as you can see, it failed
<zyga> jdstrand: I'll run another pass in qemu locally (I'll switch to linode next) to try to capture syslog and snap changes when this happens
<zyga> jdstrand: but it also means that I don't reall know what is causing this to fail
<zyga> dduffey: you can disable the snapd.refresh.timer perhaps
<zyga> dduffey: (systemd level timer)
<evgenijmalanov> What i can inistall .snap files ( Ubuntu Touch device
<evgenijmalanov> .. What i can inistall .snap files ( for Ubuntu Touch device) on desktop
<qengho> evgenijmalanov: I don't understand what you want.
<mup> PR snapcraft#827 opened: Support setting build targets in the maven plugin. Make the maven pluâ¦ <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/827>
<oparoz> Does "refresh" pick up changes in the beta channel?
#snappy 2016-09-24
<mup> Bug #1627218 opened: snap refresh does not pull the latest betas <Snappy:New> <https://launchpad.net/bugs/1627218>
<neurot> If I have a program installed natively or through a PPA and I want to install the same program but newer version through Snap am I getting two of the program or am I going to get an update
<Mikaela> neurot: you get two instances, the repo/PPA version and the snap, unless something big has happened without me noticing (just a user)
<oparoz> Are symlinks between snaps blocked by some policy?
<neurot> Mikaela thank you
<Mikaela> you're welcome
<neurot> From what I understand snap packages stay in their own folder correct
<oparoz> it depends on what you mean by "stay"
<oparoz> They're installed in their own folders, split in 2-3
<oparoz> more like 2-5
<neurot> ok i have hexchat 2.12.0 installed (ppa) and unofficial-hexchat 2.12.1 (snap) how can I run the unofficial hexchat
<neurot> sorry I'm new to snaps
<niemeyer> neurot: You should have /snap/bin/unofficial-hexchat*
<neurot> ok thank you
<oparoz> Are the plugs global to the snap or is Snappy really looking at which command is authorised to use a plug?
<mup> Bug #1627309 opened: bluetooth-control noble.js not working <Snappy:New> <https://launchpad.net/bugs/1627309>
<oparoz_> :S the content interface needs a serious redesign
<oparoz_> It doesn't make sense to land on the ro partition when giving read-write access
<mup> Bug #1627338 opened: Content interface needs a redesign <Snappy:New> <https://launchpad.net/bugs/1627338>
<popey> ogra_: you will be pleased to hear I have purchased a serial cable :)
<berker_> Hi
<berker_> I just installed snappy on my raspberry pi 2
<berker_> Did a sudo apt-get dist-upgrade
<berker_> Afterwards i did a reboot
<berker_> It seems like its not connected to the internet anymore...
<berker_> when i do sudo apt-get update, it gives me unable to resolve host ubuntu: connection refused
<berker_> I will very much apreciate if you could help me
<berker_> I'm traying since yesterday, followed the steps written on https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<berker_> It doesn't work.. or something is wrong with the image
<BlackStouse> Hi there!
<BlackStouse> I'm trying to use "snap install rocketchat-server" and i'm receiving a 401 http response code
<BlackStouse> https://imgur.com/a/AryVl
<BlackStouse> Thats the error
<BlackStouse> Can anyone help me?
<berker_> how can i set max usb current on snappy?
<berker_> there is no boot config
<BlackStouse> I'm trying to use "snap install rocketchat-server" and i'm receiving a 401 http response code
<BlackStouse> https://imgur.com/a/AryVl
<BlackStouse> Anyone can help me?
<BlackStouse> I'm trying to use "snap install rocketchat-server" and i'm receiving a 401 http response code
<BlackStouse> https://imgur.com/a/AryVl
<BlackStouse> https://imgur.com/a/AryVl
 * ogra_ applauds popey 
<Gesic> Hello, i tried to install Snappy on a raspi3 but I can't get past the rainbowscreen.
<Gesic> pi
#snappy 2016-09-25
<mup> PR snapd#1978 closed: interfaces/builtin: allow network-manager to access netplan conf files <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1978>
<techraf> join #gitlab
<dz0ny_> ogra_: hi, I tried both your ubuntu-core(daily and 16sep one) images for rpi3 and none goes past systemd init
<dz0ny_> current fails with cannot write hostname to writable partition
<dz0ny_> and 16.sep one boots to berry logo...
<dz0ny_> know issues or?
<niemeyer> dz0ny_: ogra_ might be the best person to talk to, but he might not be around today
<ogra_> funny that you say that :)
<ogra_> dz0ny_, i just tried the pi3 image today and itworked just fine ... weird
<ogra_> dz0ny_, there seems to be an issue if you do not have a netwiork cable plugged in (seemingly the kernel oopses if it tries to init the wlan) make sure you have that wired up
<ogra_> dz0ny_, and seeing a comment on a bug from qengho the image seems to have worked for him too ... so we need more details about your specific setup (SD card, what peripherials are connected and how)... best woould be if you file a bug (assign it to me if you can) and attach a picture of the screen or some such
<qengho> dz0ny_: where did you get that daily from?
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ should definitely work atm.
<dz0ny_> ogra_: eth connected same result, boots to 4 berries
<dz0ny_> I tested on http://people.canonical.com/~ogra/snappy/all-snaps/daily/20160924.2/ubuntu-core-16-pi3.img.xz
<dz0ny_> http://people.canonical.com/~ogra/snappy/all-snaps/u-image-pi3.img.xz
<ogra_> uhh, i need to delete tha latter, thats old crap
<dz0ny_> testing eth  + http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-pi3.img.xz now
<dz0ny_> btw ext4 partition should be mountable?
<dz0ny_> on image or not?
<ogra_> yeah, 20160924.2 does not have the fix, only 20160925.1 does (which is the current "current"
<ogra_> )
<dz0ny_> lucky me :)
<ogra_> the writable partition should always be mountable, else it wouldnt boot ;)
<dz0ny_> ogra_: http://i.imgur.com/ExBodCA.png
<dz0ny_> hm
<qengho> I just re-verified the ogra pi3 that was online 2 hours ago is good for me.
<dz0ny_> I tried two cards, enve usb key
<dz0ny_> even*
<dz0ny_> 287b8e735f9e6436c5e7954c1f6a3ce450178c7185741b91dcdd3229851432be  ubuntu-core-16-pi3.img.xz (current)
<dz0ny_> can someone confirm that
<ogra_> ogra@anubis:~/datengrab/images/snappy$ md5sum daily/20160925.1/ubuntu-core-16-pi3.img.xz
<ogra_> a1abfa8b042c024023cc0e3efe8747d7  daily/20160925.1/ubuntu-core-16-pi3.img.xz
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sha1sum daily/20160925.1/ubuntu-core-16-pi3.img.xz
<ogra_> 3d954eb76a05d4e3eeab4340df7fca34acff0b01  daily/20160925.1/ubuntu-core-16-pi3.img.xz
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sha512sum daily/20160925.1/ubuntu-core-16-pi3.img.xz
<ogra_> 12175889843c093f6629d2a86f5e6cf1eabf3c250ac7a4dafac080fa54247b86fb5de1543f94d6686b45f5aecdfe48162f73760e6166b402e73bd6cd70497858  daily/20160925.1/ubuntu-core-16-pi3.img.xz
<ogra_> ogra@anubis:~/datengrab/images/snappy$
<ogra_> the checksumes are also in the dir
<ogra_> **checksums
<ogra_> that looks like your download is corrupt or some such
<dz0ny_> worked fine on first boot, went thru "install" & store info
<ogra_> cool
<dz0ny_> rebooted it, then this https://ton.twitter.com/i/ton/data/dm/780106986687963140/780106986713210881/1iZwh1Ki.jpg:large
<ogra_> you waited until you had the "finish" button ?
<dz0ny_> yep
<ogra_> (the store stuff takes between 5-10 min)
<dz0ny_> hm :)
<dz0ny_> it was faster
<dz0ny_> let me try again
<ogra_> welll, perhaps a bit less ...
<ogra_> serveral minutes
<ogra_> the twitter link is broken, doesnt show anything
<dz0ny_> ogra_: http://imgur.com/a/EFWL7
<ogra_> network cable still plugged in ?
<dz0ny_> yep
<dz0ny_> I glanced starting snappy setup then poof
<ogra_> i have only seen it oopsing on tteh wlan device (will discuss that with paolo tomorrow)
<ogra_> can you ssh in ?
<dz0ny_> I'll get serial console tomorrow so you can have full log
<dz0ny_> ogra_: starting from scratch now :)
<ogra_> what kind of SD card is that btw
<dz0ny_> san disk ultra 16gb
<dz0ny_> 10Mb class
<ogra_> souds ok
<dz0ny_> https://i.imgur.com/lTjkXis.jpg
<ogra_> that looks good
<dz0ny_> ogra_: so at this point is it expanding sdcard and downloading something?
<ogra_> it actually only downloads your ssh key from launchpad
<ogra_> and adds a user without passworrd to the system
<dz0ny_> ahh
<dz0ny_> yep this did not happen last time
<ogra_> ?
<dz0ny_> maybe add github support?
<ogra_> there is no viasual indication of what it does
<ogra_> it does that in the background and then shows the "finish" screen
<dz0ny_> the started notify bootloader.. unit never ran
<dz0ny_> mhm
<ogra_> i have seen that on slow SD cards there are still some systemd jobs running afterwards, so give it time ...
<ogra_> never just power it off, only reboot from the ssh login
<dz0ny_> https://i.imgur.com/EZkcyxD.jpg
<dz0ny_> yep never did
<ogra_> beyond that it should work fine, surely did here for several tests
<dz0ny_> barfed again just after i pressed enter
<ogra_> anyway, my GF slays me if i dont go afk now :)
<dz0ny_> (finsih button)
<dz0ny_> ogra_: go :D
<ogra_> i'm around tomorrow :)
<dz0ny_> k:)
<mup> PR snapd#1985 closed: progress: use New64 and fix output newline <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1985>
<mup> PR snapd#1957 closed: many: add support for installing/removing multiple snaps <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1957>
<mwhudson> grr the 96boards uart serial thingy doesn't work with my dragonboard either
<mwhudson> i guess it must be a board problem
<mup> PR snapd#1878 closed: snap: add `snap download --assertion model/16/canonical/pc-amd64` support <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1878>
#snappy 2017-09-18
<zyga-ubuntu> mvo: hello
<zyga-ubuntu> mvo: how are you doing?
<zyga-ubuntu> mvo: I updated the mini-lab, the dragon board now has a HDD and swap so should be suitable for more tasks
<mvo> hey zyga-ubuntu - good monring. I'm doing well, how are you?
<zyga-ubuntu> mvo: I also made ssh keys sync hourly, though not to each device yet (just to the ssh hop)
<zyga-ubuntu> mvo: I'm iterating on layouts and feeling good :-)
<zyga-ubuntu> mvo: the damp weather is a good motivator to keep warm and code :)
<zyga-ubuntu> mvo: I will also add power control to dragon-1, it's already wired but not scripted yet
<zyga-ubuntu> mvo: how are your purchases going?
<zyga-ubuntu> mvo: while not perfect I found a working way to have home on an external HDD on ubuntu core
<mvo> zyga-ubuntu: nice progress! no news on purchases, still pondering
<zyga-ubuntu> mvo: same with swap support
<mvo> zyga-ubuntu: oh, nice, how do you do it?
<zyga-ubuntu> mvo: I created two systemd mount units
<zyga-ubuntu> mvo: ssh and have a look, it's remarkably working fine :)
<zyga-ubuntu> mvo: I ran some tests on it overnight and I have an idea
<zyga-ubuntu> mvo: when idle it could just pull master and run tests in a loop
<zyga-ubuntu> mvo: and report failures
<zyga-ubuntu> mvo: I saw a few things like "settle" something fail because of timing
<zyga-ubuntu> mvo: also noticed that the board only reports 0.7GB RAM, I suspect the rest is used up by GPU, modems and what not
<zyga-ubuntu> mvo: and I wanted to ask ogra if that could be tweaked for a headless builder
<mvo> zyga-ubuntu: interessting. I have a look in a bit once I finished look at PRs, mail etc :)
<zyga-ubuntu> mvo: sure :)
 * zyga-ubuntu -> breakfast
<sborovkov> ogra_: btw. commenting out that stuff in the psplash.c. It actually does not disable psplash-write. So may be you should disable it as well. When psplash-write is called text is drawn just as expected.
<zyga-ubuntu> re
<zyga-ubuntu> pstolowski: hello
<zyga-ubuntu> pstolowski: question, there's a debian bug report about missing manual page for snapctl
<pstolowski> zyga-ubuntu, good morning!
<zyga-ubuntu> pstolowski: would you like to write one in restructured text like some of our other manual pages?
<pstolowski> zyga-ubuntu, sure. do we generate man pages from built-in help?
<zyga-ubuntu> pstolowski: I think that's largely insufficient, look at the manual page for snap-confine for instance
<zyga-ubuntu> pstolowski: the help part is really one element
<pstolowski> zyga-ubuntu, ok, will do, just looked at .spec for fedora and saw man page generated from snap --man tere
<pstolowski> *there
<zyga-ubuntu> pstolowski: that's not the same, again
<zyga-ubuntu> pstolowski: unless you have 10s of options I really strongly encourage you to write it manually
<pstolowski> zyga-ubuntu, okay. snap-confine.rst it is
<zyga-ubuntu> pstolowski: thanks, I'll gladly help if you need anything
<pstolowski> thanks zyga-ubuntu
 * zyga-ubuntu fights the 14.04 battle
<zyga-ubuntu> mvo: would it be possible to build snapd with golang 1.6 like on 16.04?
<zyga-ubuntu> mvo: I just got a failure about C99 constructs that are probably because of older golang defauls
<mvo> zyga-ubuntu: on 14.04? we use a backported go-1.6
<mvo> zyga-ubuntu: bug of course there is an older gcc there
<zyga-ubuntu> mvo: aah
<zyga-ubuntu> mvo: that makes sense!
<zyga-ubuntu> thank you
<zyga-ubuntu> well, one more rn
<zyga-ubuntu> *run
<ogra_> zyga-ubuntu, you can turn off the GPU ram but wont be able to run accellerated graphics stuff... just drop the last line in /booot/uboot/config.txt
<zyga-ubuntu> ogra_: oh, thank you
<zyga-ubuntu> ogra_: do you think that would make sense as a core config option?
<ogra_> sborovkov, perfect, yeah, i''ll do that
<ogra_> zyga-ubuntu, probably ... we need to have it on by defautl so trhat mir works thugh
<zyga-ubuntu> ogra_: yes, certainly
<zyga-ubuntu> ogra_: I don't have /boot/uboot/config.txt - just uboot.env which is binary
<ogra_> zyga-ubuntu, bah, sory, i mis-read
<ogra_> i thougth you were n a Pi
<zyga-ubuntu> aha, right
<ogra_> i dont think there is a way to tune that on a dragonboard
<zyga-ubuntu> ogra_: ok, thanks
<ogra_> despite using your own patched kernel or so
<zyga-ubuntu> one of those days we will get sodimms on the devkits :)
<ogra_> zyga-ubuntu, also ... the dragonboard is am64 ... the ram is not really eaten by GPU but by the fact that your binaries are about 1/3 bigge in ram
<ogra_> arm64 on small boards is a massive insanity
<zyga-ubuntu> ogra_: oh? why does linux report 0.7GB memory total then?
<ogra_> (especially if the same board can run 32bit and eat half the ram in the end)
<ogra_> well, part of it is surely GPU ... but you will also use massively more ram for the binaries
<zyga-ubuntu> sure but it looks like 0.3 is just reserved up front
<ogra_> yeah
<ogra_> as i said, i dont think thats tunable
<ogra_> despite recompilling parts
<mup> Issue snapcraft#1543 closed: Unable to specify make arguments <Created by akashrajkn> <Closed by akashrajkn> <https://github.com/snapcore/snapcraft/issue/1543>
<ogra_> just a FYI ... htop in a beaglebone repts 48MB in use on a idle system ... with the same set of snaps installed, htop on rteh dragonboard reports 122MB
<ogra_> (there is some minimal overhead because the dragonboard uns wpa_supplicant and stuff, but you get the difference between arm64 and armhf)
<sborovkov> ogra_: hi :) so from that script you provided me for using on the first boot. File system is always available? I am a bit confused about what's going on there.. I tried this if [ ! -d "/root/system-data/var/snap/screenly-client/" ] ; then psplash-write.... And checking for snap.json file. Somehow it executes that line on every boot :-(
<ogra_> sborovkov, oh, sorry, i improved that a lot already ... one sec. let me dicg it up
<ogra_> sborovkov, checking for state.json is the best thing to do here http://paste.ubuntu.com/25563809/
<ogra_> sborovkov, it works fine here
<ogra_> (only shows on first boot)
<sborovkov> great.
<sborovkov> thanks
<ogra_> :)
<sborovkov> I was checking it with -f
<sborovkov> not sure why it shows up every time
<sborovkov> ah
<sborovkov> cause I did not check for /root/writable
<sborovkov> but /root/system-data instead
<ogra_> ah, yeah
<Chipaca> in the forum, when something is fix-committed, do i do anything or do i leave it on upcoming?
<Chipaca> do i leave myself tagged in it?
<ogra_> isnt there ar "solution" tag that seta a gee checkmark and such ?
<ogra_> *sets
<ogra_> *green
<pedronis> Chipaca: I think we remove upcoming and name only when is fix-release
<pedronis> d
<Chipaca> k
<pedronis> Chipaca: unless is some kind of code reorg/internal feature, then probably landing to master is enough
<mwhudson> zyga-ubuntu: did you see that maciattobin board thing?
<mwhudson> zyga-ubuntu: that looks like an arm64 device you could use without endless swearing
<zyga-ubuntu> mwhudson: yeah but it's not a ref device, I would probably consider getting one of the server boards if that was one
<mwhudson> true
<zyga-ubuntu> mwhudson: (one of the older armv8 server boards with DDR slots and sata and everything)
<mwhudson> which of those?
<zyga-ubuntu> mwhudson: any that's available :)
<mwhudson> ah heh
<zyga-ubuntu> mwhudson: it would be interesting to have an UEFI device
<Chipaca> zyga-ubuntu: mwhudson: and the OpenQ 820?
 * Chipaca doesn't know what makes something a 'reference device'
<zyga-ubuntu> Chipaca: our decision
<Chipaca> ah :-) ok
<zyga-ubuntu> Chipaca: btw, can you perhaps ssh into office.zygoon.pl?
<Chipaca> I dunno
<Chipaca> properly get cooties
<zyga-ubuntu> I wanted to check if this works for you
<mwhudson> zyga-ubuntu: that's still a mobile phone cpu isn't it?
<zyga-ubuntu> mwhudson: ye
<Chipaca> zyga-ubuntu: what's your fingerprint?
<mwhudson> zyga-ubuntu: at least it has usb 3 and pcie so the fastest io probably isn't the wifi :)
<Chipaca> (i read about the macchiatobin and the 820 reading about arm64 laptopts)
<zyga-ubuntu> 256 SHA256:C3V0UBPGQHPToLeX/qcEAAGX02XbbwHDx0zQkVQtM74 mini (ECDSA)
<zyga-ubuntu> 2048 SHA256:x4RFVP/TtE/nLtJ2WUO3dlLsavKWny7qeXNR1gHL3HA mini (RSA)
<zyga-ubuntu> 256 SHA256:adjGbm4pxRSXYErI0y/bnQeaeJqCDfJKYPHPDLQxKoM mini (ED25519)
<Chipaca> https://lwn.net/Articles/733837/
<mwhudson> oh wait, last two comments should have been at Chipaca :)
<Chipaca> mwhudson: :-)
<Chipaca> zyga-ubuntu: i'm in
<Chipaca> zyga-ubuntu: minicom says i can't use the serial port
<zyga-ubuntu> Chipaca: can you ssh into dragon-1 now
<zyga-ubuntu> Chipaca: oh, I'll adjust that
<zyga-ubuntu> Chipaca: you should be good now, also you should be able to hop onto dragon-1
<Chipaca> zyga-ubuntu: the pi3 asks me for my password
<Chipaca> zyga-ubuntu:  the dragon works
<zyga-ubuntu> Chipaca: yes, pi is not configured yet, when I have more time I'll improve the script that sets this up to push accounts there as well
<zyga-ubuntu> Chipaca: I mainly wanted to make the dragon available as most people have a working PI already
<Chipaca> ah ok
<zyga-ubuntu> Chipaca: and the dragon is a hit and miss it seems
<zyga-ubuntu> Chipaca: feel free to use that any time
<Chipaca> zyga-ubuntu: i can confirm minicom now lets me talk to the dragon
<zyga-ubuntu> Chipaca: nice
<Chipaca> zyga-ubuntu: why minicom and not screen, btw?
<zyga-ubuntu> Chipaca: I will add a way to power the device on and off from mini
<zyga-ubuntu> Chipaca: screen was corrupting input heavily
<zyga-ubuntu> Chipaca: and minicom was solid
<zyga-ubuntu> Chipaca: no idea, try screen
<zyga-ubuntu> Chipaca: I also like minicom :)
<Chipaca> :-)
<mup> PR snapd#3930 opened: cmd/snap-repair: integrate root public keys for repairs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3930>
<mup> Bug #1717857 opened: UDisks2 interface restricts sending DBus.Properties.Get message from the client to udisksd service <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1717857>
<mup> PR snapd#3931 opened: interfaces/builtin: allow receiving dbus messages <Created by zyga> <https://github.com/snapcore/snapd/pull/3931>
<mvo> zyga-ubuntu: hm, is 3931 a regression?
<zyga-ubuntu> mvo: no, it's an old bug
<mvo> zyga-ubuntu: interessting that we have not gotten bugreports earlier
<zyga-ubuntu> mvo: yep, looks like nobody really tried tihs
<ogra_> ppisati, i have been getting reports about SD corruption lately and i think we are hitting https://github.com/raspberrypi/firmware/issues/397#issuecomment-219287224 with some newer SD cards ... i suspect we'll need to collect some data and will need to ship some quirks like https://github.com/respeaker/openwrt/blob/master/target/linux/brcm2708/patches-4.4/0354-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch
<ogra_> ppisati, that is raspi2 only though
<ogra_> (i'm still collecting info, just a FYI)
<ppisati> ogra_: kernel version?
<ppisati> ogra_: and we already have those quirks applied
<ppisati> ogra_: i'm interested to know, if they experienced this on a 4.4.0-1071.79+ version
<pedronis> mvo: IÂ just noticed reading the topic that the plan was that the script would just call 'repair' (not 'snap-repair')Â using some kind of symlink, it's a bit annoying but makes sense
<mvo> pedronis: I was looking at the summary in the snap-repair show and was wondering if it makes sense to include the summary into the log output, it would make it easier for humans to inject the snap-repair directories using find/less/grep
<mvo> pedronis: re 'repair'> sure, I can create a symlink
<pedronis> mvo:   we could, a bit of a question of how to format it there
<pedronis> and how to present this in show itself
<mvo> pedronis: yeah, I was thinking a tiny header like: "repair: canonical-1\nsummary: repair one\noutput:..." and we can/could either show in snap-repair show (even though slightly redundant) or just filter out in the command
<mvo> pedronis: feels nice to have the relevant info in the file itself, was thinking e.g. filesystem corruption where fsck might not reconstruct the filename but the content. anyway, maybe overthinking this
<zyga-ubuntu> hmm
<zyga-ubuntu> Unpacking manpages-dev (4.13-2) ...
<zyga-ubuntu> dpkg: error processing archive /tmp/apt-dpkg-install-FOEqdJ/39-manpages-dev_4.13-2_all.deb (--unpack):
<zyga-ubuntu>  trying to overwrite '/usr/share/man/man4/console_ioctl.4.gz', which is also in package manpages 4.10-2
<zyga-ubuntu> must be my lucky day
<zyga-ubuntu> the systemd-virt-detect bug fixed itself
<zyga-ubuntu> and now this strikes back from hell
<mvo> pedronis: I will modify 3925 to create a dir with "repair" that symlinks to snap-repair and have that in PATH. we only need one,right? i.e. not snap-repair and repair (both names) for the repair script?
<pedronis> mvo: yes, sounds rights
<pedronis> *right
<mvo> ta
<ogra_> ppisati, it is the curent pi2-kenel snap, namely AlbertA and bschefer are using the same SD type and brand and both have a corrupted booot pattiion after every core upgrade (which means daily if you use the edge channel... )
<ogra_> ppisati, some 32GB sandisk ... i'm waiting for them to get online to get the manfid and stuff
<ppisati> ogra_: 4.4.0.1071.71 - edge
<ogra_> (sadly i shuffled the card into another board and cant currently use it in the pi)
<ppisati> ogra_: then no, it is not what i think
<ogra_> it seems to be oonly a small set of SDs but i hear about it regulary from users
<pedronis> mvo: about summary in output, I think it makes sense,  just a bit wondering that it would be best to strip it out in show and have it separate, but we need to think what to do about newlines
<ogra_> ppisati, and i know we already have a quirks patch ... i just think it needs to cover some more cards
<ppisati> ogra_: ack, is there a way to reproduce it?
<ogra_> ppisati, for bschefer and AlbertA the overlays subdir on the boot partition gets messed up so the kms dtb doesnt get loaded and they end up without /dev/dri ... for them this is reproducable with every update
<ogra_> foo me on my card it used to be uboot.env that got corrupt, also reliably with every update
<mvo> pedronis: yeah, I will ponder a bit
<ogra_> ppisati, my idea was to cllect their SD data, and let them try a patched kenel t see if it help ... but the behaviour sounds suspiciously like the erase issue from above
<ogra_> (specifically because they both have the same card exposing the same issue 100% of the time)
<mup> PR #100: Ongoing work on the capability APIs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/100>
<ogra_> *** baa-dum tish ***
<ogra_> zyga-ubuntu wins the price fr the 100st PR !!!
 * ogra_ throws confetti
<ppisati> ogra_: makes sense - do you have an old edge image around? so i can try with some sd cards here, and to some update cycles
<ogra_> ppisati, http://people.canonical.com/~ogra/snappy/all-snaps/daily/ just pick an old one there
<zyga-ubuntu> heh :-)
<ppisati> ogra_: cool, will do - pi2 or pi3?
<ogra_> ppisati, pi3 here but i bet it doesnt matter
 * zyga-ubuntu tries a fix for the debian bug and goes to make more tea
 * zyga-ubuntu itereates on manpages bug
<zyga-ubuntu> and while spread runs let's test Fedora 25 update
<zyga-ubuntu> mvo: that's something for you
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3932
<mup> PR #3932: spread: work around temporary packaging issue in debian sid <Created by zyga> <https://github.com/snapcore/snapd/pull/3932>
<zyga-ubuntu> mvo: locally still going
<mup> PR snapd#3932 opened: spread: work around temporary packaging issue in debian sid <Created by zyga> <https://github.com/snapcore/snapd/pull/3932>
<mup> PR snapd#3933 opened: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>
<mvo> zyga-ubuntu: ta
<zyga-ubuntu> mvo: tests are rolling so I think this is a good fix
<ppisati> $ snap list
<ppisati> No snaps are installed yet. Try "snap install hello-world".
<ogra_> ppisati, hrm
<ppisati> ogra_: pi3 image of 3 days ago, i feel confused
<ogra_> ppisati, sounds like fixrct didnt run
<ppisati> 14 of sept image
<zyga-ubuntu> darn, I ran out of disk space
<ogra_> ppisati, very weird, i tested them after fixrtc got fixed again
<ogra_> oh ... one sec
<ppisati> ogra_: let me try with the 15th and 16th of sept image
 * ogra_ checks if edge actually has the latest kernel 
<ogra_> hmm, no, latest kernel there
<ogra_> i thought perhaps edge would be behind
<mvo> pedronis: do we allow newlines in the summary currently?
<zyga-ubuntu> Son_Goku: thank you for pushing the 2.27.6 release out
<Son_Goku> my 2.27.6 is special, though :)
<zyga-ubuntu> Son_Goku: yes, I know :)
<Son_Goku> it's better than all the other snapd 2.27.6 :)
<zyga-ubuntu> Son_Goku: I'm testing it on F25 now
<zyga-ubuntu> Son_Goku: though it's out already I wanted to finish it
<zyga-ubuntu> Son_Goku: sorry for being slow, the weather is getting the better of me :/
<Son_Goku> it's fine
<zyga-ubuntu> how are you doing?
<pedronis> mvo: in principle yes, we don't check for them not to be there?Â we could prohibit them in asserts/repair.go if we want
<Son_Goku> zyga-ubuntu: alright I suppose
<ogra_> zyga-ubuntu, you should use stgraber's in-browser terminal that he uses for https://linuxcontainers.org/lxd/try-it/ and hook that up to native containers on the pi and dragonboard ;)
<ogra_> (for your device lab that is)
<zyga-ubuntu> ogra_: is there a snap for the client part?
<ogra_> no idea :)
<zyga-ubuntu> ogra_: I've redirected ports for mosh but I don't think we have a working mosh snap
<ogra_> but that sounds like an awesome spare-time project :)
<zyga-ubuntu> ogra_: but you can mosh into the mac mini allright
<ogra_> having a central website to try ubuntu core in a browser on specific supported boards
<zyga-ubuntu> ogra_: I need to get a 2nd hand desk rack
<zyga-ubuntu> ogra_: I will add my other boards there but I have no space to make this reliable now
<zyga-ubuntu> ogra_: btw, how do you power the dragon board?
<zyga-ubuntu> ogra_: I've set 12V and 2A
<ogra_> yeah, that should be fine
<zyga-ubuntu> ogra_: I wonder what the on-board regulators do
<ogra_> the 96boards boards all support 12-19V iirc
<zyga-ubuntu> ogra_: is thre an optimal value that produces least waste heat
<ogra_> i think 12V/2A is fine
<ogra_> not sure how much lower you can go, there is a lot HW on the dragonboard
<zyga-ubuntu> ogra_: fun fact
<zyga-ubuntu> ogra_: I powered it last week using the PSP power adapter
<zyga-ubuntu> ogra_: that's 5V
<ogra_> https://www.96boards.org/product/power/
<ogra_> "The 96Boards CE boards require an 8-18V 2A power supply."
<ogra_> so you were lucky i guess :)
<zyga-ubuntu> well now it should be solid :)
<zyga-ubuntu> I was thinking about setting the limit to 3A
<zyga-ubuntu> but even under load I see at most 0.5A
<tbr> fun fact: the spec was *specifically* written to exclude powering it from USB/5V "because that's just too weak"
<ogra_> because you are not using all HW ... iirc there is GPS and such
<tbr> also hook up some USB devices that go to full spec load of 0.5A
<ogra_> yep
<zyga-ubuntu> tbr: it powers an external HDD using two USB ports
<zyga-ubuntu> tbr: but now it's on 12V/2A supply
<ogra_> the 12/2 thing will guarantee that it stays fully functional if all onboard HW is powered and used
<tbr> and all USB ports used
<tbr> power budget is always spec'd to full load *everything* and a bit of safety margin (at least one would hope)
<ogra_> right
 * Chipaca grabs the painkillers and heads back to bed
 * zyga-ubuntu hugs Chipaca 
<zyga-ubuntu> Chipaca: stay strong, it's not even winter yet
<Chipaca> heh
<Chipaca> zyga-ubuntu: it's my back having a bad day, is all
 * zyga-ubuntu reads https://www.securecoding.cert.org/confluence/display/c/MSC06-C.+Beware+of+compiler+optimizations
<Chipaca> i must've done something unexpected over the weekend
<zyga-ubuntu> Chipaca: ouch, even more sympathy then :/
<Chipaca> like, the dishes /o\
<zyga-ubuntu> I know how bad that is
<mup> Bug #1710637 opened: Input falls through to gdm3 and terminates the session on Ctrl+C <amd64> <apport-bug> <artful> <gnome-17.10> <rls-aa-incoming> <wayland-session> <Snappy:New> <console-setup (Ubuntu):Fix Released> <gdm3 (Ubuntu):Incomplete> <gnome-shell (Ubuntu):Incomplete> <mutter
<mup> (Ubuntu):Incomplete> <https://launchpad.net/bugs/1710637>
<zyga-ubuntu> whaat?
<ogra_> check the desktop channel :)
<zyga-ubuntu> mvo: hey, just FYI in case it blows up on us: https://forum.snapcraft.io/t/snap-remove-somesnap-triggers-keyboard-input-fallthrough-to-vt-ctrl-c-in-terminal-logs-out-of-current-gdm-session/2162/6 and https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1710637 -- we may need another release for that
<mup> Bug #1710637: Input falls through to gdm3 and terminates the session on Ctrl+C <amd64> <apport-bug> <artful> <gnome-17.10> <rls-aa-incoming> <wayland-session> <Snappy:New>
<mup> <console-setup (Ubuntu):Fix Released> <gdm3 (Ubuntu):Incomplete> <gnome-shell (Ubuntu):Incomplete> <mutter (Ubuntu):Incomplete> <https://launchpad.net/bugs/1710637>
 * zyga-ubuntu breaks for lunch before standup
<ackk> niemeyer, when you have time, could you have a look at https://github.com/snapcore/snapd/pull/3916 for the addition to the snap.yaml content for apps?
<mup> PR #3916: add support for socket activation in apps <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<zyga-ubuntu> jdstrand: hello
<zyga-ubuntu> jdstrand: thank you for the review, I pushed more things and I think it's ready for re-review
<zyga-ubuntu> jdstrand: I'd like to start proposing new PRs instead of iterating on this one as it's veryt hard to keep track of everything
<jdstrand> zyga-ubuntu: I'm done with my big reviews, so anything extra is just making sure what I commented on is done
<jdstrand> zyga-ubuntu: I assume you are talking about PR 3621?
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<jdstrand> zyga-ubuntu: that PR is tricky because we are doing retroactive reviews. ie, it is arguably fine when not called from snap-confine but when called from snap-confine, needs changes
<zyga-ubuntu> jdstrand: yes
<zyga-ubuntu> jdstrand: let's mark it as good then
<zyga-ubuntu> jdstrand: and land it :)
<zyga-ubuntu> jdstrand: I just cannot land it before you agree
<jdstrand> but anyway, like I said, I finished the big reviews, all that is left is making sure that comments are addressed, so I think it will be mergeable soon
<zyga-ubuntu> thank you
 * jdstrand nods
<ogra_> ppisati, did you get anywhere with the newer images ?
<ogra_> koza, hmm, https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/reference/sending-files#receiving-files ... it doesnt seem like the mentioned "bluez-test" snap from there is in the store
<ogra_> *bluez-tests
<ppisati> ogra_: yes, so all the available daily (14/15/16 of sept) behave the same - snap list is empty
<ppisati> ogra_: but when installing the hello world snap, tra triggered the update of core
<ppisati> ogra_: so it did the update and rebooted fine
<ogra_> ppisati, seems the builder was stuck, there are new images nnow
<ppisati> $ snap list
<ppisati> Name         Version    Rev   Developer  Notes
<ppisati> core         16-2.27.6  2849  canonical  core
<ppisati> hello-world  6.3        27    canonical  -
<ogra_> ppisati, no, thats completely broken
<ppisati> ogra_: yeah, it should show more snaps, but i was looking after the corruption
<ogra_> ppisati, the device didnt get initialized ... else you would see the gadget and kernel snap in list ... what you have there is simply snapd that pulled in *another* core to be able to run hello-world
<ogra_> ppisati, well, lets wait for bschaefer or AlbertA ... they can definitely reproduce 100%
 * ppisati tries the new daily
<ogra_> ppisati, in the case where you have an uninitialized image an upgrade wont actually upgrade the bootloader bits (because the image simply doesnt know about the bootloader) ... so thats pretty different
<ogra_> on proper images a core update re-writes the bootloader config
<ogra_> and thats where the corruption usually happens ... the vfat seems to be more prone to corruption than the ext4 partition in that case
<ppisati> ogra_: the latest daily (18 of sept) is good, snap list report a list of snaps
<ogra_> phew
<ogra_> so the stale builds used soome old kernel before the no-change rebuild
<ppisati> $ snap refresh core
<ppisati> snap "core" has no updates available
<ogra_> yeah ...
<ogra_> do "snap refresh core --stable"
<ogra_> that force-switches the channel so it will definitely up/downgrade
<ppisati> ogra_: did it, it rebooted fine and i'm back in - mmcblk0p1 is mounted and i can see its content
<ogra_> ppisati, great
<ogra_> ppisati, so your SD isnt affected
 * ppisati tries with another sd card, just in case...
 * zyga-ubuntu forgot about his daughter because of the 2nd call
<zyga-ubuntu> pstolowski: hey
<zyga-ubuntu> pstolowski: I'll gladly help you on that effort
<zyga-ubuntu> mvo: can we land https://github.com/snapcore/snapd/pull/3932?
<mup> PR #3932: spread: work around temporary packaging issue in debian sid <Created by zyga> <https://github.com/snapcore/snapd/pull/3932>
<zyga-ubuntu> jdstrand: thank you for a re-review
<pedronis> zyga-ubuntu: pstolowski: a bit worried that this will mean even more Plug/SlotInfo around and that will be confusing
<zyga-ubuntu> pedronis: if we add a interfaces.Connection type that stores PlugInfo, SlotInfo pointers nothing will (yet) change
<zyga-ubuntu> pedronis: then some reshuffling to represent things this way
<zyga-ubuntu> pedronis: as long as we don't land the plugdata branches it should not get more confusing than it is now
<zyga-ubuntu> jdstrand: I didn't miss those btw, I was still under the impression that those can be merged separately
<zyga-ubuntu> jdstrand: (so that this PR can land)
<zyga-ubuntu> jdstrand: but I can make them here as well if you think this is necessary
<mvo> zyga-ubuntu: is there a bts bug already about this issue in debian? if so, I think we should include a link to that so that we can remove this workaround once its fixed
<pedronis> zyga-ubuntu: well we have things like Plugs()  []*Plug,  Plug have identity sort of, PlugInfo don't
<zyga-ubuntu> mvo: I didn't look
<zyga-ubuntu> pedronis: yes but that won't yet change, I think
<zyga-ubuntu> pedronis: unless I'm mistaken and we need to cross that bridge soon
<jdstrand> zyga-ubuntu: there so small I think here is good. if we land them and something happens and the next one gets released, that isn't good. I could try to separate out the must haves and the should haves, but then it just makes the other PR review difficult cause we need to reference back to this one
<jdstrand> thy're*
<jdstrand> meh
<jdstrand> they're*
<zyga-ubuntu> jdstrand: yes, that's a good point (about the release)
<jdstrand> zyga-ubuntu: I mean, I guess technically you create a PR for just the security audit changes, land that before 3621, then merge that into 3621, but I don't see any gain in that
 * jdstrand is trying to get this to land fast too :)
<zyga-ubuntu> jdstrand: I didn't want to do the simplification changes as I think they are not critical and don't have a security impact
<jdstrand> zyga-ubuntu: those are the should have column
<jdstrand> like I said, we can split it up, but I don't see any reason
<zyga-ubuntu> jdstrand: ok
<jdstrand> I mean, we can make things harder on ourselves if we want :P
<jdstrand> I'll leave the to split vs not up to you, but will say if split, please get the audit feedback in before 3621, so it is in place whenever 3621 is
<zyga-ubuntu> jdstrand: I'll do them in the PR
<jdstrand> ok cool. it is really close to landing
<zyga-ubuntu> jdstrand: can you please edit https://github.com/snapcore/snapd/pull/3621#pullrequestreview-63369978 to indicate if something is optional
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> jdstrand: I'm not sure if all of that is mandatory or not
<zyga-ubuntu> sorry for being confused, I just dropped from a call and I'm swapping context
<jdstrand> zyga-ubuntu: I did. I consider it all mandatory except the one that says (not a blocker)
<zyga-ubuntu> jdstrand: why are the simplifications mandatory?
<jdstrand> zyga-ubuntu: I gave my feedback on why the simplification is important last week in response to your question
<zyga-ubuntu> ah
<zyga-ubuntu> let me recheck
<jdstrand> zyga-ubuntu: to be clear, there aren't security bugs there, but see my comment
<zyga-ubuntu> ah, I see that
<zyga-ubuntu> I must have missed that, sorry, the thread is so long now
<jdstrand> indeed
<jdstrand> zyga-ubuntu: the basic idea is since it is security sensitive, make it easy to verify
<pstolowski> zyga-ubuntu, pedronis hey, sorry, was distracted and missed your earlier messages
<mup> PR snapd#3810 closed: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/3810>
<pstolowski> pedronis, what was your worry? about having PlugInfo & SlotInfo in the "Connection" struct?
<pedronis> pstolowski: not that, but when we remove Plug and Slot
<ogra_> AlbertA, bschaefer so my pi did behave just fine over the weekend, no corruption ... but i found https://github.com/raspberrypi/firmware/issues/397#issuecomment-219287224 ... we might need something similar to https://github.com/respeaker/openwrt/blob/master/target/linux/brcm2708/patches-4.4/0354-mmc-Apply-QUIRK_BROKEN_ERASE-to-other-capacities.patch for your specific SD card
<bschaefer> ogra_, o interesting
<ogra_> AlbertA, bschaefer, the output of "grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null" (as mentioned in the issue above) might be interesting ... ppisati was also looking into it but has no SD he can reproduce it with
<bschaefer> ogra_, i bought two of the SD cards
<ogra_> i assume both of yur boards ended up with a corrupt overlays dir again ?
<bschaefer> i can give you or him one in new york (the one that was acting an issue)
<bschaefer> or test some things out
<bschaefer> ogra_, monday for me today + i had that hack of manually untaring
<bschaefer> let me test agian
<bschaefer> (monday 8:30am :)
<ogra_> yeah, the patch is trivial, once we have the data from the grep above we ca surely cook something up
<ogra_> *can
<mup> PR snapd#3934 opened: snap-repair: implement `snap-reapir {listt,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>
<zyga-ubuntu> mvo: llist
<zyga-ubuntu> er, sorry, I meant listt
<bschaefer> ogra_, cool let me re-flash and boot up
<mvo> pedronis: I reworked 3777 quite a bit (I think its nicer now) in 3934 - I can either push this over 3777 or close 3777 either way is fine with me
<mvo> zyga-ubuntu: thanks, fixed
<Son_Goku> zyga-ubuntu: are you going to be at the sprint/rally/thing next week?
<Son_Goku> mvo: ^?
<ogra_> mvo, is reapir an aggressive brother of tapir ?
<ogra_> :P
<zyga-ubuntu> Son_Goku: no, I don't think I will
<pedronis> mvo: I'll look in a bit
<mvo> pedronis: no rush, I need to leave soonish anyway to play hockey
<mvo> Son_Goku: I will be there
<Son_Goku> \o/
<mvo> ogra_: its what I turn into when I did not have enough tea sadly
<ogra_> heh
<mvo> Son_Goku: and more of the folks you know, we will have a blast!
 * ogra_ gives mvo more tea
<AlbertA> ogra_: ok I'll try to get those logs a bit later
<bschaefer> ogra_, http://paste.ubuntu.com/25566047/
<ogra_> thx
<bschaefer> np! Let me know if theres any fixes you want me to test out as well
<ogra_> will do
<AlbertA> ogra_: http://pastebin.ubuntu.com/25566134/
 * Chipaca ~> lunch
<ogra_> AlbertA, bschaefer oooh, they differ !
<ogra_> (different oemid)
<mup> PR snapd#3935 opened: cmd/snap-repair: implement the repair run loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/3935>
<bschaefer> ogra_, though i think we both had corrupting issues :)
<ogra_> yes, and obviously the same
<bschaefer> AlbertA, your SD is old!
<bschaefer> 2015
<AlbertA> :)
<AlbertA> ogra_: bschaefer: interesting, another core upgrade but this time after a second reboot, system won't boot at all (stuck at the "Starting Kernel..." screen)
<bschaefer> AlbertA, that use to happen to me
<bschaefer> but i blamed by 8GB SD card
<AlbertA> ogra_: which SD cards do you use?
<bschaefer> and got these 32GB ones and havent had an issue with that since
<ogra_> AlbertA, totally random ones i buy at the electronics discounter next door
 * bschaefer never knew the intricacies of SD cards
<ogra_> i have some toshibas, sandisk, terratec ... apacer
<ogra_> whatever they have in the offers when i need new ones, i explicitly dont pick a particular one (to be able to run into issues by my weird choice ... obviously that never works :P )
<ogra_> AlbertA, well, you can check the card in your PC reader if it is really corrupt
<ogra_> ppisati, see above ...
<ogra_> ppisati, i'll cook up a patch that supppresses erase on both cards tomorrow
<bschaefer> ogra_, ill be sure to pack the current one im using plus the other new one i have unopened
<bschaefer> if you need more testing on those
<bschaefer> though hopefully this is enough :)
<ogra_> well, i should have a kernel snap or complete image for you guys to test tomorrow ... we'll then see if that helps
<ogra_> up to now it is just a theory anyway
<AlbertA> ogra_: yeah
<AlbertA> thxs!
<ogra_> :)
<bschaefer> ogra_, awesome, and thanks!
<ppisati> ogra_: ack, FWIW i tested on two more sd cards, everything was fine
<ogra_> ppisati, yeah, i have like 30 cards here and only one that ever has shown such an issue
<mup> Issue snapcraft#1489 closed: Custom path of desktop file - should not be expanded in prime directory <Created by koppor> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1489>
<mup> Issue snapcraft#1506 closed: Inconsistent formatting when opening vs. closing channels <Created by Roadmaster> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1506>
<zyga-ubuntu> Chipaca: how are you feeling?
<Chipaca> zyga-ubuntu: better, thank you
<Chipaca> had lunch even
<Chipaca> did i miss much?
<bschaefer> hmm is there a bug for this? "snap install <snap_name_not_complete><hit_tab_to_autocomplete> --devmode" turns into "snap install --devmode --devmode"
<zyga-ubuntu> Chipaca: no, I think all is good
<zyga-ubuntu> Chipaca: some discussion around iface repository and connections
<ogra_> bschaefer, tab completion is Chipaca's baby
<Chipaca> bschaefer: hm, that's a new one
<bschaefer> Chipaca, i mainly hit it when i have mir-kiosk_*snap and mir-kiosk-apps*snap
<bschaefer> and im install both with --devmode
<bschaefer> so i just try to auto tab from mir-kisok-<tab> but since --devmode is there seems... to want to reaplce the string with that :)
<Chipaca> bschaefer: I'll take a look, but just for the record a lot of things don't auto-complete properly from the middle of the command
<niemeyer> ackk: Will check it out.. sorry for not replying earlier.. we were in the standup and then I forgot to reply
<bschaefer> Chipaca, yeah figured it was an strange edge case :)
<bschaefer> not really a huge issue
<Chipaca> bschaefer: it _should_ work, though, and i know to fix it if it doesn't
<Chipaca> so, i'll take a look
<bschaefer> Chipaca, cool :), tahnks!
<mup> Bug #1666386 changed: Snap apps do not work on Lubtuntu <Snappy:Invalid by zyga> <lubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1666386>
<nacc> for those using LP to build their snap, how are people organizing their repository to deal with stable/edge branches, etc. It seems I can only have one repository <-> package connection, which means I have to publish to edge, and manually promote to stable at the appropriate time? Can I have a stable branch pushing to stable and an edge branch pushing to edge?
<kyrofa> nacc, to be clear, there are multiple ways to use LP to build snaps. You cannot achieve what you're asking with build.snapcraft.io, but you can if you simply use LP differently
<pedronis> mvo: IÂ think it's ok to close the previous one
<kyrofa> nacc, so from the limitations you've mentioned, I assume you're using build.snapcraft.io, correct?
<nacc> kyrofa: i'm using LP directly
<nacc> (no b.s.io)
<kyrofa> Oh! Well then yes, you can definitely do as you're asking
<nacc> kyrofa: ok! link to docs?
<kyrofa> nacc, don't make me laugh
<nacc> kyrofa: if i click on the second branch and try to associate it to the same snap, LP says no
<kyrofa> nacc, "snaps" in LP are really snap _recipes_
<kyrofa> nacc, you can only create one per branch, and they must be named differently, but when they're uploaded to the store they're uploaded using the name in the YAML
<kyrofa> nacc, which means they're the same snap
<nacc> kyrofa: yep, that makes sense
<kyrofa> nacc, so you're on the right path
<kyrofa> nacc, create a new snap, called <mysnap>-stable
<mup> PR snapd#3936 opened: data/completion: small tweak to snap completion snippet <Created by chipaca> <https://github.com/snapcore/snapd/pull/3936>
<kyrofa> Associate it with the stable branch, auto-upload to stable, and voila
<Chipaca> bschaefer: ^ :-)
<nacc> kyrofa: oh! so basically lie to LP's recipe creator? :)
<nacc> kyrofa: fun :)
<bschaefer> Chipaca, awesome thanks!
<kyrofa> nacc, whatever it takes :P
<nacc> kyrofa: yeah :)
<Chipaca> bschaefer: if you drop data/completion/snap from that pr into your /usr/share/bash-completion/completions, your issue should go away (and nothing bad could possibly happenâ¢)
<nacc> kyrofa: thannks! i'll try it now
<kyrofa> nacc, you should see the gymnastics we do in the nextcloud snap
<bschaefer> Chipaca, o sweet yeah ill give that a try now
<nacc> kyrofa: are there bugs open for this to be easier?
<nacc> kyrofa: as it seems like a pretty obvious workflow to me
<nacc> kyrofa: do you make -stable -edge or whatever other snaps you create private so they don't show up int he store?
<nacc> kyrofa: they are just placeholders, it feels like
<kyrofa> nacc, I'm afraid I don't know about bugs
<kyrofa> nacc, the snap recipes you create in LP do not show up in the store
<kyrofa> nacc, the names are specific to LP
<nacc> kyrofa: oh right and since there will be no uploads to git-ubuntu-stable, e.g., it will never show up
<nacc> kyrofa: funny
<kyrofa> nacc, there are fields on the recipe that cover "what is this named in the store"
<bschaefer> Chipaca, sweet, confirmed working /me comment
<Chipaca> bschaefer: ta
<mup> PR snapd#3937 opened: interfaces/udev: only 'trigger --action=change', not 'control --reload-rules' <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3937>
<mup> PR snapcraft#1551 closed: dirs: set plugin, schema, and library dir for snap <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1551>
<cachio> niemeyer, I am looking at the test ubuntu-core-services which check the status for the different snapd services
<cachio> i am looking the results on dragonboard and it is failing
<cachio> basically snapd.autoimport.service and snapd.snapd.refresh.timer are not active on dragonboard
<cachio> i am not sure if it is expected or it is an issue
<cachio> niemeyer, any idea?
<niemeyer> Hmm
<niemeyer> cachio: Refresh timer is not supposed to be active anymore I believe. This is now internal.
<niemeyer> cachio: As for autoimport, I *think* this is actually a once only thing on startup.. it's not supposed to be active the whole time.. but that's been a while ago and my memory fails
<cachio> niemeyer, ok, i'll ask tomorrow to mvo because the test he just added is failing on ubuntu-core
<pedronis> also test themselves manipulate those (maybe in different ways between core and classic)
<cachio> pedronis, yes, that could be a reason, because i am running with external backend
<pedronis> anyway mvo is indeed the best person to talk about this
<cachio> niemeyer, the test-snapd-upower-observe-consumer snap is not available for arm-64 and a test is failing because of that, I don't have permissions to upload that to prod, do you?
<niemeyer> cachio: I don't as well
<mup> PR snapd#3938 opened: interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3938>
#snappy 2017-09-19
<zyga-ubuntu> o/
<zyga-ubuntu> mvo: hey, how is 2.28 looking
<mup> Bug #1718026 opened: Applications from installed snaps don't appear in activities overview <Snappy:Fix Committed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1718026>
<mvo> zyga-ubuntu: looking good overall looks like some things need to go into it (3937)
<mvo> zyga-ubuntu: did you figure out if it is this rule that triggered the issue?
<zyga-ubuntu> mvo: no, I had to leave last night
<zyga-ubuntu> mvo: jamie prepared a PR and some rationale
<zyga-ubuntu> mvo: it looks good but fails testing
<zyga-ubuntu> mvo: I will investigate that soon
<mvo> zyga-ubuntu: testing is currently failing left and right but I have not looked into the why yet too
<zyga-ubuntu> mvo: I wanted to highligh one bug https://bugs.launchpad.net/snappy/+bug/1718026 - this is fixed in master, I haven't checked if it is in 2.28 reease branch
<mup> Bug #1718026: Applications from installed snaps don't appear in activities overview <Snappy:Fix Committed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1718026>
<zyga-ubuntu> mvo: if we do another respin it would be worth to pick it up
<zyga-ubuntu> mvo: specifically this patch should be in 2f55619677810a4872145b8ccbbe2bdc1ba364fa
<mvo> zyga-ubuntu: aha, build fails in udev-support.c in a bunch of places - setup_dvices_cgroup
<zyga-ubuntu> mvo: build fails? that's odd - in jamie's branch tests failed but the build was (supposedly) ok
 * zyga-ubuntu looks again
<mvo> zyga-ubuntu: this is the opengl change
 * mvo goes top-to-bottom
<zyga-ubuntu> aha, I was looking another pr
<mvo> zyga-ubuntu: no worries, I fixed the issue in jamies
<zyga-ubuntu> thank you
 * zyga-ubuntu walks kids to school
<niemeyer> Early hellos
<mvo> niemeyer: good morning, early is an understatement here :)
<niemeyer> mvo: :P
<mvo> zyga-ubuntu: btw what happend to the debian man-page bug, did it fix itself magically?
<niemeyer> mvo: Just felt like one of those days..
<mvo> niemeyer: heh :) take it easy
<zyga-ubuntu> mvo: probably
<zyga-ubuntu> mvo: it broke a lot of sid :)
<niemeyer> mvo: We had some issues with Debian preparing yesterday.. have you seen that?  Just wondering if it went away already..
<niemeyer> mvo: Felt like an unrelated packaging bug
<mvo> niemeyer: yeah, we ran into it yesterday, I'm just looking, its debian bug #876128, zyga-ubuntu has a workaround PR, I check the bugstatus and then we can apply the workaround if needed
<mup> Bug #876128: Window too tall <amd64> <apport-bug> <oneiric> <running-unity> <thunderbird (Ubuntu):New> <https://launchpad.net/bugs/876128>
 * mvo wonders if we should test against testing instead of unstable - this would prevent issues like this one
<niemeyer> mvo: Yeah, that might be a good idea
<niemeyer> mvo: We'd still pick issues earlier but not be so close to the edge to face those unrelated bugs that will likely be fixed there
<mvo> indeed
<niemeyer> mvo: What are most devs using?
<mvo> niemeyer: unstable I would say
<niemeyer> mvo: Well.. then there's not much of a choice
<mvo> niemeyer: we can pick 3932 with the workaround
<niemeyer> mvo: We do want to know if people have a broken setup
<mvo> niemeyer: right
<niemeyer> mvo: 20h ago.. was it broken for other reasons?
<ackk> niemeyer, thanks for the review
<niemeyer> ackk: Heya
<mvo> niemeyer: tsee the comment in the PR, the PR itself is fine, I think it should include a link to the debian bug so that we know when we can remove this again. I added that now
<niemeyer> ackk: No problem, thanks for the PR.. hopefully the notes make sense?
<niemeyer> mvo: Good idea
<ackk> niemeyer, sure. fwiw the main reason I went for a string for the socket-mode is that using an int makes snacfraft write it out in decimal notation in the snap.yaml. I guess that can be somehow overridden (although even leaving as decimal works of course)
<niemeyer> ackk: Yeah, and I think it's easy to fix that as well
<niemeyer> ackk: I mean, forcing the notation on ints
<niemeyer> ackk: Look at the second answer here:
<niemeyer> ackk: https://stackoverflow.com/questions/18666816/using-python-to-dump-hexidecimals-into-yaml
<niemeyer> Hey.. I know this guy... :P
<ackk> heh
<ackk> niemeyer, thanks for the pointers
<mvo> zyga-ubuntu: do you know more about this udev regression that jamie talks about in the forum? I just tried to reproduce but no luck
<niemeyer> ackk: The question about the actual structure of the syntax and its equivalence in the systems is more of an issue though, but we should discuss this in the forum
<zyga-ubuntu> re
<zyga-ubuntu> mvo: the udev issue can be reproduced on a artful (probably zesty as well) machine runnin wayland
<zyga-ubuntu> mvo: for me it was sufficient to install gimp and then hit alt-f4 (note, just alt-f4, nothing more)
<zyga-ubuntu> mvo: if you switch to VT4 you are affected
<zyga-ubuntu> mvo: and subsequent ctrl-c will kill gnome-shell
<mvo> zyga-ubuntu: sorry, I mean the other issue that jamie reported, https://forum.snapcraft.io/t/2-28-release-cycle-started/2026/13
<zyga-ubuntu> mvo: I wasn't aware of this, lookng
<zyga-ubuntu> mvo: it looks like a busy day ahead, sorry for starting late btw, I wanted to have a walk as I'm mostly indoors lately
<mvo> zyga-ubuntu: no worries
<mvo> zyga-ubuntu: and +1 for walking, its good for productivity :)
<mvo> (seriously!)
<zyga-ubuntu> mvo: so first thing I checked if jamie's test snap has any apps in it
<zyga-ubuntu> but it does...
<zyga-ubuntu> (pretty fancy snap actually)
<zyga-ubuntu> mvo: let me try to reproduce on master
<zyga-ubuntu> mvo: so far I cannot think of anything
<zyga-ubuntu> mvo: well, :)
<zyga-ubuntu> mvo: maybe one (silly) explanation would be that jamie tried to disable the udev backend while exploring the wayland issue
<zyga-ubuntu> mvo: and then didn't notice this when testing the other issue
<zyga-ubuntu> mvo: also the udev code has not changed lately
<zyga-ubuntu> mvo: last change is in March 2017
<zyga-ubuntu> mvo: so +1 on doubt it's real
<mup> PR snapd#3777 closed: snap-repair: implement basic `snap-repair {list,show}`  <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3777>
<mvo> niemeyer: I was just looking over the spread PRs (got a ping about #30) and it seems like e.g. #33 is uncontroversial (maybe tweaking the error a bit)
<mup> PR #33: small daemon tests cleanup <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/33>
<mup> PR snapd#3932 closed: spread: work around temporary packaging issue in debian sid <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3932>
<niemeyer> mvo: Yeah, the queue needs some love.. let me check that one
<zyga-ubuntu> mvo: btw, I found the debian bug tracker entry for manpages: 876128
<zyga-ubuntu> mvo: shall I add it?
<niemeyer> zyga-ubuntu: mvo already did it
<zyga-ubuntu> ah, thank you mvo :)
<mvo> zyga-ubuntu: I added it already and merge the PR, sorry that I wasn't more explicit about it
<zyga-ubuntu> I didn't notice
<niemeyer> And merged it
<niemeyer> zyga-ubuntu: He also fixed the apparmor summary/level PR
<zyga-ubuntu> niemeyer: yes, we discussed that earlier so I knew about it
<niemeyer> zyga-ubuntu: You'll need to get layouts working to compensate him ;)
<zyga-ubuntu> working on that :)
<pedronis> mvo: hi, where should we create the lock file for snap-repair run ?
<niemeyer> zyga-ubuntu: That last comment from jdstrand is a bit eye opening.. we need to address review items made, or respond to the points when that's the case
<niemeyer> zyga-ubuntu: But definitely not ignore.. as a rule of thumb, always respond to all review points in a review, even if it's a thumbs up
<zyga-ubuntu> niemeyer: I discussed each point jamie made
<niemeyer> zyga-ubuntu: So why is his review reading like that?
<zyga-ubuntu> niemeyer: I didn't understand that he essentially said that is all mandatory
<zyga-ubuntu> niemeyer: when you are subtle on the internet...
<niemeyer> zyga-ubuntu: "You did not address the off-by-one in read_cmdline() yet"
<zyga-ubuntu> niemeyer: read the full discussion, I disagree about that item (it's not a bug, it's an optimization)
<zyga-ubuntu> niemeyer: I'll address each element jamie made, it's just not easy to keep track of everything in that PR and, as I said, I was confused by his earlier statements about what is needed and what is optional and nice
<mvo> pedronis: I have not looked at your latest branch yet but maybe in main.go when you start the runner. I will soon look at your latest PRs maybe I have a better idea then
<zyga-ubuntu> (some of the things I pushed into the PR were in the "nice" category according to my earlier understanding)
<oSoMoN> zyga-ubuntu, hey, out of curiosity, could you please point me to the commit in master that fixes bug #1718026 ?
<mup> Bug #1718026: Applications from installed snaps don't appear in activities overview <Snappy:Fix Committed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1718026>
<pedronis> mvo: no,Â I mean on disk?
<zyga-ubuntu> oSoMoN: yes, one sec
<zyga-ubuntu> oSoMoN: 2f55619677810a4872145b8ccbbe2bdc1ba364fa
<pedronis> mvo: sorry, I wasn't clear, IÂ mean where on disk
<zyga-ubuntu> oSoMoN: I verified this by installing the updated file on 17.10 running wayladn
<oSoMoN> zyga-ubuntu, thanks
<mvo> pedronis: oh, sorry :) /var/lib/snapd/repair/lock maybe?
<pedronis> ok
<pedronis> that seems reasonable
<pedronis> and what I was thinking as well
<pedronis> ah
<pedronis> mmh
<pedronis> mvo: no reason to creat it in /run/snapd/repair/lock ?  (IÂ see we create some other locks under /run)
<niemeyer> zyga-ubuntu: His comment seems spot on regarding off by one..
<niemeyer> zyga-ubuntu: and he's asking you to take it into account
<mvo> pedronis: oh, that is a good one too, the advantage is of course that its slightly cleaner)
<mvo> pedronis: less clutter on the real disk, so that works for me
<niemeyer> zyga-ubuntu: His code is both safer and more technically correct as it handles the length of the string properly for the exact fitting case
<zyga-ubuntu> niemeyer: yes, I don't disagree about it but it's not a blocker in any sense of the word
<niemeyer> zyga-ubuntu: just n > m on itself would already be worth fixing
<pedronis> mvo: thanks
<niemeyer> zyga-ubuntu: Instead of an exact == match
<niemeyer> zyga-ubuntu: Please take Jamie's review more carefully..
<pedronis> mvo: I'm reviewing your PRs btw
<mvo> pedronis: thanks for that!
<mvo> pedronis: I will address and look at your PRs too. fwiw, if you merge master into your PRs tests should be happy again (kudos to zyga-ubuntu for the workaround)
<pedronis> ah, good
<mwhudson> what does "Ubuntu Artful, for Ubuntu Core 16" mean in a snap build on launchpad?
<mvo> mwhudson: my guess is that the snap was build with an artful chroot but is targeted towards ubuntu core 16 (which AFAIK is the only target we have currently :)
<mwhudson> ah so build-packages etc will come from artful
<mwhudson> that might actually be useful for me
<mwhudson> can i get cleanbuild to use an artful lxd?
<pedronis> mvo:  I added the flock code to the loop PR
<mvo> mwhudson: I think you can but I'm not familiar with the syntax unfortunately
<mvo> pedronis: thank you
<mwhudson> mvo: "        self._image = 'ubuntu:xenial/{}'.format(deb_arch)" :(
<mvo> mwhudson: *cough*
<ogra_> urgh ... i hope we dont allow that
<mvo> mwhudson: sounds like a PR waiting to happen then
<ogra_> nne of the deps will be coorrrect
<ogra_> *none
<ogra_> afaik launchpad always calls cleanbuild regardless ... so the host might be artful but the build container will still be xenial
<pedronis> that message seems mostly confusing then (the host shouldnd't play a big role)
<mvo> indeed, if thats the case its pretty useless to even offer builds on anything but xenial
<ogra_> well, and we shuldnt
<pedronis> yes, until we have base-18 (or however we will call it)
<ogra_> buillding on anythhing but xenial for core 16 willl only result in dependency mess for stage-packages, you really dont want that
<ogra_> ight
<ogra_> once we have another base/core we should have choices, but not atm
<mwhudson> ogra_: no, that's definitely not what is happening
<ogra_> got a link to the log ?
<mwhudson> ogra_: https://launchpadlibrarian.net/337523100/buildlog_snap_ubuntu_artful_amd64_subiquity-artful_BUILDING.txt.gz
<mvo> pedronis: should we restrict summary further or is checking for \n enough in your estimate?
<ogra_> yeah, that uses atful all the way through, thats definitely wrong and dangerous
<mwhudson> i assume lp didn't just add this by accident...
<ogra_> mwhudson, talk to wgrant or cjwatson
<ogra_> such builds shouldnt be provided
<cjwatson> wat
<ogra_> (imagine yoou wouldnt use the python plugin (which pulls in the interpreter) but just dump to copy sme py modules in place ... how woould you knw they are even remotely compatible with the intepreter shhipped in core (which we'd fall back to in this case)
<mvo> how would people get e.g. stage-package for artful then?
<cjwatson> sorry, how is this our problem?
<ogra_> cjwatson, why doesnt it call cleanbuild ?
<cjwatson> LP has never used cleanbuild
<cjwatson> it uses containers based on its own chroots
<ogra_> still
<pedronis> mvo: ScanLine uses the equivalent of `\r?\n`
<cjwatson> if it's using artful it's because the person who set it up explicitly asked for it to use artful
<pedronis> *ScanLines
<cjwatson> cleanbuild is beside the point
<ogra_> another example ... pulse has 100% incompatible API changes in libpulse between xenial and all the following releases ... as soon as your app uses sound you are screwed ...
<mvo> pedronis: aha, nice. I will use a similar pattern than, but essentially a blacklist \n\r? is ok, we don't want a fancy whitelist "[a-zA-Z,.-?...] (?)
<cjwatson> right, so don't do that, but it still needs to be possible to run test builds where appropriate
<ogra_> builds should only target xenial
<cjwatson> so we won't withdraw the facility
<pedronis> mvo: don't think we need a fancy whitelist, no
<mvo> pedronis: thank you
<pedronis> it's mostly us for now that will make them
<mvo> +1
<pedronis> mostly keeping us honest, not confuse that code
<ogra_> cjwatson, well, as long as you cant release the result to the store i guess it is fine for test building ... to me it looked like mwhudson was hitting a default though
<cjwatson> you can, but it's up to the builder to ensure that the result works, like anything
<cjwatson> I mean the person operating the recipe
<cjwatson> artful is not the default
<mwhudson> i selected this option because i _want_ all my stage-packages etc to come from artful
<mwhudson> at least for a trial
<ogra_> mwhudson, right, just dont release it ... (and i think there shoudl be at least a warning when you select that option)
<cjwatson> the default is xenial
<mwhudson> ogra_: this is subiquity, it is a normal snap in no ways at all
<mwhudson> for another questoin
<ogra_> mwhudson, well, what goes to the store should always target xenial ... if you do test builds it doesnt matter indeed (not sure about the benefit of it ... but well)
<wgrant> Someone can produce something that doesn't work by asking snapcraft to download a tarball with the wrong ABI.
<ogra_> sure
<wgrant> I don't see why we should prevent them from shooting themselves in the foot if they don't know what they're doing by selecting a series that won't work for them.
<mwhudson> for another question
<mwhudson> hm no
<ogra_> but thats a pretty explicit action ... i'd expect you to knwo what yuo do any why in that case
<ogra_> wgrant, the point is that it wont work for the ednuser ... it might just build fine for the developer
<mwhudson> oh heh pushing my change to github and then immediatly building from the import branch on lp, not so useful
<ogra_> mwhudson, fsvo "immediately" :)
<mwhudson> ogra_: i generally don't wait for 3 or so hours by mistake
<ogra_> (i have never the luck to hit the import schedule with my commits ... it usually just ran or says "will run in 20min" or soo)
<ogra_> you can just click the import button
<mwhudson> yes i know
<mwhudson> i implemented the import button :)
<ogra_> heh
<mwhudson> a very very long time ago now
<pstolowski> zyga-ubuntu, is the bug re manpages (that you mentioned above) concerning snapctl (discussed yesterday)?
<zyga-ubuntu> pstolowski: there are two bus, one affecting all of debian sid (packaging bug where file clashes) and one affecting snapd (snactl does not have a man page but is in path)
<mup> PR snapd#3939 opened: core/repo: Connection type <Created by stolowski> <https://github.com/snapcore/snapd/pull/3939>
<pstolowski> niemeyer, pedronis, zyga-ubuntu : quick first feedback appreciated before I dive in with more significant changes: https://github.com/snapcore/snapd/pull/3939
<mup> PR #3939: core/repo: Connection type <Created by stolowski> <https://github.com/snapcore/snapd/pull/3939>
<pstolowski> zyga-ubuntu, i see, ack. ok, I'm going to work on snapctl man page now
<zyga-ubuntu> pstolowski: thanks, it's not a high priority but I think one will be useful for developers and users alike
<niemeyer> Is it time for another review sprint yet, or too soon?
<niemeyer> mvo: How do you feel about our queue atm?
<mvo> niemeyer: its too big, but I hope before EOD we can close a good bunch, some are very close but tests issues have slowed progress a bit
<ackk> niemeyer, wrt the SocketInfo struct, you're suggesting to add Name as an attribute and have App.Sockets as a []SocketInfo rather than a map, right?
<ackk> niemeyer, that would also allow having socket.File() as you suggested
<niemeyer> ackk: Let's please discuss this in that topic in the forum
<niemeyer> Oh, wait
<niemeyer> ackk: Sorry, separeate issue
<niemeyer> ackk: No
<ackk> yeah, that's about implementation details
<ackk> :)
<niemeyer> ackk: The idea was still having it as a map
<niemeyer> ackk: Having a Name attribute isn't something I thought of, but sounds like a good idea
<niemeyer> ackk: Even if redundant with the map key
<ackk> niemeyer, yeah I was trying to avoid duplication
<niemeyer> ackk: It's good duplication in this case..
<ackk> niemeyer, FWIW I'm not sure we even a map at that point
<niemeyer> ackk: Means we can use the SocketInfo by itself
<ackk> right, I do like the idea of socket.Name
<niemeyer> ackk: What's the issue iwth the map?
<ackk> niemeyer, I don't think there's really one, but if we don't need to look up by name (which we probably don't), we could just keep a list
<ackk> I'm talking just about App.Sockets, not about the Yaml format, to be clear
<ackk> anyway, duplication is not a big deal in this case, agreed
<ackk> if you prefer to keep the map, LGTM
<niemeyer> ackk: Yeah, let's keep it at least for now, as it reflects the structure in the yaml.. but there's still that more fundamental underlying question about whether the whole thing is workable or not
<ackk> niemeyer, what's the issue?
<niemeyer> mvo: Ack.. let's wait til the EOD and reevaluate tomorrow
<niemeyer> ackk: It's in the review
<ackk> niemeyer, ah yeah, I did answer that in the review
<mvo> niemeyer: +1
<ackk> xnox, hi, can you define more than one Listen* in a .socket file?
<pstolowski> zyga-ubuntu, do we still want bugs concerning snap-confine to be reported against https://bugs.launchpad.net/snap-confine/+filebug ? or is it the main snapd bug tracker now?
<zyga-ubuntu> pstolowski: I don't have a strong opinion on that
<zyga-ubuntu> pstolowski: it can be moved to snapd
<pstolowski> zyga-ubuntu, i see, just asking, wasn't sure if snap-confine bugtracker isn't dead or something
<zyga-ubuntu> pstolowski: I'm not sure either, we have snapd, snappy, snap-confine + distro versions of those
<zyga-ubuntu> so it's all a bit all over the place
<pstolowski> zyga-ubuntu, ok, I was wondering about updating snap-confine manpage while on it, but it seems there is no obvious answer, that's fine
<xnox> ackk, hi, you can use $ systemd-analyze verify FILE for systemd to check syntax of a unit file.
<zyga-ubuntu> pstolowski: go ahead and do it if you want to
<zyga-ubuntu> pstolowski: one less bug tracker to worry about (eventually)
<pstolowski> ok
<pedronis> mvo: niemeyer: IÂ have an errand this afternoon, if there are no delays I should be back for the standup, but IÂ might not
<mvo> ta
<niemeyer> pedronis: Thanks for the note
<niemeyer> mvo: #3934 is reviewed
<mup> PR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>
<niemeyer> mvo: Have you seen the description on #3929?
<mup> PR #3929: Correct typo in test <Created by gliptak> <https://github.com/snapcore/snapd/pull/3929>
<niemeyer> mvo: I'm assuming the answer is "no" :D
<niemeyer> mvo: I mean, to the questions in the description
<mvo> niemeyer: thanks for the review, i have a look
<mup> PR snapd#3940 opened: dirs: fix classic support detection <Created by chipaca> <https://github.com/snapcore/snapd/pull/3940>
<mvo> niemeyer: I had hoped we get an answer for the question.
<mup> PR snapd#3929 closed: snap: correct typo in test name <Created by gliptak> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3929>
<niemeyer> mvo: Well, getting "No" as a description wouldn't be much better I'm afraid.. LOL
<mvo> niemeyer: heh :)
 * zyga-ubuntu runs tests on updated update-ns PR and takes a break
<mup> PR snapd#3941 opened: overlord/snapstate: prefer a smaller corner case for doing the wrong thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/3941>
 * zyga-ubuntu hugs chipaca
 * Chipaca hugs back
<mwhudson> snapping snapcraft is quite a slow process, probably not the right way to go for testing local hacks :)
 * Chipaca hugs the snaps he's written before snapcraft was a thing
<zyga-ubuntu> mwhudson: does snap try on snapcraft works?
<niemeyer> I still sort of want "snap pack" or something similar..
<mwhudson> zyga-ubuntu: huh i didn't know about snap try
<Chipaca> mwhudson: dude :-)
<Chipaca> mwhudson: as long as you're not modifying the snap metadata, with snap try you can edit stuff and test them without touching anything else
<mwhudson> sounds exciting :)
<mvo> niemeyer: "snap pack" would be like "snapcraft snap" ?
<niemeyer> mvo: I'm not sure, which is perhaps another reason why I'd like to have it :)
<niemeyer> mvo: snapcraft snap used to mean something else
<niemeyer> mvo: Its help text says:
<niemeyer>   If you want to snap a directory, you should use the snap-dir command
<niemeyer>   instead.
<niemeyer> Except, snap-dir doesn't exist?
<niemeyer> sergiusens: ^
<niemeyer> mvo: I think "snapcraft" and "snapcraft snap" are the same thing
<niemeyer> mvo: Anyway, yeah.. something dumb that just packs a snap dir..
<niemeyer> pstolowski: #3939 LGTM
<mup> PR #3939: interfaces: add Connection type <Created by stolowski> <https://github.com/snapcore/snapd/pull/3939>
<Chipaca> niemeyer: snapcraft snap <directory> just mksquashfs's
 * Chipaca hasn't read all the context
<niemeyer> Chipaca: I don't think so..
<Chipaca> niemeyer: you think wrong
<Chipaca> :-)
<pstolowski> niemeyer, great, thank you. i'll shortly outline what's next on the standup (or after it)
<Chipaca> niemeyer: but yes the docs for snap are wrong and/or misleading
<mwhudson> did i imagine something about using a persistent container for building snaps?
<niemeyer> Chipaca: Well, if it is a dumb pack, then it's broken in terms of UX too
<Chipaca> niemeyer: no no no
<niemeyer> Chipaca: As "snapcraft snap" and "snapcraft snap foo/" would be completely different
<Chipaca> niemeyer: no adding ux requirements mid-rant
<Chipaca> :-)
<niemeyer> LOL :)
<niemeyer> Chipaca: The former reads snapcraft.yaml and builds the whole snap
<Chipaca> niemeyer: yes they are completely different, and surprising, and being in the current directory and doing one instead of the other is a pain
<Chipaca> which suggests that the idea is to move it to snap-dir? dunno
<Chipaca> but today, it is like it is
<Chipaca> (i'm just telling you how it is)
<Chipaca> (in particular, i'm not saying it's the way it should be)
<pedronis> mvo: btw, should we build snap-repair for 14.04 at all?  we don't have 14.04 core systems
<niemeyer> Chipaca: I honestly don't know either.. but "snap pack" will solve it all.. :)
<Chipaca> niemeyer: we used to have that
<pedronis> we still do internally (for tests)
<Chipaca> niemeyer: we got rid of it to only have the mksquashfs call in one place (lots of little flags that need to be in sync)
<pedronis> IÂ mean, we didn't quite manage to get rid of the code
<pedronis> anyway
<Chipaca> i know i know
<Chipaca> also, more and more snapcraft calls snap for things, so maybe we made the wrong call
<Chipaca> and moving to snap pack is the right thing
<Chipaca> but, there is that DRY thing i wanted to point out
<niemeyer> Chipaca: Yeah.. we should probably seed the idea with a hidden command and see what happens next
<sergiusens> ogra_ mwhudson wrt launchpad, it creates its own container and runs plain old snapcraft (without cleanbuild
<niemeyer> sergiusens: What's the deal with snap vs. snap-dir
<niemeyer> ?
<niemeyer> sergiusens: The snapcraft commands, I mean
<sergiusens> wrt "mvo: "        self._image = 'ubuntu:xenial/{}'.format(deb_arch)" :(" as soon as base support comes in, we will map this to proper bases
<sergiusens> build.snapcraft.io does not allow you to pick artful, if using launchpad directly you have a bit more "advanced" flexibility
<Chipaca> how is there a travis build running for 3h+
<niemeyer> Chipaca: If seen a bug in travis happening recently where they concatenate two independent runs and sum up the logs and the times
<niemeyer> Chipaca:  Have a look in the middle of the logs.. look for a big jump in the timestamp
<niemeyer> sergiusens: Parlez-vous anglais?
 * zyga-ubuntu pushes lots of changes to https://github.com/snapcore/snapd/pull/3621 and crosses his fingers
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<sergiusens> niemeyer we have a bug for that, should be fixed soon (wrt snap-dir)
<niemeyer> sergiusens: Ack, thanks
<niemeyer> sergiusens: Which direction will the fix go?
<sergiusens> and the issue was oversight
<sergiusens> niemeyer we need to implement snap-dir and deprecate using `snap <directory>`
<niemeyer> sergiusens: Nice, sounds like the best option
<niemeyer> sergiusens: Might be worth renaming snap-dir, though, to make the delta more clear
<sergiusens> niemeyer suggestions?
<niemeyer> sergiusens: snapcraft pack
 * sergiusens is open for them early in the morning after staying up too late working on integration tests
<niemeyer> sergiusens: Hopefully one day this will simply call "snap pack"
 * zyga-ubuntu does school run
<sergiusens> niemeyer rings nice as I say it out loud
<niemeyer> sergiusens: Yeah, it's dumb-sounding
<pedronis> Chipaca: what's the status of #3835 ?
<mup> PR #3835: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3835>
<niemeyer> "Just pack it up..."
<Chipaca> pedronis: needing a second review
<zyga-ubuntu> Chipaca: it's also red
<ogra_> sergiusens, yeah, i learned that above, i always though it uses cleanbuild :)
<mvo> pedronis: good point, we don't need snap-reparir for 14.04 at all
<Chipaca> pedronis: "red"?
<zyga-ubuntu> Chipaca: tests are failing
<Chipaca> the last spread test was green
<pedronis> they are being re-run
<Chipaca> which tests were failing?
<zyga-ubuntu> autopackage
<pedronis> Chipaca: afaict spread tests are running atm because mvo just pushed master into it
<zyga-ubuntu> maybe harmless, just observing
<Chipaca> yes
<Chipaca> but if you click the previous commit's red X, you'll see the green spread tests
<mvo> niemeyer: I would love to bring "snap pack <dir>" back, this would allow us to stop building the snapbuild helper for our tests. if there is a +1 from you I make this happen, should be reasonable quick
<mvo> Chipaca: there wre conflicts
<niemeyer> mvo: +1!
<pedronis> mvo: let's close a bit more PRs first though :)
<mvo> Chipaca: this is why I merged master/pushed (in debian/snapd.dirs)
<mvo> pedronis: *pfff*
<Chipaca> mvo: thank you
<mvo> pedronis: ;)
<Chipaca> to be expected when it's just sat there for nearly three weeks
<mvo> Chipaca: yeah, it has my +1
<Chipaca> mvo: yes
<niemeyer> pedronis: Man, we're in a roll today! ;)
<niemeyer> I should not sleep more often.. feels so much more productive
<niemeyer> LOL
<Chipaca> niemeyer: _on_ a roll, hopefully
<niemeyer> Chipaca: Both!
<Chipaca> heh
<pedronis> mvo: what's the status of #3901 ?  issues with 14.04 ?
<mup> PR #3901: snap-seccomp: run secondary-arch tests via gcc-multilib <Created by mvo5> <https://github.com/snapcore/snapd/pull/3901>
<pedronis> can't we skip it there for now? and see about that in a follow up?
<mvo> pedronis: the last run died because of the debian issue, I haven't yet the status since (I merged master this morning)
<niemeyer> pstolowski: #3918 reviewed too
<mup> PR #3918: hooks: substitute env vars when executing hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3918>
<niemeyer> pstolowski: LGTM, but let's just move the test logic into the existing test that is already supposed to check basics of snap run for hooks
<sergiusens> ogra_ they should produce similar environments in the end
<ogra_> sergiusens, sure ... unless the wrong release is used
<pstolowski> niemeyer, i can, np.. it is sometimes nice though to have even basic tests separated, as a failure gives a very quick hint about what went wrong
<ogra_> (which was my point)
<sergiusens> ogra_ oh, not sure we plan to support anything outside of bases for that
<ogra_> sergiusens, well, we do support building a snap completely on artful atm ... that was what made me curious
<ogra_> sergiusens, but it is an explicit action you have to select (despite likely producing something useless)
<sergiusens> ogra_ well, yes, given we release snapcraft to artful means we have to make sure it passes tests
<ogra_> sergiusens, this is about the option to pick artful as a target for your snap ... i know snapcraft runs its autopkgtests
 * Chipaca ~> lunch
<niemeyer> pstolowski: We don't really want to split out functional tests every few lines because they are testing a slightly different aspect of the same logic
<pstolowski> niemeyer, fair enough
<niemeyer> pstolowski: The test is literally called "snap-run-hook" already..
<niemeyer> pstolowski: I'd even more the env into the snap used in that test
 * Chipaca ~> really lunch
<ogra_> mvo, uhmmmm ... your change to xdg-open cant really work ... we have no dbus-send inside core ...
<ogra_> hmm, ignore that, the old code also used dbus-send ... how the heck did that work without a dbus-send binary
<ackk> xnox thanks
<mup> PR snapd#3887 closed: snapstate: auto-install missing base snaps <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3887>
<niemeyer> pstolowski: #3852 just has the rename mentioned in the first comment pending
<mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
<niemeyer> pstolowski: Should be something like servicestate.Change, similar to configstate.Configure, cmdstate.Exec, snapstate.Install, etc.
<pstolowski> niemeyer, indeed, but I thought it was ok to postpone this, per your second comment?
<niemeyer> pstolowski: The second comment is talking about the return value
<niemeyer> pstolowski: Unrelated to the rename
<pstolowski> niemeyer, I see. ok. misunderstood
<niemeyer> np
<ackk> niemeyer, posted the question related to the yaml format on https://forum.snapcraft.io/t/socket-activation-support/2050/12
<mup> PR snapd#3942 opened: doc: snapctl man page <Created by stolowski> <https://github.com/snapcore/snapd/pull/3942>
<pstolowski> zyga-ubuntu, ^
<niemeyer> ackk: Thanks
<niemeyer> ackk: Also reading your feedback on the PR
<ackk> niemeyer, I just pushed the other changes you requested
<zyga-ubuntu> re
<zyga-ubuntu> pstolowski: thank you
<zyga-ubuntu> pstolowski: reviewed
<zyga-ubuntu> jdstrand: hey, around?
<pedronis> mvo: there's a error difference in artful that makes some unit tests fail here on artful: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170919_102916_63405@/log.gz
<mvo> pedronis: yeah, I saw that too, I will update my tests
<jdstrand> mvo: hey, regarding cgroups-- I was doing this on xenial classic distro, using a dpkg-buildpackage built deb from master. what were you doing? (I'm going to try again)
<mup> PR snapcraft#1554 opened: store: handle revoked developers <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1554>
<mvo> jdstrand: I was doing it on zesty running snapd from git
<mvo> jdstrand: I can try your setup next
<jdstrand> mvo: 'snapd from git' means dpkg-buildpackage?
<mvo> jdstrand: it means "go build && sudo ./snapd" from cmd/snapd in the source tree
<jdstrand> mvo: so, I was using dpkg-buildpackcage because of all the different binaries involved
<jdstrand> snapd, snap, snap-confine, snap-seccomp, snap-update-ns, snap-discard-ns, snap-exec, etc
<jdstrand> I have a script to go build everything, copy over, etc
<jdstrand> but I was trying to do what you typically do :P
<jdstrand> (we talked about this I think last week)
<jdstrand> mvo: I'm going to retest on classic xenial, zesty and artful. maybe I messed something up in the vm
<jdstrand> mvo: does core in edge have master code? I'd like to retry there too
<mvo> jdstrand: yeah, core should be up-to-date
<mvo> jdstrand: I can check after the standup
<niemeyer> Just grabbing a cup'a and will be in the standup
<roadmr> mvo hi
<roadmr> mvo: question about base snaps: is it possible for a snap to have more than one base snap? (i.e. can it have "no" base snap or "one" base snap but not more?)
<roadmr> mvo: and I guess follow-up: is it planned for multi-base snaps to be a possibility in the future? or not at all?
<roadmr> (I guess not because that'd reintroduce dependency hell, right?)
<ogra_> yeah, very unlikely
<ackk> niemeyer, I'm not sure I follow the point about systemd generating the .socket files. where do you put the [Socket] definition itself?
<niemeyer> ackk: In a configuration file for systemd?  :)
<niemeyer> ackk: Ah, no.. not those socket files
<niemeyer> ackk: The *real* socket files
<ackk> niemeyer, for unix sockets?
<zyga-ubuntu> roadmr: not right now because a base snap is the rootfs
 * ackk is a bit lost :)
<zyga-ubuntu> roadmr: so we'd have to understand what you mean by having more than one first
<roadmr> zyga-ubuntu: I mean exactly that :P
<zyga-ubuntu> roadmr: and what would that do? there can be only one rootfs in the traditional meaning of the word
<roadmr> zyga-ubuntu: I don't know, that's why I'm asking :)
<zyga-ubuntu> roadmr: why are you asking? do you have a workflow on your mind?
<roadmr> zyga-ubuntu: it's in connection with https://bugs.launchpad.net/snapstore/+bug/1715824. We'll work on implementing that but we'd like to know if we need to design for 0-N bases or only for 0,1 bases
<mup> Bug #1715824: Please provide "base" snap data from snaps <Snap Store:Confirmed> <https://launchpad.net/bugs/1715824>
<zyga-ubuntu> roadmr: for that you can safely assume each snap has exactly one base snap (with a default, so it's never empty)
<zyga-ubuntu> roadmr: technically it's a unset -> default or explicitly set but I don't know if you need to have that detail at the API level
<roadmr> zyga-ubuntu: nice, thanks!
<niemeyer> ackk: Yeah, the unix socket files.. sorry, in the standup so a bit slow
<ogra_> zyga-ubuntu, base-busybox + base-rootfs-core + base-fobbar-service
<zyga-ubuntu> ogra_: what is the composition operator for a filesystem? union?
 * ogra_ hopes thats a nono
<ogra_> zyga-ubuntu, well, it is all squashfses .... i think you can merge them on mount ...
<ogra_> (would still be awful though)
<zyga-ubuntu> ogra_: we cannot currently merge them on mount
<ackk> niemeyer, but that's what is defined by ListenStream, no?
<ogra_> (i just meant to outline the possibility of multiple base snaps)
<niemeyer> ackk: Yes, exactly
<ackk> niemeyer, so I don't get the comment about FileDescriptorName (which TIL)
<zyga-ubuntu> ogra_: since we never discussed merging multiple base snaps I'll skip that for now, once overlayfs becomes LSM-aware and apparmor is overlayfs aware we can explore this with layouts
<ogra_> zyga-ubuntu, uh, i hope we never have to ... :)
<zyga-ubuntu> ogra_: as a layout element it would be powerful capability, it's just we cannot do it yet
<ogra_> one bae snap is enough for everyone !!!
<niemeyer> ackk: Those two things are unrelated.. do you get the first one, before we move to something else?
<ackk> niemeyer, about sanitizing the keys for the sockets: entries? yes
<niemeyer> ackk: That's a third thing..
 * ogra_ wonders if ackk's choice of nick is because you always have the feeling of agreement if people talk to you 
<ackk> niemeyer, sorry, not sanitizing, ensuring the generated names are safe
<ackk> ogra_, lol, I had this since since forever (actually just "ack" but that's taken here)
<ogra_> :)
<ogra_> it surely gives a positive feeling :)
<niemeyer> ackk: Ok, cool.. yeah, not quite clear how we'll do that
<ackk> niemeyer, isn't validating the key like for snap names not enough?
<ackk> (as you mentioned)
<niemeyer> ackk: No.. as I said, that's a separate problem and a separate solution
<niemeyer> ackk: The file location safety is about confinement
<ackk> niemeyer, right. for that I guess we could change it so that listen-stream in the case of an actual socket file would be prefixed with the snap dir ($SNAP_DATA IIRC?)
<mvo> roadmr: no plans to have multiple bases currently. you can have "no" base by using the "bare" bases which is literally an empty base snap, nothing inside it (not even libc)
<roadmr> mvo: nice. Hey, we put that (and a few other) question(s) in the bug, would you mind answering there? it helps with keeping things documented :)
<roadmr> mvo: (thanks in advance !)
<mvo> roadmr: sounds good, what was the bugnumber again ?
<roadmr> https://bugs.launchpad.net/snapstore/+bug/1715824
<mup> Bug #1715824: Please provide "base" snap data from snaps <Snap Store:Incomplete> <https://launchpad.net/bugs/1715824>
<roadmr> mvo: ^^
<mvo> ta
<zyga-ubuntu> mvo: question about bases that's probably related: can we agree that base snaps cannot have any apps
<zyga-ubuntu> actually, no because core config
<zyga-ubuntu> sorry
<zyga-ubuntu> roadmr: I think mvo is right that base snaps don't have a base
<zyga-ubuntu> roadmr: because they are their own base
<ogra_> zyga-ubuntu, i was about to ask you to explain how we boot core then ;)
<ogra_> (if a base cant have any apps)
<mvo> zyga-ubuntu: we could, but I think morphis has some interessting ideas for base snaps with apps
<zyga-ubuntu> ogra_: apps != programs
<ogra_> ?
<ogra_> what are they then ?
<zyga-ubuntu> mvo: I think I wanted to say that base is its own base snap
<zyga-ubuntu> mvo: then the propery I cared about holds regardless of apps/hooks
<mvo> zyga-ubuntu: yes
<mvo> zyga-ubuntu: I mean, yes, base is its own base snap
<zyga-ubuntu> mvo: or that the "base" property applies to app snaps and gadget snaps but not to base snaps :)
<zyga-ubuntu> yep
<ogra_> why would it apply to gadget snaps ?
<ogra_> (a gadget should pretty much operate standalone without any dependency on a base ... the model assertion should then define the base)
<zyga-ubuntu> ogra_: because those will have hooks as far as I konw
<zyga-ubuntu> *know
<zyga-ubuntu> and any executable process needs a well-defined base
<ogra_> they *can* have hooks (note we dont have a single one that does atm)
<ogra_> currently our gadgets only have bootloader binaries and a snap.yaml with interface definitions
<zyga-ubuntu> ogra_: s/will have/may have/ and I agree
<niemeyer> pedronis, zyga-ubuntu: Any objections to LivePlug instead of ConnectedPlug?
<pedronis> not from me
<Pharaoh_Atem> oh god, I'm so confused now
<niemeyer> Just want to avoid typing 24 characters every single time on every single interface
<Pharaoh_Atem> niemeyer: tab completion ;)
<ogra_> zyga-ubuntu, we should make that optional so you can use gadgets without hooks still with multiple bases via models ... (so that a fedora image could be built using the existing bootloader for a board)
<ogra_> (snapcraft should handle that imho ... if there is a hook, fail the build if there isnt a base defined ... without hooks ... dont care)
<niemeyer> pedronis, zyga-ubuntu: We can even dial them back to interfaces.Plug/Slot again after it's all clean and we're used to the new world
<ogra_> Pharaoh_Atem, +1000
<zyga-ubuntu> niemeyer: hmmm
<ogra_> (you cant even easily copy/paste them because of the colon currently)
<zyga-ubuntu> niemeyer: LivePlug doesn't feel very clear, is there a DeadPlug or is it in some form "ready" (as in live explosives)
<zyga-ubuntu> niemeyer: what made you change your mind about connected plug?
<zyga-ubuntu> niemeyer: +1 on a temporary name though
<niemeyer> zyga-ubuntu: I don't care right now.. will name them as ConnectedPlug as we agreed
<zyga-ubuntu> niemeyer: I don't mind that, it also has a nice "unclashing" property of assumptions
<zyga-ubuntu> (no prior semantics so nobody can get confused about what it used to do)
<mvo> zyga-ubuntu: slightly bad news, bug 1667479 becomes an issue when playing with bases, i.e. when testing and installing bases then the things that consume bases hit this bug, I think morphis just got hit by this
<mup> Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:In Progress by zyga> <https://launchpad.net/bugs/1667479>
<Pharaoh_Atem> what am I supposed to do anymore?
<zyga-ubuntu> mvo: let's sync on this first thing tomorrow, I think we can solve it much how like I initially attempted,
<zyga-ubuntu> mvo: with a way to work around any kernel issues
<mvo> zyga-ubuntu: neat
<zyga-ubuntu> mvo: for today it's too much stack, I think
<mvo> zyga-ubuntu: yeah, I have some more things I need to finish as well
<pstolowski> back
<pstolowski> niemeyer, pedronis, zyga-ubuntu can we resume the discussion (or are you still in the HO ;) ?
<niemeyer> ackk: $SNAP_DATA is probably too restrictive.. software will often want its socket in a predictable place such as /run.. that's the challenge
<niemeyer> pstolowski: Just sent a summary to the forum
<mvo> roadmr: I replied, please let me know if there is aynthing unclear
<roadmr> thanks mvo
<niemeyer> Stepping out for lunch
<pedronis> pstolowski: https://forum.snapcraft.io/t/preparing-the-interfaces-logic-for-connection-hooks/2184
<pstolowski> niemeyer, thanks, reading
<ackk> niemeyer, yeah, for instance LXD expects it as $LXD_DIR/unix.socket
<pstolowski> niemeyer, great summary, looks like a sensible plan. thanks for detailing that!
<mup> PR snapd#3937 closed: interfaces/udev: only 'trigger --action=change', not 'control --reload-rules' <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3937>
<cachio> mvo, about the service snapd.autoimport.service
<cachio> it is in state Active: inactive (dead) since Thu 2017-09-14 14:33:18 UTC; 4 days ago
<cachio> it is making the tests fail on db
<cachio> mvo, should be enough with status=0/SUCCESS?
<mzanetti> mvo, ondra: hi there. The "After=network-online.target" doesn't seem to help
<ondra> mvo some other ideas what to try?
<mup> Bug #1710637 changed: Input falls through to gdm3 and terminates the session on Ctrl+C after udevadm trigger is executed under wayland <amd64> <apport-bug> <artful> <gnome-17.10> <rls-aa-incoming> <wayland-session> <Snappy:Won't Fix> <console-setup (Ubuntu):Fix Released by cyphermox> <gdm3
<mup> (Ubuntu):Invalid> <gnome-shell (Ubuntu):Invalid> <mutter (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1710637>
<ppisati> ogra_: what did you have to do to get the bluetooth to work on the dragonboard? i'm using ubuntu classic ATM
<mup> PR snapd#3943 opened: tests: fix ubuntu core services  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3943>
<ogra_> ppisati, https://bugs.launchpad.net/snappy/+bug/1674509
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<ogra_> has the full set of steps i used
<ogra_> ppisati, mainly the hciattach line and you need to power on the device with bluetoothctl
<ppisati> ogra_: i guess you have this stuff in some systemd service on ubuntu core
<ogra_> we dont yet
<ogra_> the bug is still open ... but it describes what is needed
<ppisati> ogra_: do you have this lp bug handy?
<ogra_> ppisati, you mean beyond the one i pasted 110 lines ago ? :)
<ogra_> *10
<ppisati> ogra_: but that is for the rpi3
<ogra_> uh, oh
<ogra_> sorry, i totally mis-read
<ogra_> the dragonboard should be the same but without the hciattach call
<ogra_> if not, then we are missing something
<ogra_> bluetoothctl should just work afaik
<ppisati> ogra_: it's an old ubuntu classic image, so i'm probably missing something
<ppisati> ogra_: hcitool doesn't show anything, and just invoking 'bluetoothctl' hangs the tty
<ogra_> yeah ... you probably use the old bluez stack
<ppisati> ogra_: i'm on xenial here
<ogra_> well, i'm not sure, does xenial have bluez5 at all ?
<ppisati> me checks
<ppisati> $ dpkg -l | grep -i blue
<ppisati> ii  bluez                               5.37-0ubuntu5.1                       arm64        Bluetooth tools and daemons
<ogra_> the snap is at 5.44
<ogra_> but i guess it shoudl still just work
<ppisati> i think i'm gonna try with ubuntu core, and see if i can deduct what's going on
<ogra_> ppisati, https://forum.snapcraft.io/t/wifi-and-bluetooth-on-snappy-ubuntu-on-a-dragonboard/1297/9?u=ogra
<ogra_> so it just works here ...
<ogra_> your bluetoothctl call should actually give you a shell, it definitely does here
<ppisati> ogra_: ok, i'll give it a try with a more recent bluez stack, let's see
<ogra_> if that doesnt work either i'D guess there is firmware missing
<ogra_> assuming the kernels are actually identical
<ppisati> ogra_: yep, same kernel, and i installed the linux-firmware-snapdragon package - so that should be fine, i don't see any 'missing fw' msg in dmesg
<ogra_> your wlan works fine ?
<ppisati> ogra_: let me try ubuntu core, and see if i can grasp what's going on there
<ppisati> ogra_: i can see the wlan0, but i didn't attach to my wifi network
<ogra_> (we did have to jump through some hoops to fix the MAC addresxs handling of that weirdly broken driver)
<ogra_> i wonder if that would influence BT behaviour
<Chipaca> niemeyer: 0*: bad epoch, or equivalent to 0?
<Chipaca> niemeyer: yes i will transcribe this to the forum
<mvo> cachio: re snapd.autoimport.service> yes, the SUCCESS is enough
<mvo> if we can get a second review for 3835 it can go in
<mvo> also 3807
<mup> PR snapd#3814 closed: interfaces: enable partial apparmor support <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3814>
<cachio> mvo, this is the log
<cachio> https://paste.ubuntu.com/25573688/
<mzanetti> ondra: also, makes me think... even if the network-online.target would work for me, Simon has no ipv6 setup except the zigbee interface in our device... so in his case ipv6 only DNS resolving would never work.
<mup> PR snapd#3889 closed: interfaces: mount host system fonts in desktop interface <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3889>
<mvo> cachio: oh, " Main PID: 1301 (code=exited, status=1/FAILURE)" woudl be really good to figure out why that failed, any hints in /var/log/syslog or anything?
<mzanetti> altough, manually restarting snapd at a later point makes it work... so... dunno, really
<cachio> mvo, no yes, checking
<cachio> no yet
<mup> PR snapd#3927 closed: tests: only run tests/regression/nmcli on amd64 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3927>
<cachio> mvo, not able to get any other log
<cachio> mvo, this error is from the nightly execution
<cachio> i am gonna run in a vm here now to see the log
<mvo> cachio: thank you
<mvo> cachio: I call it a day, but I'm keen to hear tomorrow what you figured out
<cachio> mvo, SURE
<Chipaca> niemeyer: i have some questions: https://play.golang.org/p/AA24O9k_oo
<niemeyer> Chipaca: I'm almost alive again.. will just grab a mate and we can talk if you still have some minutes
<Chipaca> niemeyer: heh. i didn't expect an answer until tomorrow (but i am still here for a bit)
<niemeyer> Chipaca: Okay, checking it out
<niemeyer> Chipaca: For 0*, I think that's an error
<Chipaca> ok
<Chipaca> niemeyer: the others are questions about the behaviour of go-yaml :-)
<niemeyer> Chipaca: We have no -1 epoch of course, so it would be a clear exception and perhaps an indication that there's a misunderstanding about how it works
<niemeyer> Chipaca: Vaguely, what should I be looking for there?
<niemeyer> Chipaca: The fact strings always unmarshal?
<Chipaca> niemeyer: if you run that pastebin (sadly it won't run directly), you'll notice that the custom unmarshaller isn't called in a couple of cases
<Chipaca> in particular, for an empty string, the yaml.Unmarshal call returns an error, but the unmarshaller never got a say
<Chipaca> also for the null value it isn't called, but at least no error is returned
<Chipaca> it just assumes that null value means empty value, which isn't true for us
<Chipaca> (to be clear, these won't block my work, but they were weird enough that i thought i'd check with you if it's working as expected)
<niemeyer> Chipaca: Weird.. for the null case I sort of expected it to not be called
<niemeyer> Chipaca: But I cannot see the behavior on the empty string
<Chipaca> niemeyer: "cannot see" in the sense of "cannot understand"?
<niemeyer> Chipaca: No.. I get no errors see
<niemeyer> Argh
<niemeyer> Chipaca: I get no errors here
<Chipaca> niemeyer: running that code?
<niemeyer> --- `a: ""`:
<niemeyer> struct { A main.Foo }{A:main.Foo{X:"", Y:true}}
<Chipaca> wat
<Chipaca> --- `a: ""`:
<Chipaca> yaml: unmarshal errors:
<Chipaca>   line 1: cannot unmarshal !!str `` into main.Foo
<niemeyer> Chipaca: Let me update my package
<Chipaca> niemeyer: go 1.6?
<niemeyer> Chipaca: There might be changes in tip of go-yaml itself that I don't have
<Chipaca> and i'm on tip?
<Chipaca> (i'm on whatever get-deps got)
<Chipaca> niemeyer: i thought you were the go-yaml guy?
<niemeyer> Chipaca: Nope, still runs fine
<niemeyer> Chipaca: Thankfully I have other people maintaining it by now
<Chipaca> niemeyer: what version of go?
<niemeyer> Roger Peppe specifically
<niemeyer> Chipaca: tip
<Chipaca> niemeyer: can you try with 1.6?
<niemeyer> Chipaca: But I don't expect that to count.. yeah, sure.. let me find it :)
<Chipaca> :-)
<niemeyer> Chipaca: Still works
<Chipaca> ok...
<Chipaca> â¦
<niemeyer> Chipaca: It's probably the proximity with me.. it knows that if it breaks in front of me I will fix it
<Chipaca> niemeyer: so, i just go got it, and it works
<Chipaca> so whatever go get gets, works
<Chipaca> which is good
<Chipaca> but whatever we have in snappy doesn't?
<niemeyer> Chipaca: Ah, okay.. so probably something that was fixed back then
<Chipaca> niemeyer: and whatever we have in vendor is also ok
<Chipaca> because get-deps is no longer updating outside of vendor
<Chipaca> so i still have leftover crud
<Chipaca> :-(
<Chipaca> niemeyer: thank you :-)
 * Chipaca wipes it all clean
<niemeyer> Chipaca: np, and quite curious indeed
<Chipaca> ok, i'm off to walk the dog and make dinner (or viceversa)
<Chipaca> niemeyer: take care, and get more sleep
<Chipaca> niemeyer: sleep is good for you, keeps the cray-cray away
<niemeyer> Chipaca: Thanks, enjoy your evening and hope the dog tastes good
<niemeyer> I should probably not make that sort of joke on such a diverse community :)
<Chipaca> niemeyer: ð­
<niemeyer> Chipaca: One of our favorite bad jokes was translating that to Spanish literally
<Chipaca> niemeyer: there was a skit we'd do where we spoke in Bad Translator Accent, and talk about carros and perros calientes
<Chipaca> we were all sorts of fun
 * Chipaca ~> really off now
<mup> PR snapcraft#1555 opened: store: switch to new endpoints <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1555>
<diddledan> ogra_: I got ring working
<diddledan> ogra_: this is the yaml which worked for me:  https://www.irccloud.com/pastebin/JFeIwqQr/
<diddledan> I'll pop it on github in a sec
<diddledan> there ya go: https://github.com/diddledan/ring-snap
<mup> Issue snapcraft#1556 opened: build-snaps recording <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1556>
<elopio[m]> Hello from riot.im !
<sergiusens> elopio[m] inovative ;-)
<elopio[m]> I'm from the future.
<sergiusens> diddledan do you have an example on how to build a nice project using jhbuild and snapcraft?
<diddledan> sergiusens: older builds of corebird used jhbuild: snapcraft.yaml: https://go.bwlh.at/2xkN0ga corebird.modules file in parent directory: https://go.bwlh.at/2w5UUHs full repo at latest commit which uses jhbuild: https://go.bwlh.at/2xv37bA
<diddledan> I specifically used jhbuild because a lot of gnome stuff it required were newer than 16.04 provided, but I've since moved to using the gnome-3-24 platform snap and ppa
<diddledan> jhbuild was the easiest way I could find to reliably build the gnome deps
<sergiusens> diddledan boo, is `jhbuild` now abandonware? :-)
<diddledan> I think it's still usefull, but people keep moaning at me for large download sizes :-(
<diddledan> of snaps*
<diddledan> I particularly like it for the ability to build on other people's work because you can import other *.modules files from gnome for example which are prepared with all the relevant dependencies and build info for stuff you might rely on
<fmulti> hi, im behind a corporate proxy and cant get snap to  install anything due to the x509 certificate checking
<fmulti> same issue as https://forum.snapcraft.io/t/certificate-substitution-and-snaps/1077 but cant find any resolution
<elopio> sergiusens: I would remove this sentence from the release notes: (for the case of today of only supporting one base)
<elopio> sergiusens: the build-snaps section has a sentence that's not finished: "This release exposes the feature through"
<mwhudson> i can't cleanbuild snapcraft master
<mwhudson> fails with "mkdir: cannot create directory âbuildâ: File exists"
<mwhudson> during the build of apt it seems
<mwhudson> well ok this is my hacked up version, not master but my changes really shouldn't have caused this :)
<kyrofa> mwhudson, I get that if I try to build snapcraft from snapcraft src
<mwhudson> yes, that's what i mean
<kyrofa> mwhudson, my solution was to build it using the deb or snap instead
<mwhudson> oh
<kyrofa> There's _something_ weird there
<mwhudson> yeah ok i have the snap i built from master earlier installed
<mwhudson> so if i refresh that back to candidate it'll work?
<mwhudson> bah
<mwhudson> reverting from a local snap to the store should be easier than this i think
<kyrofa> mwhudson, I don't think you should be able to install local over the store or vice-versa. They could be completely different snaps, but now you're sharing data
<kyrofa> If it's not associated with the store, it could be named anything
<mwhudson> i guess
<Hilikus> hello. i'm trying to understand when do i need to create a custom gadget snap. can someone explain this to me. i see for example a pi2 and pi3 image, but there's also a i386 and amd64 image. is the gadget snap per architecture? how come the pi image is not ARMv7 image?
<kyrofa> Hilikus, normally I'd refer you to ogra_, but it's pretty late for him
<kyrofa> Hilikus, so I'll do my best :)
<Hilikus> awesome :)
<kyrofa> Gadgets have a number of responsibilities. They contain the bootloader, and they also are responsible for exposing the hardware of the board to the rest of the system
<kyrofa> Hilikus, so yes, they are not only arch specific, but hardware specific
<kyrofa> Reference platforms, such as the rpi2/3, amd64, etc. have a gadget already created for them
<kyrofa> But if you're using other hardware, you may have to write one
<kyrofa> So there's one reason to write one. Another reason is that perhaps the hardware isn't being exposed quite how you're like using the official gadget. An example of this is serial ports: gadgets are the only place you can specify udev-like rules to get serial ports consistently mounted and provided to snaps in a confined manner
<kyrofa> As for the pi image arch, I'm afraid I can't field that one
<Hilikus> what exactly does "other hardware" mean? where i get confused is with the i386 and amd64 images. does that mean that i can buy any embedded computer kind of machine and as long as it's an x86 32 or 64bit then i can use the i386 or amd64 images? if not, for what exact type of i386 and amd64 where those made? would they work in a desktop? server?
<Hilikus> by having an i386 and amd64 i get the idea that this image will work almost anywhere as long as the arch matches, but based on what i read from the gadget snap that's not the case
<kyrofa> Yeah as a general rule that's not the case, but amd64 and i386 gadgets are a little more general purpose as I don't imagine they expose any specific hardware and use grub
<kyrofa> You can use them in virtualbox, for example
<kyrofa> Or on a NUC
<kyrofa> Kernels are often device-specific as well
<Hilikus> really? i thought the kernel snap was only arch dependent
<mup> PR snapcraft#1557 opened: cleanbuild: add a --image option to build in a different image <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1557>
<Hilikus> ok, so if udev is really configured in the gadget snap then i think that's clear to me. i can't for example use the x64 ubuntu core image and configure my bluetooth or NFC adapter in it
<Hilikus> i would have to create an image specifically for the peripheral I want to control
<kyrofa> Hilikus, well, other interfaces might cover that. I know there are bluez interfaces
<kyrofa> But I've not experimented with them
#snappy 2017-09-20
<sergiusens> elopio yeah, incomplete as I tend to add examples
<sergiusens> and ack on the other
<sergiusens> elopio btw, snapcraft#1555 has been updated
<mup> PR snapcraft#1555: store: switch to new endpoints <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1555>
<kyrofa> sergiusens, keep an eye on snapcraft#1549, it should be green any moment
<mup> PR snapcraft#1549: plugins: extract pip from python plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1549>
<kyrofa> It took virtually all day
<sergiusens> kyrofa funny, I just looked to see if it was ready ð±
<kyrofa> We hammered travis today
<sergiusens> kyrofa do you have the next PR in line ready?
<mwhudson> what happened here??https://launchpadlibrarian.net/337615189/buildlog_snap_ubuntu_artful_ppc64el_subiquity_BUILDING.txt.gz
<sergiusens> mwhudson did that work with cleanbuild?
<mup> PR snapcraft#1549 closed: plugins: extract pip from python plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1549>
<mwhudson> sergiusens: all the other arches built
<sergiusens> mwhudson oh, just taking notice of the architecture, is there a core snap for this architecture? For classic snaps it is sort of needing during linking as we force the linker to be the one in the snap
<mwhudson> sergiusens: yes, it usually builds fine on ppc64el :)
<mwhudson> i suspect some kind of networking glitch but it's a bit silent
<mwhudson> i guess i'll try again
<sergiusens> mwhudson it seems to have been common today, I had a weird error earlier in a lxd container too and ev was reporting similarly
<mwhudson> hmm reproducible it seems
<mwhudson> (aka it failed three times in a row)
<mup> Issue snapcraft#1452 closed: machine information <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1452>
<mup> PR snapcraft#1529 closed: recording: record the packages installed in the machine <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1529>
<zyga-ubuntu> good morning
<zyga-ubuntu> hey morphis
<zyga-ubuntu> how are you doing
<zyga-ubuntu> mvo: good morning
<mvo> hey zyga-ubuntu, good morning
<zyga-ubuntu> mvo: could I ask you for a 2nd review?
<mvo> zyga-ubuntu: sure
<mvo> zyga-ubuntu: what branch?
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3621
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> jdstrand gave me a +1 but it's a huge branch and I'd like an extra look
<zyga-ubuntu> just in case we missed something over the months
<mvo> ok
 * zyga-ubuntu edits the commit message there
<mup> PR snapd#3905 closed: tests: add new test that checks that the compat snapd-xdg-open works <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3905>
<mup> PR snapd#3920 closed: snap-confine: improve error message if core/u-core cannot be found <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3920>
<mvo> zyga-ubuntu: I go over the queue right now and will take extra time for your Pr
<zyga-ubuntu> mvo: thank you!
<mup> PR snapd#3943 closed: tests: fix ubuntu core services  <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3943>
<mup> PR snapd#3930 closed: cmd/snap-repair: integrate root public keys for repairs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3930>
<mvo> hrm, hrm, artful cups-control-test seems to be broken everywhere
<mup> PR snapd#3940 closed: dirs: fix classic support detection <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3940>
<mvo> zyga-ubuntu: 3939 is still relevant in the light of yesterdays discussion, right?
<zyga-ubuntu> I think so
<zyga-ubuntu> though
<zyga-ubuntu> not sure if we should land it now or add the ConnectedPlug and the other thing
<zyga-ubuntu> mvo: one thing that doesn't match is the sequencing
<mvo> zyga-ubuntu: ok, lets wait for pawel then, it just has two +1 so I was tempted :)
<zyga-ubuntu> mvo: as gustavo outlined a sequence that has this way down, as step 5
<pedronis> hi, yes, in light of yesterday discussion I think it's simple but premature
<pedronis> seems travis had a big queue, seeing things still waiting from yesterday night
<zyga-ubuntu> pedronis: yes, though you can easily start spread locally to test stuff in anticipation
<pedronis> I want to land stuff
<zyga-ubuntu> yes, don't we all
 * zyga-ubuntu has much better mood today
<pedronis> this is all repair stuff, it has no spread tests so far, so your comment is irrelevant either way
<zyga-ubuntu> pedronis: in that case I'm sorry :/
<pedronis> I'm even not quite sure how to run spread tests for it
<mup> PR snapd#3936 closed: data/completion: small tweak to snap completion snippet <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3936>
<pedronis> mvo: #3925 can be merged now , not surw if we want to merge it or squash it though
<mup> PR #3925: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3925>
<mvo> pedronis: I have a look, 3935 is almost ready one tests needs tweaking (see PR)
<pedronis> mvo: it's the spread test that testeds it did nothing
<pedronis> mvo: I fear we just need to kill it, we could have a write a fake service but the end result wouldn't be that different from the integrationy unit test
<mvo> pedronis: yeah, just kill it
<mup> PR snapd#3925 closed: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3925>
<mup> PR snapd#3931 closed: interfaces/builtin: allow receiving dbus messages <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3931>
<mup> PR snapd#3918 closed: hooks: substitute env vars when executing hooks <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3918>
<mup> PR snapd#3926 closed: snap: implement `snap {repair,repairs}` and pass-through to snap-repair <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3926>
<mvo> zyga-ubuntu: 3807 looks like it needs some test tweaks
<zyga-ubuntu> mvo: looking
<zyga-ubuntu> ah, exellent
<zyga-ubuntu> CE asks about that often
 * zyga-ubuntu looks
<kalikiana> good morning, snappy
<zyga-ubuntu> indeed, though it might rain later
<pedronis> mvo: I was looking at #3934 , it seems the rework to make WriteOutput/ScriptIndented to return error and make the caller deal isn't finished
<mup> PR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>
<pedronis> mvo: commented in the PR as well
<pedronis> otherwise it would be landable IÂ think
<mvo> pedronis: uh, sorry for this, I fix that in a bit
<pedronis> mvo: btw, work to expose base in the store api has started
<pedronis> but you might have been pinged already about that
<mvo> pedronis: yes
<zyga-ubuntu> hmm
<zyga-ubuntu> "interface-cups-control" is a bit broken
<mvo> zyga-ubuntu: yes, only in artful
<pedronis> mvo: in #3933 we need to ignore if the symlink already exists
<mup> PR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>
<pedronis> or remove and recreate
<mvo> pedronis: aha, thanks for this, I check if the symlink exists but there is of course the TOCTOU issue, I fix accordingly. good catch
<mvo> pedronis: 3934 also shows the error cases are under-tested, I fix that now too
<pedronis> well some other tests failed
<pedronis> but yes
<mvo> pedronis: untested and buggy, once I add tests they show. oh well, tests ftw
<mup> PR snapd#3901 closed: snap-seccomp: run secondary-arch tests via gcc-multilib <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3901>
<pstolowski> zyga-ubuntu, mvo hey, any idea why .deb build fails on newly added man page like this http://pastebin.ubuntu.com/25578293/ ? Note the new manpage gets created in packaging/.../tmp
<zyga-ubuntu> pstolowski: looking
<zyga-ubuntu> pstolowski: is the PR updated?
<zyga-ubuntu> pstolowski: typically man pages are compressed
<zyga-ubuntu> pstolowski: so maybe you need to change the rule to 1* or 1.gz or similar
<pstolowski> zyga-ubuntu, I think I followed all the patterns of snap-confine.5, also updated debian packaging files but apparently there is still somthin magic happening somewhere
<pstolowski> zyga-ubuntu, PR updated now
<zyga-ubuntu> pstolowski: let me look quickly
<zyga-ubuntu> aha, I think I see it
<zyga-ubuntu> pstolowski: pushing
<zyga-ubuntu> (just letting tests finish actually)
<pstolowski> zyga-ubuntu, what was it?
<zyga-ubuntu> pstolowski: needless rule
<zyga-ubuntu> you'll see in a moment
<pstolowski> k
<zyga-ubuntu> pstolowski: pushed now
<pstolowski> zyga-ubuntu, I see.. hmm interesting. let me test
<zyga-ubuntu> pstolowski: I tested locally
<zyga-ubuntu> and spread will test for other systems
<pedronis> mvo: this is a bizarre failure:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/i386/s/snapd/20170920_081905_d1ef4@/log.gz  epoll failing
<mvo> pedronis: hm, yes, artful
<pedronis> that's a EBADF btw
<pedronis> ??
<pedronis> mvo: are we forgetting to stop a mock server ? so weird fork interaction?
<zyga-ubuntu> pedronis: 9 is EBADF
<pedronis> zyga-ubuntu: I just wrote that
<pedronis> s/so/some/
<zyga-ubuntu> right, I thought you were asking for confirmation (because of the ?? below)
<pedronis> no, just wondering how the go runtimee got one
<pedronis> memory corruption?
<pedronis> it's also i386 fwiw
<pstolowski> zyga-ubuntu, it builds fine indeed, thanks!
<pstolowski> zyga-ubuntu, I now need to tweak the formatting, it doesn't look as expected yet
<zyga-ubuntu> pstolowski: you can test it locally easily
<zyga-ubuntu> pstolowski: just open with man
<pstolowski> zyga-ubuntu, yeah, just struggling with rst, is it documented anywhere?
<pstolowski> zyga-ubuntu, nvm, found some docs
<zyga-ubuntu> pstolowski: look at other man pages
<zyga-ubuntu> pstolowski: there's very litte syntax to use
<pstolowski> zyga-ubuntu, indeed, but it doesn't seem to like indentation in my {.. json snippet for example
<pstolowski> zyga-ubuntu, ok, nailed it
<zyga-ubuntu> pstolowski: \o/
<ogra_> diddledan, wow, thats quite  a snapcraft.yaml (my test one only used the existing debs an a lot of hackery around them)
<pstolowski> zyga-ubuntu, k, pushed, adressing your comments
<zyga-ubuntu> thank you
<pstolowski> ... and I just realized it will need an update when #3852 lands ;)
<mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
<pstolowski> but that's fine, let's just land
<popey> diddledan: ogra_ joedborg we're prepping a doc which captures the 'assumed knowledge' (bugs/lack of docs) 'we' (snapcrafting people) have when making snaps. Could you take a look and add anything you know you do which is probably a bug or not in a doc anywhere?
<popey> diddledan: ogra_ joedborg  https://docs.google.com/spreadsheets/d/1Ii1Q3MFY1W2Tt__JB4sZ05CzP05TwDgB4hN8Z6fR1Hw/edit#gid=0
<popey> (so we can turn these janky things into bugs/docs)
<joedborg> popey: will do!
<popey> thanks
<ppisati> ogra_: i just tested the daily snapdragon image, and it has the same problem as the 'old' rpi images - no snaps are listed
<ppisati> $ snap list
<ppisati> No snaps are installed yet. Try "snap install hello-world".
<ppisati> ogra_: it's the current daily FWIW
<mvo> pstolowski: a question about https://github.com/snapcore/snapd/pull/3915/files#diff-a058ac805f223376d159acc796573e68R175 - do we have a test for this case? i.e. when can it happen? I am currently poking at this code a bit and was wondering about this case
<mup> PR #3915: cmd/snap: return empty document if snap has no configuration <Created by stolowski> <https://github.com/snapcore/snapd/pull/3915>
<mvo> hrm, hrm, master broken in debian-unstable runner_test:296
<pstolowski> mvo, looking
<zyga-ubuntu> I see it
<zyga-ubuntu> runner_test.go:390:
<zyga-ubuntu>     c.Assert(err, Equals, repair.ErrRepairNotModified)
<zyga-ubuntu> ... obtained *url.Error = &url.Error{Op:"Get", URL:"http://127.0.0.1:43035/repairs/canonical/2", Err:(*net.OpError)(0xc420010640)} ("Get http://127.0.0.1:43035/repairs/canonical/2: dial tcp 127.0.0.1:43035: i/o timeout")
<zyga-ubuntu> ... expected *errors.errorString = &errors.errorString{s:"repair was not modified"} ("repair was not modified")
<zyga-ubuntu> hmmm
<zyga-ubuntu> why on debian and not here though
<mvo> zyga-ubuntu: yeah, also I tried to run tests with go 1.9 from the go snap and got no error
<zyga-ubuntu> I'm waiting for debian to boot but no ideas yet
<zyga-ubuntu> especially, why here, other tests also use mock server
<zyga-ubuntu> could it be timing?
<zyga-ubuntu> 5 retries
<zyga-ubuntu> 1ms exponential
<zyga-ubuntu> up to one second
<mvo> pstolowski: context is https://github.com/snapcore/snapd/compare/master...mvo5:cmd-get-tweaks?expand=1 which was a bit of an experiment to get rid of some of the nesting in get (not sure if you like it or not, probably best to look at the resulting file not the diff)
<zyga-ubuntu> mvo: my guess is debian kernel scheduling
 * zyga-ubuntu cries whenever we use timing-based tests
<pedronis> mvo: same epollwait problem on zesty, it seems a real issue somehow
<pedronis> mvo: I wonder what is happening:  https://docs.google.com/document/d/1_8n09MPn8JHOyD6VrnLVcMJUvLFKeirCSayY6iEDD5w/edit#
<zyga-ubuntu> mvo: so... it just passed for me on linode
<zyga-ubuntu> hmmm
<pedronis> oops
<pedronis> mvo: wrong link
<pedronis> mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170920_095013_d1ef4@/log.gz
<zyga-ubuntu> pedronis: looking at https://github.com/golang/go/issues/11498 (which is arguably an accidental match) it looks like we are closing something twice and hence killing an already reused FD number
<pstolowski> mvo, added one more test case, however it's tricky to fully cover this case because 'isTerminal' prevents it - futher down we default to json output + warning on stderr instead of list because of that
<Chipaca> niemeyer: added a couple of questions to the epochs topic, if you could when you can
<ppisati> ogra_: ah, never mind, apparently changing sd card fixed the 'snap list' issue
 * Chipaca considers making epochs be written only in roman numerals
<pedronis> zyga-ubuntu: mvo: there is code that closes statusW twice
<pedronis> could that be it?
<zyga-ubuntu> pedronis: yes
<zyga-ubuntu> pedronis: that can definitely cause this
<pedronis> I thought the runtime would check for something
<zyga-ubuntu> pedronis: I don't think it can
<mvo> pedronis: ohhh, that sounds like it
<zyga-ubuntu> pedronis: well, in pure go world it could
<zyga-ubuntu> pedronis: reset the fd to -1 or similar after closing
<zyga-ubuntu> that's a safe way to do it
<pedronis> zyga-ubuntu: IÂ mean have a flag around things, but maybe it doesn't
 * zyga-ubuntu nods
<zyga-ubuntu> pedronis: are you making a PR to change this?
<pstolowski> mvo, nb, thanks for looking at refactoring this.. the logic good convoluted indeed, i'm having hard time every time looking at it
<pedronis> zyga-ubuntu: ?
<zyga-ubuntu> pedronis: "there is code that closes statusW twice"
<mvo> pstolowski: yeah, its a bit tricky but of course there is a lot of conditions
<pedronis> zyga-ubuntu: it's probably something for mvo to fix on the failing branch
<mvo> pstolowski: anyway I might push something very small and see if I can go from there
<pedronis> zyga-ubuntu: mvo wrote that code , I'm not even sure IÂ remember why the code is like it is
<pstolowski> mvo, on the positive side, we have good test coverage
<mvo> pedronis: sure
<mvo> pstolowski: yeah, that makes it very nice to work on the refactor \o/
<mvo> pedronis: I'm looking at this code now
<zyga-ubuntu> mvo: does this make any sense to you? http://pastebin.ubuntu.com/25578825/
<mvo> zyga-ubuntu: not right away
<mvo> pstolowski: 3915 can go in once tests are green, I send a small PR your way for review, once we are happy I can do a proper pr
<mvo> pedronis: I fixed the double close, thanks for catching this
<pedronis> mvo: hopefully it was that
<mvo> +1
<pedronis> mvo: other unit test failure here:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170920_100802_d1ef4@/log.gz
 * zyga-ubuntu -> tea
<pedronis> something about TestRepairHasCorrectPath
<pedronis> but seems a timing issue
<pedronis> or something
<pedronis> bit confused
<ogra_> ppisati, well, keep an eye on it ... if changing the Sd fixes it there is something weird ... note thuogh that the snap list issue also typically happens if the SD was mounted during dd
<niemeyer> Heya
<niemeyer> Chipaca: Looking
<pedronis> zyga-ubuntu: something very weird going on there
<pstolowski> mvo, sounds good,thanks!
 * sergiusens waves good morning
<pedronis> mvo: the other branch also has double close problems
<pedronis> bit of a whack-a-mole landing these last bits
<pedronis> :/
<mup> PR snapcraft#1555 closed: store: switch to new endpoints <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1555>
<pedronis> mvo: is it annoying to split out the statusW fix to its own PR ?
<pedronis> I'm getting a bit confused by all the autopkgtest red in your PRs
<pedronis> I wonder why we didn't notice it before as well, that code is already on master :/
<cachio> mvo, hey
<cachio> still see + snap install --edge test-snapd-upower-observe-consumer
<cachio> error: snap "test-snapd-upower-observe-consumer" not found (at least in channel
<cachio>        "edge")
<mvo> pedronis: no, I can split it out, no problem
<pedronis> thank you
<mvo> cachio: checking
<pedronis> mvo: it seems also that we have issues with TestRepairHasCorrect path, seems timeout is too low and also something is off on some releases
<pedronis> s/Correct path/CorrectPath/
<mvo> cachio: fixing this now
<cachio> mvo, tx
<cachio> mvo, i was researching yesterday the autoimport service issue
<cachio> mvo, it is failing when the device is using user assertions to create users by default
<cachio> mvo, does it make sense?
<ondra> mzanetti are you around, mvo and pedronis are trying to figure out how to fix the problem
<mup> PR snapd#3915 closed: cmd/snap: return empty document if snap has no configuration <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3915>
<mup> PR snapd#3944 opened: snap-repair: fix double close of statusW (thanks to Samuele) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3944>
<pedronis> mvo: thank you, let's see how that goes and then we can merge it in the others
<diddledan> popey: I've just requested access to the google doc - my account is @bowlhat.net
<ogra_> so british !
<diddledan> :-p
<mup> PR snapd#3945 opened: snap: refactor cmdGet.Execute() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3945>
<popey> diddledone!
<diddledan> yey
<mvo> pedronis: +1
<mvo> pedronis: thanks a lot for baby sitting these branches \o/
<mvo> cachio: *now* it should be there, sorry, amd64 and arm64 are just too close :/ I overlooked it
<mvo> cachio: it being test-snapd-upower-observer-consumer
<cachio> mvo, great, tx
<cachio> mvo, i am registering the device now but i have the same errror with the ubuntu-core-services
<ogra_> mvo, that will be fixed once we switched to compiler names for arches ... aaaargh64 isnt that close to x86_64 :)
<cachio> mvo, not sure if I need to refresh the core after that
<mvo> ogra_: will we switch? it seems like we trade amd64/arm64 against x86/x86_64 which is arguable a bit better
<ogra_> i dont know, i just know there was a discussion started about it
<mvo> ondra, mzanetti: quick question, do you have the dns error just for refresh? or for any snapd network operation?
<mvo> cachio: sorry, I have too many parallel conversations right now, what is the same error for ubuntu-core-services? it means auto-import did not succeed but failed? and we have no log or any indication in what way it failed :( ?
<cachio> well, I have, 2 minutes, but it is really short the log
<mvo> cachio: no rush, take your time :)
<cachio> mvo, what I saw is that when I use a user assetion with the image that test fails
<cachio> and if I run manually console conf to register hte user, the test pass
<mvo> cachio: so the user assertion is valid? but does not work on first-boot?
<diddledan> for your eyes only https://forum.snapcraft.io/t/proposal-additional-package-sources/2199
<mvo> pedronis: 3933 is ready now but needs a second review
<cachio> mvo, this is what I have https://paste.ubuntu.com/25579273/
<mvo> cachio: that is ok Sep 19 18:38:05 localhost.localdomain snap[1072]: error: cannot create user: device already managed
<mvo> cachio: I mean the error is expected if the machine is already managed
<cachio> mvo,  Failed to start Auto import assertions from block devices.
<cachio> mvo, not sure if it is related to the previous error in the log
<mvo> cachio: yeah, its the followup on the previous error
<mvo> cachio: are the test machines only configured this way that they have this auto-import assertion? if so we may just need to blacklist this test or just check that it was run at all, regardless of ok or not
<mvo> (the later is probably the best choice)
<cachio> ok
<cachio> I am updating the code of the machines setup to first register a valid user and then refresh the core, does could help?
<cachio> mvo, ~
<pedronis> mvo: there were failures like this in #3933:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170920_100802_d1ef4@/log.gz
<mup> PR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>
<pedronis> mvo: as I said TestRepairHasCorrectPath needs some tweak
<mvo> cachio: probably, if the boot that does the tests does not have the block devices things should work
<mvo> pedronis: ta
<pedronis> mvo:Â I saw it fail also in another different way, but that might be the other branch
<pedronis> where the new code is not there
<pedronis> mvo:  we probably need to land #3944  #3933 and #3934 in that order
<mup> PR #3944: snap-repair: fix double close of statusW (thanks to Samuele) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3944>
<mup> PR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>
<mup> PR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>
<pedronis> mvo: otherwise is a bit too hard to tell if we solved the issues or not
<mvo> pedronis: yeah
<mvo> pedronis: I just pushed a fix for 3933, this should be good now, once that is green I merge the fix into the other branches
<mvo> pedronis: sorry for the back-and-forth
<mvo> zyga-ubuntu: yay, 3807 looks ready we just need to find a second reviewer
<mvo> zyga-ubuntu: actually jdstrand said "looks fine" soâ¦
<zyga-ubuntu> mvo: yes, I asked jamie to review
<zyga-ubuntu> oh, he did?
<zyga-ubuntu> ah
<zyga-ubuntu> I see, earlier
<zyga-ubuntu> well, let's merge it, I can conjure the fix for NFS that CE requested
<mvo> zyga-ubuntu: yeah, very early
<mvo> zyga-ubuntu: done
<zyga-ubuntu> great, thank you!
<mup> PR snapd#3807 closed: cmd/snap-confine,packaging: import snapd-generated policy <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3807>
 * zyga-ubuntu gave up debugging repair tests on debian
<mvo> zyga-ubuntu: thats sad, it means I will have to do it
<pedronis> those failures were strange
<mvo> do you think they are transient? is master ok again?
<pedronis> some seemed to be about the fake directories
<pedronis> doesn't make much sense
<zyga-ubuntu> mvo: they were failing each time the same way for me (interactively)
<pedronis> anyway repair tests are a bit in a strange state atm
<pedronis> IÂ would wait to get a couple more things landed (with fixes)
<pedronis> before pursuing that
 * zyga-ubuntu nods
<sergiusens> hey niemeyer, mind looking at https://forum.snapcraft.io/t/proposal-additional-package-sources/2199/2 ?
<niemeyer> sergiusens: Looking
<pedronis> mvo: it's not  statusW,  same issues in that branch :/
<pedronis> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170920_125631_2e002@/log.gz
<pedronis> or at least the change doesn't help
<sergiusens> kalikiana do you have a fix lined up to only push snaps into the container if they differ?
 * zyga-ubuntu goes to make food and will be back with layouts shortly
<mvo> pedronis: yeah, I'm in a debian machine now and I can reproduce it ~50% of the time
<mvo> pedronis: also the other errors are super strange
<pedronis> mvo: I wonder which change introduced it though, because it appeared recently afaik
<pedronis> time to bisect?
<mvo> pedronis: yeah, if I don't find anything soon I will bisect
<pedronis> also it seems indeed related to new go, because on 1.6 it doesn't seem to fail
<mvo> yeah
<mvo> or debian
<mvo> I see the failure with go1.7.4
<mvo> in testing
<mvo> debian/testing
<mvo> which is the same version that I have on my zesty system
<mvo> so its even more mysterious
<pedronis> well debian has a newer go,    we see it fail in zesty and artful
<mvo> I can not reproduce the failure in my zesty system
<zyga-ubuntu> mvo: also works on my artful FYI
<pedronis> interesting I seen autopkgtest for zesty fail with that
<mvo> so it migt be artful
<pedronis> (unless IÂ misremeber)
<mvo> 4.9 is debian
<mvo> 4.10 is what I have here
<mvo> in zesty
<mvo> pedronis: oh, interessting, I have a look at the autopkgtests
<pedronis> mvo: this is a failure on zesty for example:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170920_131417_2e002@/log.gz
<mvo> pedronis: yeah, also kernel 4.10
<mvo> pedronis: so strange
<sergiusens> kalikiana mind updating this branch https://github.com/snapcore/snapcraft/pull/1382 ?
<mup> PR snapcraft#1382: rust plugin: make libc configurable <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382>
<pedronis> mvo: does go test -race tells anything interesting  on debian ?   (nothing interesing on 1.6)
<mvo> pedronis: not right now
<mvo> pedronis: I mean, no :/
<pedronis> mvo: ok, I rememver correctly btw:  at least 1.6 had code such that calling Close twice shouldn't be a problem, at least from the same goroutine
<cachio> pstolowski, https://paste.ubuntu.com/25579877/
<cachio> this test is failing on edge for ubuntu core
<zyga-ubuntu> apparently 15 years later schoolkids still bully kids with longer hair
<cachio> pstolowski, is it new? first time i see it fail
<pedronis> mvo: so double closing shouldn't be a problem,  later version have more complicated code but the result is the same
<pedronis> mvo: calling Close twice should error, not close the descriptor again
<zyga-ubuntu> pedronis: is the descriptor copied (as in memcpy) anywhere?
<pstolowski> cachio, yes. it's very new, it just landed today or yesterday
<pedronis> zyga-ubuntu: ?
<pstolowski> cachio, I'll investigate
<zyga-ubuntu> pedronis: golang runtime errors aside it means we somehow did close a descriptor that was still in the epoll
<pedronis> zyga-ubuntu: yes, but IÂ doubt it's us closing it
<pedronis> I fear the runtime
<zyga-ubuntu> aha
<cachio> pstolowski, nice, we have fast feedback now :)
<pedronis> mvo: have you tried print the StatusW/R   descriptor number to see if they even match with what is in the error?
<pedronis> zyga-ubuntu: internally when we close a runtime fs it replaces the fd number with -1
<pedronis> so the next Close should see that and error
<mvo> pedronis: no, I'm working on the other failures right now
<pedronis> ok
<mvo> pedronis: but thanks for this, I will try that next
<mvo> pedronis: I have a new theory, some of the other failures are because tests in autopkgtest runs as root but local run as user
<pedronis> missing SetRootDir ?
<mvo> pedronis: yeah, or incorrect paths, I'm just look at this
<ondra> mvo more update from simon, so 10seconds delay helps, but does not cure it 100%, when they increased time out to 60 seconds, then they are not able to reproduce.
<niemeyer> Chipaca: Forgot to mention, but your point about the conflict between snap pack and snap ack is a good one, btw...
<sergiusens> mpt mind looking at https://forum.snapcraft.io/t/mechanisms-for-converging-store-and-snap-metadata/2200 ?
<niemeyer> Chipaca: Thinking about something else that would be equivalently terse and nice..
<ondra> mvo they are wondering if start of it is here https://github.com/snapcore/snapd/blob/release/2.27/httputil/retry.go#L87
<Chipaca> niemeyer: yesterday in the standup i said it as well, and somebody proposed an alternative that was nice
<Chipaca> but i don't remember it, or who
<Chipaca> zyga-ubuntu: was it you?
<niemeyer> sergiusens: Per note above, "pack" is probably changing due to the similarity with "ack"
<ogra_> snap ack -> snapprove
<ogra_> ;)
<niemeyer> ogra_: That one has sailed
<ogra_> i wasnt serious anyway :)
<mvo> pedronis: and I also suspect the epoll issue is root specific for whatever reason
<mvo> ondra: I have it on my list but there is amaster failure right now
<mup> PR snapd#3946 opened: snap: add new `snap pack` and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3946>
<sergiusens> niemeyer ok, it wasn't clear to me if you were intending to moving the "packing/assembling" logic back to the snap command though (back in Budapest September 2015) we had decided that `snappy build` would be `snapcraft snap`... to be clear, I am fine revisiting decisions made in the past :-)
<ondra> mvo cool thanks
<niemeyer> sergiusens: I'm not suggesting that change right now
<ondra> mvo but please keep it high on priority list, as this is critical error for us
<niemeyer> sergiusens: For now I'd just like to get a command name that is the same on snap and snapcraft
<Chipaca> incident at the boys school, need to run
<niemeyer> Chipaca: o/ take care
<sergiusens> but if we do `snap <pack-placeholder-name>` we should ensure the snap command can be installed without snapd to support build systems
<niemeyer> Chipaca: Hope it's all well there
 * sergiusens is looking out the window from a coffee shop as the gusts of wind blow things
<niemeyer> sergiusens: Yeah, let's not get there right now..
<sergiusens> they announced 40km/h to 60km/h wind
<mpt> looking
<sergiusens> niemeyer gotcha on the home of the logic, we should still sleep on it to figure out a good name if `snap-dir` is not the best
<niemeyer> How about... squash :)
<niemeyer> sergiusens: ^
<niemeyer> mvo: ^
<sergiusens> sounds kind of weird to me at first sight but I'll let it sit there in the back of my head and see if I grow on it
<zyga-ubuntu> mvo: about https://github.com/snapcore/snapd/pull/3946 - should there be a cmd_pack.go somewhere?
<mup> PR #3946: snap: add new `snap pack` and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3946>
<niemeyer> sergiusens: You mean it's weird to say squash when you're squashing something? :)
<niemeyer> sergiusens: The outcome of this command consists almost entirely of running mksquashfs
<zyga-ubuntu> mvo: did you forget to add it? I don't see how "snap pack" would work otherwise
<mvo> zyga-ubuntu: oh oh
<zyga-ubuntu> git add? :D
<mvo> *cough*
<mvo> zyga-ubuntu: good that it is renamed :)
<niemeyer> sergiusens: With that said, I sort of agree otherwise.. for someone that isn't into the details, it may be an awkward choice
<niemeyer> mvo: Let me look further into the dictionary :)
<mvo> niemeyer: snap collect?
<niemeyer> mvo: Misses the idea of "bundling".. actually.. bundle?
<mvo> niemeyer: bunble works for me, the downside is that we can create a "bundle" of snaps in the future but I guess that is rather theoretical
<sergiusens> niemeyer the first to things that popped into my mind were git squashing and the sport my wife plays :-)
<sergiusens> bundle has a better ring
<niemeyer> mvo: Hmm
<niemeyer> mvo, sergiusens: "assemble" was my original idea back then.. it felt sort of long, but I'm starting to appreciate it again given these corners we're finding on each of the other options
<sergiusens> we could go back to assemble
<sergiusens> +1
<mvo> +1 from me as well, long but pretty precise
<sergiusens> it was originally called assemble :-)
<sergiusens> in snapcraft at least
<niemeyer> Cool, let's go with it then..
<niemeyer> It's okay that it's long.. snapcraft is what most people will use anyway
 * mvo will do
<niemeyer> I was also looking for something that has a reasonable antonym for obvious reasons
<niemeyer> disassemble will do
<mup> PR snapd#3947 opened: snap-repair: fix tests when running as root <Created by mvo5> <https://github.com/snapcore/snapd/pull/3947>
<mvo> pedronis: this should fix the first part of the failures
<mvo> (the easy part sadly)
<pedronis> ok
<mup> PR snapd#3944 closed: snap-repair: fix double close of statusW (thanks to Samuele) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3944>
<pedronis> mvo:  does running with -check.vv helps narrowing down the other issue to a single test?
<pedronis> is the other issue related to root as well? or not?
<mvo> pedronis: good news, I have not seent the other failure anymore, however I now see http://paste.ubuntu.com/25580143/ in ~1/10 runs
<mvo> pedronis: I'm in the same debian machine with my first fix applied and no longer see the panic with the epoll, just this i/o timeout
<mvo> pedronis: this one I only see in debian, I can not reproduce on zesty
<pedronis> that is curious
<pedronis> that the epoll went away like this
<pedronis> but good IÂ suppose
<pedronis> mvo: is it always the same test that times out, or a particular one?
<mvo> pedronis: I was wrong, its back, races are annoying
<mvo> pedronis: it looks like its happning in TestFetch500
<mvo> pedronis: looks like teardown
<mvo> pedronis: checking, it appears to be only TestFetch500
<pedronis> it doesn't do anything special
<pedronis> afaict
<mup> PR snapd#3942 closed: doc: snapctl man page <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3942>
<zyga-ubuntu> niemeyer: ^ I'm somewhat unhappy about that manual page, it's fine to link to the forum but I think that manual page was well worth having, even if people find out about the forum
<niemeyer> zyga-ubuntu: What specifically do you disagree with in my comments?
<zyga-ubuntu> niemeyer: both I suspect
<niemeyer> zyga-ubuntu: As you can imagine, I still have no idea about what you mean
 * Chipaca back
<zyga-ubuntu> niemeyer: we have non-generated manual pages today, not sure what makes it better if it is generated (in this particular case)
<niemeyer> zyga-ubuntu: Do we have a non-generated manual page for the snap command?
<zyga-ubuntu> niemeyer: and not sure why manual page cannot document how to use snpactl
<zyga-ubuntu> niemeyer: we have non-generated manual pages for snap-confine, snap-discard-ns
<niemeyer> zyga-ubuntu: Do we have a non-generated manual page for the snap command?
<zyga-ubuntu> niemeyer: you know that I know the answer, I don't see the value of generating a piece of prose in the right format; there are no sophisticated options that we save time by maintaining automatically by generating anything
<niemeyer> zyga-ubuntu: The question is specific, on purpose.. there's a reason why we don't have a hand-written manual page for the snap command, so I'm waiting for you to let that sink and acknowledge that reason
<mvo> pedronis: its very strange, it looks like in TestFetch500 it hangs in runner.Fetch() and not hit the test server in some cases
<zyga-ubuntu> niemeyer: is that reason the fact that it is a complex command with sub commands?
<mvo> pedronis: almost as if httptest.NewServer() is not fully ready when it returns
<niemeyer> zyga-ubuntu: No.. the reason is that we write documentation for every single one of those commands, already. Dozens of commands. There's literally zero value in hand-writing that exact same documentation again, elsewhere.
<zyga-ubuntu> niemeyer: I disagree about the assumption that "foo --help" and "man foo" provide similar content
<zyga-ubuntu> niemeyer: they provide a subset of the content that is the same but typically manual pages go to greater length about details
<mvo> pedronis: sstrace shows me a EAGAIN error in accept4() but the trace is really hard to read
<zyga-ubuntu> niemeyer: (and as I said, it's fine to say "more details are on the forum http://url/", but most people know about man pages and don't know about a software-specific forum
<niemeyer> zyga-ubuntu: We've repeatedly failed to maintain documentation up-to-date in multiple places, and we're failing that again. See snapcraft.io if you want an example. There's absolutely no way we will have an ad-hoc hand-written manual page going in without us establishing a strategy for it not to fail.
<pedronis> mvo: this is all bizarre because we have a lot of tests like this in many other unit tests, I wonder what is different here
<niemeyer> zyga-ubuntu: We *have* a manual page for snap, today.
<zyga-ubuntu> niemeyer: how is it any better if that prose is written in snapctl.go and echoed via --man mechanism? it's still text that needs maintenance
<niemeyer> zyga-ubuntu: If you would like to improve the documentation about any of those commands, by all means please do. You know where to do that.
<niemeyer> zyga-ubuntu: Exactly!
<niemeyer> zyga-ubuntu: That text already exists!
<mvo> pedronis: yes, especially since it is always the same test apparently but we have many that use the retry strategy and that use the mock server
<niemeyer> zyga-ubuntu: Type in: snapctl get --help
<pedronis> mvo: does it fail also run alone?
<niemeyer> zyga-ubuntu: Why on earth would we maintain that by hand elsewhere?
<zyga-ubuntu> niemeyer: "snapctl --help" doesn't tell you anything about the purpose of the tool
<zyga-ubuntu> niemeyer: it's fine to generate everything if we can put that text somewhere
<niemeyer> zyga-ubuntu: Feel free to fix that, after layouts. :)
<zyga-ubuntu> niemeyer: (and arguably showing it in --help is not very useful)
<niemeyer> zyga-ubuntu: Not okay to duplicate documentation. We've been there, I know where this goes.
<mvo> pedronis: it does not, it works when I run it alone, it survived ~400 runs now
<pedronis> mvo: so it's the combination with something else, but what?
<zyga-ubuntu> niemeyer: I still feel that pawel did the work that's definitely good enough to be useful to people (people cared because we have a bug report on this) and we closed the PR because the text was not going through the generator
<zyga-ubuntu> niemeyer: that's all I wanted to say, we've made our points I think
<niemeyer> zyga-ubuntu: I closed the PR because it does something we don't want to do, for reasons I justified and backed by history. We're not having a loose piece of text that will definitely go unmaintained. Let's do it properly.
<niemeyer> pstolowski: Please let me know if you'd like to discuss the approach further. As mentioned in the PR, just look at the handling of --man in cmd_help.go and you'll clearly see how this works.
<pstolowski> yes, that's a bit disappointing and unexpected tbh, but I'm not going to argue about that. I knew of --man but as discussed earlier with zyga-ubuntu, this looked a bit limiting vs a more rich document
<pstolowski> i was under impression (wrong one apparently) that we're moving away from auto-generated man
<mvo> pedronis: ok, when I skip the fetch500 it appears in fetchBroken so it seems related to the retry strategy
<niemeyer> pstolowski: Do you seriously want to write and maintain the snap manual page by hand?
<pedronis> mvo: are we sure is not related to tests before?
<pedronis> mvo: you said it works alone
<mvo> pedronis: it could be, let me try some more
<mvo> pedronis: it does
<pstolowski> niemeyer, depends how rapidly the command changes. snapctl does't change too often
<pedronis> mvo: what if you run just cmd_done_retry_skip_test.go and Fetch500 ?
<pedronis> that's the only thing that is recent
<pedronis> ly added
<cachio> pstolowski, the snap-run-hook test is also failing on my dragonboard
<niemeyer> pstolowski: It doesn't matter.. even if it changes just once every month, why do you want to maintain the exact same piece of information in two different places?
<cachio> i have a debug session open
<cachio> pstolowski, do you need some information?
<niemeyer> pstolowski: ... when we tend to fail to maintain documentation up-to-date even when it is in *one* place.
<pedronis> mvo: maybe just this  +go test -check.vv -check.f "StatusHappy|Fetch500"  ?
<pstolowski> cachio, is it possible to recreate on linode? if so, can you give me the details (in the meantime I'm checking locally)
<pedronis> mvo:  or +go test -check.vv -check.f "TestStatus|Fetch500"
<mvo> pedronis: yeah
<pedronis> does it fail like that?
<mvo> pedronis: yes, I found it I think! misisng close in one of the status tests, thank you so much for your intuition on this one
<pedronis> the os.Pipe in status Happy?
<mvo> pedronis: yes
<pedronis> seems a bug in the rumtime though :)
<pedronis> sorry, IÂ mean :(
<pedronis> it shouldn't interfere like that
<cachio> pstolowski, I can reproduce it just on real ubuntu cores
<cachio> pstolowski,
<cachio> https://paste.ubuntu.com/25580415/
<cachio> it is not resolving the env vars
<ppisati> ogra_: didn't we have a '--dangerous' switch (or something similar) when installing custom kernels? i mean, to avoid the "cannot replace signed kernel snap with an unasserted one" error
<mvo> pedronis: definitely, very strange
<cachio> TEST_COMMON=$SNAP_COMMON instead of TEST_COMMON=/var/snap/basic-hooks/common
<ogra_> ppisati, i think that only works if the original kernel snap was actually a local snap when you built the image
<mvo> pedronis: the side-effects of this are not at all obvious
<cachio> pstolowski, you can create a vm with ubuntu core and reproduce it on there
<ogra_> i.e. if snap list shows it as x1
<ogra_> ppisati, but do you need the modules ? if just testing vmlinuz you can simply replace it on the vfat
<ppisati> ogra_: uhm, ok, let me try that
<cachio> pstolowski, i can provide you any information of the exec
<mup> PR snapd#3948 opened: snap-repair: fix missing Close() in TestStatusHappy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3948>
<cachio> pstolowski, just tell me what you need
<pedronis> mvo: IÂ know, IÂ think I understand,  we are passing in the same runtime the  FD as a int
<pedronis> mvo: so at that point is not under runtime control anymore
<pedronis> so when it gets close we close something random
<pedronis> mvo:Â if we don't do it ourselves
<pedronis> mvo: we are causing a double close somehow
<pedronis> mvo: I'm not even sure how to avoid it
<mvo> pedronis: make sense. I need to take a break, lets see if the world is a more happy place once the branches are in
<pedronis> mvo: does those close help?
<pedronis> I suppose they do because we control when the double close happens
<pedronis> it still happens though
<pstolowski> cachio, indeed. it kinda looks like the problem of running "old" snap-exec vs the namespacing problem. zyga-ubuntu any idea if that could be it?
<pedronis> yes, double close still happens and where we expect it
<pedronis> zyga-ubuntu: so it was a double close but in a more interesting place
<zyga-ubuntu> pedronis: oh, I'm curious to learn
<zyga-ubuntu> pedronis: where was it?
<pedronis> zyga-ubuntu: we have a test that passes around a fd through an env variable but in the same process, not across processes, fun ensues
<zyga-ubuntu> pedronis: aah
<zyga-ubuntu> pedronis: so it was "copied" as I was wondering
<zyga-ubuntu> (well copied as in memcpy, not dup)
<zyga-ubuntu> pedronis: interesting find, does that bring master to sanity?
<cachio> pstolowski, I am updating the core from adge again
<cachio> pstolowski, and rexec to see the results
<pedronis> zyga-ubuntu: copied as we end up with two os.File with the same fd without the runtime knowning this
<pedronis> apparently
 * sergiusens is looking at his battery drop during the blackout
<zyga-ubuntu> pedronis: right, sadly that's exactly the case
<zyga-ubuntu> jdstrand: hey, I saw your nvidia PR, I'll get to it soon
<lutostag_> anybody got an idea why I might be hitting https://bugs.launchpad.net/snappy/+bug/1659719 ?
<mup> Bug #1659719: ssh can't call a binary from a snap without the full path <isv> <Snappy:Fix Committed by ogra> <livecd-rootfs (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1659719>
 * zyga-ubuntu looks
<ogra_> lutostag_, is the file there ?
 * ogra_ just commented on the bug a minute ago 
<lutostag_> ogra_: indeed it is
<ogra_> i definitely see it everywhere on classic installs as well as on devices
<lutostag_> hah, good timing ;)
<ogra_> lutostag_, hmm, do you use some weird shell like zsh ?
<lutostag_> nope lxd, with bash
<zyga-ubuntu> lutostag_: it might be ssh and pam doing some fancy variable sanitization
<ogra_> (or some other that wouldnt parse profile.d on login)
<lutostag_> if I do ssh ubuntu@ip "juju-crashdump" it fails
<zyga-ubuntu> what is the target OS that hosts snaps?
<ogra_> lutostag_, ah
<ogra_> lutostag_, that wont spawn a shell
<lutostag_> because profile isnt executed without -l
<nacc> lutostag_: you need a login shell
<ogra_> lutostag_, right
<zyga-ubuntu> ah, that bug is pretty well triaged already
<ogra_> well,
<nacc> e.g., ssh ubuntu@ip bash -l -c juju-crashdump
<ogra_> openssh people would tell you "notabug" :)
<lutostag_> that is confusing for me, yeah
<ogra_> its the "you're holding it wrong" of ssh ;)
<lutostag_> I know why and all, just that we hit it as we expected /snap/bin to be a top-level PATH citizen, but...
<ogra_> if you have control of the image build you could indeed modify /etc/environment
 * zyga-ubuntu downloads ubuntu ISO for the Nth time in his life
<zyga-ubuntu> I need to figure a way to keep those arund
<zyga-ubuntu> *aroud
<zyga-ubuntu> *around even
<ogra_> pfft isos ...
<lutostag_> and I guess bashrc in /etc/bashrc doesnt support .d directory loading so we could add the snippet from https://bugs.launchpad.net/snappy/+bug/1659719/comments/4
<mup> Bug #1659719: ssh can't call a binary from a snap without the full path <isv> <Snappy:Fix Committed by ogra> <livecd-rootfs (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1659719>
<ogra_> lutostag_, doesnt help if you dont run bash ...
<ogra_> ssh ubuntu@ip <command> will use /bin/sh ... not bash
 * zyga-ubuntu sets up NFS in a VM, better safe than sorry
<lutostag_> hmm... jenkins@juju-6f7422-solutions-qa-integration-1:~$ ssh ubuntu@10.62.42.103 "juju-crashdump"
<lutostag_> Warning: Permanently added '10.62.42.103' (ECDSA) to the list of known hosts.
<lutostag_> bash: juju-crashdump: command not found
<lutostag_> seems like an error from bash for me...
<nacc> lutostag_: you aren't running a login shell
<ogra_> add -l or use /bin/bash -c
<lutostag_> gotcha, thanks
<lutostag_> ogra_: and I guess /etc/environment tweaking for the whole the default ubuntu as a whole is a no-go?
<lutostag_> (for fresh installs)
<ogra_> lutostag_, thats a question for foundations :)
<nacc> heh
<ogra_> you can definitely not do it retroactively though
<ogra_> (so yes, the installer/iso  would have to have that change)
<nacc> and presumably would need to dtrt on upgrades, etc.; seems pretty invasive :)
<niemeyer> mvo, sergiusens: One last idea before closing down on assemble: fold/unfold
<nacc> what voodoo do i need to invoke to have the beta/candidate channels for my snap follow edge as it is now?
<niemeyer> mvo, sergiusens: I like this one a bit more than assemble because it has that very cheap feeling.. not a lot is happening when we fold
<elopio> nacc: if you want edge, candidate and beta to be the same, release the revision to candidate, and close the other two.
<nacc> elopio: yep, just realized that :)
 * niemeyer steps out
 * zyga-ubuntu is stuck in a traffic jam
<nacc> it feels like this message could be improved (fro sudo snap refresh git-ubuntu): error: cannot refresh "git-ubuntu": snap "git-ubuntu" has changes in progress
<nacc> changes where?
<zyga-ubuntu> nacc: in snapd, there are "snap changes" that affect it
<nacc> zyga-ubuntu: ah, meaning it's currently doing an update from the store?
<zyga-ubuntu> nacc: `snap "git-ubuntu" is being processed by snapd`
<zyga-ubuntu> nacc: any change involving that snap
<nacc> zyga-ubuntu: ah ok, yeah that would be clearer to me
<zyga-ubuntu> nacc: (refresh is one of possibilities but not the only one)
<nacc> "cahnges in progress" implies (to me) that i have done some local modification
<nacc> is it possible to remove an architecture from a snap? (e.g., currently i'm buildign for amd64 and i386, but the i386 version is fundamentally broken and unsupported)
<nacc> so i'd like to just remove it from the store, untile we get around to enablinng it properly
<zyga-ubuntu> nacc: ask store people, I don't know really
<nacc> zyga-ubuntu: ok, thankns
<Chipaca> ok, this epoch thing isn't going out today
 * Chipaca wraps up
<posi> I am building a snap for brave using electron-builder. When I go to snap install it I must use dangerous because "error: cannot find signatures with metadata for snap "dist/brave_0.21.0_amd64.snap""
<nacc> posi: you're doing a local snap install (of a local snap file)?
<posi> Well I build the snap file yea
<posi> and then i wanted to test it
<posi> and got that error
<posi> perhaps i wont get it if it goes to a repo?
<nacc> posi: yes, you'll need to use --dangerous
<posi> just because it's not going through a signed repo?
<nacc> posi: 'verified', in this context, i think means it comes from the store
<nacc> posi: i'm not sure, though
<posi> cools town
<posi> i wont worry about it then
<nacc> posi: i should say for our jenkins job that builds a snap from our repo for a test, we use dangerous to do a 'local install'
<nacc> posi: so it's not surprisinng to me, at least :)
<zyga-ubuntu> posi: yes, that's exactly what's going on
<zyga-ubuntu> posi: you don't have store-signed assertion if you build locally
<posi> makes total sense
<posi> thanks y'all
<nacc> zyga-ubuntu: thanks for confirming
<posi> also
<posi> we are using linux namespaces for security
<posi> so i had to switch to confinement classic
<posi> curious what y'all imagine apps should do who use user naemspaces like us and chromium
<nacc> posi: there is some discussion here, but it's about snapd and user namespaces, i thinnk (https://forum.snapcraft.io/t/snappy-and-users-and-groups-obsolete/331)
<zyga-ubuntu> posi: it's possible
<nacc> posi: also, there's LP: #1586547
<mup> Bug #1586547: allow browsers to use user namespaces in its sandbox <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1586547>
<zyga-ubuntu> posi: depending on what you mean specifcally, chromium uses a number of thins together so it needs a privileged interface
<jdstrand> posi: you don't have to use classic for linux namespaces with electron
<jdstrand> posi: are you brave upstream?
<jdstrand> posi: if you are, see https://github.com/snapcore/snapd/wiki/Interfaces#browser-support
<posi> jdstrand: yes
<posi> jdstrand: right it's not an electron thing
<posi> jdstrand: it's a how we secure our rendering thread
<jdstrand> posi: you can set an interface attribute. this is, for example, what the chromium snap is doing
<jdstrand> posi: right. use 'allow-sandbox: true'. that should allow brave to do what it needs, just like chromium and chrome
<posi> great!
<jdstrand> in strict mdoe
<jdstrand> mode*
<jdstrand> posi: that attribute is intended to be used by trusted upstream browser publishers (eg, Chrome/Chromium, Firefox, ...). Brave certainly fits that category
<posi> yep
<zyga-ubuntu> jdstrand: o/
<zyga-ubuntu> jdstrand: I didn't get to your nvidia PR yet, sorry
<zyga-ubuntu> jdstrand: on the upside I'm working on tests for NFS
<posi> Can I cleanup this conversation, remove your names and summerize it in a PR to the electron-builder community?
<jdstrand> posi: to just get the snap going, iirc flexiondotorg didn't enable the user namespaces support so allow-sandbox: true wasn't needed, but I figured one day someone from Brave would ask about this
<jdstrand> zyga-ubuntu: no worries
<jdstrand> posi: well... for the average electron app, they should *not* use allow-sandbox: true
<jdstrand> posi: and just rely on the snappy sandbox
<posi> Right we'd add a allow blah
<jdstrand> posi: if you summarize the conversation, it is really important you communicate that point, because use of 'browser-support' alone allows automated reviews to pass in the public Snap Store. specifying 'allow-sandbox: true' requires a conversation with a trusted publisher, because the policy it allows would allow a malicious snap to break out of confinement
<jdstrand> posi: so we very tightly restrict its use
<posi> Right
<posi> so would we want both of them on
<posi> in the case of a browser
<posi> or is browser-support legit
<jdstrand> browser-support is fine for a browser that is configured itself with --disable-sandbox
<jdstrand> it relies on the snappy sandbox only
<posi> no we want enable-sendbox
<posi> *sandbox
<jdstrand> I know you do
<posi> ahh ok
<posi> so i want both then
<jdstrand> I'm saying for the general case
<posi> sure
<mup> PR snapd#3948 closed: snap-repair: fix missing Close() in TestStatusHappy <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3948>
<jdstrand> a trusted publisher who has a browser that is in use by tons of users, allow-sandbox: true makes sense (Brave, Chrome, etc)
<jdstrand> anyway, it is a fine point
<jdstrand> I just want to make sure people don't see it and are like 'sure I want all of this' since there will be store friction
<jdstrand> at some point, apparmor will better work with user namespaces and we won't need to guard this so carefully
<jdstrand> ie, we need to grant 'capability sys_admin' to the snap
<jdstrand> but the snap only needs sys_admin in the user namespace
<jdstrand> but, today, it only shows up as sys_admin, regardless if it is system namespace or user namespace (this is but one example)
<posi> yea
<posi> dude, i still can't believe the archlinux would prefer a setuid binary to a linux namespace binary
<jdstrand> posi: perhaps if you say something like 'Major browser manufacturers may want to use.... Use of 'allow-sandbox' will require permission for use in the public Snap Store at this time'
<jdstrand> s/for use/for distribution/
<jdstrand> wordsmith as desired
<jdstrand> posi: well, it isn't like user namespaces haven't had any CVEs :P
<posi> True but if they knew what i knew about how drm worked....
<jdstrand> that code was a CVE factory for awhile :)
<zyga-ubuntu> jdstrand: unprivileged user namespaces/
<jdstrand> but the user ns/apparmor issues are known and on the roadmap to make better. I don't have a timeline for when that will left the restriction wrt browser-support, but we'll get there eventually
<posi> https://github.com/electron-userland/electron-builder/issues/2100
<jdstrand> zyga-ubuntu: that's what I was talking about, yes
<jdstrand> will left?
<zyga-ubuntu> right, I was just checking
<jdstrand> we'll lift
<jdstrand> posi: so, to be clear, Brave is fine to use allow-sandbox. I'm fine with you taking this conversation back to the electron community. we'll be working to make userns/snapd/apparmor work better together
<posi> Yay
<jdstrand> (but again, no fixed timeline)
<jdstrand> in fact, I'll just grant it to the snap now so you can just upload away
 * jdstrand thought he might've already done that
<jdstrand> no, I did not
<jdstrand> posi: ok granted. I'm not sure if you've used interface attributes before, so here you go: http://paste.ubuntu.com/25581549/
<kyrofa> Hey everyone
<zyga-ubuntu> hey kyle
<kyrofa> sergiusens, I'm finally at the hotel and settled
<sergiusens> kyrofa and I finally have electricity again!
<zyga-ubuntu> 1st world / 3rd world problems
<zyga-ubuntu> at least we are all on IRC
<sergiusens> zyga-ubuntu apparently the 80km/h winds affected the grid :-/
<kyrofa> Oh dang, storming down there eh?
<zyga-ubuntu> sergiusens: I'm sorry, I was kidding, it's not a fun time for a good chunk of the world :/
<sergiusens> zyga-ubuntu we are on the good side of it, our bad weather and flooding is around the middle of summer (Jan/Feb)
<pedronis> mvo: thanks for merging, as you have seen IÂ added some more description that you included
<mup> PR snapd#3949 opened: cmd/snap-repair: skip disabled repairs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3949>
<mup> PR snapd#3950 opened: cmd/snap-repair: prefer leaking unmanaged fds on test failure over closing random ones  <Created by pedronis> <https://github.com/snapcore/snapd/pull/3950>
<mvo> pedronis: yeah, thank you for your extra comments
<pedronis> mvo: IÂ proposed my Dup variant (for extra paranoia)
<sergiusens> elopio around?
<elopio> sergiusens: pong
<jdstrand> stgraber: hi! so I've noticed a number of lxd stable snap updates lately (cause the container restarts and I lose state). container restarts aside, I wonder if I should be tracking 2.0/stable? (though, it is still at 2.0.10 it looks like, far behind 2.17)
<sergiusens> elopio well, retroactive ping then ;-)
<sergiusens> elopio how about updating those PRs so they land?
<stgraber> jdstrand: hmm, your containers reboot when lxd updates? that's not normal
<stgraber> jdstrand: can you pastebin "journalctl -u snap.lxd.daemon"?
<jdstrand> stgraber: well, I'm assuming. I ssh in then the connection drops. maybe it is something else?
<mvo> pedronis: thanks, looking
<jdstrand> (not immediately drops mind you-- I thought with updates, maybe not)
 * jdstrand journalctls
<stgraber> jdstrand: ah, LXD re-applies its network config on daemon startup, I wonder if that's somehow enough to disconnect ssh
<elopio> sergiusens: on the snapd integration tests, I need to figure out a test for lib crawling. And on the shared cache, I'm not sure if we are +1 or -1
<elopio> are you talking about those?
<sergiusens> elopio yes, those; also followup on my docstrings
<sergiusens> elopio and do you have a minute to run a test?
<mvo> pedronis: one question inline, but I call it a day now, things look good
<sergiusens> elopio need your publisher-id for staging (snapcraft whoami)
<jdstrand> stgraber: http://paste.ubuntu.com/25581972/ (yes, snap refresh)
<jdstrand> well
<jdstrand> that was last night
<stgraber> jdstrand: ok, that should be fine, it detected the refresh which means it shouldn't have brought down containers
<jdstrand> stgraber: I don't have anything from the last few minutes in the log
<elopio> sergiusens: sure. Do you need my id, or do I need my id to run the test?
<jdstrand> stgraber: I did move from one wifi network to another. could that cause it?
<jdstrand> where 'it' is network restart
<stgraber> jdstrand: unless network-manager is doing something very very wrong, it shouldn't
<stgraber> jdstrand: what's "uptime" showing inside one of your containers?
<pedronis> mvo: we don't strictly need it, but otoh it makes the test very similar to what we have in Run (which I think is good)
<jdstrand> stgraber: 20:13:48 up 11:15,  2 users,  load average: 0.42, 0.53, 0.68
<stgraber> jdstrand: and you got disconnected less than 11 hours ago?
<sergiusens> elopio I need your id to share a snap with you and then ask you to push a new version
<jdstrand> stgraber: I thought so, but I have several others ssh sessions that are up that survived the AP change
<jdstrand> stgraber: I closed that terminal. It might've been lingering since yesterday
<jdstrand> (sorry for closing that one)
<jdstrand> so, it sounds like a snap refresh might restart the network
<elopio> sergiusens: wait, my user on staging has 2fa enabled, but the staging 2fa was my ubuntu phone.
<elopio> let me register a new user.
<stgraber> jdstrand: yeah, a refresh of the LXD snap would cause the daemon to be stopped and restarted, which will reset iptables rules, routes and IPs on the lxdbr0 bridge. But I'm unable to reproduce this causing ssh to drop here.
<jdstrand> hmm
<jdstrand> oh
<jdstrand> stgraber: I wonder if it is because it got an IP address change
<stgraber> that seems reasonably unlikely. While LXD's dnsmasq doesn't issue static leases, it does provide IPs based on a hash of the MAC, so that should keep things rather stable and avoid random IP changes.
<jdstrand> stgraber: I have a pretty lame way I am sshing in: I run 'lxc exec <name> -- ip -4 addr show eth0', scrape the ip address and ssh into it
 * jdstrand wonders if there is a better way
<stgraber> Host *.lxd
<stgraber>   StrictHostKeyChecking no
<stgraber>   UserKnownHostsFile /dev/null
<stgraber>   ProxyCommand nc $(lxc list -c s4 $(echo %h | sed "s/\.lxd//g") %h | grep RUNNING | cut -d' ' -f4) %p
<stgraber> in .ssh/config
<nacc> stgraber: feels like that should be in the manpage :)
<jdstrand> stgraber: ok, so, we let me try to get more info the next time it disconnects and go from there. do you have a recommendation on stable vs 2.0/stable?
<nacc> stgraber: i remember that makinng a huge difference to me :)
<stgraber> jdstrand: 2.0/stable is the LTS release as you have it in xenial-updates. So it's quite a bit behind LXD 2.17/2.18 as far as features. It's also not fully supported as a snap yet (waiting for 2.0.11 which will get us there)
 * jdstrand jots down the ssh/config entry
<jdstrand> I see
<jdstrand> well, I seem to be on the stable train then
<elopio> sergiusens: DPKYnDYokujK66geceR4EdcVEi4tekzr
<sergiusens> nessita I get this on pushes on the store now "Please choose the store for the mandm snap before uploading" for a snap I registered on Monday I believe (didn't we discuss using the default store by default?)
<sergiusens> elopio will have to wait a bit :-)
<sergiusens> well, the dashboard allowed me to fix, so no hurry here
<jdstrand> stgraber: curious, does the *.lxd work with up-to-date artful and systemd-resolved?
<jdstrand> I've had no end of trouble with resolved and libvirt and lxd
<nacc> jdstrand: i'm on it currently and yes
<nacc> jdstrand: note, not using the snnap, though, but i don't think that hsould matter on artful?
<jdstrand> I wouldn't think so
<sergiusens> elopio did you get an email or something? if not straight out make a simple modification to this http://paste.ubuntu.com/25582065/ and push please
<Pharaoh_Atem> :/
<sergiusens> Pharaoh_Atem out of nowhere non smiley emoticons are not allowed ;-)
<kyrofa> But smiley ones totally are
<Pharaoh_Atem> ^_^
<nessita> sergiusens, hum yes! you should get the default store by default!
<nessita> sergiusens, let me triple check
<nessita> sergiusens, is this from snapcraft?
<sergiusens> nessita yes
<nessita> sergiusens, checking
<nessita> sergiusens, is it a name you already own, right?
<jdstrand> nacc: for libvirt, I have a crazy script to use gdbus to call SetLinkDNS and SetLinkDomains. it shouldn't be this hard
<sergiusens> nessita https://pastebin.ubuntu.com/25582089/
<jdstrand> nacc: you have a standard install?
<sergiusens> nessita and yes, I think I registered it before you made the change, just never "pushed" anything until today
<sergiusens> might be corner casey :-)
<jdstrand> I should probably talk to xnox
<nessita> sergiusens, it should still use the default store, let me find where the bug is
 * jdstrand -> ubuntu-devel
<elopio> sergiusens: no mail
<nessita> sergiusens, could you please file me a critical bug while I fix?
<nacc> jdstrand: yeah
 * cmars looks up from the corner
<nessita> sergiusens, hum I've just reproduced in prod, so I will fix asap
<elopio> sergiusens: pushed revision 2
<mup> PR snapcraft#1558 opened: tests: add fake pip fixture <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1558>
<nessita> sergiusens, got my reply?
<mup> PR snapd#3933 closed: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3933>
<sergiusens> nessita yes, sure thing
<sergiusens> went for a short walk to stretch my legs :-)
<nessita> sergiusens, branch with fix is on its way to trunk but the bug would be good for tracking
<sergiusens> nessita LP: #1718540 although I cannot set the Importance
<mup> Bug #1718540: default store not set on registered snaps <Snap Store:New> <https://launchpad.net/bugs/1718540>
<nessita> sergiusens, thanks!
<sergiusens> kyrofa I am confused by your PR
<kyrofa> sergiusens, I realized after I opened it that it contains roughly zero documentation :P
<kyrofa> I'm fixing that. But are you confused beyond that?
<kyrofa> Ah, I see your comment
<kyrofa> First, you of course have a point that this is not yet heavily used, since the only tests that exist so far test the pip class itself and thus don't benefit very much from this. But for example, take a look at the test change here: https://github.com/snapcore/snapcraft/pull/1558/files#diff-0081187be45e5e561b2da7a6516c2f17R533
<mup> PR snapcraft#1558: tests: add fake pip fixture <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1558>
<kyrofa> While the change is small, it's suddenly testing more than just list
<sergiusens> kyrofa oh, I forgot to mention, that was kind of like the only place it made sense
<kyrofa> Yes, agreed. I'm proposing it now so that it can be used in the catkin and python PRs
<sergiusens> it still feels a bit heavy
<kyrofa> sergiusens, but it's also up for discussion, of course
<sergiusens> as you end up calling fakes for those which "do things"
<kyrofa> sergiusens, well, yeah, wouldn't it be a mock otherwise?
<kyrofa> sergiusens, elopio was talking about how he wanted to test the entire path of the class (install something, list what you installed)
<kyrofa> sergiusens, I'm not completely sold on this. Because in order to test using the Python plugin that way with full coverage we end up needing to parse e.g. requirement.txt files
<kyrofa> You want to talk about heavy...
<kyrofa> elopio, you around?
<sergiusens> kyrofa I am divided on this one, let's see what elopio has to say.... to be clear, I am not saying no, I just feel there is too much involvement here
<kyrofa> sergiusens, that's totally fair
<kyrofa> sergiusens, ignoring the fake though, I love the spy
<elopio> Yup
<sergiusens> kyrofa it almost feels like creating a fake python interpreter you actually call which interacts with our code would be simpler and more straight forward
<kyrofa> Hahaha
<sergiusens> would feel more in line with the fake servers
<kyrofa> elopio, I proposed the fake implementation I showed you when you get a minute to take a look
<sergiusens> elopio thanks for the push of mandm btw, was a good test of collaboration, but the revoking doesn't seem to fit a lot. Mind pushing a "version: 0.3", it should fail so don't go crazy
<elopio> I'm looking
<elopio> sergiusens: this error: https://paste.ubuntu.com/25582589/
<sergiusens> elopio good, I just don't like the error message :-)
<sergiusens> that __all__ is just, ..., don't have the words...
<elopio> I said the same ;)
<kyrofa> Heh
 * sergiusens will bbiab
<mwhudson> anyone around to help write a spread test?
<mwhudson> this line https://github.com/snapcore/snapd/pull/3872/files#diff-fbc5a3aafffbc409b850466293abe66dR20 fails with "/bin/bash: line 65: SNAPMOUNTDIR: unbound variable"
<mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
<mwhudson> which doesn't make any sense to me given the line just above
#snappy 2017-09-21
<mwhudson> er spread just says this to me:
<mwhudson> error: invalid project name: ""
<mwhudson> oh is this because my gopath is not in $HOME
<mwhudson> yes
<mwhudson> grumble
<sergiusens> elopio please check my last comment on snapcraft#1552
<mup> PR snapcraft#1552: tests: replace the first batch of demo tests with snapd integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1552>
<mup> PR snapcraft#1559 opened: static: fix flake8 errors in setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1559>
<sergiusens> elopio or kyrofa easy one ^
<mup> PR snapcraft#1560 opened: ci: use travis conditionals <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1560>
<mup> PR snapcraft#1561 opened: rust plugin: record the Cargo.lock file <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1561>
<kyrofa> elopio, are you still around?
<kyrofa> Nah, nevermind, it's too late
<mup> PR snapcraft#1562 opened: Record rust versions <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1562>
<elopio> kyrofa: I'm here. But yes, I'll EOD, I'll continue meditating about your PR tomorrow :)
<mup> PR snapcraft#1563 opened: tests: simplify a little the data in nodejs unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1563>
<zyga-ubuntu> brr
<mup> PR snapd#3950 closed: cmd/snap-repair: prefer leaking unmanaged fds on test failure over closing random ones  <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3950>
<mup> PR snapd#3951 opened:  snap: add new `snap fold` and use in tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3951>
<mup> PR snapd#3949 closed: cmd/snap-repair: skip disabled repairs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3949>
 * zyga-ubuntu wonders if the rain will stop
<zyga-ubuntu> or will it just switch to snow
<mup> PR snapd#3939 closed: interfaces: add Connection type <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3939>
 * zyga-ubuntu -> cold :/
 * ogra_ hands zyga-ubuntu a campfire
 * Chipaca helps zyga-ubuntu warm up by running the test suite on all his lab machines
 * Chipaca is lying
 * Chipaca always lies, even now
<Chipaca> huh, just got a unit test dying because of my webcam
 * Chipaca squints
<Chipaca> looks like i'm missing a .h
 * Chipaca hugs âapt build-dep ./â
 * zyga-ubuntu fights with nfs
<pedronis> seems we have again linode -> github issues
 * Chipaca ponders nfs-aware snapds
<Chipaca> e.g. grab snaps off other snapds, query other snapds acking
<Chipaca> (fear not, only pondering this because waiting for unit tests)
 * zyga-ubuntu has small progress :)
<Son_Goku> zyga-ubuntu: I wonder if we could have a box set up running the latest Fedora to run through the latest snapd with setroubleshoot installed and active, and collect all the denials
<Son_Goku> from the spread test
<Son_Goku> setroubleshoot has an API, so you could use that to collect all the denials related to snappy policy domain
<zyga-ubuntu> mmm
<zyga-ubuntu> Son_Goku: we could just adjust the spread test run for fedora and somehow collect the results
<zyga-ubuntu> Son_Goku: spread has a "residue" system where it could collect a file from the tested system
<Son_Goku> is setroubleshoot-server installed and running when the fedora vm is booted?
<Son_Goku> without setroubleshoot, you just get shitty AVC denial messages like you do with AppArmor
<zyga-ubuntu> Son_Goku: we could bake it into the image
<Son_Goku> then the next question is, how do we get the data
<Son_Goku> I know it spews messages into the journal
<zyga-ubuntu> we'd run it manually on linode and collect it via the resudue
<Son_Goku> but I don't know if there's another location too
<zyga-ubuntu> we'd have to script things so that there's a file to collect
<Son_Goku> right
<pedronis> mvo: so good news, preliminary testing again staging worked as expected,  otoh I think we should disable the snap-repair timers during spread tests or it might get confusing when we start having some?
<mvo> pedronis: agreed
<mvo> pedronis: having said that, we could do it when we get the first repair
<pedronis> as you prefer
<zyga-ubuntu> ok, I have working NFS support in snapd
<zyga-ubuntu> let's propose it piece by piece and let's work on a spread test
<mup> PR snapd#3952 opened: cmd: update "make hack" <Created by zyga> <https://github.com/snapcore/snapd/pull/3952>
<zyga-ubuntu> Chipaca: ^ trivial
<mup> PR snapcraft#1563 closed: tests: simplify a little the data in nodejs unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1563>
<mup> PR snapcraft#1559 closed: static: fix flake8 errors in setup.py <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1559>
<pedronis> mvo: sample runs (with staging):  http://pastebin.ubuntu.com/25585711/
<ppisati> $ snapcraft cleanbuild --output
<ppisati> Error: no such option: --output
<ppisati> $ snapcraft cleanbuild
<ppisati> [cpu stuck at 100% but no output, and apparently nothing happens]
<ppisati> sergiusens: ^
<ppisati> elopio: ^
<ppisati> kyrofa: ^
<popey> jdstrand: i just uploaded an app (pulsemixer) which got stuck in review because it has no desktop file (I use the x11 interface). It is a CLI app - no GUI. But the x11 interface is required for pulse to work!
<popey> (known bug?)
<jdstrand> popey: it isn't a bug in the tools. I can add an exception for it
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: I have a POC for nfs support, do you want to have a quick look?
<jdstrand> hey zyga-ubuntu
<popey> jdstrand: I mean a bug in the pulseaudio interface..?
<pedronis> mvo: #3934  spreads runs seems to be plagued by networking issues :/
<mup> PR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>
<mvo> pedronis: yeah, I noticed as well, super annoying, so close
<jdstrand> popey: no. pulse uses x11 window properties to find the server. something that is doing that should declare the x11 interface
<popey> ahh
<jdstrand> (ie, we don't want to add X access to the pulseaudio interface)
<jdstrand> zyga-ubuntu: where is it?
<zyga-ubuntu> jdstrand: I just pushed it to feature/nfs-support branch
<zyga-ubuntu> jdstrand: I tested it successfully on my artful system, I'm working on spread test
<zyga-ubuntu> jdstrand: have a look at each patch, I tried to make it logically follow one another
<zyga-ubuntu> jdstrand: I was thinking about also parsing etc/fstab and looking for NFS there
<zyga-ubuntu> jdstrand: and enabling the workaround if _either_ NFS is actually mounted or fstab says it may be mounted
<jdstrand> zyga-ubuntu: I made a couple of comments. I think the direction is fine and who it is implemented makes sense
<zyga-ubuntu> jdstrand: thank you, looking
<jdstrand> zyga-ubuntu: I was initially thinking only nfs home. I guess its possible some of the other policy might allow access to nfs directories depending on the setup, so I guess checking the mount table for anything is ok
<jdstrand> maybe it makes sense to start with only home, and expand if people are affected...
<jdstrand> probably need more people to discuss, but that can happen in PR review
<mup> PR snapcraft#1560 closed: ci: use travis conditionals <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1560>
<zyga-ubuntu> jdstrand: anything that is a subdir of home is a good test as this will let us test this easily and will be constrained how you explained
<zyga-ubuntu> jdstrand: as for reexec, that will work automatically thanks to the way the apparmor imports are handled
<zyga-ubuntu> jdstrand: I think it makes sense to extend filesystem type to handle samba but I haven't tested that so I'd like to do it as a separate step
<zyga-ubuntu> jdstrand: thank you for the quick look, I think this will work fine shortly
<sergiusens> ppisati I don't think we ever supported --output in `cleanbuild`
<jdstrand> zyga-ubuntu: it isn't the imports I was worried about, it was loading the older snap-confine policy when we are reexecing
 * sergiusens waves hello
<jdstrand> zyga-ubuntu: re samba> sounds fine
<zyga-ubuntu> jdstrand: older policy?
<zyga-ubuntu> jdstrand: when we are re-execing the newer snapd will run snap-confine from core and we already have support for managing that dedicated profile
<zyga-ubuntu> jdstrand: and that profile is a derivative of the profile stored in the core snap
<jdstrand> zyga-ubuntu: there is /etc/apparmor.d/usr.lib.snapd.snap-confine.real, but we also end up with usr.lib.snapd.snap-confine.real.rev (or something)
<zyga-ubuntu> jdstrand: so it will source the system-wide policy extension for snap-confine
<zyga-ubuntu> jdstrand: right but see above, those all source one place
<zyga-ubuntu> jdstrand: and we already have setup code that ensures those are reloaded
<jdstrand> it isn't /var/lib/snapd/apparmor/snap-confine.d I am worried about
<jdstrand> that directory is fine (indeed, I suggested it)
<jdstrand> it is that you are hardcoding to apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real, not accoutning for usr.lib.snapd.snap-confine.real.rev
<zyga-ubuntu> right
<zyga-ubuntu> I assume by .rev you mean the core revision
<jdstrand> yes
<jdstrand> I forgot what it looked like for real
<zyga-ubuntu> I was trying to explain that IMO this is not needed because the code that manages the per-rev profile is already doing everything we need
<jdstrand> snap.core.2898.usr.lib.snapd.snap-confine
<jdstrand> that's an example ^
<zyga-ubuntu> as it will derive the contents of the .rev file from the profile stored in the core snap
<zyga-ubuntu> and then load it
<zyga-ubuntu> is there more that we need to manage for per-revision profiles?
<cachio> niemeyer, mvo i am taking my son to the hospital to make a bone scan
<mvo> cachio: uh, good luck!
<cachio> mvo, TX, should be back soon
<nessita> sergiusens, hi! unsure if you saw but the bug from yesterday was fix released last night
<pedronis> mvo: aftering having played a bit with "snap repair", do you think it would make sense to print as field the mtime of the log file do have an idea one things have run?
<pedronis> s/do have/to have/
<zyga-ubuntu> jdstrand: does my explanation make sense?
<niemeyer> Thanks for the note, and good luck there!
<jdstrand> zyga-ubuntu: looking at the above profile, and reminding myself what shows up in aa-status, I think there may not be a bug. but it seems weird that that code is only loading .real. doesn't that mean we might load .real when we don't have to?
<zyga-ubuntu> jdstrand: aha, interesting question; yes, when we are rexeced we don't need to reload the .real profile
<pedronis> mvo:  mmh, s/idea one/idea when/
<zyga-ubuntu> jdstrand: just write the policy and wait for the setup code to reload the right file
<jdstrand> zyga-ubuntu: like, when we are execing the snapd in /snap/core/..., it is going to reload .real
<zyga-ubuntu> jdstrand: right, I agree
<zyga-ubuntu> oh, standup time
<zyga-ubuntu> brb
<mvo> pedronis: yeah, I think this is very nice
<mvo> pedronis: we should also include it in the log in case of fs corruption
<mvo> pedronis: I can add that after the meeting
<pedronis> thanks
<pedronis> I'll also rework my branch with some details, so it's ready when review/spread tests are back to being helpful
<ppisati> sergiusens: ok, but do you happen to know why my 'snapcraft cleanbuild' doesn't do anything? is it normal that i don't get any output?
<sergiusens> ppisati that is not normal, no
<sergiusens> ppisati can you add --debug?
<sergiusens> ppisati also check ps and see that we are not stuck on a lxc call
<sergiusens> nessita thank you
<davidcalle> ogra_: just so you know, we now have this page https://developer.ubuntu.com/target-platforms/boards giving an overview of available images/boards, it's not core exclusive, so if you have others in mind I don't know of (only requirement is to have flashing steps somewhere on the web and a somewhat official image working), let me know
<davidcalle> (also, you can pass the search term through the url, eg https://developer.ubuntu.com/target-platforms/boards#arm64 to have a filtered view)
<ppisati> sergiusens: root     17092  0.0  0.0 160904  1396 ?        Ssl  14:00   0:00 /usr/bin/lxcfs /var/lib/lxcfs/
<ppisati> root     18245  0.0  0.0  95016  5472 ?        Ss   14:02   0:00 [lxc monitor] /var/lib/lxd/containers first
<ppisati> flag     19422 97.2  0.5 346624 89224 pts/19   R+   15:07   2:21 /usr/bin/python3 /usr/bin/snapcraft -d cleanbuild --debug
<ppisati> flag     19634  0.0  0.0 130284   980 pts/20   R+   15:09   0:00 grep --color=auto -e lxc -e snapcr
<ppisati> ops
<ppisati> sorry
<ppisati> sergiusens: http://pastebin.ubuntu.com/25586157/
<sergiusens> ppisati strange that no name for the assigned container is being shown. Can you `lxc list` and figure it out and then `lxc exec <container> -- ps -auxww`
<ogra_> davidcalle, i have five "community" images too ... not sure if we want to mention them (for nanopi, nanopi-air, beaglebone, hummingboard and sabrelite)
<ogra_> (and three more boards for "community" images in the pipe)
<ppisati> sergiusens: http://pastebin.ubuntu.com/25586244/
<sergiusens> ppisati there is no snapcraft running in that one :-/
<sergiusens> ppisati and it is not named after the petname triplet we use for those containers
<sergiusens> ppisati oh wait, have you ever used cleanbuild to build kernels?
<matteo> ppisati: watch your step!
<sergiusens> ppisati we tar up everything in the source and only then create a container
<sergiusens> and push that tarball into the container
<sergiusens> if you want a somewhat more streamlined version of this try to do `SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft`
<ppisati> sergiusens: never used cleanbuild, first time
 * ogra_ has never seen cleanbuild fail before :)
<davidcalle> ogra_: it would be a good idea to give them more visibility, where can I learn more about these images? Do you have repos for each or maybe a wiki page?
<davidcalle> ogra_: (I've noticed your forum posts on images, but wondering about other places you might have)
<ogra_> davidcalle, a wiki is still on my TOD (just didnt get to that yet) ... images are in my people.u.c home at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ ... gadgt source is at my GH account, kernels are scattered around between GH and launchpad
<ogra_> i need to do some cleanu for the kernels ... and eventually give ppisati a patch for the allwinner support
<ogra_> davidcalle, i'll try to get to the wikipage over the NYC week and then we can look how/if we link it from some official place
<ogra_> are you at the rally ?
<davidcalle> ogra_: I think the boards page can be the right place for these (with an official/community images distinction)
<davidcalle> ogra_: no, I won't be in NYC
<sergiusens> ogra_ ppisati so my suspicion is that it feels stuck given the size of the source, we need a nice spinner to show it is not stuck, if you go the envvar path and using a local lxd remote (default), then you get nice bind mounts instead which would speed things up and not pollute your environment and if it is the first run it would feel as close as a
<sergiusens>  cleanbuild can feel
<pedronis> niemeyer: do you have time for a quick chat today? I'm writing some notes for a topic for next week and IÂ would like a sanity check that I'm not thinking not useful stuff
<niemeyer> pedronis: Definitely
<pedronis> niemeyer: now?Â or in a bit?
<niemeyer> pedronis: My calendar is quite open today
<niemeyer> pedronis: Now works
<pedronis> let's do now
<pedronis> then
<niemeyer> pedronis: Ok, coming back to the standup
<ppisati> sergiusens: ah, if i wait long enough, the builds finally start - sorry for the noise... :|
<sergiusens> no worries, ppisati if you want, feel free to log a bug that it feels stuck and we will sort it with proper feedback
 * zyga-ubuntu checks 14.04 support 
<zyga-ubuntu> a few more tweaks and unit tests and I'll propse NFS
<bladernr> How does one get aliases defined in snapcraft.yaml to work?
<bladernr> for example, if I have this: usb-only:
<bladernr>     command: bin/usb-only
<bladernr>     plugs: *standard
<bladernr>     aliases: [usb-only]
<pedronis> bladernr: that's a deprecated approach, next version of snapcraft will say as much
<bladernr> OK, but I'm not developing on the enxt version of snapcraft, I'm using the snapcraft available today.
<bladernr> e.g. 2.34
<pedronis> bladernr: that's not relevant, since snapd from 2.26 will ignore that field
<pedronis> bladernr: the new world is described here:  https://forum.snapcraft.io/t/improving-the-aliases-implementation/18
<pedronis> bladernr: automatic aliases are something now only controlled through the store
<pedronis> bladernr: you'll just need to make a forum request about the aliases you need
<pedronis> bladernr: see the last session in that forum topic
<pedronis> sorry
<pedronis> section
<bladernr> and what If I don't want to distribute via the ubuntu snap store?  For developpment purposes, I want to distribute the snap from a local store on my MAAS server.
<bladernr> because uploading a snap to the ubuntu tore takes me upwards of 30 minutes each upload
<bladernr> or 5 seconds locally
<roadmr> bladernr: even with delta uploads?
<pedronis> bladernr: what's a local store?
<bladernr> roadmr - no idea what that is.
<roadmr> bladernr: snapcraft should automagically upload just the delta between your last upload and the current one
<mup> PR snapd#3953 opened: snap-confine: fix base snaps on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3953>
<bladernr> pedronis, I want to serve snaps locally for my maas server (this is orthogonal to the alias question).  I just want to push a snap to my maas server and then on a node, snap install from my maas server
<bladernr> I work around that nowy with a bunch of scp
<pedronis> bladernr: well if it's supported local store it will still use the same mechanisms
<roadmr> bladernr: you do that in a script presumably?
<roadmr> you'd have to "it's possible for the user the setup manual aliases under their control:"
<bladernr> sigh...
<pedronis> there will be a store level decclaration
<pedronis> coming from the main store
<pedronis> or local (but that is not designed yet at all)
<bladernr> Ok, it seems maybe my expectations are too high.
<bladernr> Let me start from the beginning... I have a snap, I want ot put that snap on a node behind my MAAS.  What is the way to do that? Do I upload to the ubuntu sture and dhen download it locally?
<bladernr> err... by download, I mean snap install blah on my node.
<pedronis> we are working on proxy store that can be setup localy
<pedronis> but yes for a while all snaps will go through the main store
<bladernr> So in the future, assuming I start using snaps exclusively for my work, a local, standalone distribution point is a hard requirement.  I CAN NOT depend on some internet based snap store.
<bladernr> will that proxy store replace the stuff that's documented now for local hosting but doesn't work anylonger?
<pedronis> yes
<bladernr> e.g. the stuff at the bottom of https://snapcraft.io/docs/core/store
<bladernr> ahhh ok
<bladernr> that will help then
<pedronis> first version will do proxying/caching  and some local control
<bladernr> unfortunately, most of my customers are in segregated environments that likely have zero internet connectivity.
<pedronis> but it will grow more features over time
<pedronis> bladernr: you probably want to talk to people driving that about your requirements
<bladernr> pedronis, ahh thanks.
<cachio> is it possible to create a branch on snapd with the same content we have on edge channel?
<cachio> mvo, ~
<roadmr> cachio: a branch on snapd? (I think it's possible but I may be unclear about what you want)
<cachio> roadmr, I need a branch with the same content than the core snap on edge channel
<roadmr> cachio: ah, the *core* snap.
<roadmr> cachio: do you know which revision of the core snap that is? (as in, that sequential revision/upload number you get)
<mvo> cachio: that should be lp:snapd-vendor
<mvo> cachio: well, roughly, let me double check
<roadmr> cachio: (does mvo's answer work for you? I may be talking about different kind of branch here haha)
<cachio> roadmr, yes, mvo has the solution :)
<roadmr> awesome! disregard me then :)
<zyga-ubuntu> + exportfs -r
<zyga-ubuntu> exportfs: localhost:/srv/nfs: Function not implemented
<zyga-ubuntu> hmmm
 * zyga-ubuntu fires up 14.04 to experiment with nfs
<cachio> mvo, I got it, I'll implement the change to clone that repo instead of the github one
<cachio> mvo, that, when we run on edge
<mup> PR snapd#3954 opened: snap: introduce structured epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/3954>
<Chipaca> ^^ tadaa ^^
<Chipaca> now to take a break, have some tea, and then fix some tests
<zyga-ubuntu> enjoy :)
<ondra> mzanetti ping
<mvo> mzanetti: re the ipv6 problem that ondra told me about, I wonder if it makes a difference if you set "GODEBUG=netdns=cgo" in /etc/environment, i.e. if that changes the behaviour
<pstolowski> mvo, hey, i'm getting http://pastebin.ubuntu.com/25586715/ with master, do we have a new dependency or something?
<nacc> so i have a rather urgent, but perhaps obvious, classic snap question. We are building git-ubuntu on LP usingn artful. However, the core snap is (aiui) still 16. The python3 in artful is now linnked against the new glibc in artful, and (looking at unsquashfs -l), even though it's a dependency, the artful glibc is not in my snap. How isthis supposed to work on xenial, e.g. Even on artful, potentially.
<nacc> i get messages like: /snap/git-ubuntu/x1/usr/bin/python3: relocation error: /snap/git-ubuntu/x1/lib/x86_64-linux-gnu/libdl.so.2: symbol _dl_catch_error, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
<nacc> i'm 'faking' PATH/LD_LIBRARY_PATH confinement in my snap
<nacc> also what's odd is that if I have the CORE_SNAP default library paths first in LD_LIBRARY_PATH, it works fine, but then stuff I've installed in my snap (e.g., xz) fail, because the xz from the core snap is a different version than the one in artful
<nacc> confusingly, right now, the snap segfaults on artful hosts! ... i think this is all tied together, but i'm not sure
<mvo> pstolowski: hm, with master - strange. what machine is failing? 14.04?
<abeato> mvo, hi, is it possible to explicitly define the writable partition in gadget.yaml? it is not usually defined: http://paste.ubuntu.com/25586755/
<Chipaca> nacc: why are you building on artful?
<nacc> Chipaca: i need newer dependencies than are on artful
<nacc> *that* are
<nacc> (e.g., git from artful, etc.)
<pstolowski> mvo, 16.04, it's my xenial system
<Chipaca> nacc: can't you pull them from git or something like that?
<nacc> Chipaca: i'm trying to make sure what we build (e.g., dpkg) is built exactly like the debs, this is for working on source package uploads to Ubunut
<nacc> *Ubuntu
<nacc> Chipaca: if the answer is that I shouldn't be using the Artful option, I really think it should be disabled in LP
<Chipaca> nacc: if the libc in artful diverges, then yes, I don't think you should be building on artful
<Chipaca> nacc: but â¦ maybe i'm wrong, maybe there's a trick to it that sergiusens or mvo know about?
<nacc> Chipaca: that seems ... horribly broke
<nacc> Chipaca: right? that it's even an optio?
<nacc> I don't see how it can work :)
<nacc> I'm also very confused why LD_LIBRARY_PATH's order (core snap libs then my snap's libs) works but the other order (with the same contents!) fails
<Chipaca> nacc: wrt it being an option, you could be building a snap that doesn't use the libc, for example
<nacc> Chipaca: unless you recurse and ensure that nothing you depend on uses libc, it doesn't work
<ogra_> nacc, if you reallly are artful i'd suggest to go artfull all the way and simply drop the core snaps LD_LIBRARY_PATH completely
<nacc> Chipaca: e.g., i'm using the python3 from artful (apparnetly, even though it's a dependency of my stage-packages, not explicitly listed)
<ogra_> (and indeed ship *all* yu need in your snap)
<nacc> ogra_: doesn't work
<nacc> ogra_: there's *no* libc in my sap
<nacc> *snap
<ogra_> ship one ;)
<nacc> ogra_: so i have to explicitly list every dependency?
<ogra_> (might need some hacking since snapcraft willl ty to strip it out)
<nacc> and every depdendency of every dependency
<Chipaca> nacc: it sounds to me like your issue is more with snapcraft that snapd
<Chipaca> nacc: may i suggest you try the rocketchat?
<nacc> Chipaca: i have non idea where it is :)
<Chipaca> nacc: rocket.ubuntu.com/channel/snapcraft
<Chipaca> more snapcrafters there
<nacc> Chipaca: ok
<Chipaca> nacc: wrt recursing and ensuring, yes, you are responsible for all your dependencies
<nacc> Chipaca: i feel like htat's pretty false advertising :)
<nacc> Chipaca: as obviously if i'm installing python3-keyring from artful, i want python3 from artful which wants libc from artful
<Chipaca> nacc: what part is false advertising?
<nacc> Chipaca: what I just said -- i'm asking for a package to be staged, which obviously means its dependencies
<Chipaca> nacc: right, you're talking about what you tell snapcraft and what it does
<Chipaca> nacc: i'm saying, it's your responsibility to get all the dependencies into the snap
<nacc> yeah, that's the false part (to me). i'll ask in rocket
<nacc> Chipaca: yep, i get that
<nacc> I thought I was! :)
<Chipaca> nacc: yeah
<Chipaca> nacc: snapcraft might not support doing that, or there might be a flag for "ship all of libc" that defaults to 'no'
<ogra_> yeah
<ogra_> snapcraft has a blacklist for some packages
<Chipaca> in the early days there was a long list of what is libc, that was skipped for packing
 * zyga-ubuntu scratches head with nfs on trusty
<ogra_> libc is ne of them iirc
<nacc> Chipaca: yeah, i can see that
<Chipaca> but i haven't kept up; it might be smarter today
<nacc> but the LP builder needs to be smarter, it feels like
<Chipaca> at least a flag should be doable :-D
<nacc> or somethingn does :)
<Chipaca> nacc: snapcraft, probably
<nacc> yeah
<Chipaca> if we want this to work at least
<nacc> I guess that's true
<ogra_> but using artful packages is a bad idea in general ... and in classic even wrse
<Chipaca> nacc: of course, the promise-the-sky answer is that what you want is an artful _base_
<Chipaca> :-)
<nacc> Chipaca: right exactly
<nacc> and honnestly, at first, that's what i thought i was goingn to get
<nacc> build o artful, use artful as your base
<Chipaca> nacc: bases aren't there that
<Chipaca> there yet*
<ogra_> yea
<nacc> Chipaca: ok
<ogra_> thats still a bit out
<mvo> 2.28 will have basic support! 2.29 will be better
<ogra_> but we wont have usable base snaps yet
<Chipaca> woo!
<Chipaca> 10 GOTO 10
 * Chipaca snaps that
<ogra_> even idf snapd can handle them
<Chipaca> mvo: i'll leak that bit of info to whoever it was said we supported android os
<ogra_> (and my bet is also that we wont look into having an artful base as first thing)
<nacc> yeah
<nacc> well, it was just surprising, this all worked just until libc moved
<nacc> (in artful)
<mvo> Chipaca: *cough*
<nacc> so i hadn't considered any of this :)
<zyga-ubuntu> darn, that was easy, nfs was just disabled on startup
<Chipaca> mvo: <mvo> 2.28 will have basic support!
<Chipaca> mvo: you can't take it back now
<Chipaca> nacc: sorry :-( good thing artful's release is ages away still right?
<ogra_> Chipaca, 10 print hello; 20 goto 10
<nacc> Chipaca: well, the snap is already published :)
<nacc> Chipaca: and was working until yesterday
<nacc> when it happened to rebuild with the new libc
<nacc> i think, at least
<Chipaca> i wonder how many other (classic) snaps are now dead
<nacc> yeah
<ogra_> blame infinity !
<nacc> well, i don't know if anyone was 'clever' like me :)
 * ogra_ bets many people were 
<Chipaca> well, 1. classic snap, 2. built on artful
<nacc> cjwatson: may be able to tell us if it's searchable
<nacc> (from a LP admin view, that is)
 * ogra_ just had a discussion this week about LP offering artful builds ... 
<nacc> ogra_: as in, it shouldn't? :) or what was the discussion?
<ogra_> seems you are the first one being hit by it :)
<cjwatson> not easily searchable
<nacc> cjwatson: ok, thakns
<ogra_> nacc, yeah, my pinion was that it shouldnt
<nacc> or it should't until bases are available that correspond, i guess
<ogra_> but in the end the thing we discussed was a test build... nothing to be released (who would do that anyway :) )
<nacc> lol
<ogra_> Chipaca, given that cllassic will also mix-mesh with the actual host rootfs i wnde if artful classic snaps woulldnt even be broken when theer are base snaps available
<ogra_> *wonder
<nacc> ogra_: yeah i had to write my own wrappers (expected) so that everythingn was in my snap or the core snap
<nacc> libs and binaries
<ogra_> yeah
<nacc> a few other classic snappers have blogged the same (incl. didrocks)
<ogra_> well, you can always use some wget and dpkg -x to actually squeeze the artful libc in from a scriptlet ... not sure what the outcome would be thouogh
<nacc> heh
<nacc> yeah
<ogra_> most likely i gigantic snapcraft.yaml but perhaps a working snap in the end
<ogra_> s/i/a/
<ogra_> might end up like a multi page novel
<pstolowski> mvo, weird. I had to install libc6-dev-i386 and it works again. did anything change?
<mvo> Chipaca: lol
<mvo> pstolowski: yeah, but that is part of the new build-depends
<nacc> ogra_: yeah, that's what i'm worried about :)
<mvo> pstolowski: we build a i386 syscall test runner now on amd64 to test secondary arch syscall support
<ogra_> nacc, btw, did you try to drop things like xz from the snap to get around the difference you described initially ?
<pstolowski> mvo, ok, makes sense. i should have looked at build-depends.. thanks
<nacc> ogra_: if i do that, xz will fail (the versionin the core snap is too old for gbp)
<nacc> ogra_: well, gbp will fail, rather
<nacc> ogra_: the stuff i've added is stuff that is too old in the core snap
<nacc> ogra_: so i could do that, and then the snap becomes less useful
<ogra_> ah
<nacc> ogra_: goes back to why i'm buildinng on artful in the first place :)
<Chipaca> pstolowski: that's what my going on about "apt build-dep ./" was
<Chipaca> brb
<pedronis> mvo: IÂ pushed some tweaks to #3935 , probaly merit a check/recheck
<mup> PR #3935: cmd/snap-repair: implement the repair run loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/3935>
<mvo> pedronis: great, I have a look
<nacc> sergiusens: how do you know the apt you are bulidig doesn't also need a newer dpkg in snapcraft's snapcraft.yaml ?
<nacc> based upon what you said, you should also be building dpkg from src, no?
<nacc> it feels like that if one is make a classic snap, one should simply not use stage-packages at all, as those come from teh build env (or one should only build on the same build env as the core snap, which is not an explicit binding in the yaml)
<ogra_> well, the latter is the expectation
<nacc> right, but that should be a hard rule then
<ogra_> whioch is why you should always use cleanbuild ... because this makes sure to use the right env
<nacc> yeah
<kalikiana> elopio: Could you give https://github.com/snapcore/snapcraft/pull/1382 another look? I apologize for the messy diff... branch is okay locally
<mup> PR snapcraft#1382: rust plugin: make libc configurable <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382>
<ogra_> (and by default LP as well as build.s.io both default to xenial only builds)
<nacc> ogra_: yep, i get that -- this just makes our snap so cumbersome as to possibly make it not worth my time and I should just make a .deb instead
 * kalikiana really hates git sometimes when a simple thing in bzr becomes a huge mess in git
<ogra_> kalikiana, you mean like *every freaking command* ?
<sergiusens> nacc so, following in up here, the only reason this is a snapcraft problem is because snapd hasn't gone down the hard path of injecting library path through the linker and overriding the chosen linker to use to load (all hard things)
<nacc> sergiusens: i don't know, is that true?
<sergiusens> nacc that said, zyga-ubuntu did most of the initial work on classic so should be aware of the limitations
<nacc> sergiusens: becuase afaict, there is no artful libc in either my snap or the core snap
<nacc> sergiusens: so even if the loader was updated, i have to somehow get libc from artful into my sap
<ogra_> sergiusens, well, snapcraft would still prevent your snap from shipping another libc, wouldnt it ?
<kalikiana> ogra_: Yeah, kind of. Sometimes even typos in 'git add'. Rebase especially because there's no snaity checks or defaults
<sergiusens> nacc and last but not least, we came up with the idea that all runnables should be compiled through snapcraft, it sort of doesn't matter where as we ensure the linker from the core snap gets picked and restrict library loading through rpath
<nacc> sergiusens: right, but your example (snapcraft itself) does't compile dpkg
<nacc> which apt runs
<ogra_> kalikiana, i know what you mean ... after using git for a while i get along but it is still making me want to throw my laptop out of the window regulary
<nacc> so I don't have a good example yet
<nacc> kalikiana: i suggest usign `git add -i`
<sergiusens> nacc ah, ic your point now
<nacc> kalikiana: less chance of typos
<nacc> sergiusens: and so i have to manually (it seems) recurse to the lowest level of every dep and build those all by hand? what's the pointn :)
<sergiusens> kalikiana sometimes, if rebases get hard, from master: `git checkout -b new-branch; git merge --squash old-branch; git brand -D old-branch`
<ogra_> or just convince upstream to use bzr :)
<sergiusens> nacc I never said I liked classic, the work was dumped on me to get it working without even consulting with me ;-)
<ogra_> classic is an ugly wart ...
<nacc> sergiusens: right but it's there, and either should work, or should have large alarms for stuff that's fundametnally broken, or should be disabled :)
 * sergiusens blames zyga-ubuntu
<elopio> kalikiana: sure
<sergiusens> he said it was going to be easy ;-)
<ogra_> it is the equivalent of slef containing tarballs you dump into /opt ... just with a proper update mechanism
<sergiusens> nacc right, but we also only really support building on xenial
<nacc> kalikiana: are you sayign there aren't actually 136 commits between you and the target branch?
<nacc> ogra_: yep, i agree
<kalikiana> sergiusens: I actually did that, well using 'git am', because rebase took an old copy of master, rebasing of which would've introduced conflicts in files I never touched
<nacc> ogra_: really, i don't need to be a classic snap (although that wonn't solve this problem), I just ened to be able to write anywhere o the disk the user tells me to and have network
<ogra_> so just make your "tarball" contain *everything* ;)
<kalikiana> nacc: 'git log' shows me 8 commits on top, which is my actual changes, and the diff affects 4 files
<zyga-ubuntu> sergiusens: what? :)
<nacc> kalikiana: oh i see what you did
<nacc> kalikiana: snapcraft:rust-musl is 128 commits behind master
<nacc> kalikiana: so you rebased onto master? which was definitely wrong
<nacc> kalikiana: you should have rebased onto snapcraft:rust-musl
<ogra_> nacc, just make your snapcraft.yaml wget http://cdimage.ubuntu.com/ubuntu-base/daily/current/artful-base-amd64.tar.gz ... unpack it from a prepare scriptlet and do the rest on top ;)
<nacc> right, but *every* classic snap on artful shold be doing htat
<ogra_> no
<nacc> if they use libc, that is
<ogra_> not if it isnt *built* on artful
<nacc> sorry, that's what i meant by 'on artful'
<ogra_> :)
<nacc> *built on nartful
<nacc> *artful
<ogra_> nerdful :)
<nacc> or any non-xenial, really
<nacc> it should use the corresponding base image
<nacc> but is that really sane to do?
<ogra_> yes, but we dont have that yet ... the tarball above would be a workaround though
<nacc> yeah
<nacc> ok, i'll try that first before going down the path of rebuilding everything
<ogra_> well, it is as sane as the whole classic concept
<nacc> lol
<ogra_> :)
<nacc> also i find it frustrating that i have to use VMs to build artful snaps (cleanbuild just doesn't have any optio)?
<nacc> (e.g., it should take a lxd-profile)
<ogra_> well, you should simply not use artful until we have a base snap for it
<ogra_> else ... there is the path through the hoops -> ...
<nacc> ok
<kalikiana> nacc: I don't follow - this is rust-musl, and I wanted to rebase it onto master... I don't see how I rebase on the same branch...?
<nacc> I mean, I won't be able to convince anyone who has bought into snaps 100% that this is insane :) I know that
<ogra_> the really really awesome thing is ... snapcraft will actually let you do this :)
<nacc> ogra_: but yeah, that is nice
<nacc> at least there is a workaround
<ogra_> you might end up with a giant snap and a 70page snapcraft.yaml ... but it will definitely be possible in the end
<nacc> kalikiana: https://github.com/snapcore/snapcraft/pull/1382 says you are merging from kalikian:rust-musl to snapcore:rust-musl
<mup> PR snapcraft#1382: rust plugin: make libc configurable <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382>
<nacc> kalikiana: not snapcore:master
<nacc> kalikiana: also *your* rust-musl is not snapcore's rust-musl
<nacc> distributed development ftw
<sergiusens> merge and rebase are different; if you look at the command I gave out, it is much easier to operate if you don't want to replay the commits on top of the new base and just squash instead
<kalikiana> nacc: Hmm interesting. How did that even get there. There's not supposed to be any branch like that - there's only master, and I proposed rust-musl, based on master... *scratches head*
<kalikiana> nacc: Ha, changing the base branch fixes it! Awesome that you pointed this out!
<kalikiana> elopio: Mess fixed :-D ^^
<kalikiana> On a side note, this is working wonders for my headache, great distraction
<nacc> sergiusens: you can do that with interactive rebase
<nacc> sergiusens: which i would suggest over merge
<nacc> sergiusens: and 'merge' in github terminology can be FF
<nacc> (well git terminology, but the PR/MP model)
<nacc> kalikiana: yw
<sergiusens> nacc oh yeah, but replaying the first commit my make you scratch your head if the following ones are where you fixed things
<nacc> sergiusens: true, yeah, i don't know the details in this case
<nacc> sergiusens: i tend to do iterative development with wip commits (possibly with where they need to be squashed to), then innteractive rebase, squash appropriately
<sergiusens> nacc from the name, it is a month old branch, so many things have changed :-)
<nacc> sergiusens: yeah :)
 * sergiusens gets started with lunch
<kalikiana> elopio: wrt #1530 I really don't know what to make of your phrasing... you sound doubtful if it's worth it, and you had doubts before... how am I supposed to see value in it? :D
<mup> PR #1530: asserts: add cross checks for snap asserts <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1530>
<kalikiana> erm that was supposed to be https://github.com/snapcore/snapcraft/pull/1530
<mup> PR snapcraft#1530: tests: share the cache dir in the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1530>
<pedronis> merging stuff today seems a bit hopeless
<Chipaca> ok, dinner etc
 * Chipaca goes
<kalikiana> elopio: kyrofa https://github.com/snapcore/snapcraft/pull/1348 would appreciate another look
<mup> PR snapcraft#1348: repo: setup a foreign arch and sources <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1348>
<zyga-ubuntu> eh
<zyga-ubuntu> github
 * kalikiana concludes tonight, as headache gets too bad to work, and investigating why inside lxd 'fuser /var/lib/apt/lists/lock' doesn't seem to work as expected is proving tedious
<kyrofa> elopio, I have an odd request: any chance you have a fedora VM lying around?
<kyrofa> Or really anyone: I could use SSH access to a fedora machine for a few minutes
<kyrofa> Stupid under-powered eeepc
<kyrofa> zyga-ubuntu, I saw a forum post from you about your setup. Any fedora installs on there?
<zyga-ubuntu> yay, so tests pass
<kalikiana> kyrofa, wouldn't be surprised if Pharaoh_Atem had one for you
<zyga-ubuntu> kyrofa: hey, one but not wired (I use it for various things)
<zyga-ubuntu> kyrofa: what would you find useful?
<zyga-ubuntu> kyrofa: I can set something up and give you an account
<kyrofa> Argh, Pharaoh_Atem you need a consistent handle :P
<kyrofa> zyga-ubuntu, I just want to try running a snap on it
<zyga-ubuntu> kyrofa: any arch will do?
<kyrofa> amd64 if possible
<zyga-ubuntu> kyrofa: I need to find some ram sticks but I can prepare a machine for tomorrow
<zyga-ubuntu> kyrofa: that's easiest
<kyrofa> zyga-ubuntu, ah, I need it tonight. You know, now that I bring it up, I bet DigitalOcean has me covered
<zyga-ubuntu> kyrofa: do you have access to spread?
<kyrofa> zyga-ubuntu, thank you for being willing, though!
<kyrofa> I do
<zyga-ubuntu> kyrofa: my pleasure, I'll try to set one up anyway, maybe over weekend
<zyga-ubuntu> kyrofa: just spawn our F25 box
<kyrofa> zyga-ubuntu, ah! It's been a while, what command would that be?
<zyga-ubuntu> kyrofa: hmm, copy spread.yaml from snapd
<zyga-ubuntu> kyrofa: yank everything but the fedora linode system
<zyga-ubuntu> kyrofa: remove all the prepare stuff, essentially gut it
<zyga-ubuntu> kyrofa: add foo/task.yaml with summary line
<zyga-ubuntu> kyrofa: and see what "spread -list" prints
<kyrofa> zyga-ubuntu, alright, good deal, thanks!
<zyga-ubuntu> kyrofa: then
<zyga-ubuntu> kyrofa: spread -shell linode:fedora-25-65:foo
<zyga-ubuntu> kyrofa: that *should* give you a shell quickly
<zyga-ubuntu> kyrofa: I can prepare a working spread.yaml if you want
<kyrofa> zyga-ubuntu, if you have a sec, that would be greatly appreciating, I have a meeting now
<kyrofa> Huh. Grammar is not my skill today
<zyga-ubuntu> kyrofa: on it
<sergiusens> kyrofa digital ocean ftw ;-)
<sergiusens> then you get to control all the toggles
<zyga-ubuntu> kyrofa: testing now
<zyga-ubuntu> kyrofa: niiiiiice
<zyga-ubuntu> kyrofa: let me test other systems and I'll give you a working gist
<zyga-ubuntu> oooooh
<zyga-ubuntu> f***********
 * zyga-ubuntu needs to restore from backup
<zyga-ubuntu> I removed my snapd tree
<zyga-ubuntu> along with all the code I was working on
<zyga-ubuntu> DARN
<zyga-ubuntu> I copied a symlink
 * zyga-ubuntu is pretty upset now
<zyga-ubuntu> darn, I wonder if my backup worked
<zyga-ubuntu> I suspect it's a few days old at least at a weekly schedule
<zyga-ubuntu> kyrofa: that's for you http://paste.ubuntu.com/25588274/
 * zyga-ubuntu needs to look at his backup
<sergiusens> elopio mind taking a look at snapcraft#1564 ?
<mup> PR snapcraft#1564: setup: changes to make installable from PyPI <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1564>
<mup> PR snapcraft#1564 opened: setup: changes to make installable from PyPI <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1564>
<sergiusens> elopio also what mup will show in a bit please :-)
<mup> PR snapcraft#1565 opened: cli: add the assemble command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1565>
<jdstrand> roadmr: hi! can you sync r933 of the review tools? not urgent; only changes are additions to overrides.py
<roadmr> jdstrand: sure! note it's unlikely to make it to prod until after next week's rally :/
<jdstrand> roadmr: that's totally fine
<roadmr> jdstrand: whee :) see you there I expect?
<jdstrand> roadmr: you bet! :)
<Pharaoh_Atem> kyrofa: ?
#snappy 2017-09-22
<mup> PR snapcraft#1558 closed: tests: add fake pip fixture <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1558>
<mup> PR snapd#3947 closed: cmd/snap-repair: fix tests when running as root <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3947>
 * zyga-ubuntu has the worst friday possible
<zyga-ubuntu> I removed my snapd tree, including all of git history last night
<zyga-ubuntu> so plan for today, is to ensure this doesn't happen again
<mup> PR snapcraft#1566 opened: recording: record build-snaps installed during the pull <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1566>
<zyga-ubuntu> kyrofa: hey
<zyga-ubuntu> kyrofa: did you use that pastebin I gave you last night?
<cjwatson> daily automated backups of everything - it's the only way
<zyga-ubuntu> cjwatson: deja dup backups got corrupted
<zyga-ubuntu> cjwatson: I'll use something else as this is not the first time backup was not working, just this time was more damaging
<cjwatson> Yeah, I used deja-dup for a little while and then decided it was far too complex
<cjwatson> I use rsbackup now which is basically just glorified rsync --link-dest; much less to go wrong
<zyga-ubuntu> thank you, I'll check that out
<mvo> zyga-ubuntu: could oyu please check 3953?
<zyga-ubuntu> mvo: sure
<zyga-ubuntu> mvo: why not go all the way and just do this unconditionally?
<mvo> zyga-ubuntu: not sure, to minimize risk maybe?
<mvo> zyga-ubuntu: I'm fine with all-the-way for 2.29
<zyga-ubuntu> mvo: sounds good to me
<mvo> thanks
<zyga-ubuntu> done
<mup> PR snapd#3953 closed: snap-confine: fix base snaps on core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3953>
<mvo> thanks zyga-ubuntu
<zyga-ubuntu> thank you for doing this :)
<mvo> Pharaoh_Atem: is 2.28~rc3 doing ok on fedora or anything needs fixing before 2.28-final?
<kalikiana> zyga-ubuntu: backups of git? in my word, that's what you get by pushing ;-)
<kalikiana> good morning, snappy world
 * kalikiana no more headache for now, just caughing, may the health be with me today
<oSoMoN> My latest upload to the store of chromium failed the automated review because the chrome sandbox executable has the setuid bit set, but that used to be allowed previously (not sure if it was an exception for that snap only, or something else). Can anyone from the store/review team help?
<oSoMoN> (oh, and good morning everyone, by the way!)
<mvo> zyga-ubuntu: http://paste.ubuntu.com/25590963/ <- snapd needs to create that dir in the re-exec case or fail gracefully, right now re-exec with edge is briken
<mvo> broken
<zyga-ubuntu> mvo: loking
<zyga-ubuntu> oh
<zyga-ubuntu> good point
<zyga-ubuntu> mvo: how did tests not catch that?
<zyga-ubuntu> mvo: ah, I think I know
<zyga-ubuntu> mvo: ok I have a patch
<mup> PR snapd#3955 opened: dirs,interfaces: create snap-confine.d on demand when re-executing <Created by zyga> <https://github.com/snapcore/snapd/pull/3955>
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3955
<mup> PR #3955: dirs,interfaces: create snap-confine.d on demand when re-executing <Created by zyga> <https://github.com/snapcore/snapd/pull/3955>
<zyga-ubuntu> Chipaca: can you please look at https://github.com/snapcore/snapd/pull/3955/files
<mup> PR #3955: dirs,interfaces: create snap-confine.d on demand when re-executing <Created by zyga> <https://github.com/snapcore/snapd/pull/3955>
<Chipaca> aye aye cap'n
<zyga-ubuntu> thank you
<zyga-ubuntu> Chipaca: I lost my snapd tree with 2 weeks of code in it
<zyga-ubuntu> not a great day
<Chipaca> zyga-ubuntu: did you look under the bed
<zyga-ubuntu> Chipaca: I wanted to stay there today actually
<Chipaca> zyga-ubuntu: under the bed?
<zyga-ubuntu> in it
<Chipaca> zyga-ubuntu: my dog hides under the bed during thunderstorms
<Chipaca> she's brave like that
<zyga-ubuntu> CI is slow today?
 * Chipaca quotes poetry at niemeyer 
<sparkiegeek> Chipaca: Vogon poetry?
<Chipaca> sparkiegeek: unix poetry
<Chipaca> sparkiegeek: tomeito/tomahto
<mup> PR snapcraft#1567 opened: recording: record the snaps installed in the machine <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1567>
<mup> PR snapd#3956 opened: snap-confine: bind mount /usr/lib/snapd relative to snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3956>
<mvo> zyga-ubuntu: ^- something for you :) should be easy but was a bit tricky to figure out
<zyga-ubuntu> looking
<zyga-ubuntu> mvo: interesting,
<zyga-ubuntu> mvo: I suspect we can do away with _some_ of those snprintfs but it looks good
<mup> PR snapd#3955 closed: dirs,interfaces: create snap-confine.d on demand when re-executing <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3955>
<zyga-ubuntu> mvo: done
<pedronis> mvo: zyga-ubuntu: should 't we change the name of sc_mount_config.on_classic_distro to something else , now that is true on core also with base snaps
<zyga-ubuntu> pedronis: yes, I think it will become "use_classic_confinement" or similar
<zyga-ubuntu> pedronis: as everything else will be identical
<zyga-ubuntu> we may not need that variable afte rall
<pedronis> classic_confinement is a bit strange given that is not confiment: classic
<zyga-ubuntu> in which way?
<zyga-ubuntu> I mean that the only remaning boolean variable is if we need a mount namespace or not
<pedronis> I'm saying that using classic in the name of a bool that we use both on classic and core is strange, that classic confiment means too many things already
<zyga-ubuntu> pedronis: right, I think we are in agreement, it is not done yet but eventually there will be just one flag "mount namespace needed", we need to finish the transition and rename things
<ackk> niemeyer, hi, left a question on https://github.com/snapcore/snapd/pull/3916 about validateion
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<ackk> *validation
<doko> snapcraft autopkg test failure: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/s/snapcraft/20170922_010609_57ea7@/log.gz
<doko> output: {{{b'/snap/godd/x1/bin/godd: relocation error: /snap/godd/x1/lib/x86_64-linux-gnu/libpthread.so.0: symbol __mmap, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference\n'}}}
<doko> but it's built with glibc-2.26 ...
<ogra_> godd is also a properly confined snap (i have only seen that with --classic snaps on artful yet) which makes it even weirder ...
<ogra_> mvo, ^^^
<ogra_> *classic snaps that get built *on* and *against* artful
<mvo> ogra_: looking
<mup> PR snapd#3934 closed: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3934>
<mup> PR snapd#3928 closed: interfaces/system-observe: allow clients to enumerate DBus connection names <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3928>
<ackk> ogra_, mvo does snapd already have code to validate URIs (hostname:port, ip:port, ipv6:port, port and so on)?
 * ogra_ doesnt know ... i think we used to have code to check for occupied ports when we used to support the "ports:" keyword in snap.yaml during 15.04, but i dont know if that code survived
<ackk> ogra_, now that I think about it, for the listen-stream case I think I could just validate that it's a port, there's no real point in specifying an address
<ackk> well, maybe localhost
<ogra_> ackk, well, what happens if i install a snap using port 80 that already has an apache deb installed ?
<ackk> ogra_, that's a separate issue though
<ogra_> right, but there needs to be some check so my snap doesnt madly try to respawn
<kyrofa> zyga-ubuntu, I did, thank you! It was tremendously helpful. I tried to thank you last night, but you were gone :(
<sergiusens> kyrofa up so early?
<kyrofa> sergiusens, I've been a little more popular than I was anticipating... haven't had time to put that lightning talk together! This is my solution :P
<sergiusens> elopio mind looking at the artful issues with snapcraft (mentioned on ubuntu-release and here by doko)? I'll be running errands all day today
<zyga-ubuntu> kyrofa: I was upset because while doing that I removed my whole snapd tree with unmerged code
<zyga-ubuntu> kyrofa: I had a symlink
<kyrofa> zyga-ubuntu, I'm sorry about that! Were you able to recover from backup?
<zyga-ubuntu> kyrofa: and I wasn't operating on a copy :(
<zyga-ubuntu> kyrofa: no, my backup was broken (deja-***-dup)
<kyrofa> :(
<zyga-ubuntu> anyway
<zyga-ubuntu> I kind of remember what I wrote
<zyga-ubuntu> guess what I'm doing today
<mvo> ackk: hi, re url parsing> is https://golang.org/pkg/net/url/#Parse that you need?
<Chipaca> I wish there was an Equals interface in go
<ackk> mvo, not really. listen-stream for TCP/UDP is basically in the form of  [address:]port
<mvo> ackk: hm, I see
 * Chipaca takes a break
<ackk> mvo, I mean, I can implement the validation, just wondering if there's something like that already
<mvo> ackk: not sure what exactly listen-stream looks like, but https://play.golang.org/p/Fi-0n-cRNF is using url.Parse() even without schema
<ackk> mvo, also, it may be that we just care about the port (see my comment https://forum.snapcraft.io/t/socket-activation-support/2050/28?u=ack)
<mvo> ackk: I have a meeting now, but can check after the meeting for listen-stream
<ackk> mvo, it doesn't really work https://play.golang.org/p/QPUxhKV_Dv :)
<niemeyer> Moin moin
<niemeyer> ackk: Thanks, responded
<mvo> niemeyer: please start without me, I'm in a different meeting
<zyga-ubuntu> oh
<zyga-ubuntu> standup
<zyga-ubuntu> joining
<phil_m> zyga-ubuntu: hi, how are you today?
<zyga-ubuntu> phil_m: hi
<zyga-ubuntu> phil_m: I'm around
<phil_m> good.
<phil_m> just wanted to ask you about the current progress you made with Manjaro.
<phil_m> any news. some I should test on my end?
<zyga-ubuntu> phil_m: I didn't have time to try it on real hardware but I have a spare HDD so I plan to install it over weekend; apart from that it is ready and I just want to test it
<zyga-ubuntu> phil_m: (on hardware, works in VM)
<zyga-ubuntu> phil_m: I had a pretty bad day last nigth though because my I managed to rm -rf my work directory on my main desktop
<phil_m> zyga-ubuntu: ouch.
<phil_m> that is really sad to hear.
<ackk> niemeyer, thanks. basically I think I only need a final decision about what is acceptable for listen-stream
<ogra_> niemeyer, how do i add an "ogra" tag in the forum (does that need you with admin rights ?)
<niemeyer> ogra_: Yeah, not just me, but someone with permissions
<zyga-ubuntu> phil_m: but no worries, all my patches are still in that VM so I didn't completely blow my data
<niemeyer> ogra_: Only thing I ask is to please follow the conventions in that topic (can find the link if you want) about tagging with upcoming and backlog as well, so the username tag should not be alone
<phil_m> zyga-ubuntu: ok. makes sense
<ogra_> niemeyer, it is for https://forum.snapcraft.io/t/split-initrd-implementation/2224/1
<ogra_> (allready has upcoming and will likelyy get more names on it)
<ogra_> niemeyer, thanks!
<niemeyer> ogra_: Done, tag created
<ogra_> oh, gone again
<niemeyer> ogra_: You should be able to use it now
<ogra_> k
<ogra_> yup, works
<mup> PR snapcraft#1568 opened: lxd: don't re-inject the same snaps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1568>
<mvo> jdstrand: when you have a moment (not urgent) a review of 3956 would be appreciated
 * kalikiana feeling dizzy and hungry, taking a break and looking for some food
<mup> Bug #1718942 opened: running favorited snap shows two icons in Ubuntu dock <Snappy:New> <https://launchpad.net/bugs/1718942>
<phil_m> zyga-ubuntu: I just created a new package of snapd with version 2.28dev+g0723493
<phil_m> zyga-ubuntu: still face the error 'cannot locate the base snap: ubuntu-core: No such file or directory' on my end.
<ogra_> phil_m, weird, does it really still say ubuntu-core ?
<ogra_> phil_m, also ... did you see https://forum.snapcraft.io/t/snap-on-arch-liri-os/2223/1
<phil_m> yep.
<phil_m> zyga-ubuntu: used files can be found here: https://github.com/manjaro/packages-community/tree/master/snapd-git
<phil_m> and the standard stable release at: https://github.com/manjaro/packages-community/tree/master/snapd
<ogra_> (funny that is seems to be kind of working with a few minor changes on liriOS but not on manjaro ... )
<phil_m> maybe I should change PATH=$PATH:/var/lib/snapd/snap/bin:/snap/bin to just PATH=$PATH:/snap/bin
<phil_m> orga_: we already use: https://github.com/snapcore/snapd/commit/413a2a099dc57e3fb7c7e82a6c7250cf4c2f74fd
<ogra_> yeah
<zyga-ubuntu> phil_m: hmmmmm
<zyga-ubuntu> phil_m: we had a patch for that error message
<zyga-ubuntu> phil_m: one sec
<kyrofa> Hey kalikiana I've got an odd bug. As you've been touching the repo code most recently, any chance you've come across it? https://bugs.launchpad.net/snapcraft/+bug/1686481
<mup> Bug #1686481: stage-packages doesn't respect architectures <kubernetes> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1686481>
<kyrofa> Or otherwise have any insight
<zyga-ubuntu> phil_m: do you have 8c821c13bb62703c5119a1b0b1edbd53ce7f48aa in your tree?
<phil_m> let me check
<phil_m> no, will try some now.
<mup> PR snapd#3957 opened: cmd,dirs: treat "liri" the same way as "arch" <Created by zyga> <https://github.com/snapcore/snapd/pull/3957>
<phil_m> hmm, the error is gone, but now it simply hangs a while
<phil_m> chromium now started with a delay
<ogra_> well
<phil_m> second start was faster.
<ogra_> snaps typically coopy some stuff arund on first start
<ogra_> s thats kind of expected
<phil_m> seems it is now kinda working
<ogra_> \o/
<zyga-ubuntu> phil_m: is snapd running?
<phil_m> seems so
<ogra_> if the chroium snap runs it better should :P
<phil_m> now I only don't know if it is in /snap or in the /var/lib/snapd/snap
<zyga-ubuntu> phil_m: what did you rebuild?
<zyga-ubuntu> phil_m: can you please look at https://forum.snapcraft.io/t/snap-on-arch-liri-os/2223/4
<zyga-ubuntu> phil_m: using that source package (just with .6 and manjaro patch instead of liro patch) you should be mostly fine
<phil_m> will upload the changes soon
<jdstrand> mvo: done
<flexiondotorg> Hey zyga-ubuntu
<flexiondotorg> So, you're still seeking an Arch TU to collaborate with?
<zyga-ubuntu> flexiondotorg: hey
<zyga-ubuntu> flexiondotorg: yes, very much so
<zyga-ubuntu> flexiondotorg: especially now with arch derivatives suffering from old package ther
<zyga-ubuntu> flexiondotorg: do you have someone that could help?
<flexiondotorg> Well, I've been reaching out to the main derivatives Manjaro and Antergos.
<flexiondotorg> I'll see if I still have any credit in the Arch community. I'll see if I can find a sponsor to reprise my role as Arch Linux TU
<zyga-ubuntu> flexiondotorg: thank you!
<flexiondotorg> If I can get a sponsor, it will still be down to a vote and that takes a month
<zyga-ubuntu> yes, I read the protocol
<zyga-ubuntu> the best we can do though
<zyga-ubuntu> I really wish timothy didn't abandon the package
<zyga-ubuntu> but it seems he has
<zyga-ubuntu> (also ignoring email)
<flexiondotorg> Yep, I've tried contacting him too
<zyga-ubuntu> maybe we could give him a ring via RH
<flexiondotorg> Indeedð
<zyga-ubuntu> "step down considerably" is not a virtue it seems
<zyga-ubuntu> e
<zyga-ubuntu> er
<zyga-ubuntu> "resposibly" was it?
<zyga-ubuntu> anyway
<Pharaoh_Atem> mvo: let me give it a whirl
<Pharaoh_Atem> zyga-ubuntu: I'll see if I can get a hold of tradelli
<mvo> Pharaoh_Atem: thanks
<Pharaoh_Atem> zyga-ubuntu: he's in the Fedora community somewhat since he now works at Red Hat
<zyga-ubuntu> Pharaoh_Atem: thank you!
<zyga-ubuntu> Pharaoh_Atem: note that we made multiple attempts to contact him (irc, twitter, email, linkedin) and got no replies
<zyga-ubuntu> (over extended amount of time)
<Pharaoh_Atem> zyga-ubuntu: I've talked to him a couple of times recently
<Pharaoh_Atem> his dead is down in the weeds in DPDK and kernel networking stuff
<Pharaoh_Atem> s/dead/head/
<mvo> jdstrand: thanks a bunch! I addressed your comments
<zyga-ubuntu> Pharaoh_Atem: haha
<Pharaoh_Atem> he took over from Panu Matilainen when he returned to the helm of rpm development/maintenence
<zyga-ubuntu> Pharaoh_Atem: DPDK?
<Pharaoh_Atem> Data Plane Developer Kit
<Pharaoh_Atem> from Intel, now a Linux Foundation project
<Pharaoh_Atem> does weird things to network subsystem to make things go fasterer
<Pharaoh_Atem> https://en.wikipedia.org/wiki/Data_Plane_Development_Kit
 * ogra_ points to apt-cache show dpdk
<zyga-ubuntu> magic
<Pharaoh_Atem> but basically, DPDK is terrible and sucks the life out of you
<zyga-ubuntu> Pharaoh_Atem: it must pay well then
<Pharaoh_Atem> mvo: err, why is the spec in 2.28 branch telling me it's 2.27.5?
<phil_m> zyga-ubuntu: Manjaro now supports fully snaps
<Pharaoh_Atem> mvo: ah, you haven't been bumping the versions like you did for 2.27 during the rc development
<phil_m> I've tested the curren stable v2.17 and current dev series v2.28
<zyga-ubuntu> phil_m: \o/ !!
<zyga-ubuntu> phil_m: excellent
<zyga-ubuntu> phil_m: what kind of GPU do you have?
<zyga-ubuntu> phil_m: and can you tell me more about your kernel
<zyga-ubuntu> phil_m: (and can we add a logo with installation instructions to snapcraft.io?)
<phil_m> you can add a logo and the instruction # pacman -Sy snapd when we released it also to our stable branches
<phil_m> I've an Nvidia gpu
<zyga-ubuntu> phil_m: excellent, I'll make that happen! Thank you! :)
<phil_m> and the kernel is more or less vanilla with some patches added.
<zyga-ubuntu> phil_m: do you have a preferred logo (quality, etc) I should use?
<davidcalle> zyga-ubuntu: phil_m: can you open a bug with the logo?
<phil_m> https://github.com/manjaro/packages-core/tree/master/linux413
<phil_m> is the current stable kernel
<phil_m> davidcalle: in which tracker should I open the bug?
<davidcalle> https://github.com/canonical-websites/snapcraft.io-static-pages
<davidcalle> Thanks phil_m :)
<zyga-ubuntu> thank you both!
<kalikiana> kyrofa: Sorry for the late reply, this stupid cold forced me to rest... regarding bug 1686481 I'll add a comment in a moment
<mup> Bug #1686481: stage-packages doesn't respect architectures <kubernetes> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1686481>
<jdstrand> mvo: hey, did you see my followup comment on PATH_MAX?
<jdstrand> mvo: also, think you need a go fmt
<phil_m> davidcalle: https://github.com/canonical-websites/snapcraft.io-static-pages/issues/387
<zyga-ubuntu> jdstrand: thank you for the instructive reviews!
<zyga-ubuntu> mvo: can I merge https://github.com/snapcore/snapd/pull/3952
<mup> PR #3952: cmd: update "make hack" <Created by zyga> <https://github.com/snapcore/snapd/pull/3952>
<zyga-ubuntu> one more test...
<kalikiana> kyrofa: Good job spotting that old bug :-D I posted a test snippet that seems to work for me. Although this is almost untested so not sure if it does what they need - but at least I've got some tests for this in my queue
<kyrofa> kalikiana, excellent, thank you very much :)
<ogra_> ARGH !
<ogra_> my rocket snap just made my system get stuck
<ogra_> niemeyer, is it wanted that mup just sent ~1000 PR messages to #snapcraft on rocket ?
<niemeyer> ogra_: I hope you know the answer to that :)
<ogra_> heh
<ogra_> well, something is weird
<niemeyer> ogra_: IIRC mup was actually disabled there
<ogra_> yeah
<niemeyer> ogra_: Someone is probably fiddling with settings
<ogra_> thats what i meant with weird :)
<niemeyer> ogra_: They broke the plugin API for the Nth time a couple of months ago and I disabled it.. need to look into it to see if it's fixed
<ogra_> seems to have stopped now
<sergiusens> kalikiana elopio how about a look on snapcraft#1565 ?
<mup> PR snapcraft#1565: cli: add the assemble command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1565>
<niemeyer> ogra_: Probably someone just flipped the switch enabling it
<ogra_> yep, for a minute or two and it replayed some caxche i guess
<kalikiana> sergiusens: You got some comments
<ikey> looks like manjaro landed snap support
<ikey> the commune groweth
<zyga-ubuntu> ikey: indeed :)
<ikey> looks like everyone is getting on the bandwagon now
 * ikey likes cascading self ordering chaos
<niemeyer> ikey, zyga-ubuntu: Nice!
<ogra_> nacc, i guess kyrofa would know more about that ;)
<ogra_> (and i'm saying this here because he isnt in #ubuntu-release=
<ogra_> )
<ogra_> :)
<nacc> ogra_: ack :)
<mvo> zyga-ubuntu: I think so
<mvo> jdstrand: yeah, I fixed that, thanks and sorry :)
<mvo> Pharaoh_Atem: I can push with 2.28~rc4 if you want
<mup> PR snapd#3952 closed: cmd: update "make hack" <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3952>
<jdstrand> mvo: thanks!
<zyga-ubuntu> mvo: thank you
<Pharaoh_Atem> mvo: I'm testing to see if the new cheggaaa-pb package works without the hack atm
<mvo> Pharaoh_Atem: thanks
<Pharaoh_Atem> if it does, I'm going to send a PR to revert that commit and then the corresponding revert can be done in 2.28
 * zyga-ubuntu -> supper
<kyrofa> Nooo, I got up at 5am to prep a lightning talk only to arrive and learn they switched it to a raffle instead of first-come-first-served... and didn't get in
<kyrofa> nacc, ogra_ I seem to be missing the scrollback that contains context. What would I know more about?
<nacc> kyrofa: it's mostly in #ubuntu-release
<nacc> kyrofa: let me get the linnk
<kyrofa> Haha, well that would explain the missing context
<nacc> https://irclogs.ubuntu.com/2017/09/22/%23ubuntu-release.html
<nacc> kyrofa: exec. summary: 1) snapcraft dep8 tests are broken on artful 2) artful builds of snaps are broken
<nacc> aiui, the solutions are multiple: 1) snapcraft dep8 should use cleanbuild
<zyga-ubuntu> man, travis and github don't love me today
<nacc> 2) there needs to be blacklist libs file added for all non-16.04 releases (elopio had a test for this for 17.10 specifically)
<zyga-ubuntu> network isuses
<kyrofa> Yes indeedy, that's not surprising at all
<nacc> 3) the fallback for not havinng a filelist should be an error (IMO), not a fallback. As it just doesn't work. Or the fallback list should be everything the libc deb provides
<nacc> now that won't fix artful builds of snaps, as they still have a xenial core snap and there be dragons
<nacc> but it means the libc issue that's currently busted would work, i think
<nacc> s/would work/would not manifest itself/
<kyrofa> Sorry guys, I didn't realize that was a room in which I should idle
<kyrofa> Rectified now
<nacc> kyrofa: we probably should have brought the convo here
<kyrofa> nacc, so yeah, snapcraft crawls prime and essentially sucks over any libs it discovers via ldd on every elf
<kyrofa> nacc, it ships the libraries/16.04 file as a blacklist of stuff in the core snap to NOT suck over
<kyrofa> But of course, it checks the OS before deciding whether or not to use libraries/16.04, or libraries/16.10, etc
<kyrofa> The latter of which doesn't exist
<kyrofa> Thus nothing gets excluded, and it sucks everything off the host
<nacc> kyrofa: yep that was my analysis from the source as well
<nacc> kyrofa: since snapcraft's dep8 is runnig natively on artful, it didn't find any blacklist file
<kyrofa> This is a problem not only per release, but per arch, as different arch core snaps contain different things, and thus need separate blacklists
<nacc> kyrofa: ouch :/
<kyrofa> To compound matters, we've decided the library sucking feature sucks (heh) because it's magical and unreliable, as you've discovered, so we haven't really invested in making it better
<nacc> well, as of right now there are two relatively high-profile (to me) issues then: snapcraft dep8 is failing and any snap built on artful right now is going to be broken
<kyrofa> Yes and yes. Agreed
<nacc> I happened to get built by the latter before the former was seen, I guess :)
<asafniv1[m]> any good snap apps?
<kyrofa> I really don't think we should just remove the feature though, or current snaps will stop working
<kyrofa> So we probably need to invest some time in improving it
<asafniv1[m]> we should make snaps use system fonts and theme
<nacc> kyrofa: yeah, i'm not sure the best way forward -- i think elopio's file list is a good start (i'm not sure how many non-amd64 non-classic snaps are being built on artful, e.g.)
<nacc> kyrofa: but like you said, that's insufficient on its own
<nacc> i'm also switching my snap to build on xenial (presuming the tests pass :)
<kyrofa> ogra_, if I install a snap on artful, what core snap am I getting? The 16 one, right?
<kyrofa> Which means even if we DO blacklist the stuff in the core snap, if the libc in artful changes, it'll still be pulled in
<zyga-ubuntu> kyrofa: yes
<kyrofa> Even if the library sucking feature was gone, the snap would be built against a different libc version than that with which it will be run
<kyrofa> There's no solution to this problem!
<kyrofa> :P
<nacc> kyrofa: yeah, this is all pretty buggy (building on artful) until we get base snaps
<kyrofa> Yep
<nacc> that's why, honestly, it should be disabled (but there's no way to communicate that effectively it feels like)
<nacc> it's just guaranteed to have weird failures eventually :)
<kyrofa> nacc, well, like I said, even if it was disabled, building on artful won't result in a snap that runs
<nacc> kyrofa: no, i mean, don't allow buildig on artful :)
<nacc> at least not via LP
<kyrofa> Ahhh
<asafniv1[m]> Don't use ubuntu
<kyrofa> Agreed. It should only be xenial
<nacc> it's just goign to lead to bad publishes to the store right now
<nacc> kyrofa: yep
<kyrofa> Indeed
<kyrofa> And the autopkgtests should be cleanbuild
<nacc> kyrofa: yeah, that will at least get them passing, regardless of aythign
<kyrofa> Although that means less of snapcraft is tested, which isn't great
<asafniv1[m]> what if someone makes a snap virus
<zyga-ubuntu> asafniv1[m]: what then?
<asafniv1[m]> would canonical remove it?
<asafniv1[m]> btw do they test snaps?
<asafniv1[m]> or scan?
<zyga-ubuntu> asafniv1[m]: we don't test snaps
<zyga-ubuntu> asafniv1[m]: we scan them for certain things
<zyga-ubuntu> asafniv1[m]: and check which interfaces they want to use, snaps get manual review if they request privileged interface for the first time
<asafniv1[m]> ok
<nacc> kyrofa: yeah, the coverage would go down, i suppose
<zyga-ubuntu> asafniv1[m]: the security model depends on a combination of sandbox, distinction between privileged and common interfaces and packages that are signed by the snap store
<zyga-ubuntu> asafniv1[m]: you can upload any code you like, it will not be allowed to do anything from the privileged set unless there is a store review and we essentially trust you
<zyga-ubuntu> niemeyer: hey
<zyga-ubuntu> ah, found it :)
<niemeyer> zyga-ubuntu: Heya :)
<zyga-ubuntu> niemeyer: I flagged some spam on the forum
<zyga-ubuntu> niemeyer: wasn't sure if you are still around
<niemeyer> zyga-ubuntu: Done
<zyga-ubuntu> thank you :)
<niemeyer> zyga-ubuntu: np, thanks for flagging!
<nacc> we've got a jenkins job that is trying to test MPs for git-ubuntu before we land them by building a snap on xenial (using cleanbuild) in a xenial VM and then testing that locally built snap. Anyone know why we're gettinng the following error related to the core snap?https://paste.ubuntu.com/25594413/
<sergiusens> kyrofa nacc we shouldn't improve it, we should remove it as we discussed months ago, breakage here is a simple fix
<sergiusens> and there probably won't be base snaps for non LTS releases
<sergiusens> but we haven't gotten into the details around that, probably a discussion for next week with niemeyer
<nacc> sergiusens: yeah, i'm +1 onn removing it if there really can't be support for it
<nacc> sergiusens: i'm not going to be at the rally, but i thikn i'll be getting hte info from my team
<mup> Bug #1690880 changed: test_snappy_version fails on artful <cloud-init:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1690880>
<kyrofa> sergiusens, I don't think that's a good idea-- lots of snaps will break. But it's your call
<sergiusens> kyrofa they will have a simple fix
<kyrofa> sergiusens, it's still breakage that requires them to fix it
<nacc> sergiusens: build from source on xenial?
<kyrofa> Think CI, daily builds
<sergiusens> kyrofa if CI never breaks, why do you run it?
<sergiusens> I know it will break, people running CI will detect it fast and adapt
<kyrofa> CI is for catching MY problems :P
<sergiusens> same thing for new features and deprecations in snapd (e.g.; aliases)
<kyrofa> But yeah, your call
<nacc> sergiusens: is what i said the fix?
<nacc> is this expected?
<nacc> ls -ahl /snap/core/current/lib64/ld-linux-x86-64.so.2
<nacc> lrwxrwxrwx 1 root root 32 Sep 11 23:36 /snap/core/current/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.23.so
<nacc> (which does't exist on artful)
<nacc> ogra_: --^ i switched my snnap to build with cleanbuild and now i get the relocation error on artful :)
<ogra_> heh
<nacc> still waiting for jenkins to finish to see if it works on 16.04 now, at least
<nacc> specifically /usr/bin/python3: /snap/core/current/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /usr/bin/python3)
<nacc> not sure why it' susing the python3 from the host
<ogra_> is it using the python plugin ?
<nacc> ogra_: no, my app just uses the dump plugin
<nacc> and every command is pointed at a wrapper script
<nacc> that invokes python3 *in* my snap
<ogra_> kyrofa, sorry, i didnt mean you should permanently idle in #ubuntu-release ... that was more a ping for if you were around to participate in the discussion :)
<ogra_> nacc, right ... the pytjon plugin makes sure you get the interpreter inside iirc
<ogra_> *python
<nacc> ogra_: hrm, by doing what? i mean does it tell snapd something?
<ogra_> so you should perhaps add another part using the python plugin and not doing anything else
<ogra_> it ships it in $SNAPp
<nacc> oh i do have one for python2
<ogra_> it ships it in $SNAP/bin
<nacc> hrm
<nacc> ok
<nacc> ogra_: i have a python3 in my snap
<nacc> i'm wondering if env is messed up now
 * ogra_ gets dinner and needs to go afk ... 
<nacc> ogra_: np, thanks for all the help today!
<ogra_> :)
<nacc> ok relocation error was a bug in how i was calling the python3 argcomplete
<kwmonroe> ahoy snapaholics - in the content interface doc (https://forum.snapcraft.io/t/the-content-interface/1074) it mentions writable data should "share all of $SNAP_DATA or $SNAP_COMMON for now."  is that still a thing?  i'm able to share writable subdirs in core-16-2.27.6, but dunno what nasties may come.
<nacc> ogra_: lol, i see it now and am not sure how to fix it
<nacc> #!/usr/bin/env python3 in my pseudo-confined snap will segfault on artful
<nacc> because i've modified LD_LIBRARY_PATH to point to the core snap
<nacc> but /usr/bin/env is from artful
<nacc> ogra_: so that was definitely one issue (which is hard to debug, as the segfault happens in the python script wrapped)
<nacc> ogra_: and i foudn the other one, i had forgotten to drop the stage-packages i was no building from src, so they were overriding my built binaries and leading to segfaults ;)
<nacc> i'm rebuilding now to test
<mup> PR snapcraft#1569 opened: tests: refactor the fake snapd to not hardcode values <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1569>
<nacc> kyrofa: sergiusens: do you want me to file a bug or something for this?
<nacc> ogra_: --^
#snappy 2017-09-23
 * ikey is gonna print off his pending snapd patches and hand deliver them on sunday
<niemeyer> ikey: That'd be fantastic :P
<ikey> lol
<ikey> TSA will probably lock me up thinking i cracked some satellite codes
<ikey> send in Bruce Willis to protect me
 * ikey might've watched netflix recently.
<sergiusens> ikey better that than being Axl Torvalds from swordfish :-)
<ikey> heh
<diddledan> sergiusens: ikey: what about axel foley from beverly hills cop (1, 2 or 3)
<diddledan> the swordfish reference, I'm not sure I can crack 512bit DOD encryption in 60 seconds by "just seeing a pattern"
<diddledan> especially when there's a lady doing naughty things
<diddledan> I suppose the kid from mercury rising would be able to though
<diddledan> and of course that brings us back to bruce's willi
<ogra_> hmm
 * ogra_ wonders if that would be snappable https://github.com/letoram/arcan
<ogra_> diddledan, oh man ... that ring snap builds each and every dependency ....
<ogra_> (i wonder why it needs any stage-packages at all )
<CoderEurope> Hello is this a xenial snap yet ?  #snappy https://docs.saltstack.com/en/2015.8/topics/installation/ubuntu.html
<ogra_> $ snap find salt
<ogra_> The search "salt" returned 0 snaps
<ogra_> ...
<ogra_> seemingly not
<CoderEurope> How do I change that ? Iam on deepin
<ogra_> CoderEurope, well, you could try to snap it yourself, talk to upstream in #salt and ask them to build a snap or you could ask on the forum (see channel topic) if someone else is willing to snap it
<ogra_> regarding the forum ... https://forum.snapcraft.io/t/snap-wishlist-suggestions-wanted/567 ...
<mup> PR snapd#3621 closed: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3621>
<mup> PR snapd#3938 closed: interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3938>
<mup> PR snapcraft#1566 closed: recording: record build-snaps installed during the pull <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1566>
<nacc> fwiw, i think the help here is wrog, at least on the latest snapcraft: https://snapcraft.io/docs/build-snaps/plugins
<nacc> plugins are now in snapcraft.plugins
<nacc> and each modules defines its own
<nacc> so the example there would be 'from snapcraft.plugins import base'
<sergiusens> nacc the baseplugin to import from is still correct though
<sergiusens> should be at least
<nacc> sergiusens: oh is that special? i think it's actually much more common to override oen of the non-base plugins :)
<nacc> sergiusens: i'm getting a segmentation fault from a classic snap built on xenial, running onn artful
<nacc> the segv is i ld-2.26.so, which is from the host (afaict)
<nacc> in the core snap, I see
<nacc> $ ls -ahl /lib64/ld-linux-x86-64.so.2
<nacc> lrwxrwxrwx 1 root root 32 Sep  4 00:34 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.26.s
<nacc> err
<nacc> ls -ahl lib64/ld-linux-x86-64.so.2
<nacc> lrwxrwxrwx 1 root root 32 Sep 11 23:36 lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.23.so
<nacc> which is a broken symlink (but perhaps there is some voodoo?)
<nacc> but i feel like hwat's segfaulting is the older loader isn't being used
#snappy 2017-09-24
<sergiusens> nacc readelf on your binary and check that the correct "program loader" is used.
<nacc> sergiusens: thanks, will look
<mup> Bug #1652617 changed: customized dragonboard image cannot complete booting <Snappy:Expired> <https://launchpad.net/bugs/1652617>
<mup> Bug #1705091 changed: unable to use snap after install <Snappy:Expired> <https://launchpad.net/bugs/1705091>
<Son_Goku> kyrofa: ping
#snappy 2018-09-17
<mup> PR core18#67 closed: hooks: add ping <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/67>
<ahasenack> hi, is awk supposed to be in the core snap?
<ahasenack> I started getting this error today:
<ahasenack> 09/17/2018 05:44:20 - ERROR:stderr: /snap/git-ubuntu/433/usr/share/quilt/push: line 306: awk: command not found
<ahasenack> my core snap was updated 5 days ago, and I haven't used the laptop since then (was on pto)
<ahasenack> or maybe this is related to snapd's update regarding the PATH issue from last week?
<mup> PR snapcraft#2277 opened: snap: move to a newer pysha3 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2277>
<jamesh> ahasenack: git-ubuntu is a classic snap, so it may be relying on utilities on the host system
<jamesh> awk is definitely in the core snap, but /usr/bin won't be from core for classic snaps
<jamesh> and looking at the core snap, /snap/core/current/usr/bin/awk is an absolute symlink, so won't resolve if the snap adds /snap/core/current/usr/bin to $PATH
<sergiusens> Wimpress: how's the sprint?
<Wimpress> All good
<ads20000> popey: quick idea, does the snap-advocacy-bot thingy update snap dependencies automatically? If so: 1. That's really really cool!!! 2. Where's the code and could you guys make it a service for other snaps to use?
<ads20000> *non-snapcrafters snaps
<ahasenack> jamesh: thanks. Trying to track what changed, since the git-ubuntu snap didn't (afaik)
<jamesh> ahasenack: looking at the git-ubuntu snap.yaml, it is definitely adding /snap/core/current/usr/bin to $PATH
<jamesh> ahasenack: so if I had to guess, the usr/bin/awk symlink has changed from relative to absolute
<jamesh> ahasenack: I suspect https://github.com/snapcore/core/pull/93 is the cuprit
<jamesh> culprit, even
<mup> PR core#93: hooks: unwind /etc/alternatives <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/93>
<ahasenack> rbasak: ^
<rbasak> jamesh: that sounds likely. I'm happy to fix the git-ubuntu snap as needed, but isn't it a problem that changes in the core snap regress existing classic snaps like this?
<jamesh> rbasak: I don't think it is a problem with the git-ubuntu snap
<rbasak> Oh, I misunderstood. You think it could be a core snap regression then?
<jamesh> rbasak: yeah.  Ideally all these symlinks should be relative so they point at the same thing whether in strict or classic confinement
<rbasak> OK, thanks
<popey> ads20000: it is just a shell script that touches a file which triggers a rebuild. It's not that clever :D
<mborzecki> cachio: https://api.travis-ci.org/v3/job/428160334/log.txt
<popey> ads20000: the goal was to trigger a rebuild of every single snap in snapcrafters to review what's broken
<rbasak> Is there a reliable way for me to detect inside the code in a part whether snapcraft is running (eg. by it calling setup.py) or if I'm running in production?
<rbasak> I was using $SNAP but that only worked with the deb, and I suspect it has stopped working with the latest snapcraft in Xenial.
<rbasak> This is for a workaround for a bug, so some kind of temporary hack will also do.
<popey> rbasak: to detect if you're currently building via snapcraft? There are various $SNAPCRAFT_ environment variables that only exist during the snap build in snapcraft
<popey> e.g. $SNAPCRAFT_PART_INSTALL
<rbasak> That sounds like it'll do. Thanks!
<cachio> mborzecki, https://paste.ubuntu.com/p/PHhq2ZpMH7/
<ads20000> popey: oh I see... fair enough! :)
<jamesh> popey: is SNAPCRAFT_PART_INSTALL actually set in the environment?  I thought they just expanded it in the scriptlet
<popey> oh, one for @sergiusens
<ogra> there are other vars though
<ogra> thresh, yo ... i noticed that vlc can not access any avahi exported resources (namely i run various webcams around my house and while i can open them in a browser, the vlc snap does not resolve .local names at all)
<ogra> opeing them via IP works fine ...
<ogra> probably just adding the "avahi-observe" plug would just be enough ... not sure ...
<thresh> possibly
<thresh> if you could test that I'd be grateful
<ogra> if you can provide a snap with it enabled (in edge or so) i'll happily test
<thresh> let me fire the build then
<thresh> ogra, you're on stable right, so 3.0.4?
<mup> PR snapd#5835 opened: tests: find snaps just for edge and beta channels <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5835>
<ogra> thresh, yep
<mup> PR snapd#5827 closed: ifacestate/autoconnect: do not self-conflict on setup-profiles if core-phase-2 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5827>
<mup> PR snapcraft#2278 opened: snap: pull early <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2278>
<kyrofa> Hey Chipaca, what is the core snap release process? Does snapd master land anywhere that it can be used?
<ogra> there is a PPA
<thresh> ogra, it's in beta, #583
<mup> PR #583: interfaces: support permanent security snippets <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/583>
<ogra> kyrofa, does https://launchpad.net/~snappy-dev/+archive/ubuntu/edge help ?
<kyrofa> ogra, I should have just asked that second question: how can I test out a feature in snapd that hasn't yet been released?
<ogra> kyrofa, ah, just the edge core snap then
<ogra> that should always have a daily build of master
<kyrofa> Oh, that's what I thought, but a feature seems to be missing. Maybe it's my problem
<ogra> (though dont ask me how that works for core18 ... )
<thresh> it also seems vlc from the store is missing a camera autoconnect
<ogra> well ... not sure if i'd like it to do that on my system
<kyrofa> ogra, it seems edge core contains 2.35.2
<ogra> so manual seems fine
<kyrofa> (unless that version is hard-coded)
<popey> jdstrand: did something change in mksquashfs overnight? I have a snap which grew 5.5MB, but contents are same from yesterday to today.
<ogra> kyrofa, ah, i think mvo overrides it when he does a release, normally you have dailies from master though
<ogra> popey, debug symbols ? (check the sizes of the binaries if you have yesterdays build around)
<popey> the contents are the same
<popey> only the snap grew overnight
<kyrofa> ogra, are you in brussels?
<ogra> kyrofa, nope
<ogra> 250km east :)
<kyrofa> :(
<kyrofa> Well drive over here already
<ogra> haha
<ogra> thresh, https://paste.ubuntu.com/p/NQbtcQ9wGC/ ... sadly the interface isnt enough ... i guess it'd also need a client lib or some such
<ogra> IP works fine ...
<ogra> $ vlc http://192.168.2.59:8080/?action=stream
<ogra> VLC media player 3.0.5 Vetinari (revision 3.0.4-20-g7df06c6)
<ogra> [0000000000d5f3b0] main libvlc: VLC wird mit dem Standard-Interface ausgefÃ¼hrt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
<ogra> (the UI pops up after that line)
<popey> Do you have network-bind?
<ogra> yeah, vlc has that by default
<ogra> (and it is auto-connected)
<thresh> I think it has the avahi-client lib or somethign
<thresh> I mean the discovery works so
<ogra> watching dmesg while it starts up with avahi address only gets me the typical perf denial ... nothing special there
<ogra> (and using the IP shows the same message ... )
<thresh> ogra, do you have avahi-daemon running?
<thresh> running vlc -vv gives me e.g. "[00007fa7d0d7b530] avahi services discovery: service 'ms' of type '_sftp-ssh._tcp' in domain 'local' port 22
<ogra> thresh, locally ? sure, else the browser wouldnt open the url
<ogra> and the processlist agrees
<thresh> but it did resolve to an ip address it seems
<thresh> ogra, can you PM/mail me the output of vlc -vv from your machine so I can compare?
<thresh> preferably with LC_ALL=C
<ogra> wow, thats a lot of output ...
<ogra> https://paste.ubuntu.com/p/yW78Kct79N/
<ogra> thresh, ^^^
<thresh> oh I should have been more verbose: try accessing the discovered streams as well
<thresh> ah wait
<thresh> you're using CLI to actually access them
<ogra> i can use the UI only but that gets the same result
<ogra> https://paste.ubuntu.com/p/93nJGhkXHB/
<ogra> same thing using the GUI to open the stream URL
<thresh> you probably used "open network stream";  can you go to the "zeroconf network services" to check if it's there?  https://imgur.com/98AKRXp
<thresh> normally it's nsswitch.conf that's supposed to have mdns4 or somethign similar, I'm not sure how that works in the snapped env
<ogra> i actually use "open network stream" (is there another way ?)
<ogra> sorry, i had to change machines now for a meeting ... will take a bit til i get back to the other one
<thresh> interestingly this "zeroconf network services" works without granting vlc avahi-observe
<thresh> sure
<ogra> my typical way is: media -> open network stream -> pick (former) URL from the pulldown
<ogra> i normally use the minimal interface and no playlist ... so i never noticed there is that zeroconf list
<kyrofa> zyga, are you around?
<mup> PR snapd#5836 opened: tests: try to build cmd/snap for darwin <Created by chipaca> <https://github.com/snapcore/snapd/pull/5836>
<Chipaca> kyrofa: in a meeting
<kyrofa> Chipaca, does snapd actually have a room?
<Chipaca> kyrofa: yes
<Chipaca> kyrofa: we are fancy that way
<kyrofa> It's not on the spreadsheet. Or rather, it is, but it's actually MY room :P
<Chipaca> kyrofa: Â¯\_(ã)_/Â¯  come up to floor 7. We have cookies.
<Chipaca> * the cookies are, all of them, lies
<kyrofa> Nice. Cookies always have butter in them anyway
<mup> PR snapd#5837 opened: daemon: make error responders not printf when called with 1 argument <Created by chipaca> <https://github.com/snapcore/snapd/pull/5837>
<mup> PR snapcraft#2277 closed: snap: move to a newer pysha3 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2277>
<mup> PR snapd#5838 opened: many: return real snap name in API response <Created by zyga> <https://github.com/snapcore/snapd/pull/5838>
<mup> PR snapd#5839 opened: overlord/state: return latest LastAdded time in WarningsSummary <Created by chipaca> <https://github.com/snapcore/snapd/pull/5839>
<ogra> thresh, so looking at the zeroconf stuff, that only opens sftp to act as file server
<ogra> (back at the other machine)
<thresh> but they do resolve?
<thresh> probably via libavahi calls, not system dns resolver
<ogra> yes, they do resolve and i get a user/password prompt
<ogra> but i guess thats very specific to the file services bit in the playlist ... wotn affect generic DNS resolution
<ogra> *wont
<mup> PR snapcraft#2279 opened: sanity checks: run properly on build VMs <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2279>
<thresh> interesting that we only support ftp/sftp/nfs/smb/rtsp published via avahi, and not http
<ogra> ah, is there a protocol list in the code somewhere ?
<kyrofa> sergiusens, ^
<ogra> perhaps thats the limiting bit
<thresh> yep https://git.videolan.org/?p=vlc.git;a=blob;f=modules/services_discovery/avahi.c;h=956835dbc1ad2f5376a50e09cf2ce0e934933320;hb=10e610ee2f1f11c6fbc6f723bb52a665010fbeb7#l81
<thresh> well, I'm pretty sure vlc wont try avahi-sd when it just gets the http://foo.local/ link
<ogra> aha
<ogra> so not actually a snap issue then ... interesting
<ogra> (funny that i never noticed it before though ... but i really havent)
<thresh> will a regular system resolver be used for gethostbyname calls in a snap?
<thresh> I mean, does it respect the system-wide nsswitch magic or core snap has its own copy?
<ogra> it should through network and network-bind i think
<ogra> hmm
<ogra> chromium cant resolve it either
<ogra> just trying with the chromuim snap here
<thresh> then I'm a bit buzzled why it works in firefox then
<ogra> well, not using a FF snap here
<thresh> my snapped firefox doesnt resolve .local too
<ogra> but it seems to be a systemic snap issue
<ogra> yeah
<thresh> non-snapped ping foo.local works though, so I would say different settings in nsswitch for snaps
<ogra> aha ... snaps only use https://www.freedesktop.org/software/systemd/man/nss-resolve.html
<ogra> so the fact that i'm running 16.04 whihc doesnt use systemd-resolved might also play a role
<thresh> I'm on debian testing, and I dont have that daemon as well
<ogra> oh, really ? did debian not switch to it yet ?
<ogra> 18.04 uses it by default
<ogra> instead of resolvconf ...
<ogra> there is definitely nothig in any interface allowing access to nsswitch.conf though
<ogra> so unless the snap uses systemd's nss resolver .local links wont be resolved anywhere
<ogra> smells like a bug ... hmm
<thresh> I've no idea what's the default in debian these days, I try to avoid system-* stuff where possible
<ogra> thresh, well, not a vlc issue in any case, thanks a lot for your time
<thresh> no problem at all
<ogra> (and thanks for vlc ... it is one of my most used snaps !)
<mwhudson> Chipaca: is created-at from the store v2 api going to get propagated to the snapd v2/find endpoint any time soon?
<Chipaca> mwhudson: define soon
<Chipaca> mwhudson: once the search api is also v2, yes
<Chipaca> mwhudson: otherwise search and info would be too different
<mwhudson> Chipaca: dunno what i mean by soon really
<mwhudson> (or any other words at this point of the day)
<mwhudson> the reason for asking is that i want to show the info in subiquity
<Chipaca> mwhudson: there's a v2 search session this week
<mwhudson> which currently just pings v2/find?name=blah
<Chipaca> mwhudson: be there or be parallelepiped
<mwhudson> Chipaca: "snap search improvements"?
<Chipaca> mwhudson: yeh
<Chipaca> probably
 * Chipaca looks
<Chipaca> mwhudson: yes, that's the one i meant
<mwhudson> ok
<mwhudson> i shall consider loitering
<Chipaca> mwhudson: when you say it pings v2/find,  you mean on the store?
<mwhudson> no
<thresh> ogra, I wonder if there is any software capable of publishing http streams on avahi
<mwhudson> on snapd
<thresh> I'd try that at home
<mwhudson> sorry, should have said
<ogra> thresh, well, on a laptop with webcam: snap install mjpg-streamer, edit "DAEMON" from false to true in /var/snap/mjpg-streamer/current/config; snap restart mjpg-streamer ... then it serves on "http://<host>.local:8080/?action=stream"
<ogra> should theoretically work on any modern lptop
<ogra> *laptop
<ogra> oh, i forgot ... snap connect mjpg-streamer:camera ... it doesnt auto-connect
<thresh> right, thanks!
<mup> PR snapcraft#2280 opened: Use the better snapcraft.io/account URL <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/2280>
<mup> PR snapcraft#2276 closed: spread: move legacy wiki tests to spread <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2276>
<mup> PR snapcraft#2278 closed: snap: pull early <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2278>
<anarcat> hello
<anarcat> i'm trying to figure out the history of my firefox snap package
<anarcat> i'm running 62 now but i seem to recall other versions were installed in the past
<anarcat> what's the magic command? "snap changes" doesn't yield any output
<Thesaurus> did they break the icons for gnome-system-monitor and gnome-characters in a recent update?
<thresh> hmm, seems apt://vlc no longer works as a <a> link to install VLC on Ubuntu Software app anymore, any tips what snapcraft.io app uses?
<thresh> snap://vlc it seems
#snappy 2018-09-18
<icey> hey; I recall a tool to help identify the plugs that a new snap that's in development needs but can't find a reference to that, I'd rather not go spelunking through logs if I can help it ;-)
<sergiusens> icey: snappy-debug
<mup> PR snapcraft#2279 closed: sanity checks: run properly on build VMs <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2279>
<mup> PR snapcraft#2281 opened: build providers: re-exec as root <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2281>
<icey> thanks sergiusens
<mup> PR snapd#5713 closed: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<jdstrand> popey: not to my knowledge. is it possible something in your staged packages got bigger?
<popey> jdstrand: the snap contents are the same
<popey> overnight a bunch of snaps got bigger
<popey> it's just the squashfs is larger
<jdstrand> popey: looking at https://launchpad.net/ubuntu/+source/squashfs-tools I don't see any super recent changes
<popey> https://www.irccloud.com/pastebin/OnGrwj4c/
<jdstrand> popey: do they still pass automated review?
<popey> yes
<popey> ^ 55 / 54 are unpacked squashfs
<popey> perhaps the unsquash / resquash padded somehow?
<jdstrand> popey: I'm gonna have to shrug. I don't know what caused that, certainly not overnight
<popey> ah, not store resquash, as launchpad built it bigger
<jdstrand> popey: popey is it possible that 54 was built without -no-fragments?
<popey> i didnt change anything
<jdstrand> 54 wouldn't pass automated review then
<jdstrand> popey: was 54 built with the older squashfs-tools than what is in xenial now?
<jdstrand> popey: it wouldn't surprise me based on the fscaps patch for it to be a bit bigger. not sure why it would be so much bigger...
<popey> it's not the only one, others have grown
<jdstrand> actually, reading that patch, it shouldn't be any bigger
<jdstrand> popey: the review tools pass on both 54 and 55?
<jdstrand> popey: does one contain the snap/manifest.yaml and one doesn't? probably not, you said the files are identical. did you diff 'unsquashfs -lls <snap>' for 54 and 55?
<jdstrand> popey: I need to do a little meeting prep then attend a meeting
<popey> jdstrand: i diffed the unpacked directories
<popey> no worries, just wondered why it bloated overnight, with seemingly no changes
<kyrofa> roadmr, nextcloud is still having troubles releasing revisions
<kyrofa> What is going on?
<roadmr> kyrofa: same thing as before?
<jdstrand> popey: diffing the unsquashfs -lls output might also be interesting
<kyrofa> roadmr, not quite, I'm no longer getting emails about failed or manual reviews
<roadmr> kyrofa: I see no stuck uploads this time, they're all either released or ready to release
<kyrofa> roadmr, but none of my dailies are actually being released, just uploaded
<roadmr> kyrofa: I assume you're using Launchpad to do the builds? do the Launchpad logs for failed-to-release revisions tell anything? (If you point me to one I can have a look)
<popey> jdstrand: http://paste.ubuntu.com/p/KRqH7HP5NW/
<kyrofa> roadmr, indeed, it seems that the release failed, wonder why I didn't get an email. I don't see a log, though: https://code.launchpad.net/~nextcloud-snappy-dev/+snap/nextcloud-daily-master/+build/334596
<roadmr> checking, kyrofa
<roadmr> kyrofa: hm... yes, no log about the upload failure...
<roadmr> kyrofa: let me check with Colin (we're in a meeting so might take a bit)
<icey> is it possible to configure a snap license as not Proprietary?
<kyrofa> Thanks roadmr
<roadmr> icey: it is
<roadmr> icey: go to http://dashboard.snapcraft.io/, log in with your account if needed, click on the snap's name, and at the bottom of the overview page you can edit the license information
<icey> thanks roadmr
<mup> PR snapd#5839 closed: overlord/state: return latest LastAdded time in WarningsSummary <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5839>
<mup> PR snapd#5724 closed: tests: new test for the cpu-control interface <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5724>
<cjwatson> roadmr,kyrofa: can't tell right now because our OOPS system is backlogged; I need to chase a vanguard about that once one appears
<cjwatson> it'll be https://oops.canonical.com/?oopsid=OOPS-80ef5e7e2eea921e55aac893b16c643f but that doesn't exist yet
<roadmr> ohh :( thanks for having a look cjwatson
<mup> PR snapd#5838 closed: many: return real snap name in API response <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5838>
<mup> PR snapd#5836 closed: tests: try to build cmd/snap for darwin <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5836>
<mup> PR snapd#5837 closed: daemon: make error responders not printf when called with 1 argument <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5837>
<mup> PR snapd#5840 opened: interfaces/apparmor, interfaces/builtin: tweaks for parallel snap installs <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5840>
<mup> PR snapcraft#2281 closed: build providers: re-exec as root <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2281>
<mup> PR snapcraft#2282 opened: build providers: cleaner start and launch messaging <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2282>
<mup> PR snapd#5841 opened: interfaces/hotplug: hotplug spec takes one slot definition <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5841>
<mup> PR snapd#5842 opened: interfaces/testiface: added TestHotplugInterface <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5842>
<mup> PR core#96 opened: hooks: use relative path when unwinding /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/96>
<stokachu> all of a sudden my builds are failing, https://paste.ubuntu.com/p/yX2hdkDXDS/
<stokachu> supposedly this is a known issue with snapcraft?
<stokachu> it also doesn't like snap/wrappers anymore
<stokachu> https://github.com/conjure-up/conjure-up/tree/master/snap is where my snap stuff is
#snappy 2018-09-19
<mup> PR snapd#5834 closed: cmd/snap: commands no longer build their own client <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5834>
<mup> PR snapd#5843 opened: client, cmd/snap: expose warnings to the world <Created by chipaca> <https://github.com/snapcore/snapd/pull/5843>
<Chipaca> bongiorno, principesse
<Chipaca> buon*
<Chipaca> drat
<Chipaca> :-)
<mup> PR core18#71 opened: hooks: use relative symlinks when unwinding <Created by mvo5> <https://github.com/snapcore/core18/pull/71>
<zyga> Chipaca: reviewed
<Chipaca> zyga: #5802 +1'ed
<mup> PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802>
<mup> PR snapcraft#2282 closed: build providers: cleaner start and launch messaging <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2282>
<rbasak> This seems odd:
<rbasak> Failed to reuse files from previous run: The 'pull' step of 'wrappers' is out of date:
<rbasak> The source has changed on disk.
<rbasak> On a Launchpad snap build of git-ubuntu
<rbasak> https://launchpadlibrarian.net/389203040/buildlog_snap_ubuntu_xenial_amd64_git-ubuntu_BUILDING.txt.gz
<rbasak> Surely that should never happen on a single fresh snapcraft run?
<rbasak> Oh
<rbasak> I never merged https://code.launchpad.net/~kyrofa/usd-importer/+git/usd-importer/+merge/354509
<rbasak> That's probably it. Sorry.
<zyga> jdstrand: hey, low priority ping that I updated https://github.com/snapcore/snapd/pull/5170
<mup> PR #5170: interfaces/builtin: add adb interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<mup> PR snapd#5802 closed: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5802>
<mup> PR snapd#5844 opened: interfaces/opengl: misc accesses for VA-API <Created by flexiondotorg> <https://github.com/snapcore/snapd/pull/5844>
<mup> PR snapcraft#2283 opened: snapcraft snap: refactor override-build into a script <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2283>
<kyrofa> sergiusens, ^
<mup> PR snapcraft#2284 opened: build providers: make use of time for multipass stop <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2284>
<mup> PR snapcraft#2285 opened: snapcraft snap: vendor legacy snapcraft <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2285>
<thresh> hello
<thresh> are there any "get it on Snap store" kinda buttons for the website?
<thresh> I'm redoing the "download for ubuntu" page for VLC, and would like to use something
<thresh> popey, maybe you know? ^^^
<popey> Yes, I will dig it out after lunch. Iirc slack has it on their download page if you want to steal that :)
<thresh> popey, found it;  not sure if it's made by slack or snapteam;  would like to know the license if it's made by you folks
<popey> thresh: our design team made it, but I'll find the original mail where I got it
<popey> thresh: ok, asked design for the details, we should get it within the next day or so.
<diddledan> popey: can you make sure someone relevant sees my comment here: https://forum.snapcraft.io/t/developer-sprint-sep-17th-2018/7336/20
<popey> diddledan: i do believe that is the plan, even though it may not be written on that thread. Good catch
<diddledan> good good
<thresh> popey, thanks!
<ogra> diddledan, +1000 !
<diddledan> ooh, Innernet Points!
 * diddledan cashes them in for a shiny badge
<ogra> :D
<zyga> kyrofa: https://discourse-docs.staging.snapcraft.io/t/the-snap-format/698
<zyga> kyrofa: look for "autostart"
<mborzecki> kyrofa: let me know if there's anything missing there on autostart
<kyrofa> mborzecki, actually works better than I thought it did. One weird thing, I'm gonna head up there in a minute to show you something
<kyrofa> Haha, he's running
<kyrofa> You can't hide from me mborzecki
<mup> PR core18#71 closed: hooks: use relative symlinks when unwinding <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/71>
<sergiusens> kyrofa: take a chance and look at my PR, he is standing right in front of me
<kyrofa> sergiusens, I did
<mup> PR snapcraft#2283 closed: snapcraft snap: refactor override-build into a script <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2283>
<stokachu> sergiusens, https://paste.ubuntu.com/p/H3zkBwh4W8/
<stokachu> any idea?
<stokachu> ive had to refactor some of the snapcraft stuff b/c it doesn't like wrappers in snap/ anymore
<stokachu> https://github.com/conjure-up/conjure-up/tree/snap-fixes is the current state of it
<stokachu> rbasak, that error you saw, happened to me, had to move wrappers out of snap
<stokachu> then do some override-prime to make it work
<sergiusens> stokachu: I am having dinner now. But I can help you with a PR if you want.
<stokachu> basically whats in my ^ snap-fixes branch
<sergiusens> As soon as I get back
<stokachu> sergiusens, sure or if youre EOD can do it tomorrow
<stokachu> whatever works
<sergiusens> I have no issues with unblocking you as early as I can
<stokachu> hah, you make me feel so loved
<mup> PR snapd#5843 closed: client, cmd/snap: expose warnings to the world <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5843>
<mup> PR snapd#5845 opened: interface: add new dotfiles interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845>
#snappy 2018-09-20
<mup> PR snapd#5844 closed: interfaces/opengl: misc accesses for VA-API <Created by flexiondotorg> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5844>
<mup> PR snapd#5758 closed: overlord/snapstate, snap: handle shared snap directories when installing/remove snaps with instance key <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5758>
<mup> PR snapd#5846 opened: snap: tweak commands <Created by mvo5> <https://github.com/snapcore/snapd/pull/5846>
<mup> PR snapd#5841 closed: interfaces/hotplug: hotplug spec takes one slot definition <Hotplug> <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5841>
<mup> PR core#96 closed: hooks: use relative path when unwinding /etc/alternatives <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/96>
<mup> PR snapcraft#2284 closed: build providers: make use of time for multipass stop <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2284>
<mup> PR snapd#5847 opened: overlord/snapstate: improve cleaup in mount-snap handler <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5847>
<mup> PR snapcraft#2286 opened: config: change default outdated action to clean <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2286>
<mup> PR snapcraft#2287 opened: meta: support relocatable prime for path verification <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2287>
<memphisto> hi. running ubuntu 16.04 in lxc (on proxmox) and i've installed snapd but it fails with  cannot mount squashfs image using "squashfs": mount: /tmp/selftest-mount
<memphisto> anyone faced the issue or can help where to look for
<memphisto> snap version 2.34.2; snapd is unavailable
<mborzecki> memphisto: can you check if you have squashfuse installed?
<memphisto> no it wasn't ; but event with it i get errrors
<memphisto> Get http://localhost/v2/find?q=openkm&scope=wide: dial unix /run/snapd.socket: connect: connection refused
<memphisto> i get lots of similar errors :  Failed to reset devices.list on /system.slice/ufw.service: Operation not permitted
<memphisto> there isn't /system.slice folder
<memphisto> doing apt install --reinstall snapd
<memphisto> it fails just afer installed ; when setting up snapd
<zyga> memphisto: when snapd detects that it cannot mount snaps it doesn't start
<memphisto> error it reports is this snapd.service: Start request repeated too quickly.
<memphisto> but when i get throug syslog i syee lots of thesee
<memphisto> Sep 20 10:15:14 smbct systemd[1]: Failed to reset devices.list on /init.scope: Operation not permitted
<memphisto> Sep 20 10:15:14 smbct systemd[1]: Failed to reset devices.list on /system.slice/proc-meminfo.mount: Operation not permitted
<memphisto> Sep 20 10:15:14 smbct systemd[1]: Failed to reset devices.list on /system.slice/rc-local.service: Operation not permitted
<memphisto> but there isn't system.slice
<memphisto> https://github.com/lxc/lxd/issues/2004
<Son_Goku> zyga, niemeyer: epel7 branch requested: https://pagure.io/releng/fedora-scm-requests/issue/8214
<Son_Goku> by hook or crook, somehow this is going to work this weekend
<kyrofa> cachio, was talking to mvo earlier this week about how edge typically follows master until a release process starts, then it becomes the next release. It would be ideal if edge could always follow master. mvo switched it back for me so I can test stuff, but it seems it's become the release again
<cachio> kyrofa, we should be creating a new core snap on edge when there is a change in master
<cachio> it takes a time to be created
<cachio> kyrofa, is it not happening?
<kyrofa> cachio, ideally you could switch it back to the previous master release after you promote it, perhaps
<kyrofa> cachio, not sure if anything has landed recently, but until it does (and causes a new build) one cannot test anything that isn't in a release
<kyrofa> Which makes edge kinda useless for a while
<kyrofa> cachio, anyway, mvo told me to mention it to you
<mup> PR snapcraft#2288 opened: build providers: use multipass automatically when on darwin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2288>
<mup> PR snapd#5846 closed: snap: tweak commands <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5846>
<stokachu> sergiusens, any word on that build error?
<mup> PR snapd#5842 closed: interfaces/testiface: added TestHotplugInterface <Hotplug> <Simple> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5842>
<King_InuYasha> zyga: https://github.com/wrabcak/udica
<mup> PR snapd#5848 opened: cmd/snap, tests/main/snap-info: highlight the current channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/5848>
<mup> PR snapd#5848 closed: cmd/snap, tests/main/snap-info: highlight the current channel <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5848>
<mup> PR snapd#5849 opened: testing <Created by chipaca> <https://github.com/snapcore/snapd/pull/5849>
#snappy 2018-09-21
<mup> PR # closed: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5714, snapd#5717, snapd#5727, snapd#5739, snapd#5759, snapd#5768, snapd#5771,
<mup> snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5805, snapd#5809, snapd#5811, snapd#5813, snapd#5822, snapd#5823, snapd#5824, snapd#5825, snapd#5832, snapd#5833, snapd#5835, snapd#5840, snapd#5845, snapd#5847, snapd#5849
<mup> PR # opened: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5714, snapd#5717, snapd#5727, snapd#5739, snapd#5759, snapd#5768, snapd#5771,
<mup> snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5805, snapd#5809, snapd#5811, snapd#5813, snapd#5822, snapd#5823, snapd#5824, snapd#5825, snapd#5832, snapd#5833, snapd#5835, snapd#5840, snapd#5845, snapd#5847, snapd#5849
<mup> PR snapcraft#2287 closed: meta: support relocatable prime for path verification <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2287>
<mup> PR snapcraft#2288 closed: build providers: use multipass automatically when on darwin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2288>
<mup> PR snapcraft#2286 closed: config: change default outdated action to clean <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2286>
<kyrofa> Wait sergiusens, you need to land the legacy vendor or that ^ WILL hit people
<mup> PR snapcraft#2285 closed: snapcraft snap: vendor legacy snapcraft <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2285>
<Odd_Bloke> Is it possible to manually remove an old version of a snap?
<Odd_Bloke> I have one snap installed who's N-2 revision was accidentally very big, and would like to be rid of it.
<sergiusens> popey: mind helping Odd_Bloke ^?
<popey> hello
<popey> sudo snap remove "$snapname" --revision="$revision"
<popey> where you fill in the snapname and revision gaps
<popey> Odd_Bloke: ^
<Odd_Bloke> Perfect, thanks!
<Odd_Bloke> As a side note, that says "$snapname removed" when it's complete, even though $snapname is still installed; perhaps a little UI nit that could be fixed?
<mborzecki> Odd_Bloke: yeah, should be an easy fix
<mup> PR snapd#5850 opened: cmd/snap: improve UX when removing specific snap revision <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5850>
<mup> PR snapd#5849 closed: Have a minimal smokescreen test on osx <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5849>
<mup> PR snapd#5851 opened: tests: don't fail interfaces-bluez test if bluez is already installed <Created by plars> <https://github.com/snapcore/snapd/pull/5851>
<mup> PR snapd#5852 opened: tests: fix listing to allow extra things in the notes column <Created by plars> <https://github.com/snapcore/snapd/pull/5852>
<mup> PR snapd#5850 closed: cmd/snap: improve UX when removing specific snap revision <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5850>
<mborzecki> Odd_Bloke: ^^ a nicer remove message should appear in next core update in the edge channel
<mup> PR snapd#5853 opened: daemon, snapstate: consistent snap list [--all] output with broken snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5853>
<ogra> hmm, is snapctl from a hook allowed to call "disable" on itself ?
<mup> PR core18#68 closed: Install rsyslog in core18 <Created by sil2100> <Closed by sil2100> <https://github.com/snapcore/core18/pull/68>
<lilis> Hi guys, newb question but is there a way to put epoch on the snap filename?
<ogra> why would you do that (note that the version string is totally shallow anyway, it is just for enduser convenience but not used for anything else)
<lilis> Itâs just for me to know that itâs a different from the one I build before. Say, the program version is the same but I decided to change some configuration for the build.
<lilis> Or is there something inherently wrong with that?
<ogra> not really, you can indeed use the version for your own convenience and bump it with every build, but snaps are managed by their store revision number
<ogra> so whatever you put into the version field is pretty much up to you ... as long as it doesnt contain any weird chars
<lilis> Does that still work if I donât publish to the store?
<ogra> i think many people just add the git commit number to the end of an upstream version
<ogra> that way you can easily map your code commit to the snap in use
<lilis> Hmm what should I do if I donât touch the code but modify the script in snapcraft.yaml?
<ogra> fi you dont publish you will only get a local fake revision ... it is typically an x with an iterating number that counts up for each "snap install --dangerous ..." you do
<ogra> i.e.:
<ogra> $ snap list uboot-tools
<ogra> Name         Version  Rev  Tracking  Publisher  Notes
<ogra> uboot-tools  0.1      x1   -         -          -
<ogra> that s a snap i only have installed locally with the --dangerous option
<lilis> Ahh yes, I remember seeing that.
<lilis> Is there any advantage to snap if I want to treat them like standalone .deb packages?
<ogra> if you dont touch the upstream code but only snap related stuff you can use $upstream_version-$your_snap_iteration
<ogra> and iterate the part after the dash if that makes you feel better :)
<ogra> you can not "treat a snap like a standalone deb package"
<ogra> they are quite different things :)
<ogra> a snap typically bundles all dependencies for example
<ogra> you could rather compare a snap to a PPA that contains a metapackage that in turn depends on all packages inside the PPA ... thats probably the closest if you compare deb to snap
<lilis> Yes, Iâm actually bundling everything ala AppImage.
<ogra> (with the exception that the snap is not bound at all to the release or distro of the host system you install it on)
<lilis> I see. In that case, does snap allow creation of your own store?
<lilis> I think PPA allows self-hosting
<mup> PR snapd#5852 closed: tests: fix listing to allow extra things in the notes column <Created by plars> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5852>
<mup> PR snapd#5853 closed: daemon, snapstate: consistent snap list [--all] output with broken snaps <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5853>
<mup> PR snapd#5835 closed: tests: find snaps just for edge and beta channels <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5835>
<mup> PR snapd#5854 opened: docker_support.go: add rules to read apparmor macros <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5854>
<om26er> mir-kiosk 1.0 snap does not seem to have the wayland-socket-dir interface, what replaced that ?
<om26er> ah, found https://github.com/MirServer/mir-kiosk/commit/01fe16ca90eff5408c44f9448f4da8d7d27d296c#diff-5fde7a6d86053f0e1d88c0a2a238941f
<ogra> om26er, wayland
<ogra> the socket now lives in XDG_RUNTIME_DIR (/run/user/0 for kiosk apps) and is accessible via the normal wayland interface
<mup> PR snapcraft#2262 closed: schema: add "legacy" adapter type <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2262>
<om26er> ogra: So that above change I posted breaks the desktop launcher
<om26er> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L204
<ogra> i dont think i have ever seen the desktop-launcher being used with mir-kiosk ... 90% of the stuff that does will not even exist on a core install
<ogra> (and  i dont think anyone expects the desktop launcher to work in that context since mir-kiosk is typically not used on desktop systems)
<ogra> ... but file a bug anyway :)
<om26er> ogra: I use desktop-glib-only part for my Qt application, which otherwise wouldn't start
<ogra> i guess we'd need a kiosk-glib-only premote part one day ...
<ogra> the desktop launchers expect fonts, themes and icons to exist ... all that stuff you dont really want on a minimal kiosk system
<om26er> in our specific case our app is supposed to run both on the Desktop (X11, Wayland) and on UbunutCore (kiosk more)
<ogra> did you try to simply use QT_QPA_PLATFORM=wayland for your app ?
<ogra> that should just work
<seffyroff> hey folks! I'm looking at some automated deployment of ubuntu-core and am working on automating the system user part first.  I read on the forums there's a snap called make-system-user which I've installed, but I get an error when I try to use it
<seffyroff> it looks like this:
<seffyroff> https://paste.ubuntu.com/p/hgjRnDHr7S/
<seffyroff> it sort of looks like a python error
<seffyroff> should i just 'pip install snapcraft'?
<seffyroff> i guess I naively assumed the snap would include all the deps
<seffyroff> solved it by refreshing the snap to the edge channel..
#snappy 2018-09-22
<thresh> popey, pingie download button
<popey> thresh: hello! I was at a sprint last week and the design guys are uploading translated versions to github
<popey> thresh: i asked for a permissive license, and I think it's currently with management making sure we use the right one
<popey> thresh: I will check on monday
<popey> and get back to you
<thresh> oh very nice thanks!
<thresh> btw i changed our websites ubuntu download button to snap://vlc
<popey> Oh nice!
<popey> We're adding some magic to make that work on a wider set of places I believe
#snappy 2019-09-16
<mup> PR snapd#7465 closed: snap-confine: fix return value checks for udev functions <Simple ð> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7465>
<mup> PR snapcraft#2716 opened: tests: completely mock subversion tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2716>
<mup> PR snapcraft#2712 closed: snap: migrate to core18 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2712>
<rogpeppe> zyga: the pi is still going down very regularly :-\ i'm still interested to try to diagnose the issue, if it's possible.
<zyga> rogpeppe: we are sprinting this week so availability is difficult, I would like to change something on your pi so that at least it doesn't reboot all the time and cause you more issues
<rogpeppe> zyga: that would be nice :)
<rogpeppe> zyga: it never seems to stay up for more than about 24h
<rogpeppe> zyga: although, interestingly, it doesn't seem to be doing the "need to power cycle twice to boot ok" thing any more
<zyga> snap refresh --time
<zyga> can you tell us what that told you?
<rogpeppe> zyga: http://paste.ubuntu.com/p/gqwzFMW9VC/
<rogpeppe> zyga: looks like that's not the issue
<zyga> indeed
<zyga> hmm
<pstolowski> cachio: https://api.travis-ci.org/v3/job/584584884/log.txt
<popey> diddledan: what's the status of makemkv these days?
<popey> it's devmode in the store
<diddledan> popey: freshly minted in the edge channel :-)
<diddledan> popey: you'll need to manually connect `hardware-observe` but otherwise I think it'll work ootb
<mup> PR snapcraft#2717 opened: build providers: inject core18 instead of core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2717>
<popey> diddledan: ooh
 * diddledan just did it :-p
<diddledan> so far I've got a 100% success rate of 1 for 1 computers working correctly :-p
<popey> It launches!
<popey> I have no blueray drives
<diddledan> d'oh :-p
<diddledan> what about DVD drives?
<popey> at home, yes, in paris, no.
<diddledan> aha
<diddledan> poke everyone there? :-D
<popey> yeah, doubt anyone has commercial dvds here
<diddledan> good point
<diddledan> TO WOOLIES!
<popey> how about you tweet about it, make sure there are detailed instructions and we'll share it?
<popey> maybe also a forum post?
<diddledan> popey: https://twitter.com/diddledan/status/1173572054584647681
<zgr> hello is it possible to restore snap from backup simply by overwriting /var/snap/snap_name directories?
<zgr> I've problems with nextcloud-snap package, tried to restore it, but it's not starting: snap.nextcloud.mysql.service: Failed at step CHDIR spawning /usr/bin/snap: No such file ...
<Chipaca> zgr: yes it should work
<mup> PR snapd#7472 opened: Add Snap Store badge to README.md <Created by flexiondotorg> <https://github.com/snapcore/snapd/pull/7472>
<zyga> Saviq: quick multipass question
<zyga> can you tell me if multipass vms are restarted or retained when the snap of multipass itself is refreshed?
<Chipaca> mborzecki: zyga: https://paste.ubuntu.com/p/PnxthtsxhB/
<Chipaca> zyga: http://releases.ubuntu.com/16.04/ubuntu-16.04.6-desktop-amd64.iso.torrent
<Chipaca> zyga: s/.torrent// for the plain iso
<Chipaca> zyga: i.e. http://releases.ubuntu.com/16.04/ubuntu-16.04.6-desktop-amd64.iso
<zyga> thank you
 * diddledan lets chipaca reply to that one (the one you're replying to already ;-)
<Chipaca> diddledan: DEAR EFFING POTATO FACED LIZARD WITH A KEYBOARD, u ok hun?
<diddledan> no, my potato is peeling :-p
<Chipaca> o noes
<Chipaca> only one thing to do
 * Chipaca turns on the deep fryer
<diddledan> chips?
<Chipaca> I'm flexible. Can also be hash browns.
<diddledan> fries for those murricans among us :-p
 * diddledan checks his makemkv rip-in-progress
<diddledan> seems it works \o/
<Chipaca> how is "calling people stupid is rude" a hard concept to grasp?
<diddledan> aye
<diddledan> I tried to be nice, and defuse the conversation a bit but it didn't work
 * Chipaca prepares a kickban
<diddledan> ð¨
<Chipaca> diddledan: BOOOM
<Chipaca> boomÂ²
<popey> you can set the account to be moderated
<popey> so they can't post until their posts are reviewed
<diddledan> I can't :-p
<diddledan> I'm not a moderniser
<popey> s/you/a mod can/
<diddledan> teehee
<Chipaca> popey: I deleted the post, and silenced them until next week, at which point i'll make them moderated for a bit
<popey> kk
<diddledan> which shall I watch this evening, John Wick 3 or Detective Pikachu? (both arrived today from the Amazon warrior)
<popey> both
<popey> I have seen neither.
<Chipaca> popey: but given that their reaction to my offer to help them understand what they were doing wrong was "why do you waste your time with this offtopic bull", i doubt they will learn
<diddledan> they only released to disc today, and they've only been downloadable for a week
<Chipaca> diddledan: detective wickachu
<diddledan> thanks to popey I am ripping them both with snapped makemkv :-D
<diddledan> (he prompted me to strictly confine it finally)
<roadmr> Chipaca: +1  elegant wrangling ð¼  ð¯
<Chipaca> popey: TBH i haven't seen how to set a user to moderated, but i'll chase you to find out
<Chipaca> ok, EODing here
<Chipaca> ð
<mup> PR snapcraft#2718 opened: Update README - remove suggestion to use forum <Created by cevap> <https://github.com/snapcore/snapcraft/pull/2718>
<mup> PR snapcraft#2718 closed: Update README - remove suggestion to use forum <Created by cevap> <Closed by chipaca> <https://github.com/snapcore/snapcraft/pull/2718>
#snappy 2019-09-17
<mup> PR snapcraft#2719 opened: Update README - Snapcraft breaks on intention <Created by cevap> <https://github.com/snapcore/snapcraft/pull/2719>
<mup> PR snapcraft#2717 closed: build providers: inject core18 instead of core <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2717>
<diddledan> Chipaca: that person you silenced yesterday has been emailing wildly in addition to their multiple pull requests and forum shenanigans
<Chipaca> yes
<Chipaca> my forum is lit up like a christmas tree
<Chipaca> and my email was flooded
<Chipaca> i am a lier and a crazy person and also john lennon
<Chipaca> also i didn't get much sleep
<diddledan> john lennon! omg sing us a song!
<Chipaca> also how do I delete a _person_
<Chipaca> not a user, the actual physical person
<diddledan> I believe deleting people is frowned upon. something about murder is bad nonsense
<diddledan> randomly they emailed kyrofa, in addition to me
<diddledan> methinks "don't engage" is the course of action now
<Chipaca> oh also i'm ignorant
<diddledan> must be so fun being popular *hug*
<roadmr> Chipaca: let me know if I can do anything to help with the troll
<Chipaca> roadmr: tbh right now I feel like deleting them from the forum will just make things work for people's emails and githubses
<Chipaca> roadmr: s/things work/things worse/
<Chipaca> did i mention very little sleep
<roadmr> Chipaca: you did - sorry (zzz). I agree with you though, maybe just let him get bored and move on
<Chipaca> i need an app, like the fasting app where you see a countdown to help with holding off the LART
<roadmr> ð¥
<diddledan> your clock is wrong :-p
<roadmr> ð
<roadmr> ð  is only 3 minutes off for EDT ð
<diddledan> it's 09:00 here, your clock emoji says it'ss 10:30 *whistles nonchalantly*
<diddledan> haha
<diddledan> ð
<roadmr> hehe
<Saviq> zyga: depends on platform and driver - retain, suspend/resume, stop/start (in preference order)
<Saviq> zyga: or rather, that would be our preference (but we currently don't know whether we're being refreshed or shut down, so we suspend/resume or stop/start where suspend not possible)
<Chipaca> Saviq: zyga says: thank you for contacting us, your call is very important
<Saviq> ;D
<Chipaca> Saviq: he actually says a lot of stuff but he talks too fast
<Chipaca> zyga: run this from a user service, on a timer: losetup | awk '/\(deleted\)$/{print $6}' | xargs -r xmessage -buttons ok,cancel -center
 * Chipaca brb
<Chipaca> sigh. every time i refresh the forum there's a bunch more flags by wotstheirname
<pstolowski> cachio: https://api.travis-ci.org/v3/job/584584884/log.txt
<roadmr> jdstrand: hey I just rolled out the latest review-tools update that was queued :)
<mup> PR snapcraft#2719 closed: Update README - Snapcraft breaks on intention <Created by cevap> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2719>
<dot-tobias> zyga: Short hint for https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/8?u=tobias very appreciated if you have the time ð
<mup> PR snapcraft#2720 opened: remote build: switch from core to core18 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2720>
<zyga> dot-tobias: try sudo /usr/lib/snapd/snap-discard-ns wpe-webkit-mir-kiosk
<zyga> dot-tobias: and restart the service
<zyga> dot-tobias: please share the details of the snap (I only really care about the snap.yaml for this class of bugs)
<zyga> dot-tobias: ideally please report the bug with details on how to reproduce with a small snap that has no real code but the same layout/mount properties
<dot-tobias> zyga: Thank you! I'll pass that to affected users. Can't test myself right now as disabling/reboot/enabling the snap has fixed the issue as well (I presume this does something similar under the hood ð ) Will post snap.yaml in the thread.
<zyga> yes it does
<zyga> that's useful, thank you
<mup> PR snapd#7472 closed: README: Add Snap Store badge to README.md <Created by flexiondotorg> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7472>
<dot-tobias> zyga: Re: minimal reproduction snap for the mount issue â should I copy over app-specific environment variables / slots / plugs or are those completely irrelevant for layouts?
<mup> PR snapcraft#2721 opened: Update README - remove obsolete unreliable links for support <Created by cevap> <https://github.com/snapcore/snapcraft/pull/2721>
<roadmr> ^^ he's at it again :)
<mup> PR snapcraft#2722 opened: meta: fixes for desktop file handling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2722>
<zyga> dot-tobias: slots are iirelevant
<zyga> dot-tobias: except for those that bring mount changes, like fonts or desktop
<zyga> dot-tobias: but you can try to remove one by one
<zyga> dot-tobias: until the file /var/lib/snapd/mount/*.fstab starts chanigng
<zyga> dot-tobias: you should be able to remove the vast majority of the interfaces this way
<zyga> dot-tobias: leave out the layout, I will see if it can be reduced more than that
<mup> PR snapd#7451 closed: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
<jamesh> zyga: could you restart the failed part of https://travis-ci.org/snapcore/snapd/builds/585992030 ?  The failure doesn't look related to my changes
<mup> PR snapd#7473 opened: sanity: sanity check cgroup probing <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7473>
<zyga> jamesh: sure
<mup> PR snapd#7005 closed: debug: state-inspect debugging utility <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7005>
<mup> PR snapd#6767 closed: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6767>
<zyga> jdstrand: https://cfp.all-systems-go.io/media/homed-asg2019.pdf
<mup> PR snapd#7474 opened: release: 2.42~pre1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7474>
<mup> PR snapd#7475 opened: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7475>
<mup> PR snapd#7476 opened: usersession/userd: make sure to export DBus interfaces before requesting a name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7476>
<mup> PR snapd#7477 opened: packaging: use snapfuse_ll to speed up snapfuse performance <Created by mvo5> <https://github.com/snapcore/snapd/pull/7477>
<mup> PR snapcraft#2716 closed: tests: completely mock subversion tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2716>
<mup> PR snapcraft#2720 closed: remote build: switch from core to core18 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2720>
<mup> PR snapcraft#2721 closed: Update README - remove obsolete unreliable links for support <Created by cevap> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2721>
<mup> PR snapcraft#2723 opened: Update README - Warning about shady snapcraft forum <Created by cevap> <https://github.com/snapcore/snapcraft/pull/2723>
<mup> PR snapcraft#2723 closed: Update README - Warning about shady snapcraft forum <Created by cevap> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2723>
#snappy 2019-09-18
<jdstrand> roadmr: thanks! I'm hoping to have another one soon :)
<roadmr> jdstrand: sure thing, just let me know
<zyga> rogpeppe: good morning
<rogpeppe> zyga: hiya
<zyga> rogpeppe: we're still sprinting so attention is spotty, I will not be able to do much interactive debugging today
<zyga> I wanted to check if the board misbehaved today
<rogpeppe> zyga: yup, it's down currently
<rogpeppe> zyga: i need to work out what's going on with the memory. perhaps using too much memory is killing the whole thing.
<zyga> rogpeppe: perhaps if the service is leaking memory you can restart it on a timer
<zyga> say hourly
<rogpeppe> zyga: i'm also wondering if it's possible that swap was configured by default before but isn't any more
<zyga> rogpeppe: I touched on the swap situation yesterday in the team but we're not sure, we need to look
<zyga> people here suggest that my memory is rusty and it's off by default but you can turn it on
<rogpeppe> zyga: i just added a pprof handler to the service, so hopefully i can look into it and find out what's taking all the memory
<rogpeppe> zyga: it's also possible that the newer Go version isn't garbage collecting as much
<zyga> rogpeppe: which version are you on?
<rogpeppe> zyga: 1.13
<zyga> rogpeppe: we're building snapd with 1.10
<rogpeppe> zyga: ancient :)
<zyga> rogpeppe: there were some changes in go memory handling but we have not seen actual leaks outside of a super specific case with a custom kernel
<zyga> rogpeppe: compromise for practicality :)
<rogpeppe> zyga: neither me. there's a tweakable parameter too - I could try tweaking GOGC
<zyga> rogpeppe: perhaps do one more thing
<zyga> rogpeppe: add a timer or something like that
<zyga> or even a screen session
<zyga> that logs dstat / top
<zyga> so you see what's going on after it crashes
<zyga> if it's really taking all the memory
<rogpeppe> yeah, that's a good idea
<zyga> top has a continuous mode, perhaps on a minute interval it would be useufl
<rogpeppe> BTW I think i've also been bitten by that systemd bug where it loses the last few messages written to the command's output
<rogpeppe> which means that it loses the whole panic message when it panics (not that that matters too much - i know where the panic was coming from: the clock issue)
<zyga> rogpeppe: is it the rate limiting behavior?
<zyga> I'm not familiar with the bug itself
<zyga> you can also perhaps log to a file explicitly but I think journald should not behave this way
<zyga> (it could be just a bug though)
<rogpeppe> zyga: no, the problem is that systemd uses unix socket tricks to get the process id of the writer, but when the writer has just exited, it can't do that, so the messages don't get associated with the right unit
<rogpeppe> zyga: (i can't remember if they're just discarded or if they just end up somewhere else)
<rogpeppe> zyga: i think it might be this bug https://github.com/systemd/systemd/issues/2913
<zyga> checking
<zyga> wow, that's useful
<mup> PR snapcraft#2722 closed: meta: fixes for desktop file handling <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2722>
<mup> PR snapd#7478 opened: snapstate: increase settleTimeout in TestRemodelSwitchToDifferentKernel <Created by mvo5> <https://github.com/snapcore/snapd/pull/7478>
<mup> PR snapd#7479 opened: tests: skip centos when running nigthly suite <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7479>
<mup> PR snapcraft#2724 opened: docs: add a Code of Conduct <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2724>
<sergiusens> Chipaca: ^
<sergiusens> I used the contributor template on Github, it seemed a bit more project related and less Ubuntu specific (after reading the Ubuntu one)
<sergiusens> please tell me what you think :-)
<Chipaca> sergiusens: SGTM but I'd want to check it with somebody ubuntu-facing in canonical
<sergiusens> Chipaca: I checked with Wimpress and popey , they are +1 on this one
<mup> PR snapd#7480 opened: store: download propagates options to delta download <Created by chipaca> <https://github.com/snapcore/snapd/pull/7480>
<Chipaca> verterok: https://github.com/snapcore/snapd/pull/7480
<mup> PR #7480: store: download propagates options to delta download <Created by chipaca> <https://github.com/snapcore/snapd/pull/7480>
<Chipaca> sergiusens: schweet
<verterok> Chipaca: that was fast!
<Chipaca> things are either fast, or impossible
<verterok> heh
<verterok> thanks
<Chipaca> now it needs to pass pesky things like peer review
<Chipaca> mvo: https://github.com/snapcore/snapd/pull/7480.patch
<mup> PR #7480: store: download propagates options to delta download <Created by chipaca> <https://github.com/snapcore/snapd/pull/7480>
<mup> PR snapd#7481 opened: data/selinux: allow snapd to issue sigkill to journalctl <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7481>
<mup> PR snapcraft#2724 closed: docs: add a Code of Conduct <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2724>
<mup> PR snapd#7482 opened: tests/main/listing: account for dots in ~pre suffix <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7482>
<mup> PR snapd#7482 closed: tests/main/listing: account for dots in ~pre suffix <Simple ð> <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7482>
<mup> PR snapd#7483 opened: We need a CoC, because people can't be nice <Created by chipaca> <https://github.com/snapcore/snapd/pull/7483>
<Chipaca> zyga: #1841137
<mup> Bug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:Confirmed for zyga> <https://launchpad.net/bugs/1841137>
<mup> PR snapcraft#2725 opened: Update HACKING.md <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2725>
<Chipaca> sergiusens: CLOSE ME?
<sergiusens> Chipaca: just playing with autopkgtest
<Chipaca> ah ok
<mup> PR snapcraft#2725 closed: Update HACKING.md <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2725>
<mup> PR snapd#7480 closed: store: download propagates options to delta download <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7480>
<mup> PR snapd#7483 closed: docs: Add Code of Conduct <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7483>
<Chipaca> verterok: on master, fwiw
<verterok> cool
<Chipaca> verterok: and on the 2.42 branch
<verterok> \o/
<mup> PR snapd#7484 opened: osutil: generalize SyncDir with FileStater interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7484>
<zyga> dot-tobias: I'm investigating that issue now
<dot-tobias> zyga: ð
<mup> PR snapd#7481 closed: data/selinux: allow snapd to issue sigkill to journalctl <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7481>
<mup> PR snapd#7474 closed: release: 2.42~pre1 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7474>
<jamesh> zyga: https://discourse.gnome.org/t/sandboxing-portal/1651/2
<zyga> thanks
<mup> PR snapd#7476 closed: usersession/userd: make sure to export DBus interfaces before requesting a name <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7476>
<mup> PR snapd#7485 opened: data/selinux: allow snapd/snap to do statfs() on the cgroup mountpoint <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7485>
<mup> PR snapcraft#2726 opened: Update README.md - Update information, shady staff <Created by JohnRLentonIsALyingBitch> <https://github.com/snapcore/snapcraft/pull/2726>
<roadmr> ^^ has this been reported to github abuse?
<diddledan> roadmr: I think we're probably heading that way if not already done
<roadmr> I did :)
<diddledan> we all know who it was
<mup> PR snapcraft#2726 closed: Update README.md - Update information, shady staff <Created by JohnRLentonIsALyingBitch> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2726>
<cwayne> roadmr: yep
<zyga> dot-tobias: hello
<zyga> dot-tobias: can you report snap version with the context of https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/10 aka https://bugs.launchpad.net/snapd/+bug/1844496
<mup> Bug #1844496: âDevice or resource busyâ error during snap refresh when using layout with variable <snapd:In Progress by zyga> <https://launchpad.net/bugs/1844496>
<zyga> dot-tobias: I attempted to reproduce it on 2.42~pre1.1 without success (aka snapd from edge)
<zyga> dot-tobias: I believe my test may be imperfect but I want to check with you first
<zyga> dot-tobias: I wrote a small test, I'll run it against older release in a moment
<joedborg> zyga: could you please give a once over to https://forum.snapcraft.io/t/apparmor-error-when-trying-to-connect-plugs/13303?
<zyga> joedborg: sure
<jdstrand> joedborg, I know what that is
<jdstrand> zyga: ^
<zyga> ack
<joedborg> jdstrand: ah awesome
<jdstrand> joedborg: can you show me your snapcraft.yml?
<zyga> thanks, I'm no longer looking unless jdstrand says otherwise
<zyga> seems like something that instantiates the interface twice
<zyga> so we get a duplicate
<joedborg> https://www.irccloud.com/pastebin/BkZH0sq0/
<jdstrand> yes. and I think the two flavors might be used in the same app
<joedborg> jdstrand: ^
<jdstrand> hmm
<zyga> ks8-{kubelet,kubeproxy} are probably applied to a hook
<jdstrand> joedborg: can you give me the snap.yaml from the snap?
<jdstrand> zyga: oh, yes.
<joedborg> from the actual built snap?
<jdstrand> joedborg: did you add another hook beyond configure?
<jdstrand> joedborg: nm, answer that ^
<joedborg> jdstrand: umm im not sure what that mean
<joedborg> *means
<zyga> joedborg: find meta/
<jdstrand> joedborg: what is in meta/hooks
<zyga> jdstrand: in the snap
<zyga> er, joedborg ^
<joedborg> ahhhhh, sorry, i see
<joedborg> no, just configure
<jdstrand> joedborg: can you paste unsquasfs -lls ./your.snap|grep meta
<jdstrand> joedborg: err, unsquashfs
<joedborg> https://www.irccloud.com/pastebin/hIMNXh1L/
<zyga> jdstrand: I'm surprised now
<jdstrand> joedborg: perhaps put the snap somewhere so I can look? (and perhaps zyga)
<jdstrand> joedborg: I need to step into a meeting in a moment
<zyga> indeed
<joedborg> no worries, 2 seconds
<joedborg> i'll upload it to our google drive and drop the link
<zyga> thank you
<joedborg> https://drive.google.com/open?id=1fZXdTCW0cGHxGxSHNdkX0mQOa4OZCtAa
<joedborg> zyga: ^
<zyga> downloading now
<zyga> joedborg: I have the snap now
<zyga> joedborg: reproduced
<zyga> joedborg: can you please file a placeholder bug, I'll use it for tracking
<jamesh> travis seems really slow today
<joedborg> zyga: i have a guess what it might be - i'm rebuilding now
<zyga> joedborg: whatever it really is it's a bug on snapd for sure
<zyga> joedborg: can you share what your idea is?
<zyga> unless the snap is manipulating profiles directly, that is
<joedborg> zyga: i removed the kube-proxy app from the list of apps, but retained mentions to it elsewhere
<zyga> I don't see that app mentioned in the yaml
<zyga> (or that string at all)
<zyga> oh
<zyga> I see
<zyga> the bug is as that this interface is then added to all the apps in the snap
<zyga> jdstrand: ^
<mup> PR snapd#7486 opened: tests: add regression test for lp: #1844496 <Created by zyga> <https://github.com/snapcore/snapd/pull/7486>
<zyga> joedborg: it's an invalid snap.yaml but the validation layer doesn't pick this up
<zyga> well
<zyga> not syntactically invalid
<zyga> joedborg: I can file a bug now if you don't have one already
<joedborg> zyga: sorry I was in a meeting, I can raise it unless you have? Yeah I agree, snapcraft should complain
<zyga> joedborg: I'll handle that, thank you for reporting
<zyga> joedborg: to unblock you, remove the "unused" interface declaration
<zyga> joedborg: the one for k8s-proxy
<zyga> and you should be good
<joedborg> zyga: yeah itâs still building from that, Iâll let you know :) thanks!
<zyga> joedborg, jdstrand: filed as https://bugs.launchpad.net/snapd/+bug/1844546
<mup> Bug #1844546: usage of multiple flavours of kubernetes-support interface for a single app is invalid but not validated <snapd:Confirmed> <https://launchpad.net/bugs/1844546>
<jdstrand> zyga: note that microk8s strict already does this
<zyga> jdstrand: hmm, does what exactly?
<jdstrand> zyga: https://github.com/ubuntu/microk8s/blob/feature/strict-v2/snapcraft.yaml
<jdstrand> zyga: uses both flavor of the kubernetes interface in the same snap (but not same command)
<zyga> Right
<zyga> Thatâs the issue here
<jdstrand> zyga: note the 'plugs: []' which is why I asked about other hooks
<jdstrand> zyga: I'm saying with microk8s, there wasn't the install issue
<jdstrand> zyga: I didn
<jdstrand> 't see what was different about the new k8s-worker
<zyga> Ah
<jdstrand> (yet, I'm in a meetin)
<jdstrand> so I was confused why there was a problem
<jdstrand> zyga: it is known (at least to me and samuele) that there is a problem if you don't specify plugs with hooks
<jdstrand> not sure I filed it
<jdstrand> zyga: but I couldn't see the difference between the yaml I pasted and the yaml joedborg pasted
<jdstrand> zyga: gotta run
<zyga> jdstrand: sure
<zyga> jdstrand: read the bug once you have the time to see if you agree with my analysis
<jdstrand> ok
<zyga> thank you so much :)
<jdstrand> zyga: briefly, what you decribe is definitely a bug (and related to the one I mentioned above), but that doesn't explain joedborg's afaics since he *did* use both k8s interfaces in two places and *did* use plugs in the configure hook
<jdstrand> which should've avoided
<jdstrand> it
<jdstrand> meh, gotta go again
<mup> PR snapd#7485 closed: data/selinux: allow snapd/snap to do statfs() on the cgroup mountpoint <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7485>
<mup> PR snapd#7477 closed: packaging: use snapfuse_ll to speed up snapfuse performance <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7477>
<zyga> jdstrand: I think I have a different opinion on that but it's something I should revisit tomorrow with fresh eyes
<jdstrand> joedborg (oh, the snap you put in drive doesn't have kube-proxy. you should k8s-kubeproxy from toplevel slots
<jdstrand> meh
<jdstrand> joedborg: that was for you, but I meant to (cc zyga) ^ :)
<jdstrand> zyga: now I understand where you were coming from. the pastes had snap.yamls with a kube-proxy command. I'll comment in the but
<jdstrand> bug*
<joedborg> Yeah I figured that after telling zyga, I think the issue is that it passes validation
<jdstrand> joedborg: yes. I'm mentioning that to unblock you
<jdstrand> joedborg: sounds lik eyou didn't need me though. sorry for the delay. meeting then team dinner
<joedborg> jdstrand: no worries! Thanks, hope Paris is going well. I also sent an email with a future blocker
<joedborg> No rush, just FYI
<jdstrand> ok
<jdstrand> I'll comment in zyga's bug and see how much gas I have left in the tank :)
<jdstrand> and yes, Paris is good :)
#snappy 2019-09-19
<jdstrand> joedborg: ok, I responded to zyga's bug and your email. I'm crashing now :) do let me know in the email if you need more immediately, but the problem is totally tractable
<jdstrand> well, the solution to the problem is tractable. anyhoo. goodnight!
<joedborg> Thanks jdstrand! Have a good one
<mup> PR snapd#7439 closed: packaging: remove obsolete usr.lib.snapd.snap-confine in postinst <Bug> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7439>
<mup> PR snapd#7478 closed: snapstate: increase settleTimeout in TestRemodelSwitchToDifferentKernel <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7478>
<mup> PR snapd#7473 closed: sanity: sanity check cgroup probing <Simple ð> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7473>
<mborzecki> pstolowski: the simple one https://paste.ubuntu.com/p/z3kmnrq22b/ one i use for setting up fedora https://paste.ubuntu.com/p/gJgf4ms36c/
<pstolowski> mborzecki: thanks!
<zyga> dot-tobias: hello
<zyga> are you around?
<dot-tobias> zyga: hi, yes I am
<zyga> dot-tobias: about https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/12
<zyga> I'm trying to expand my test to reproduce this issue
<zyga> when it occurred, was the application running?
<zyga> or alternatively, was there a service that was running?
<dot-tobias> zyga: My test app is just a daemon running âpwdâ, so I guess yes, but I can't imagine that this affects file handles
<zyga> dot-tobias: daemon written in which language?
<zyga>  I'll try to do the same
<dot-tobias> zyga: See https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/13?u=tobias â FYI: This refers to the *test* snap you asked me for, which does not contain any real code. The issue first came up with a kiosk snap running a daemonized WPE Webkit launcher (cog)
<zyga> ok
<zyga> I'll try with a simple shell daemon
<roadmr> ð·
<dot-tobias> zyga: Ok, I'll test if removing the daemon stanza (i.e. making it a regular app) produces different results
<roadmr> jdstrand: new review-tools is now in production ð
<zyga> dot-tobias: that doesn't reproduce it for me
<zyga> dot-tobias: my attempt is on https://github.com/snapcore/snapd/pull/7486
<mup> PR #7486: tests: add regression test for lp: #1844496 <Created by zyga> <https://github.com/snapcore/snapd/pull/7486>
<zyga> dot-tobias: this reliably passes for me
<zyga> dot-tobias: so there must be something missing still
<dot-tobias> zyga: Hm. I tested all the layouts iteratively and none came up with this error *except* the one I thought was the culprit, so I put that front and center. But the snapcraft.yaml (https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/13?u=tobias) contains all of them â¦ maybe copy all of those over to your test because I made a mistake during tests and it's a combination?
<zyga> I can try
<dot-tobias> zyga: Ah, also your test has a fixed layout /usr/lib/x86_64 â¦ whereas I'm using $SNAPCRAFT_ARCH_TRIPLET. Should produce the same result, but there's a difference too
<zyga> no, that's not the case
<zyga> the variable is only meaningful to snapcraft
<zyga> snapd doesn't expand it
<zyga> it is expanded in snap.yaml
<zyga> if you use snapcraft it gets expanded but I only care about the layer below
<dot-tobias> Ah, just noticed that it's snap.yaml and not snapcraft.yaml ð My bad
<zyga> no worries
<dot-tobias> zyga: Will run some more tests and get back to you
<zyga> dot-tobias: I just reproduced it
<zyga> dot-tobias: it was the extra layout entries
<zyga> I will investigate now, you can wait until I get some results
<jamesh> jdstrand: do you know if there are any ways to allow D-Bus activation for services without an AssumedAppArmorLabel key in their service activation file?
<mup> PR snapd#7487 opened: interfaces/udev: account for cgroup version when reporting supported features <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7487>
<jdstrand> jamesh: for a confined application to talk to it, no. have I mentioned how much I hate this dbus upstream misfeature (we argued against it)
<mup> PR snapcraft#2727 opened: storeapi: use the channels attribute in push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2727>
<jamesh> jdstrand: okay.  This is for the fwupd interface changes I was working on: https://github.com/snapcore/snapd/pull/7454
<mup> PR #7454: interfaces: extend the fwupd slot to be implicit on classic <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7454>
<zyga> dot-tobias: I managed to reduce the case further, it should be easier to understand
<jamesh> jdstrand: the spread tests I added end up trying to activate fwupd (it isn't initially running), so fail on Ubuntu backends
<jdstrand> jamesh: unfortunately, we need SRUs for whatever ships those service files :\
<jdstrand> jamesh: I mean, you could sed them for the test, but... ;)
<jamesh> jdstrand: fair enough.  I might adjust the spread test for now to manually start the service first, with a comment about why it is doing that.
<jamesh> and then look at the SRUs later
<jamesh> jdstrand: thanks.
<dot-tobias> zyga: Great, excited to see what you dig up ð and a reminder for me that I wanted to check out spread for testing â¦
<zyga> I have a hunch I know what is the problem now
<mup> PR snapd#7488 opened: docs: Update README.md <Created by degville> <https://github.com/snapcore/snapd/pull/7488>
<jdstrand> jamesh: np
<ijohnson> zyga: did you want to look at https://github.com/snapcore/snapd/pull/7409 again or can we merge it?
<mup> PR #7409: interfaces/wayland: allow a confined server running in a user session to work with Qt, GTK3 & SDL2 clients <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7409>
<jdstrand> jamesh: really, AssumedAppArmorLabel should default to unconfined imo. I mean, I know why they didn't do it that way, but the default deny is onerous (you would always need corresponding rules for the communication that are default deny...)
<jdstrand> (that's what we recommended before)
<jamesh> jdstrand: perhaps an AppArmor rule specifically covering D-Bus activation of a name would make sense
<jamesh> although that would be a multi-year project to roll out :-(
<jdstrand> I think that was something tyhicks also suggested when we upstreamed
<dot-tobias> jdstrand: Just to confirm: The only way to get a DBus interface between two of my snaps (same publisher) auto-connected is through a store assertion *if* my application in the forum is granted â correct? Would that also apply to new revisions of already installed snaps â i.e. would existing users benefit from auto-connection after a refresh?
<jdstrand> dot-tobias: it can be done per snap(s) or globally
<jdstrand> dot-tobias: it would apply to all revisions of your snaps
<dot-tobias> jdstrand: Great, thanks!
<mup> PR snapd#7489 opened: store, ..., client: add a "website" field <Created by chipaca> <https://github.com/snapcore/snapd/pull/7489>
<zyga> dot-tobias: I update the thread as I go if you are curious
<zyga> ijohnson: in a moment
<dot-tobias> zyga: *grabs popcorn*
<mup> PR snapd#7490 opened: interfaces/shell-support: support confined snaps launching other snaps <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7490>
<mup> PR snapcraft#2728 opened: Base bare <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2728>
<joedborg> zyga: are you around?
<zyga> joedborg: yes but heading to bed
<joedborg> zyga: no worries!
#snappy 2019-09-20
<mup> PR snapd#7489 closed: store, ..., client: add a "website" field <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7489>
<mup> PR snapcraft#2728 closed: Base bare <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2728>
<ackk> hi, if I have a snap installed with --devmode, can I switch it to strict mode without reinstalling?
<mup> PR snapd#7466 closed: [RFC] cmd/snap: special handling of snap set refresh.hold <Needs Samuele review> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7466>
<zyga> kenvandine: may I ask you to look at https://bugs.launchpad.net/snapd/+bug/1747081
<mup> Bug #1747081: Snap application icons do not appear with Wayland <snapd:Triaged> <https://launchpad.net/bugs/1747081>
<zyga> perhaps it's already fixed
<zyga> pstolowski: can you please update https://bugs.launchpad.net/snapd/+bug/1747992 once the channel switching bug is addressed
<mup> Bug #1747992: Refreshing to a newly created channel but immediately stopped tracking <snapd:Triaged> <https://launchpad.net/bugs/1747992>
<zyga> pstolowski: perhaps assign it to yourself for tracking
<jamesh> zyga: so this is people with shells that don't source /etc/profile?
<zyga> jamesh: I don't follow, sorry?
<jamesh> zyga: the "snap icons do not appear with wayland" thing
<zyga> jamesh: ah, can you add that to the bug report please
<jamesh> zyga: I suspect the bug was fixed by https://github.com/snapcore/snapd/pull/6813
<mup> PR #6813: data: update XDG_DATA_DIRS via the systemd environment.d mechanism too <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6813>
<jamesh> zyga: but that fix would only have made it out to users at the beginning of this month by the look of things
<jamesh> https://bugs.launchpad.net/snapd/+bug/1747081/comments/10 <- that's what I think the current state is
<mup> Bug #1747081: Snap application icons do not appear with Wayland <snapd:Triaged> <https://launchpad.net/bugs/1747081>
<zyga> rogpeppe: hello
<rogpeppe> zyga: hiys
<zyga> rogpeppe: is there anything new you can share with us?
<rogpeppe> zyga: no, sorry. it's been continuously going down but i haven't had time to install my instrumentation yet.
<zyga> rogpeppe: was the screen / top / logging session useful?
<zyga> rogpeppe: understood
<rogpeppe> zyga: it's been down for the last few days so i haven't managed that yet
<zyga> rogpeppe: we're almost done sprinting, next week we will have more bandwidth to dig into
<rogpeppe> zyga: thanks!
<rogpeppe> zyga: i wish i knew why it was crashing
<rogpeppe> zyga: ooh, i tell a lie, it's actually up!
<rogpeppe> zyga: for the record, it doesn't look like memory is an issue (now, at any rate) http://paste.ubuntu.com/p/RhVQtY24S5/
<mup> PR snapd#7491 opened: tests: disable {contacts,calendar}-service tests on Arch Linux <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7491>
<zyga> rogpeppe: oh, that's interesting
<zyga> it's up for half a day
<zyga> rogpeppe: that's good
<zyga> rogpeppe: can you try journalctl --list-boots
<rogpeppe> zyga: will do shortly (currently in a call)
<zyga> mborzecki: I have 7831
<zyga> I'm tracking edge
<mborzecki> zyga: try snap refresh --stable
<mborzecki> then cancel when it's downloading
<zyga> done
<zyga> I attempted fetching 7713
<mborzecki> which rev snapd tried to download?
<zyga> https://www.irccloud.com/pastebin/Rc3nXiDE/
<mup> PR snapd#7492 opened: selinux: move the package under sandbox/selinux <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7492>
<mborzecki> super simple PR ^^
<Chipaca> mborzecki: famous last words
<cachio> sil2100, hey
<jamesh> mborzecki: https://github.com/snapcore/snapd/pull/7491 would be good to get in quick: Arch upgrading their EDS has probably broken all spread runs
<mup> PR #7491: tests: disable {contacts,calendar}-service tests on Arch Linux <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7491>
<rogpeppe> zyga: i didn't know about --list-boots! here you go: http://paste.ubuntu.com/p/cd68kqqcDn/
<zyga> looking
<zyga> it seems to reboot twice a day hmm
<zyga> but it is also confusing because of the value of time at boot
<zyga> thank you for sharing this, I'm none the wiser but this is useful information
<mup> PR snapd#7487 closed: interfaces/udev: account for cgroup version when reporting supported features <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7487>
<mup> PR snapd#7491 closed: tests: disable {contacts,calendar}-service tests on Arch Linux <Created by jhenstridge> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7491>
<zyga> pstolowski: https://bugs.launchpad.net/snapd/+bug/1820060
<mup> Bug #1820060: multiline strings in gadget.yaml defaults are mangled <snapd:Triaged> <https://launchpad.net/bugs/1820060>
<zyga> ijohnson: https://bugs.launchpad.net/snapd/+bug/1821788
<mup> Bug #1821788: Install daemon in stopped state <snapd:Triaged> <https://launchpad.net/bugs/1821788>
<mup> PR snapd#7492 closed: selinux: move the package under sandbox/selinux <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7492>
#snappy 2019-09-21
<mup> PR snapcraft#2729 opened: snaps: if snap is installed, don't check is_valid() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2729>
