[00:47] <mup> PR snapcraft#1533 closed: demos: update the name of the remote mqtt part <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1533>
[01:44] <mup> PR snapcraft#1534 closed: jhbuild plugin: fix UnboundLocalError for chmod_path <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1534>
[03:37] <mup> PR snapd#3872 opened: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
[05:54] <mup> PR core#56 opened: Remove ~ubuntu* instead of cutting after the first "~" <Created by mvo5> <https://github.com/snapcore/core/pull/56>
[05:55] <mup> PR core#54 closed: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/54>
[05:57] <zyga-suse> good morning
[06:09] <mup> PR snapd#3873 opened: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3873>
[06:10] <mup> PR snapd#3874 opened: interfaces: add netlink kobject uevent to hardware observe (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3874>
[06:11] <mup> PR snapd#3875 opened: interfaces: add udev netlink support to hardware-observe (2.27) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3875>
[06:12] <mvo> hey zyga-suse, good morning
[06:12] <mup> PR snapd#3873 closed: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3873>
[06:13] <zyga-suse> mvo: good morning, thank you for the fixes!
[06:13] <zyga-suse> mvo: I edited the description on github so that it shows up in merge commits
[06:13] <zyga-suse> mvo: today is the only day my kids go to school at 8:00 :/
[06:13] <mup> PR snapd#3854 closed: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3854>
[06:13] <jamesh> mvo: I don't suppose there is any chance of getting the last polkit PR into the 2.28 release?
[06:14] <mvo> jamesh: let me check
[06:14] <mvo> jamesh: has that landed in master already?
[06:14] <jamesh> mvo: the only open issue from niemeyer's review was scope of the polkit action ID
[06:14] <jamesh> mvo: no
[06:15] <jamesh> here it is, for reference: https://github.com/snapcore/snapd/pull/3797
[06:15] <mup> PR #3797: daemon: allow polkit authorisation to install/remove snaps <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3797>
[06:15] <mvo> jamesh: yeah, I think if that makes it before the weekend there is a chance, it seems like its very low risk and the benefit is (imo) huge
[06:16] <mvo> jamesh: could you please nudge niemeyer to do a second pass on 3797? and if it goes in ideally it should be squash-merged in the commit so that it can easily be cherry-picked for 2.28
[06:16] <zyga-suse> mvo: how is the 2.27.6 release looking?
[06:17] <jamesh> mvo: on the forum, niemeyer said he wouldn't be around for the next few days, so I don't know how that affects things
[06:18] <mvo> zyga-suse: waiting for tests right now, i.e. the PR for hardware-observe
[06:18] <mvo> zyga-suse: once that is green I will continue with that
[06:18] <zyga-suse> mvo: do you want to wait for anything else or just release ASAP
[06:18] <mvo> jamesh: meh, indeed, thats slightly sad
[06:18] <mup> PR snapd#3858 closed: snap-confine,snap-update-ns: add -no-pie to fix FTBFS on ppc64el <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3858>
[06:18] <mvo> zyga-suse: I am not aware of anything else - are you?
[06:18] <zyga-suse> no, just asking if there's more
[06:19]  * zyga-suse has bad debian day
[06:19] <zyga-suse> gpg: /home/zyga/snapd_2.27.5-1.dsc: error 58: Invocation of gpgme_op_verify
[06:19] <zyga-suse> what?
[06:19] <zyga-suse> well, there are updates to gpg, let's see
[06:21] <mvo> zyga-suse: yeah, it should be just those two PRs (one from me, one from jamie)
[06:21] <mup> PR snapd#3773 closed: snap-repair: execute the repair and capture logs/status <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3773>
[06:39] <mup> PR snapd#3870 closed: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages for 2.27 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3870>
[06:43] <mup> PR snapd#3857 closed: tests: fix lxd test for external backend  <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3857>
[07:05] <zyga-suse> ikey: hey, I noticed that you ship 2.27.0, do you plan on updating snapd to 2.27.5 or .6 later today?
[07:20] <pedronis> FAIL: cmd_watch_test.go:44: SnapSuite.TestCmdWatch
[07:20] <pedronis> cmd_watch_test.go:84:
[07:20] <pedronis>     c.Check(string(buf), testutil.Contains, "\rmy-snap 50.00 KB / 100.00 KB")
[07:20] <pedronis> ... container string = "\rmy-snap 0 B / 100.00 KB    0.00%\r\x1b[K"
[07:20] <pedronis> ... elem string = "\rmy-snap 50.00 KB / 100.00 KB
[07:21] <pedronis> I have seen a couple of times
[07:22] <mup> PR snapd#3856 closed: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3856>
[07:24] <Chipaca> mo'in
[07:24] <zyga-suse> pedronis: I have as well, that looks like ansi escape
[07:25] <zyga-suse> Chipaca: hey, thank you for the epic feedback :D
[07:25] <Chipaca> what does?
[07:25] <Chipaca> zyga-suse: epic feedback?
[07:25] <zyga-suse> launchpad must adopt not only markdown
[07:25] <zyga-suse> but greek statue images
[07:25] <Chipaca> hehe
[07:25] <zyga-suse> (or was it roman?)
[07:25] <Chipaca> zyga-suse: https://en.wikipedia.org/wiki/Facepalm
[07:26] <Chipaca> was going to point you to the image directly, but this way is funnier
[07:26] <Chipaca> ogra_: you around already?
[07:28] <Chipaca> zyga-suse: so to answer your actual question, french (turn-of-the-(20th)-century)
[07:32] <zyga-suse> mvo: after I dput and get the ACCEPTED email (I did :), how can I track the package further?
[07:39] <Chipaca> mvo: remind me, when is the cut-off for 2.29?
[07:49] <pedronis> Chipaca: after the rally afaict
[07:50] <Chipaca> that's nearly two months after 2.28's cut-off
[07:50] <Chipaca> (granted we weren't very good at cutting off at that particular cut-off)
[07:50] <pedronis> ?
[07:51] <pedronis> 2.28 was Sept 4
[07:51] <Chipaca> oh wait, got my dates wrong
[07:51] <Chipaca> i thought i read aug 11
[07:51] <Chipaca> but it's sep 11
[07:51] <Chipaca> that's fine then
[07:52] <Chipaca> (i'd understood 2.28 to be already forked)
[07:52] <Chipaca> pedronis: Sep 4? github has it wrong then
[07:54]  * zyga-suse reads https://github.com/snapcore/snapd/pull/3852/
[07:54] <mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
[07:56]  * zyga-suse looks at https://ci.debian.net/packages/s/snapd/unstable/amd64/ and :/
[08:02] <mvo> zyga-suse: https://packages.qa.debian.org/s/snapd.html might be a good place
[08:02] <mvo> Chipaca: in ~3 weeks time 2017-10-02
[08:02] <zyga-suse> mvo: right, I managed to find that now, I wish it was more real-time tho :-)
[08:03] <Chipaca> mvo: a'ight
[08:03] <Chipaca> mvo: and 2.28 is already cut, right?
[08:03] <Chipaca> (just checking)
[08:03] <mvo> Chipaca: correct, fixes and low-risk things only
[08:03] <mvo> zyga-suse: yeah, there is a bit of latency in the debian archive
[08:04]  * zyga-suse looks at https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=snapd&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=important&sev-inc=normal&repeatmerged=no
[08:04] <Chipaca> mvo: s/and low-risk things //
[08:04] <Chipaca> mvo: :)
[08:04] <mvo> Chipaca: *cough* yes!
[08:04] <zyga-suse> I need to recall how to reply to those bugs
[08:04] <Chipaca> zyga-suse: email?
[08:05] <zyga-suse> I guess I need to stand on my right leg, curl up my right feet behind my back and pick my nose while typing with my ear
[08:05] <Chipaca> zyga-suse: or do you mean "lis'n 'ere mate"?
[08:05] <zyga-suse> Chipaca: right but don't forget plain text and the magic first-few-line headers
[08:05] <Chipaca> zyga-suse: how could I forget
[08:05] <mvo> zyga-suse: pretty much https://wiki.debian.org/HowtoUseBTS
[08:05] <Chipaca> something that I never knew
[08:05] <Chipaca> :-D
[08:05]  * zyga-suse hugs mvo
[08:06]  * Chipaca actually might have known once, but has forgotten not only the knowledge, but also the knowledge of knowing
[08:06] <zyga-suse> in alternate universe debian has a web-based bug tracker with a "reply" button not using mailto:// an ubuntu is geeky and built from source
[08:07] <Chipaca> zyga-suse: and we're all using something written by djb as pid 1
[08:07]  * zyga-suse stops looking at the BTS and then goes back to stuffing sharp items under his fingernails
[08:12] <mup> PR snapd#3875 closed: interfaces: add udev netlink support to hardware-observe (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3875>
[08:13] <pedronis> https://forum.snapcraft.io/t/introducing-overlord-mock/2028
[08:18] <pedronis> Chipaca: your PR had the funniest of runs,  everything failed _except_ xenial-ppc64el
[08:18] <Chipaca> pedronis: :-D
[08:18] <Chipaca> ikr
[08:18] <Chipaca> pedronis: i've got a typo (catalog -> catalogue, apparently)
[08:19] <Chipaca> but I disagree
[08:19] <Chipaca> I don't know why that's considered a typo
[08:19] <pedronis> it's US american vs UK
[08:19] <Chipaca> nope
[08:19] <Chipaca> “In both the US and Canada, both catalog and catalogue are used, with catalogue commonly used in government and traditional institutions and catalog commonly used in informal, business, retail, and computing contexts.”
[08:19] <Chipaca> it's pretentious
[08:20] <mup> PR snapd#3876 opened: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3876>
[08:21] <pedronis> Chipaca: that sentence doesn't say anything about the UK
[08:21] <mup> PR snapd#3877 opened: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3877>
[08:21] <Chipaca> pedronis: ah, i read you backwards
[08:21] <Chipaca> why are we checking our spelling against british english agian?
[08:21] <Chipaca> again?*
[08:21] <pedronis> oxford says catalague is UK spelling
[08:21] <pedronis> *catalogue
[08:22]  * Chipaca goes with catalgae
[08:22] <ogra_> Chipaca, i am now
[08:22] <Chipaca> next it's going to object to Color vs Colour
[08:22] <Chipaca> ogra_: /var/cache/snapd, how much work is it to make it happen?
[08:22] <Chipaca> ogra_: good morning! had your coffee yet? here have some writable-paths nightmares instead
[08:23] <ogra_> Chipaca, one deb upload and an edge rebuild
[08:23] <Chipaca> ogra_: deb upload + sru, or ppa?
[08:23] <ogra_> PPA
[08:23] <Chipaca> ogra_: any objection to doing it?
[08:24] <ogra_> none at all ... apart from "whatch it closely after the change and before committing to beta/candidate"
[08:24] <ogra_> -h
[08:24] <Chipaca> pedronis: if we're using british spelling, then I'm fine with it (my local tools will be happier)
[08:24] <Chipaca> pedronis: if it's using US spelling, then it's just being pretentious
[08:24] <Chipaca> ogra_: could you do it, please?
[08:25] <Chipaca> ogra_: (not urgently)
[08:25] <pedronis> Chipaca: I have no clue
[08:25] <Chipaca> pedronis: check for footprints
[08:25] <ogra_> Chipaca, mind if i do it in https://github.com/snapcore/core-build/pull/17 (same change other dir) ?
[08:25] <mup> PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>
[08:25] <pedronis> is there an official choice for ubuntu?
[08:25]  * Chipaca wonders what was in his coffee
[08:26] <ogra_> (would you approve that)
[08:26] <pedronis> Chipaca: I just discovered I left extra lines in my just merged branch, this by looking at the diff I posted to the forum :/
[08:27] <ogra_> Chhmm, are you sure its /var/cache, not /var/lib ? (i thought you are talking about #3807 )
[08:27] <Chipaca> ogra_: I don't mind! and should I approve it before or after the change
[08:27] <mup> PR #3807: cmd/snap-confine,packaging: import snapd-generated policy <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/3807>
[08:27] <ogra_> after
[08:27] <mpt> Is it possible to make a branch from edge? And if so, why? :-)
[08:27] <Chipaca> pedronis: fun!
[08:27] <pedronis> Chipaca: there's always the next PR
[08:28] <Chipaca> ogra_: /var/cache/snapd, for #3866
[08:28] <mup> PR #3866: many: implement fetching sections and package names periodically <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3866>
[08:28] <pedronis> Chipaca: we are using  github.com/client9/misspell/cmd/misspell  don't know if there's a way to enforce a dictionary
[08:28] <ogra_> Chipaca, then i'll do cache and lib in that PR as well, that will help zyga-suse's issue
[08:28] <pedronis> at least to avoid getting UK one place and US another
[08:29] <Chipaca> pedronis: https://github.com/client9/misspell/#locale
[08:29] <Chipaca> :-)
[08:29] <ogra_> Chipaca, i assume you want "synced" as well ?
[08:30] <Chipaca> ogra_: well, it could be 'temporary'
[08:30] <ogra_> (or is "copy readonlöy once and never again" enough ?)
[08:30] <pedronis> Chipaca: ok, now pick your poison and change run-checks
[08:30] <Chipaca> ogra_: but if temporary means in-memory, then maybe something else
[08:31] <Chipaca> (one of the files that'll land there might be a couple of megs)
[08:31] <ogra_> Chipaca, i have two ooptions, one copies the content from the readonly dir once on first mount (transition), the other constantly updates if new stuff shows up in the readonly partition (synced)
[08:31] <Chipaca> ogra_: you have three :-) what does temporary do?
[08:32] <pedronis> well temporary won't survive reboots
[08:32] <pedronis> one would think
[08:32] <ogra_> Chipaca, its like /run ...
[08:32] <ogra_> right, what pedronis said
[08:33] <Chipaca> it'll be recreated on boot (if there's network), but ok, sure, umm... 'synced'!
[08:33] <Chipaca> and we could ship a default sections file :-)
[08:33] <ogra_> Chipaca, it will be created on boot in any case, not just with network ... but it will come up empty
[08:33] <Chipaca> ogra_: i meant the files
[08:34] <ogra_> ah
[08:34] <Chipaca> snapd creates them on startup
[08:34] <ogra_> ok
[08:34] <Chipaca> but, make it synced
[08:34] <ogra_> will do
[08:34] <Chipaca> i don't want these on tmpfs on little devices
[08:34] <Chipaca> and if we feel like it we can ship a pre-loaded cache
[08:34] <Chipaca> sounds like a win
[08:37] <mvo> Chipaca, ogra_: please no changes to the ppa right now, we need to push a new 2.27.6
[08:37] <mvo> later is fine, but not just now
[08:37] <ogra_> mvo, only doing the PR, i'll wait fo you PR approval there ;)
[08:37] <mvo> ogra_: ta
[08:38] <ogra_> Chipaca, hmm, the dir doesnt exist by default, does it ?
[08:38] <Chipaca> ogra_: currently it doesn't
[08:38] <Chipaca> ogra_: is that a problem? do we need to change the snapd packaging first?
[08:38] <ogra_> right, then i need to create it too (no mountpoint, no bind mount)
[08:38] <Chipaca> right
[08:41] <pedronis> mmg, no change was fine, copy-pasting from terminal issue
[08:42] <Chipaca> gah, why is spellcheck _still_ not part of the static checks :-(
[08:42] <mwhudson> zyga-suse: congrats on your upload :)
[08:42] <Chipaca> shellcheck*
[08:42] <Chipaca> (also, i should run the static checks locally more often, tut tut)
[08:43] <mvo> meh, gccgo build failure on xenial/powerpc with master: https://launchpadlibrarian.net/336142278/buildlog_ubuntu-xenial-powerpc.snapd_2.27.5+git360.71a180c~ubuntu16.04.1_BUILDING.txt.gz - looks conistent
[08:44] <pedronis> Chipaca: should that dir comes from snapd.dir ?
[08:44] <pedronis> *dirs
[08:45] <mwhudson> mvo: yay!
[08:45] <Chipaca> pedronis: which dir?
[08:45] <pedronis> /var/cache/snapd ?
[08:45] <Chipaca> pedronis: /var/lib/snapd?
[08:45] <Chipaca> pedronis: i think so yes
[08:45] <mvo> mwhudson: if you have any ideas, I would be very happy. fwiw, I worked around the ppc64el issue succesfully
[08:45] <zyga-suse> mwhudson: thanks for adding the ACLs!
[08:45] <ogra_> i can created it from core-config as well if you want ... your choice
[08:45] <ogra_> *ceate
[08:45] <zyga-suse> mwhudson: I think there are some bugs to address, some low hanging fruit there
[08:46] <zyga-suse> mwhudson: man pages and such
[08:46] <mwhudson> mvo: how did you manage that -extldflags -no-pie?
[08:46] <mwhudson> mvo: well the test is hanging
[08:46] <Chipaca> dammit, i'd _fixed_ this GOPATH issue :-(
[08:46] <pedronis> Chipaca: we need on classic and we need it also on core reexec fwiw
[08:47] <Chipaca> pedronis: yes
[08:47] <mvo> mwhudson: https://github.com/snapcore/snapd/pull/3858/files is what I did for -no-pie
[08:47] <mup> PR #3858: snap-confine,snap-update-ns: add -no-pie to fix FTBFS on ppc64el <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3858>
[08:47] <pedronis> stating the obvious just in case
[08:47] <ogra_> yeah, then creating it from snapd is the better move
[08:47] <Chipaca> pedronis: not sure where core reexec comes into it
[08:47] <pedronis> so you also need a mkdir
[08:47] <mvo> mwhudson: yeah, it is hanging but apparently only on powerpc (gccgo), I have a look in a bit
[08:47] <ogra_> or debian/dirs
[08:47] <Chipaca> ogra_: both \o/
[08:47] <ogra_> :)
[08:47] <pedronis> Chipaca: even if it's dirs or core , you still need to create it on classic because your code might be running before you got the new deb
[08:48] <mwhudson> mvo: ah i guess that works
[08:48] <Chipaca> pedronis: ah, yes
[08:48] <Chipaca> i'll be tweaking that code
[08:48] <mwhudson> mvo: you can also pass -ldflags=-extldflags=-no-pie to go install
[08:48] <mwhudson> mvo: my enthusiasm for debugging gccgo issues is, erm, low
[08:48] <Chipaca> want to have it in dirs, created on boot via initramfs-tools, created on ensure, and skipping the download entirely if unable to create
[08:48] <Chipaca> i think that covers it enough
[08:49] <Chipaca> but also, who reverted the GOPATH%%:* change :-(
[08:49]  * Chipaca curses
[08:49] <mup> PR snapd#3878 opened: tests: disable opensuse 2.28 as their infrastructure is having issues <Created by mvo5> <https://github.com/snapcore/snapd/pull/3878>
[08:49] <mvo> mwhudson: aha, thanks for this hint!
[08:49] <mvo> mwhudson: gccgo> yeah, its pita that we still need to support powerpc
[08:50] <mwhudson> mvo: i guess i should really SRU the fix i linked into zesty but my enthusiasm for that is not very high either :)
[08:50] <pedronis> Chipaca: anyway double checked, seems indeed packages tend to put their /var/cach/pkg dir into .dirs
[08:51] <mup> PR snapd#3878 closed: tests: disable opensuse 2.28 as their infrastructure is having issues <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3878>
[08:51] <Chipaca> pedronis: awesome, thank you for checking that
[08:52] <Chipaca> pedronis: i think that makes dpkg clean it up on purge
[08:52] <mvo> mwhudson: no worries
[08:52] <Chipaca> pedronis: https://www.debian.org/doc/manuals/maint-guide/dother.en.html#dirs
[08:52] <mvo> mwhudson: the workaround is ok for now
[08:52] <mup> PR core#56 closed: Remove ~ubuntu* instead of cutting after the first "~" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/56>
[08:53] <mwhudson> mvo: i don't glean anything very much from that traceback of the hanging test
[08:53] <mwhudson> it looks like it's just sitting there doing nothing
[08:53] <mwhudson> but it's hard to be sure of course
[08:53] <pedronis> Chipaca: that seems what we want, no? remove on purge?
[08:53] <Chipaca> pedronis: yes
[08:54] <Chipaca> so... which english do we use?
[08:54] <Chipaca> mvo?
[08:54] <Chipaca> US or UK? is behaviour wrong, or is catalog wrong? :-)
[08:59] <mvo> Chipaca: UK is closer to me
[09:00] <mvo> Chipaca: what is complaining  ? spellcheck?
[09:00] <Chipaca> mvo: misspell, but yes
[09:00] <Chipaca> for some reason i thought we were using US
[09:01] <Chipaca> but we've managed to be neutral so far :-)
[09:01] <Chipaca> except for one word in CONTRIBUTING.md
[09:01] <Chipaca> :-)
[09:01] <mvo> mwhudson: nevermind, I will dive into it
[09:01] <Chipaca> I'll change it to Catalogue then
[09:02] <mvo> Chipaca: lets stick with uk and solve the problem via po/en_US.po
[09:02] <Chipaca> mvo: it's a variable name
[09:02] <Chipaca> :-)
[09:03] <mvo> *pffff* ok
[09:04] <Chipaca> interestingly, without telling misspell which locale to use, it seems to use a mixture?
[09:04]  * Chipaca puzzled
[09:05]  * Chipaca facepalms
[09:06]  * Chipaca is dumber by the day
[09:06]  * Chipaca doesn't get any better by night either
[09:07] <Chipaca> it wasn't catalogue vs catalog
[09:07] <Chipaca> it was "cataloge"
[09:07]  * Chipaca <- dumbarse
[09:08]  * mvo hugs Chipaca
[09:09] <Chipaca> can we add shellcheck from zesty to our ppa?
[09:12] <ogra_> why to the PPA ?
[09:19] <Chipaca> ogra_: how else do you get shellcehck from zesty everywhere?
[09:20] <Chipaca> i mean everywhere xenialish
[09:20] <Chipaca> although i guess we could just make sure we run the static checks on zesty
[09:20] <Chipaca> or artful even
[09:22] <ogra_> Chipaca, where exactly do you want to run shellcheck ?
[09:23] <Chipaca> ogra_: if shellcheck is installed, the static checks use it
[09:23] <ogra_> (do we have anything that has the PPA enabled where we use it ?)
[09:23] <Chipaca> ogra_: but maybe running it on artful is good enough
[09:24] <ogra_> what i mean is that typically our travis tests run shellcheck already ... before a package hits a PPA
[09:26] <Chipaca> ogra_: our travis checks don't run shellcheck
[09:27] <Chipaca> ogra_: if they did, they'd be red
[09:27] <ogra_> oh
[09:27] <ogra_> mine all do :)
[09:42] <zyga-suse> ogra_: I left one comment on the core PR
[09:43] <ogra_> zyga-suse, already answred ;)
[09:43] <zyga-suse> thanks!
[09:45] <pedronis> Chipaca: are you looking into classic revert now ?
[09:45] <Chipaca> pedronis: yes
[09:46] <pedronis> Chipaca: did you see #3852  ?
[09:46] <mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
[09:47] <Chipaca> pedronis: uh, yes
[09:47] <Chipaca> didn't i submit that review?
[09:47] <Chipaca> i'll look again in a sec
[09:47] <pedronis> you commented but I don't see a code review there
[09:48] <pedronis> from you
[09:49] <pedronis> mvo: did you see the comment from jdstran-d about adding bind to harward-observe ?
[09:52] <mvo> pedronis: yes, I think I did that, let me double check
[09:52] <pedronis> you did
[09:52] <pedronis> github confused me
[09:52] <mvo> pedronis: my bad, I force pushed
[09:52] <mvo> pedronis: to make the cherry-pick easier
[09:53] <mvo> pedronis: sorry for that, it was an exception
[09:53] <pedronis> yea, now I noticed
[09:54] <pedronis> mvo: any reason not to merge #3864 ?
[09:54] <mup> PR #3864: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3864>
[09:55] <mvo> pedronis: thanks, merged now
[09:55] <mup> PR snapd#3864 closed: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3864>
[09:57] <mup> PR snapd#3867 closed: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3867>
[09:58] <mup> PR snapd#3879 opened: release: merge release 2.27.6 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3879>
[09:59] <pedronis> mvo: now that we run unit tess on more places,  SnapSuite.TestCmdWatch seems to fail randomly but often enough to be annoying, haven't looked at it yet
[09:59] <pedronis> *tests
[10:01] <mvo> pedronis: thanks, I have no looked either yet, there are some build issues in the edge ppa that I wanted to look at next, once these are under control I can have a look (until you beat me to it of course :)
[10:01] <mvo> s/until/unless/
[10:02]  * zyga-suse needs to pick up his daughter in 10 minutes
[10:02] <zyga-suse> why does it have to rain all week :/
[10:03] <mup> PR snapd#3880 opened: tests: add trivial canonical-livepatch test to ensure we do not break it <Created by mvo5> <https://github.com/snapcore/snapd/pull/3880>
[10:03] <pedronis> mvo: I looked at it briefly now, I don't understand the failure mode at all
[10:04] <pedronis> might also be different versions of pb ?
[10:04] <mvo> pedronis: could be, we recently changed the import
[10:05] <pedronis> debian-unstable seems one place where it fails
[10:05] <pedronis> but not always
[10:05] <pedronis> but I have seen also some autopkgtests
[10:05] <pedronis> not sure
[10:06]  * zyga-suse sighs
[10:06] <zyga-suse> Pharaoh_Atem: that shell replacement for that ruby replacement of just using go build
[10:06] <zyga-suse> ...
[10:07] <zyga-suse> ikey: would you like if I could co-maintain snapd in solus?
[10:08] <zyga-suse> Pharaoh_Atem: this is gobuild :-( http://pastebin.ubuntu.com/25483256/
[10:08] <mup> PR snapd#3869 closed: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages for 2.28 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3869>
[10:10] <mup> PR snapd#3876 closed: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3876>
[10:16]  * zyga-suse goes into the rain, ttyl
[10:16] <mvo> pedronis: it looks like https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+build/13346641 panics in snapstate_test.go:77 which indicates that maybe 5s for settle is not enough on arm/arm64 - do you mind if I try with 10s?
[10:18] <mvo> pedronis: same error on powerpc it seems, anyway, I do a test build with 15s and see if that helps
[10:21] <mwhudson> mvo: the pb import change did not change the code imported at all fwiw
[10:21] <pedronis> mvo: I don't mind, it's there to be able to change it
[10:22] <pedronis> slow infra is slow
[10:22] <mwhudson> pretty sure that library has buggy (== wall clock dependent) unit tests all of its own
[10:25] <pedronis> does it have wall clock dependent behavior as well?
[10:28] <mup> PR snapd#3881 opened: snapstate: give snapmgrTestSuite.settle() more time to settle <Created by mvo5> <https://github.com/snapcore/snapd/pull/3881>
[10:40] <Chipaca> mvo: o/
[10:41] <Chipaca> mvo: completer snippet creation support, I thought that was in 2.27.2+, with 2.27.5 having the fix for not doing it on core
[10:41] <Chipaca> mvo: but it's not! how did I become confused?
[10:44] <Chipaca> mvo: (I looked at git's release tags for this information)
[10:50] <mwhudson> pedronis: maybe?
[10:51] <pedronis> there's a REFRESH_RATE
[10:51] <pedronis> so I suspect it is
[10:51] <zyga-suse> re
[10:51] <pedronis> which means that test is very optimistic
[10:52] <pedronis> I'm surprised it didn't fail more often
[10:52] <zyga-suse> mwhudson: hey, mind if I do .6 as well?
[10:52] <mwhudson> zyga-suse: not at all
[10:52] <zyga-suse> mwhudson: I need to re-learn the BTS insanity and reply to bug mail there
[10:53] <zyga-suse> mwhudson: I'll look at doing manual page for snapctl so that we can close that one
[10:53] <mwhudson> zyga-suse: debian bts sure is its own special snowflake
[10:53] <zyga-suse> mwhudson: how does new packages sponsorship look like?
[10:53] <mwhudson> zyga-suse: you know the bts(1) command line tool?
[10:53] <zyga-suse> mwhudson: if, say, I packaged the gettext thing, could you sponsor it?
[10:53] <mwhudson> zyga-suse: yes
[10:53] <zyga-suse> mwhudson: no, checking
[10:53] <mwhudson> uploads to NEW can't be source only and can't be done by a DM
[10:54] <zyga-suse> mwhudson: does it require an operational mail server locally?
[10:54] <zyga-suse> mwhudson: ah, debian still does binary uploads?
[10:54]  * Chipaca murders pstolowski, review-style
[10:54] <zyga-suse> mwhudson: but anyway that is fine, I just want to reduce the number of patches
[10:54] <zyga-suse> Chipaca: ohh?
[10:55]  * zyga-suse is grumpy because his daughter had no lunch at school today
[10:55]  * Chipaca whistles innocently and cleans his blade
[10:55] <mwhudson> zyga-suse: it requires something, i have mstmp which is not exactly "an operational mail server"
[10:55] <Chipaca> zyga-suse: what?
[10:55] <zyga-suse> school ends at 12:30 but lunch is served at 15:00, who made this schedule again?
[10:55] <Chipaca> zyga-suse: your daughter is hungry, and you get angry? that's dad-level hangry right there
[10:55] <matteo> lol
[10:55] <mwhudson> zyga-suse: and oh yes debian still does binary uploads :)
[10:55] <zyga-suse> Chipaca: just polish school crappiness and induced stress
[10:55] <Chipaca> zyga-suse: if it's at 15:00 it's not lunch!
[10:55] <pedronis> mvo: I fear that test needs a couple of Sleep in it
[10:55] <mwhudson> maybe not for many more years though
[10:56] <Chipaca> mwhudson: what're you doing awake dude
[10:56] <zyga-suse> Chipaca: on top of that she had to attend the religion classes again; even though we clearly stated we didn't approve of that
[10:56] <mwhudson> Chipaca: it's only 2300!
[10:56] <mwhudson> but yes i should go to bed
[10:56] <zyga-suse> mwhudson: have a great rest man!
[10:57]  * zyga-suse looks at bts(1) and laughs at 
[10:57] <zyga-suse> ``The abbreviation "it" may be used to refer to the last mentioned bug number, so you could write:  % bts severity 95672 wishlist , retitle it "bts: please add a --foo option"``
[10:58] <Chipaca> zyga-suse: sounds like something somebody used to writing Perl would do
[10:58] <zyga-suse> debian, where web-based bts is not an option but we parse `it` in sentences
[10:58] <zyga-suse> Chipaca: yes, that's a very good bet
[10:58] <Chipaca> (Perl expands your awareness of contextual information, meaning you end up thinking these sort of thoughts)
[10:59] <Chipaca> (15 years later I still don't know if that's a good thing)
[10:59] <pedronis> anaphoric macros come to mind
[10:59]  * Chipaca doesn't put no macros in no amphorae
[11:00]  * zyga-suse finally found this: https://github.com/openSUSE/golang-packaging/blob/master/golang.sh#L118
[11:00] <pedronis> Chipaca: : https://en.wikipedia.org/wiki/Anaphoric_macro
[11:00] <Chipaca> yes, reading that
[11:01] <Chipaca> today is being educational :-)
[11:01] <zyga-suse> ah
[11:01] <zyga-suse> I used that without knowing this term
[11:01]  * zyga-suse used to write proprietary lisp stuff back in the days
[11:03] <Chipaca> I should learn lisp beyond being able to edit .emacs
[11:03] <Chipaca> some day
[11:03] <Chipaca> anyway, where was i
[11:04]  * Chipaca got context-switched to hell
[11:04] <pedronis> sorry
[11:04]  * Chipaca notices it's lunch time
[11:04] <Chipaca> pedronis: you weren't the one plopping things on my stack :-)
[11:04] <Chipaca> well, maybe that last anaphorensic one was
[11:04] <Chipaca> ok, fine, take a little blame
[11:04] <Chipaca> FINE
[11:04]  * Chipaca lunch
[11:05] <Chipaca> also PS https://github.com/pts/pts-line-bisect/ is awesome
[11:05]  * Chipaca cleaning up browser tags pre-lunch
[11:07] <zyga-suse> Chipaca: I'll keep that tab for you
[11:08] <Chipaca> zyga-suse: the biggest problem is that _we don't need it_ :-)
[11:08] <Chipaca> our files are small enough for it not to matter
[11:09] <Chipaca> bah, should probably benchmark on the bbb
[11:09] <pedronis> mvo:  do you remember which test  timed out of Settle ?
[11:09] <pedronis> I'm asking because when I was finishing the branch they were all fast except the one you added recently
[11:11] <zyga-solus> ikey, hello ;)
[11:11] <zyga-solus> Chipaca, using hexchat now
[11:13] <mvo> pedronis: the TwoCores one, let me look for the exact name
[11:13] <mvo> pedronis: fwiw, now only powerpc is having issues, even 30s is not enough for that it seems :(
[11:13] <pedronis> ok, then something else is going on
[11:13] <mvo> pedronis: TestInstallWithoutCoreTwaoSnapsWithFailureRunThough
[11:13] <mvo> pedronis: including typos
[11:14] <mvo> pedronis: the tests are ok on the other arches, however powerpc is the only gccgo based arch left so maybe it is something else indeed
[11:14] <pedronis> mvo: 30s is not reasonable
[11:14] <pedronis> we can still use  a local settle ofr a couple of tests
[11:14] <pedronis> with a larger timeout
[11:15] <pedronis> mvo: ppc is a big big pain :/
[11:15] <mvo> pedronis: yeah, I'm running another test build on ppc now to see how things look
[11:15] <mvo> pedronis: yes it is!
[11:15] <zyga-solus> mvo, is the real "ppc" arch?
[11:15] <mvo> pedronis: I should have results in ~20min or so
[11:15] <zyga-solus> mvo, or something more recent
[11:15] <mvo> zyga-solus: this is powerpc
[11:15] <zyga-solus> mvo, I ask because ... I happen to have one ppc box
[11:16]  * zyga-solus looks elsewhere to avoid eye contact
[11:16] <ogra_> huh ? isnt powerpc dead ?
[11:16] <ogra_> i thought we only do ppc64el now
[11:16] <mvo> ogra_: its a zombie
[11:16] <mvo> ogra_: its alive in xenial
[11:16] <ogra_> oh my
[11:16] <mvo> ogra_: so we need to care
[11:16] <mvo> :/
[11:16] <zyga-solus> shall I boot it?
[11:16] <ogra_> do we really ?
[11:16] <zyga-solus> (well, boot and install)
[11:17] <mvo> ogra_: maybe not
[11:17] <mvo> ogra_: but the default is that we do :)
[11:17] <mvo> zyga-solus: wait a little bit please, I run one more test on the builder and then I will check if its a generic gccgo issue
[11:17] <pedronis> mvo:  here  TestInstallWithoutCoreTwoSnapsWithFailureRunThrough  takes 6.5 seconds
[11:17] <ogra_> yeah, but given it will be dead and there will likely also not be snaps anyway ...
[11:17] <pedronis> so definitely 5s is low for it
[11:17] <zyga-solus> mvo, sure - I *really* don't want to
[11:17] <mvo> ogra_: yeah, I would love to burry it for good
[11:17] <mvo> zyga-solus: heh
[11:17] <mvo> pedronis: thanks for double checking!
[11:17] <zyga-solus> just offering to help if last resort
[11:18] <zyga-solus> man, solus is really good
[11:18] <ogra_> mvo, we should start a forum discussion and if nobody complains just let it die
[11:18] <pedronis> but 30+ seems a more serious problem
[11:18] <pedronis> mvo: after that I have  TestInstallWithoutCoreTwoSnapsRunThrough	0.161s
[11:18] <pedronis> all the rest is fast
[11:18] <mvo> pedronis: woah, that looks like its worth invesitgating why the other one takes so long, I wonder if it does some retries
[11:19] <mvo> pedronis: I need to get some lunch now, lets talk in a bit, I shall have results from another test run then
[11:20] <pedronis> mvo: I suspect it might be new behavior related to the prereq task but not sure
[11:21] <pedronis> anyway, yes it's a slow test, would be good to understand/cut runtime if possible
[11:22] <zyga-solus>  pedronis, is it an io-bound test?
[11:23] <pedronis> ?
[11:23] <zyga-solus> that test you are discussing
[11:23] <zyga-solus> is it slow because of CPU, fake sleeping or IO?
[11:23] <zyga-solus> maybe worth measuring with SNAPD_UNSAFE_IO=1
[11:24] <pedronis> doubt that but we can try
[11:24] <pedronis> more likely som retries
[11:25] <mcphail> Hi everyone. Is there any possibility for a name-based virtual host layer for snaps? The idea being that multiple snaps could "bind" to port 80 and the virtual-host layer would direct to the correct one based on the requested name? That way it would be possible to run, say, the nextcloud snap and a separate server app
[11:26] <zyga-solus> mcphail, hey, that's pretty interesting but we don't have anything doing that at the moment
[11:26] <mcphail> OK. Cheers zyga-solus
[11:27] <pedronis> it blurs a bit the distinction with other container approaches, otoh when we allow to install the same snap multiple times we might have to think about that
[11:27] <pedronis> zyga-solus: no, that env var  doesn't change anything for that test
[11:29] <zyga-solus> pedronis, thank you for checking
[11:30] <pedronis> overlord.Mock doesn't write state to disk
[11:33] <pedronis> anyway, I think I have also been context-switched to hell as John put it at this point
[11:46] <mvo> pedronis: hm, even brute force 120s is not enough on powerpc, so something else must be going on
[11:50]  * ogra_ waits for pedronis and mvo to cross the 1h mark for the test :P
[11:51] <pedronis> mvo: we should understand why it takes so long on non ppc I suppose
[11:51] <pedronis> it might it why it doesn't work at all on ppc
[11:51] <pedronis> s/it might it/it might hint/
[11:51] <mvo> pedronis: precisely
[11:52] <pedronis> mvo: #3877 can be merged
[11:52] <mup> PR #3877: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3877>
[11:53] <mup> PR snapd#3882 opened: debian: improve package description <Created by mvo5> <https://github.com/snapcore/snapd/pull/3882>
[11:53] <mvo> thanks pedronis
[11:54] <mup> PR snapd#3871 closed: tests: fix regex to check core version on snap list <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3871>
[11:54] <mup> PR snapd#3874 closed: interfaces: add netlink kobject uevent to hardware observe (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3874>
[11:54] <mup> PR snapd#3877 closed: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3877>
[11:57] <pedronis> mvo: now that settle is more than do Ensure 50 times, that test look strange
[12:00] <pedronis> mvo:  we don't need the for loops around settle anymore
[12:02] <pedronis> doesn't reduce runtime, mind
[12:06] <mvo> pedronis: it looks like the outer loop is the problem, if I remove it I get runtimes of 0.8s
[12:06] <mvo> pedronis: eh, 0.08
[12:06] <pedronis> well I'm saying the inner loop is not needed
[12:06] <pedronis> but both this consideration will not solve the ppc problem
[12:09] <pedronis> mvo: there's no relation between the outer loop and settle timeout,  we  settle many times per outer loop, though as I said one settle is enough
[12:10] <pedronis> mvo: we don't have  a ppc box we can access? this is not going to be fun to debug just through autopkgtest runs
[12:12] <zyga-solus> pedronis: I could set one up and open access for you but not sure if it will work, it's an ancient-ish mac mini
[12:13] <zyga-solus> pedronis: we could also try a qemu box
[12:13] <zyga-solus> pedronis: note that ensure loop prune also often fails on ppc so it feels like golang behaves different wrt scheduling there for whatever reason
[12:14] <pedronis> mvo: this is my local diff, debugging prints included:  http://pastebin.ubuntu.com/25483699/
[12:15] <pedronis> it works fine here with those changes
[12:15] <pedronis> run time is just 10 times whatever it takes for one loop
[12:22] <pedronis> settle doesn't use timers fwiw
[12:30] <mvo> pedronis: thanks, I poke at it some more now too
[12:33] <mup> PR snapd#3882 closed: debian: improve package description <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3882>
[12:43] <mup> PR snapcraft#1535 opened: jhbuild plugin: remove dependency on pkgconf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1535>
[12:45] <pedronis> mvo: xenial-ppc64el auotpkgtest are passing though, are the failures in the PPA?  or somewhere else?  me is confused
[12:47] <mvo> pedronis: yeah, in hte ppa during build
[12:47] <mvo> pedronis: one sec, I give you a link
[12:47] <pedronis> what's different there? though
[12:48] <mvo> pedronis: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages
[12:48] <Chipaca> pstolowski: o/
[12:48] <Chipaca> pstolowski: I was trying to think how to explain what i meant about simplifying it, but can't find an easier way (for me) than code
[12:48] <mvo> pedronis: its a different build environment, I'm not sure about the details sbuild vs the autopkgtest env. I'm not sure how different hw/virtualisation is
[12:48] <pedronis> mvo: ah, this is powerpc, not ppc64 el ?
[12:48] <mvo> pedronis: correct
[12:48] <Chipaca> pstolowski: would you mind if i wrote it and pointed you at it?
[12:48] <mvo> pedronis: powerpc (32bit)
[12:48] <Chipaca> pstolowski: i wish i were better at explaining :-/
[12:49] <mvo> pedronis: I'm still working on the 2.28~rc2 test build, once that is done this gets my attention again
[12:49] <pstolowski> Chipaca, sure
[12:51] <mvo> pedronis: I'm also curious if running the tests with gccgo makes a difference
[12:51] <pedronis> mvo: well we do run them
[12:51] <pedronis> on other archs
[12:51] <pedronis> so many moving parts
[12:51] <pedronis> mvo: we have a spread test about that
[12:52] <mvo> pedronis: hm, good point
[12:52] <pedronis> probably me having made a panic is also not great
[12:52] <pedronis> given that then it ges covered by the lock panics
[12:54] <pedronis> mvo: I can try to make a cleanup PR, might be  a better baseline to investigate
[12:54] <pedronis> from
[12:54] <mvo> pedronis: sure, that is welcome!
[12:59] <mup> PR snapd#3883 opened: overlord/snapstate: cleanup settle and its uses <Created by pedronis> <https://github.com/snapcore/snapd/pull/3883>
[12:59] <pedronis> mvo: done ^
[13:00] <mvo> pedronis: thanks a lot!
[13:00] <cachio> mvo, joining a bit late
[13:00] <mvo> cachio: no problem
[13:02] <sborovkov> ogra_: hmm, is there a way to tell ubuntu image to grab one of snaps from other channel? I want to build image from stable... but psplash is devmode so it can only be beta/edge
[13:09] <sborovkov> and if I build it as an extra snap locally I won't be able to update/remove it :-(
[13:10] <ogra_> sborovkov, i'll have to talk to jdstrand at some point about having an interface that has all bits the splash needs
[13:10] <ogra_> currently the --extra-snaps way is the best way i think ...
[13:11] <Chipaca> pstolowski: note i haven't tested that code! I think the main thing you might've been missing is that info.Apps is already a map (and that info.Services() exists)
[13:11] <ogra_> sborovkov, though why do you use the userspace bit, i thought you start some UI anyway ... the gadget splash should be sufficient for that
[13:11] <pstolowski> Chipaca, yes, exactly, I missed those
[13:12] <pstolowski> Chipaca, thanks!
[13:12] <sborovkov> ogra_: well I wanted to have something to show if our service is restarted
[13:13] <sborovkov> so that we don't show login page
[13:14] <ogra_> sborovkov, would "black" be enough ? i think you can tinker with the vt.handoff= value in cmdline.txt for that (just have it come out at a vt that doesnt have login)
[13:15] <ogra_> i'd use the psplash snap only fo systems that dont have graphical bits at all, switching between the splash and your UI will likely be a "flashy" experience
[13:15] <sborovkov> hmm I guess so, since restart does not happen often and would take couple of seconds
[13:15] <sborovkov> I just was not sure if I need it to show up on the first boot when keys are generated and so on
[13:15] <sborovkov> though that's a separate issue I guess
[13:16] <ogra_> yeah, kind of ...
[13:16] <ogra_> for that step you would still have the gadget splash in place anyway
[13:16] <ogra_> (it only goes away once the login prompt comes up)
[13:17] <sborovkov> yeah but on the first boot after login promt comes up it takes like 5 minutes of it doing stuff in background. so gadget splash would not be helpful. On the other hand it's not like I can change the image used by psplash on the first boot and later boots.
[13:18] <sborovkov> oh wait, psplash does not work on the first boot
[13:18] <sborovkov> so it's not gonna help anyway
[13:18] <sborovkov> nvm
[13:22] <ogra_> sborovkov, huh ? the gadget psplash definitely works on every boot
[13:23] <ogra_> and it only goes away once the "please press enter to configure" message comes up... i.e. when console-conf starts
[13:23] <ogra_> by then all device keys should have long been created
[13:25] <mup> PR snapcraft#1536 opened: repo: implement :target suffix for package names <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1536>
[13:27] <sborovkov> ogra_: oh I was talking about psplash snap
[13:27] <ogra_> sborovkov, hmm, after the login pompt comes up yoou have an additional delay ?
[13:28] <ogra_> that sounds like a bug actually ... all keys should be generated once the prompt shows up
[13:28] <ogra_> (and psplash from the gadget actually only stops if something takes over the tty (i.e. getty for login)
[13:28] <ogra_> )
[13:35] <zyga-solus> mvo: I downloaded ppc xenial iso
[13:35] <zyga-solus> I can find that box and hit the install
[13:38] <sborovkov> ogra_: console-conf is disabled
[13:38] <sborovkov> on our image
[13:38] <mvo> zyga-solus: I have access to a porter box but no rapt installed there nor go so I can't do much
[13:40] <zyga-solus> mvo: I'll make lunch and try to install it
[13:40] <zyga-solus> mvo: worst case it doesn't work
[13:40] <ogra_> sborovkov, well, you culd try with the gadget splash and setting vt.handoff=0 ... that will keep the screen up and not show a login prompt at all ... the question is if your UI can then take over
[13:40] <zyga-solus> mvo: best case I have something you can ssh into by evening
[13:40] <zyga-solus> mvo: and I get the geek card back
[13:41] <ogra_> sborovkov, your UI might need a chvt call ...
[13:43] <sborovkov> alright I will try that, going to try to apply splash screen changes from pi2 to my pi3 gadget snap repo
[13:43] <sborovkov> first
[13:43] <ogra_> sborovkov, https://github.com/snapcore/pi3-gadget/pull/13 and i also added a gadget snap for pi3 to the bug
[13:43] <mup> PR pi3-gadget#13: add splash support <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/13>
[13:44] <ogra_> (though you got custom changes i guess)
[13:44] <zyga-solus> mvo: I found it
[13:44] <mvo> pedronis: good news, I can reproduce the error with go-6 here apparently
[13:44] <sborovkov> ogra_: ah cool will use that then, yeah, but I just need to merge it then
[13:45] <ogra_> yeah ... me too (once i get a second review :) )
[13:45] <mvo> zyga-solus: found the ppc?
[13:45] <pedronis> mvo: on master or the simplified PR ?
[13:45] <mvo> zyga-solus: maybe it is not needed, it looks like I can reproduce it with go-6
[13:45] <mvo> pedronis: master currently, trying your branch next
[13:50] <zyga-solus> mvo: yes
[13:50] <zyga-solus> mvo: ok
[13:58] <mvo> pedronis: with your branch it shows a proper error (but still panics on the lock) - its not converging. I will poke more, its good to be able to reproduce it
[13:59]  * zyga-solus breaks for food
[13:59] <zyga-solus> mvo: I'm burning the ppc iso - just in case it is needed
[14:07] <kyrofa> Urgh, forum stealing /
[14:10] <mvo> pedronis: looks like the loop is the problem - runtime with loop 1: 0.3s 2: 0.7s, 3: 1.4s 4: 2.1s 5: 3.2s 6: 4.4s 7: forever. very strange
[14:10]  * mvo digs further
[14:12] <ogra_> sborovkov, so i just tested here ... setting vt.handoff=0 to keep the splash and then later calling "sudo chvt 1" via ssh works for me ... so your UI startup script would have to do that chvt 1 call to take over the console and yoou should be fine (*if* confinement doesnt bloock chvt here)
[14:12] <kyrofa> davidcalle, I need to add a deprecation notice to https://snapcraft.io/docs/deprecation-notices, but have forgotten where that code is hosted. Help?
[14:13] <kyrofa> I thought it was https://github.com/canonical-websites/snapcraft.io
[14:13] <sborovkov> ogra_: ah, so this way until everything is done it will show black screen? or splash? And when my UI starts I just should use chvt then?
[14:13] <ogra_> sborovkov, splash
[14:14] <ogra_> and the chvt makes your UI take ooover the screen
[14:14] <sborovkov> oh ok, cool
[14:14]  * ogra_ wonders whats up with his keyboard and all these duplicated/triplicated chars
[14:15] <sborovkov> first need to figure out why after I applied PR with splash screen my images stopped booting, I merged all other changes to my branch first. It booted. Applied splash screen PR and changed the image - it stops at PI logos above, no output from uboot at all
[14:15] <ogra_> weird, the Pr doesnt change any output settings for uboot
[14:16] <ogra_> you should definitely still get the loading of kernel, initrd and such ... as well as the autoboot countdown
[14:17] <kyrofa> Ah ha! https://github.com/CanonicalLtd/snappy-docs
[14:17] <ogra_> sborovkov, you dont happen to have dtoverlay=vc4-kms-v3d set in your config.txt i hope
[14:17] <ogra_> (if thats the case there is more to do)
[14:18] <sborovkov> ogra_: ah, it boots actually. But does not show splash. My image is not getting in. It went from rapsberries at top straight to my snap
[14:18] <sborovkov> are there any requirements on image used?
[14:18] <sborovkov> and that one in config.txt is disabled
[14:18] <ogra_> sborovkov, do you use dtoverlay=vc4-kms-v3d ? (i.e. GLES)
[14:19] <ogra_> ok
[14:19] <sborovkov> nah
[14:19] <sborovkov> we dont
[14:19] <sborovkov> out qt app is not working with it
[14:19] <sborovkov> not sure on details, but there is a comment where it's commented out
[14:19] <ogra_> right, mir uses it though ...
[14:19] <ogra_> if your Qt app dooesnt use GLES we're fine on that level
[14:20] <sborovkov> I mean it's using egl
[14:20] <ogra_> welll, then you actually need vc4 enabled ... which the dtoverllay above does
[14:21] <sborovkov> no, it does not work with it
[14:21] <ogra_> if you do "lsmod | grep drm" on a booted board, does that return anything ?
[14:22] <sborovkov> one minute I need to boot another image for that, I don't have assertion for local stuff I build
[14:22] <mvo> pedronis: ok, so the issue appears to be that the MockPrerequisitesRetryTimeout is too short, the taskrunner will always try to run a preprequite task next but that will see that there is a core snap task running and will trigger a retry but because the time is too short it always retries the prepreq task and never runs the core link snap task
[14:22] <ogra_> (i wonder how you would use EGL without vc4)
[14:23] <sborovkov> ogra_: also, is the boot image going to be resized? Boot splash is 1080p. But since I connect my display via HDMI->DVI it boots at lower resolution. Can this be the reason splash is not shown on boot?
[14:24] <mup> PR snapd#3879 closed: release: merge release 2.27.6 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3879>
[14:24] <sborovkov> lsmod | grep drm does not find anything
[14:24] <ogra_> hmm, ok
[14:24] <sborovkov> ogra_: unfortunately I have no idea on implementation details. Qt is just using FB on the rpi I think
[14:24] <ogra_> sborovkov, hmm, the splash should adapt to the screen size...
[14:24] <ogra_> right, that should be fine
[14:24] <sborovkov> ok, I am using SRGB 8 bit
[14:24] <sborovkov> image
[14:25] <sborovkov> which should be fine I guess
[14:25] <ogra_> i just wanted t make sure vc4 isnt turned on while in the initrd
[14:25] <ogra_> theoreticallly that should be fine
[14:25] <sborovkov> ok, actually let me try to boot with your vanilla splash screen
[14:26] <ogra_> you should in any case get at least a white screen
[14:26] <ogra_> even if the image would be broken, the bg color should change
[14:26] <pedronis> mvo: ah,  I wondered about that, makes some kind of sense
[14:28] <ogra_> sborovkov, your cmdline.txt has the "splash" keyword set i hope (the splash checks for that)
[14:28] <pedronis> mvo: theorically we could implement something just using immidiate retries and SetBlocked, but it needs quite a bit of state tracking and the checks would be costly
[14:29] <sborovkov> ogra_: yes your patch applied cleanly
[14:29] <ogra_> just to make sure :)
[14:29] <sborovkov> it has vt.handoff=2 quiet splash at the end
[14:30] <ogra_> ok
[14:30] <ogra_> i still wonder why you dont see any uboot messages
[14:31] <mvo> pedronis: yeah, in practise with retry of 30s it should not be a problem, I pushed an update to 3881 and test build that now
[14:32] <sborovkov> ogra_: not sure... stdout=serial, lcd... SO it should show something
[14:32] <ogra_> yeah and the splash PR doesnt touch anything in that area
[14:32] <ogra_> it only chnages bits that happen a lot later in the boot
[14:32] <pedronis> mvo:  we probably don't need the global settle change, I would just do an explicit Settle in that test
[14:33] <pedronis> mvo: we need to combine 3881 and #3883 somehow
[14:33] <mup> PR #3883: overlord/snapstate: cleanup settle and its uses <Created by pedronis> <https://github.com/snapcore/snapd/pull/3883>
[14:33] <mvo> pedronis: yes, makes sense
[14:33] <mvo> pedronis: I can fix that, I can also merge yours into mine
[14:33] <pedronis> that works for me
[14:34] <mvo> pedronis: but first I want to test build to see if my box actually is close enough to the ppc
[14:34]  * mvo prepares an upload
[14:34] <pedronis> fearing the ppa is even much slower ?
[14:34] <pedronis> we could bump it to 100 ms  but check arch ?
[14:34] <pedronis> I mean bump only conditionally
[14:36]  * zyga-solus breaks for a few hrs to work on kids stuff 
[14:44] <mvo> pedronis: merged your branch into mine and resolved the conflicts
[14:47] <pedronis> thanks, let's see how it goes
[14:49] <mup> PR snapd#3883 closed: overlord/snapstate: cleanup settle and its uses <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3883>
[14:49] <pedronis> mvo: I closed mine
[14:50] <mvo> pedronis: ta
[14:52] <mup> PR snapcraft#1537 opened: project_loader: aliases are deprecated <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1537>
[15:07] <pstolowski> api.snapcraft.io has a hiccup?
[15:19] <sborovkov> ogra_: meh, no, issue is not in the image. tried clean build as well just in case. Unlike old behavior where I'd get login page while everything is configured. And then my snap would show up. All I see is raspberries on the top until our snap takes over. No splash screen though :-(
[15:19] <ogra_> sborovkov, even with my gadget snap ?
[15:20] <sborovkov> ogra_: hmm, I am not sure, let me try vanilla snap.
[15:20] <sborovkov> but the only difference from previous described behavior is your PR merged
[15:21] <ogra_> and it works fine if you just revert it ?
[15:22] <ogra_> the PR really only puts an additional file in place and adds an extra load command ... there is nothing it could do to actually make the ooutput before anythiing loads disappear
[15:23] <sborovkov> alright, I am going to revert it and try it again. Also try vanilla snap as well, but tomorrow I guess, will tell you if I succeed
[15:26] <ogra_> i'm around
[15:27] <ogra_> sborovkov, you guys dont happen to come to our rally in new york, do you ?
[15:27] <ogra_> (would perhaps be helpful to work face to face and with the HW in front of us)
[15:42] <cachio> ogra_, hey
[15:43] <cachio> ogra_, I am testing the 2.27.6 and I see it is failing on dragonboard
[15:43] <pedronis> mvo: any news if it's fixing stuff?
[15:43] <cachio> no space left
[15:43] <sborovkov> ogra_: don't think so
[15:43] <cachio> ogra_, It was running on testflinger
[15:44] <ogra_> cachio, resized propely ?
[15:44] <cachio> I'm trying to reproduce it on my dragonboard
[15:45] <sborovkov> ogra_: alright i want to bang my head against the wall. During our image creation something image is mounted to loop0 and loop1. So I was getting the freaking same image for a last hour *facepalm*
[15:45] <ogra_> oh my !
[15:45] <sborovkov> because it did not unmount
[15:45] <ogra_> :)
[15:45] <sborovkov> during one of the builds
[15:48] <cachio> ogra_, which command line do you use to flash your db?
[15:49] <ogra_> cachio, i use the same everywhere ... xzcat /path/to/image| sudo dd of=/dev/sdc bs=32M
[15:49] <ogra_> cachio, after explicitly running "sudo umount /dev/sdc1; sudo umount /dev/sdc2"
[15:50] <ogra_> (my SD reader shows up as sdc obviously)
[15:50] <cachio> ogra_, ok, I'll do the same
[15:50] <cachio> I am umounting always
[15:50] <ogra_> good
[15:56] <cachio> ogra_, /dev/mmcblk1p9  546M  378M  128M  75% /writable
[15:56] <ogra_> sigh
[15:56] <cachio> ogra_, after I flashed it
[15:56] <cachio> ogra_, where are the logs?
[15:57] <ogra_> after the first boot ?
[15:57] <ogra_> (or is that still in your PC)
[15:57] <cachio> ogra_, after the first boot
[15:57] <ogra_> the log is in /run/initramfs
[15:58] <ogra_> and you are 100% sure nothing automounted the SD after you unmounted it ?
[15:58] <ogra_> befor you dd'ed
[15:58] <cachio> yes
[15:58] <cachio> I checked that
[15:58] <ogra_> (smeone said this week that kde always remoounts it apparnetly)
[15:59] <cachio> ogra_, I ran sudo umount
[15:59] <cachio> and then checked that
[15:59] <ogra_> he did as well ...
[15:59]  * ogra_ tries to remember who that was ... 
[16:00] <cachio> ogra_, the weird think is that I ran in test flinger and it failed in 4 different dbs as well
[16:00] <cachio> with the same issue
[16:00] <ogra_> cachio, well, nothing changed in months in the resize code
[16:01] <ogra_> so i'm surprised it doesnt resize
[16:01] <cachio> https://paste.ubuntu.com/25484632/
[16:01]  * ogra_ glares at "open: No such file or directory while opening "
[16:02] <ogra_> but that message is even after it resized already
[16:02] <zyga-solus> re
[16:02] <zyga-solus> back for 40 min, then one more school meeting
[16:02] <zyga-solus> ~fun
[16:05] <zyga-solus> mvo: any luck with that ppc bug?
[16:06] <cachio> ogra_, do you need any other log?
[16:07] <ogra_> cachio, no, and i have absolutely no idea, that code has last changed in april and has not caused issues sice (at least federico never told me) so i'm a bit idea-less
[16:08] <ogra_> (actually even long before april)
[16:08] <cachio> ogra_, are you able to reproduce it?
[16:08] <ogra_> let me try an install but i have never has resize issues since the code landed
[16:08] <ogra_> *had
[16:09] <cachio> ogra_, perhaps the diff is how we are building the image
[16:09] <cachio> ogra_, I am using this script to create the image https://github.com/sergiocazzolato/validator/blob/master/create.sh
[16:10] <cachio> I ran it using CHANNEL=beta
[16:11] <ogra_> yeah, not different to what i use here, though i'm still on the ubuntu-image deb
[16:12] <ogra_> so it might be the snap has changed something that breaks the partition table ... but i wouldnt expect that
[16:12]  * ogra_ flashes todays daily 
[16:13] <ogra_> cachio, oh, dont forget when unmounting, the dragoboard uses sdc8 and 9
[16:15] <ogra_> ok, booting here
[16:17] <cachio> ogra_, yes
[16:18] <mvo> zyga-solus: I think its fixed
[16:19] <ogra_> ogra@localhost:~$ df -h /writable
[16:19] <ogra_> Filesystem      Size  Used Avail Use% Mounted on
[16:19] <ogra_> /dev/mmcblk1p9   57G  384M   54G   1% /writable
[16:19] <ogra_> cachio, ^^^
[16:19] <ogra_> :/
[16:20] <ogra_> so i cant reproduce it here
[16:20] <zyga-solus> mvo: great, I can trash this old junk then :)
[16:20] <cachio> ogra_, which image are you using?
[16:21] <ogra_> cachio, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz
[16:21] <ogra_> (got that locally here)
[16:21] <ogra_> uses edge ... but beyond that shouldnt differ
[16:21] <cachio> ogra_, could you try with to generate the image with the snapd from beta?
[16:24] <mvo> zyga-solus: I will know for sure once 3881 is in
[16:24] <ogra_> cachio, sure, but the initrd in both should be indentical ... (teh initrd is what does the resize)
[16:25] <cachio> ogra_, tx, I am gonna try with the one you used
[16:25]  * ogra_ dd's beta ... 
[16:27] <kyrofa> Hey all, it seems snapctl -h broke
[16:27] <kyrofa> It requires a cookie
[16:29] <kyrofa> Makes it difficult to figure out how to use
[16:29] <ogra_> cachio, http://paste.ubuntu.com/25484910/ this is how it shoudl look like ... (there is an extra message on the tty console about the GPT not defininig the fulll disk size (which is fine), this is copy/paste from serial)
[16:30] <mvo> cachio: how are the tests looking so far? all green?
[16:30] <cachio> ogra_, ok, I'll check with the image that worked for you
[16:30] <cachio> mvo, yes, but strugling with hte dragonboard
[16:30] <cachio> mvo, it is failing on first boot to resize
[16:31]  * zyga-solus managed to install 14.04 on the ppc junk
[16:31] <mvo> cachio: autsch, i remember you had this issue before, right?
[16:31] <cachio> it fails in testflinger for the 4 dbs
[16:31] <cachio> and in my db
[16:31] <ogra_> cachio, oh wow!
[16:31] <ogra_> ogra@localhost:~$ df -h /writable
[16:31] <ogra_> Filesystem      Size  Used Avail Use% Mounted on
[16:31] <ogra_> /dev/mmcblk1p9  546M  378M  128M  75% /writable
[16:31] <cachio> ogra_, well
[16:31] <cachio> ogra_, with beta?
[16:32]  * ogra_ checks if the kernel snap is any different between beta and edge
[16:32] <ogra_> yes
[16:32] <zyga-solus> ogra_: the ancient ppc mac has the same amount of ram as raspi3 today, isn't that silly?
[16:32] <cachio> mvo, well, now ogra_ could reproduce the error
[16:32] <cachio> mvo, the rest is ok
[16:33] <ogra_> cachio, aha ! seems the kernel in beta has an issue
[16:33] <ogra_> there are two different snaps
[16:33] <ogra_> ppisati, sitll around ?
[16:33] <ogra_> cachio, edge is on rev 33
[16:33] <ogra_> beta on 34
[16:34] <cachio> ogra_, well, that's possitive, now we know the reason
[16:34] <ogra_> they have the same version string, so i guess beta and candidate were a rebuild
[16:35] <ogra_> why is stzable so old on the dragonboard btw
[16:35] <ogra_> thats really behind (rev 27)
[16:37] <ogra_> cachio, is it urgent ? then i can re-release 33 into beta
[16:39] <cachio> ogra_, yes
[16:39] <cachio> ogra_, it is a fix that should be fully tested today
[16:40] <cachio> ogra_, to go to candidate
[16:40] <cachio> tomorrow
[16:40] <ogra_> cachio, ok, 33 is in beta and candidate now ... you shoudl be able to rebuild
[16:42] <cachio> ogra_,
[16:42]  * ogra_ does the same 
[16:42] <cachio> nice
[16:42] <cachio> ogra_, tx
[16:43] <ogra_> but looking at the build log of the kernel snap i dont  see anything wrong
[16:43] <ogra_> very weird
[16:45] <cachio> mvo, I'll restart the testing
[16:48] <ogra_> ogra@localhost:~$ df -h /writable
[16:48] <ogra_> Filesystem      Size  Used Avail Use% Mounted on
[16:48] <ogra_> /dev/mmcblk1p9   57G  380M   54G   1% /writable
[16:48] <ogra_> cachio, back to normal here
[16:48] <ogra_> err
[16:48] <ogra_> o not
[16:49] <ogra_> ogra@localhost:~$ snap list
[16:49] <ogra_> No snaps are installed yet. Try "snap install hello-world".
[16:49] <ogra_> crap
[16:49] <cachio> ogra_,  :(
[16:49] <ogra_> the rebuild was actually to fix the broken clock setting
[16:49] <ogra_> so 33 wont work
[16:50]  * ogra_ switches edge to 32 and does an edge build
[16:53] <cachio> ogra_, is it ready?
[16:53] <ogra_> let me test first
[16:53] <cachio> sure
[16:57] <ogra_> sigh
[16:57] <ogra_> ogra@localhost:~$ snap list
[16:57] <ogra_> No snaps are installed yet. Try "snap install hello-world".
[16:57] <ogra_> ogra@localhost:~$
[16:58]  * ogra_ switches edge back to 31 ... 
[16:58] <ogra_> resize was fine btw ... but that doesnt help
[17:01] <cachio> ogra_, :(
[17:01] <ogra_> booting with 31
[17:05] <ogra_> ogra@localhost:~$ snap list
[17:05] <ogra_> No snaps are installed yet. Try "snap install hello-world".
[17:05] <ogra_> :(((
[17:09]  * ogra_ goes to rev 30
[17:15] <ondra> ogra_ sorry did not get to it, but will test that cm3 tomorrow morning
[17:16] <ogra_> ondra, all fine as long as you are aware ... i'm not in a hurry
[17:16] <ondra> ogra_ yeah, it's on my list :)
[17:17]  * Chipaca shakes fist at stuff
[17:17] <Chipaca> anyway, EOD for me
[17:17]  * ogra_ joins Chipaca 
[17:18] <Chipaca> yeah!
[17:18]  * Chipaca shakes some more
[17:19]  * ogra_ hopes this boot will finally work ... i had an appointment 20min ago :(
[17:20] <ogra_> ogra@localhost:~$ snap list
[17:20] <ogra_> No snaps are installed yet. Try "snap install hello-world".
[17:20] <ogra_> ogra@localhost:~$
[17:20] <ogra_> RAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!
[17:21] <cachio> ogra_, the one we used in the previous beta was working
[17:21] <ogra_> cachio, cant be
[17:21] <cachio> ogra_, could we use that one?
[17:21] <ogra_> do you knwo which one that was ?
[17:22] <cachio> no
[17:22] <cachio> I don't
[17:22] <ogra_> i just switched edge to what was in stable (rev 27) and run another test now
[17:22] <cachio> ok
[17:27] <ogra_> ogra@localhost:~$ df -h /writable/
[17:27] <ogra_> Filesystem      Size  Used Avail Use% Mounted on
[17:27] <ogra_> /dev/mmcblk1p9   57G  384M   54G   1% /writable
[17:27] <ogra_> ogra@localhost:~$ snap list
[17:27] <ogra_> Name                Version        Rev   Developer  Notes
[17:27] <ogra_> core                16-2.28~rc2    2853  canonical  core
[17:27] <ogra_> dragonboard         16.04-0.18     32    canonical  gadget
[17:27] <ogra_> dragonboard-kernel  4.4.0-1063.68  27    canonical  kernel
[17:27] <ogra_> ogra@localhost:~$
[17:28] <ogra_> PHEW
[17:28] <ogra_> cachio, ok, i released rev 27 to all channels
[17:32] <cachio> ogra_, great
[17:32] <cachio> tx
[17:32] <ogra_> cachio, oh, crap and i think i know what the issue is, zyga-solus added a massive amount of quoting to all initrd scripts, i bet something now spits out a wrong number
[17:33] <ogra_> there looking at the diff orf the initrd scripts (specifically resize) there is a gazillion pointless doublequotes now
[17:34] <diddledan> if in doubt, quote
[17:34] <diddledan> quote, quote and then quote again
[17:34] <ogra_> -device_size="$(($(cat $syspath/size)/2))"
[17:34] <ogra_> -sum_size="$(($(grep $(basename $device)[a-z0-9] /proc/partitions|\
[17:34] <ogra_> +device_size="$(($(cat "$syspath"/size)/2))"
[17:34] <ogra_> +sum_size="$(($(grep "$(basename "$device")[a-z0-9]" /proc/partitions|\
[17:34] <ogra_>      tr -s ' '|cut -d' ' -f4|tr '\n' '+'|sed 's/+$//')))"
[17:34] <diddledan> when you think you've quoted enough quote some more :-p
[17:34] <ogra_> i bet that grep doesnt return anymore what it did before
[17:35] <diddledan> is there a unit testing framework anywhere in the world for shell scripts? (I feel there should be at least one attempt)
[17:36] <ogra_> yes, that is what got us the breakage
[17:36] <ogra_> apt install shellcheck
[17:36] <ogra_> ;)
[17:36] <ogra_> and it will make aou add quotes in a lot of pointless places
[17:37] <diddledan> quote all the things!
[17:37] <diddledan> "
[17:37] <diddledan> as long as your quotes aren't imbalanced, you'll be fine"
[17:38] <diddledan> don't forget to quote your quotes or else you'll get randomness"
[17:39] <diddledan> the one I really hate with shell scripts is that quotes in variables are interpreted when they're included in another line
[17:39] <diddledan> thing*
[17:39] <diddledan> variables aren't treated really like other languages, they're expanded BEFORE the command is parsed
[17:40] <diddledan> FOO="something with 'quotes'" do_something_with $FOO; echo "probably didn't do quite what you expected, did it?!"
[17:41] <diddledan> maybe we should kill bash :-p
[17:41] <diddledan> or kill -9 bash
[18:37] <SXX> Hello everyone.
[18:37] <kyrofa> Hey there SXX
[18:37] <SXX> I looking for some advice. I want snap-packaged application to use assets from /usr/share/ inside snap as it's usually do on main system.
[18:38] <SXX> https://gist.github.com/ArseniyShestakov/6814ddf6085eb1a798281e31d8d30737
[18:39] <SXX> Assets I need are found inside /snap/vcmi/x3/usr/share/vcmi.
[18:39] <SXX> Though I feel that app while running via snap trying to read /usr/local/share of the main system which obviously prevented by apparmor
[18:40] <SXX> Do I need to specify some special CMake prefix while building for snap?
[18:42] <sborovkov> ogra_: alright, nice, at least I got some progress. Seems like I get no output about services that are starting. Just uboot messages showing up until my snap takes over.
[19:15] <SXX> Should I somehow use $SNAP prefix in my app code?
[19:47] <ParkerR> Installed Discord via the Snap package (from the Software Center) and get this when trying to run Discord http://ix.io/zFu Any ideas? (17.10 Artful)
[19:51] <ParkerR> snapd   2.27.5+17.10
[19:59] <mup> PR snapd#3884 opened: store: simplify api url config <Created by atomatt> <https://github.com/snapcore/snapd/pull/3884>
[20:04] <zyga-solus> jdstrand: hey
[20:04] <zyga-solus> jdstrand: not sure if you did but a kind request to look at the child profile for snap-update-ns that I wrote
[21:05] <kyrofa> SXX, sorry for the delay, I was in a meeting
[21:05] <mwhudson> morning
[21:05] <kyrofa> Morning mwhudson!
[21:06] <kyrofa> SXX, yeah, you need to somehow use $SNAP there, since snaps aren't chroots
[21:06] <SXX> kyrofa: i already find out snap actually able to rewrite paths for assets in /usr/share
[21:06] <kyrofa> SXX, how you do that depends on the application. Apache has a config file that allows use of environment variables. Others have cli flags for redirecting it
[21:06] <kyrofa> SXX, or you can use the preload part, is that what you're talking about?
[21:07] <SXX> I still have a problem that our applications need to be able execute each other.
[21:07] <SXX> E.g we have 3 apps: launcher, game client and server
[21:11] <kyrofa> Sure
[21:11] <kyrofa> What is the issue there?
[21:12] <SXX> They use absolute path and desktop-launcher doesn't override that.
[21:12] <SXX> I mean desktop-launch.
[21:13] <nacc> SXX: you control your app, though -- so don't use absolute paths?
[21:13] <SXX> True, I just looking what best practice is.
[21:14] <nacc> SXX: I think hardcoded non-snap-aware paths are not best practice for snaps :)
[21:15] <SXX> Yes, but it's code that works for Linux in general and I suppose there no better way to handle it other than hardcoding.
[21:16] <SXX> nacc: so I suppose the right solution would be to getenv SNAP and prepend it to our internal paths?
[21:17] <nacc> SXX: so, e.g., in my snap, which is classic, i have application wrapper scripts that set PATH appropriately for applications to be found (that are packaged by my snap)
[21:17] <nacc> SXX: all of my applications are actually just these wrapper scripts that setup the env correctly and then exec the actual application
[21:20] <SXX> nacc: thanks!
[21:21] <nacc> SXX: that's admittedly just my way of doing it -- but I think that's also roughly what snapcraft does for classic snaps using plugins (I'm using the dump one currently)
[21:23] <SXX> Am I getting it right that with some newer snapd if I have app like "vcmi.vcmiclient" it's will automatically get alias of vcmiclient?
[21:24] <SXX> Or it's will always require user interaction to set alias?
[21:25] <nacc> SXX: i think vcmi.vmci will become vmci
[21:25] <SXX> yeah that I know
[21:26] <SXX> I read on forums before it's was possible to manually add aliases, but it didn't work anymore.
[21:27] <nacc> SXX: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18?source_topic_id=905
[21:28] <nacc> SXX: so i think it's now  store thing
[21:29] <kyrofa> SXX, yeah, best practice is to just write code that is flexible. Not all linux distros follow the same rules for where things go, either. When you find yourself writing an absolute path, add a cli flag or config file property for it, and you can _default_ to the absolute path
[21:30] <SXX> kyrofa: Do you know how long does it take for reserved names to be reviewed / granted?
[21:31] <kyrofa> SXX, I'm afraid not, that's in the store team's domain. But if you find it taking an inordinate amount of time, create a forum post in the store category and ask about it
[21:32] <SXX> kyrofa: no problem, I just sent request so not big deal. I just wonder about that since I not sure if I should wait until it's granted or register temporary name for testing.
[21:32] <kyrofa> SXX, I do know that it's a manual process. If you're blocked on it, register it as something else. Heck, the store folks might even be able to rename the temporary one you use
[21:33] <kyrofa> SXX so I say go ahead and register <what-i-want>-sxx or whatever and use that for now
[21:33] <SXX> Thanks!
[21:33] <SXX> kyrofa: for the paths we expose way to set custom binary / lib / data paths in our CMake. So other distributions can really use what they want.
[21:34] <kyrofa> SXX, ah, indeed. Snaps work best when the application is relocatable
[21:34] <SXX> Though we still need absolute paths by default since that way it's easier to make sure development builds not conflict with installed system-wide.
[21:35] <SXX> kyrofa: wait, do you mean it's make sense to just make it single-dir windows-like install for snap?
[21:35] <kyrofa> SXX, hmm... I don't quite understand what you mean
[21:36] <SXX> kyrofa, I added monolithic install support since I initially wanted to try ship it with Steam Runtime.
[21:37] <SXX> kyrofa, my attempt is failed since runtime is horrible piece of tech, but I can still just dump game in single directory so it's use relative paths. It's what I use for my development builds so I can run several different builds side-by-side.
[21:40] <kyrofa> Yeah that sounds promising
[21:44] <SXX> kyrofa: thanks for your time! I'll still need to solve problem with boost::interprocess somehow, but I have some better understanding what I need to do.
[21:44] <zyga-solus> hmm
[21:44] <zyga-solus> zyga@mini:~$ snap version
[21:44] <zyga-solus> snap    unknown
[21:44] <zyga-solus> snapd   unknown
[21:44] <zyga-solus> series  16
[21:44] <zyga-solus> ubuntu  16.04
[21:44] <zyga-solus> kernel  4.4.0-93-powerpc-smp
[21:44] <zyga-solus> we're not setting version on the powerpc build?
[21:44] <kyrofa> SXX of course, any time
[21:44] <zyga-solus> this is vanilla snapd on powerpc
[21:44] <kyrofa> zyga-solus, where on earth did you get a ppc machine? :P
[21:45] <zyga-solus> kyrofa: it was in my attic
[21:45] <kyrofa> Mac?
[21:45] <zyga-solus> kyrofa: I can also say our xenial install media is broken, the trusty one is ok though
[21:45] <zyga-solus> kyrofa: yep, my mac mini G4
[21:45] <zyga-solus> aaaancient
[21:45] <kyrofa> Wow, crazy
[21:46] <jdstrand> zyga-solus: I left voluminous comments in the PR yesterday
[21:46] <jdstrand> zyga-solus: and hi :)
[21:47] <zyga-solus> jdstrand: excellent, thank you
[21:48] <zyga-solus> jdstrand: I'll check it out tomorrow and iterate
[21:48] <jdstrand> cool
[21:48] <jdstrand> zyga-solus: note, tomorrow is a half day for me (working my morning)
[21:48] <zyga-solus> aha, noted
[21:57] <zyga-solus> jdstrand: all the comments are (as always) very detailed and sensible, thank you, I will iterate on this tomorrow morning, hopefully by the time you're up it would be something you could re-review
[22:00] <zyga-solus> hmm
[22:00] <zyga-solus> zyga@mini:~$ sudo snap install core
[22:00] <zyga-solus> error: snap "core" not found
[22:00] <zyga-solus> and mvo worries about ppc test suite
[22:00] <zyga-solus> it's just totally broken
[22:01] <zyga-solus> kyrofa: do we build core for ppc?
[22:02] <kyrofa> zyga-solus, ubuntu-core is
[22:02] <kyrofa> zyga-solus, not sure about core
[22:02] <zyga-solus> why ubuntu-core and not core?
[22:02] <zyga-solus> ah
[22:02] <zyga-solus> I see
[22:02] <zyga-solus> I think it's rather terribly broken
[22:02] <zyga-solus> I wonder how anything passes
[22:03] <kyrofa> zyga-solus, you're sure you're on ppc64el and not ppc64le or whatever other magical combinations there are?
[22:04] <zyga-solus> I'm on ppc
[22:04] <zyga-solus> that's the 32bit powerpc running in big-endian mode
[22:04] <zyga-solus> and there's snapd preinstalled (xenial)
[22:04]  * zyga-solus builds 2.27.6-1 for debian
[22:05] <kyrofa> Just because snapd is preinstalled doesn't mean it's an arch the store supports
[22:05] <zyga-solus> mwhudson: hey, in case you are around, I'll dput this soon
[22:05] <zyga-solus> kyrofa: my point is that mvo looses grey hair over ppc (precisely that arch)
[22:05] <mwhudson> zyga-solus: cool
[22:05] <zyga-solus> kyrofa: and the elephant in the room is that it's totally broken
[22:05] <kyrofa> mvo is LOSING hair now?
[22:05] <mwhudson> zyga-solus: the ubuntu / debian architecture name is 'powerpc' :)
[22:05] <kyrofa> Isn't he like 30 or something?
[22:06] <zyga-solus> mvo?
[22:06] <zyga-solus> heh
[22:06] <jdstrand> zyga-solus: I can't guarantee I'll be able to get to it tomorrow-- my mornings are typically dominated by reacting to forum, email, irc, etc, but it will certainly remain at the top of the queue
[22:06]  * zyga-solus always writes that word wrng
[22:06] <zyga-solus> jdstrand: ack
[22:06] <zyga-solus> thank you!
[22:07] <zyga-solus> so, to complete the "hardware from hell" I need the big iron
[22:08] <jdstrand> np
[22:09] <mwhudson> zyga-solus: doesn't look like ubuntu-core or core exist for powerpc
[22:09] <zyga-solus> mwhudson: yeah
[22:09] <zyga-solus> mwhudson: *oops*
[22:10] <zyga-solus> not that I care but what does snapd do on that arch there
[22:10] <mwhudson> so i guess i agree that building the snapd package there is a bit pointless :)
[22:10] <zyga-solus> then
[22:10] <zyga-solus> if we must support it then ogra_ should arrange a build
[22:10] <zyga-solus> and if not we should stop building the package and remove it from the distro and the isos
[22:10] <mwhudson> i wonder if lp can even build snaps for powerpc
[22:10] <zyga-solus> I'm curious how we got the "unknown" versions though
[22:10] <zyga-solus> mwhudson: not without core for sure
[22:11] <zyga-solus> mwhudson: but I bet it can since it can build packages
[22:11] <mwhudson> i guess we can build for s390x which similarly only has devirt builders
[22:12] <zyga-solus> ogra_: still up?
[22:13] <zyga-solus> mwhudson: are you on ubuntu now?
[22:13] <mwhudson> zyga-solus: i am on ubuntu always
[22:14] <zyga-solus> mwhudson: can you check if 2.27.5 has version?
[22:14] <zyga-solus> as in snap --version
[22:14] <zyga-solus> my ubuntu laptop is closed now so just more convenient to ask
[22:14] <kyrofa> zyga-solus, it does
[22:14] <nacc> zyga-solus: i'm on 17.10
[22:15] <nacc> http://paste.ubuntu.com/25486607/
[22:15] <zyga-solus> I wonder how 2.27.5 has such a weird version
[22:15] <mwhudson> zyga-solus: ah haha i have a test build i made for that pr installed :)
[22:15] <zyga-solus> thanks nacc
[22:15] <nacc> zyga-solus: np (taht's the output from `snap --version`)
[22:15] <zyga-solus> and not that I see 2.27.5 in apt-cache policy, not -1 inherited from debian in some way
[22:16] <zyga-solus> mwhudson: FYI the 2.27.6 merge was clean, I just copied the changelog from xenial
[22:16] <zyga-solus> mwhudson: sbuilding now, will dput if green
[22:16] <mwhudson> zyga-solus: yeah fair enough
[22:16] <mwhudson> zyga-solus: oh yeah, changelog
[22:16] <mwhudson> zyga-solus: i think i've been bringing the ubuntu changelog entries over into the debian one
[22:16] <mwhudson> like the reverse of what happens when ubuntu has a delta from debian
[22:17] <mwhudson> dpkg-mergechangelogs dtrt i think
[22:17] <zyga-solus> hmmm, I never tried that
[22:17] <mwhudson> but it's not very important
[22:17] <zyga-solus> will it break where debian version is non-native and ubuntu is native?
[22:17] <zyga-solus> so every other version will flip?
[22:18] <mwhudson> no, that will make something (dpkg-source? dch?) complain at you but otherwise it's fine
[22:18] <mwhudson> native/non-native is mostly controlled by debian/source/format anyway :)
[22:18] <mwhudson> also the ubuntu package really shouldn't be native but ehhh
[22:18] <zyga-solus> yes I agree strongly
[22:18] <zyga-solus> it would help with silly releases that just fix debian (xenial really) packaging
[22:19]  * zyga-solus install sbuild on ppc xenial 
[22:19] <zyga-solus> let's rebuild this weird snapd
[22:19] <zyga-solus> and see what we get
[22:22] <zyga-solus> mwhudson: build passed, pushing to alioth and then dput
[22:23] <zyga-solus> done
[22:24] <mwhudson> zyga-solus: \o/