=== ssweeny_ is now known as ssweeny [00:51] Issue snapcraft#1466 closed: scriptlets erroring behavior [00:51] PR snapcraft#1537 closed: project_loader: aliases are deprecated [01:18] PR snapcraft#1526 closed: catkin plugin: don't assume catkin is in underlay [02:03] PR snapcraft#1525 closed: typo: replace occured with occurred === chihchun_afk is now known as chihchun === JoshStrobl is now known as JoshStrobl|AFK [06:31] PR core#57 opened: fix typo in 500-create-xdg-wrapper.binary [07:08] PR snapd#3904 opened: tests: test the real "xdg-open" from the core snap [07:52] PR snapd#3905 opened: tests: add new test that checks that the compat snapd-xdg-open works [08:13] PR core#58 opened: use `snapctl internal configure-core` to configure core [08:15] meh, we are at 26 open PRs again, code reviews for the rescue please! [08:15] to the rescue even [08:17] ouch [08:17] 3880 is probably an easy win [08:18] how's #3777 ? [08:18] PR #3777: snap-repair: implement basic `snap-repair list` (with --verbose) [08:22] Chipaca: I think I need to address some bits from samuele first === pachulo_ is now known as pachulo [08:23] pstolowski: what's up with #3810 ? [08:23] PR #3810: interfaces/hooks: PlugData and SlotData wrappers [08:24] Chipaca, working on it [08:24] will push soon [08:29] pstolowski: thank you for the tweaks to #3852 [08:29] PR #3852: hooks: commands for controlling own services from snapctl [08:30] Chipaca, no, thank YOU! [08:30] zyga-ubuntu: #3860 had spread failures that looked like network issues; i kicked it off again [08:31] PR #3860: packaging: don't include any macros in comments [08:31] Chipaca: thank you [08:31] mwhudson: conflicts in #3872 [08:31] PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) [08:32] Chipaca: hooray [08:33] i wonder if you can use non-ascii chars in env var names [08:33] Chipaca: prooobably not want to ;) [08:34] EINVAL name is NULL, points to a string of length 0, or contains an '=' character. [08:34] nothing about having bittiness [08:34] zyga-ubuntu: agreed :-) [08:53] PR snapd#3906 opened: many: use snapcore/snapd/i18n instead of i18n/dumb [08:56] is there a best practice way of running snapd in an isolated env (docker/vm/lxd)? [08:56] Chipaca: #3890 is an easy one OTOH it seems that always fails spread tests for unrelated reasons :/ [08:56] PR #3890: overlord: use overlord.Mock in more tests, make sure we check the outcome of Settle [08:57] pedronis: i just reviewed that one [08:57] pedronis: :-D [08:57] it'll probably conflict my PR though [08:57] * Chipaca thinks the unverse is unfair every time that older PRs get conflicts from newer ones [08:59] Chipaca: universe was never meant to be fair but maybe that's just fair to discover the hard way :) [08:59] zyga-ubuntu: knowing it is unfair, and being reminded it's unfair, are completely separate [09:00] Chipaca: well, my branch might never land if spread tests continues like that, notice it changes only unit test so apart from that it should affect tests at all [09:00] *not affect [09:12] PR snapd#3884 closed: store: simplify api url config [09:15] PR snapd#3902 closed: tests: try to fix staging tests [09:17] PR snapd#3897 closed: systemd: do not run auto-import and repair services on classic [09:22] * Chipaca finishes a review pass [09:22] * Chipaca thinks he deserves a gold star [09:22] * zyga-ubuntu hands Chipaca a gold star [09:22] (insert mario chime) [09:23] zyga-ubuntu: thank you :-D [09:23] zyga-ubuntu: also, finish your review of #3835 plz [09:23] PR #3835: packaging: bring down the delta between 14.04 and 16.04 [09:28] zyga-ubuntu: what is the magic again to clean a mount namespace for a snap? context is https://forum.snapcraft.io/t/xdg-open-regression/2085/5 and I suspect that for him the fix does not work because his core snap is still the older version(?) [09:44] mvo: I replied on the forum [09:44] mvo: sorry, I saw the forum notification, no notification for irssi here [09:45] mvo: are you on gnome shell now? [09:47] zyga-ubuntu: not yet but I plan to move my workstation "soon" [09:47] zyga-ubuntu: ish :) [09:47] I cannot stand the idiotic alt-tab [09:48] when I have two apps and dozens of windows open it's useless [09:48] browser + terminal, on various workspaces [09:48] alt-tab flies me across the workspaces [09:48] sigh [09:49] zyga-ubuntu, you want alt+^ [09:49] my Mock branch failed again, something somewhere doesn't want it in [09:49] ogra_: I think gnome shell designers want that [09:50] well, yes [09:50] ogra_: the problem with alt~ is that I now need to differentiate apps and windows [09:50] and I much more prefer not to [09:50] yep, same here [09:50] and in fact, I suspect users may not even grok the difference much [09:50] "new is shiny" eh :/ [09:50] i was ranting against that since unity implemented it years ago [09:51] (unity has a way to switch back to the ld behaviour though ... i dont think gnome-shhell does) [09:51] *old [09:55] zyga-ubuntu: silly question about the discard-ns, should we run htis automatically, i.e. why did this user not get the updated xdg-open without manual work? [09:56] mvo: this is https://bugs.launchpad.net/snapd/+bug/1667479 [09:56] Bug #1667479: mount namespace is not discarded when core snap changes revision [09:56] mvo: I should update that bug [09:56] mvo: I'll add a comment shortly [10:03] mvo: updated [10:04] hah! systemd's "job for snapd.service canceled" error in real life! [10:04] https://launchpadlibrarian.net/336695206/DpkgTerminalLog.txt [10:04] (from bug#1716641) [10:04] (from bug 1716641) [10:04] Bug #1716641: package snapd 2.26.10 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1

[10:04] zyga-ubuntu: aha, thank you [10:05] * mvo hugs Chipaca for all his reviews [10:06] * Chipaca hugs mvo back [10:08] Chipaca: i wonder what does that mean in systemd-speak [10:08] stop after start but before started? [10:08] zyga-ubuntu: a daemon-reload hit during a 'stop' [10:08] aha [10:09] zyga-ubuntu: this might be because of our roll-our-own systemd overrides [10:09] zyga-ubuntu: but it might also be just dh_systemd [10:15] ondra, https://forum.snapcraft.io/t/sources-of-snap-find-macaddr0/2089 ... why would /run/macaddr0 not be created when the dargonboard runs from eMMC ? (sounds really weird) [10:18] ogra_ yeah sounds very strange [10:26] ondra, can you check this n a board that runs from eMMC ? [10:27] (i dont want to taint my board here and keep it in original state) [10:30] ogra_ just testing some other bits on dragoboard so I can have a look here [10:30] thanks [10:30] i wonder if he uses his own kenel snap or so [10:30] ogra_ yeah,something looks strange === ShalokShalom_ is now known as ShalokShalom [10:33] * zyga-ubuntu looks outside at the shimmering rain [10:38] Chipaca: can rain shimmer? is that a good way to say this? [10:39] it surely shimmers if there is enough oil in the drops :P [10:40] zyga-ubuntu: well, there's a song about it [10:40] zyga-ubuntu: but it's from final fantasy [10:40] mvo: hi, do you know if/why there was a rebuild of 2.27.6? [10:42] joc: yes, see https://forum.snapcraft.io/t/xdg-open-regression/2085 [10:43] mvo: ah, thank you [10:46] (shouldnt really matter for non-desktop ) [10:52] Chipaca: I mean it, I'm inclined to learn the rain terminology [10:52] and UK is the best place to learn [10:52] mvo: do I undestand correctly that we only need a core rebuild and we don't need a new snapd [10:53] mvo: regarding the xdg-open regression [10:53] zyga-ubuntu: correct, the core change has already happend [10:54] zyga-ubuntu: well, i've never heard rain described as shimmering, and google also thinks it's a proper name and not just an adjective [10:54] Chipaca: how would you describe a rain that falls steadily, with no wind [10:55] Chipaca: with rather large but not huge droplets [10:55] zyga-ubuntu: steady rain? [10:56] also ps just because i live in the uk doesn't make me rainman [10:56] :-D [10:58] Chipaca: quick sanity check about i18n coming from the client. we would need some sort of context/thread-local-storage per request. so quite a change compared to how we do i18n right now (and how gettext traditionally does it). or do you have an idea about something smart we could do? [10:59] mvo: we're needing a context for other things, but yes [10:59] it's not a minor change === chihchun is now known as chihchun_afk [11:00] Chipaca: it looks like a gigant change right now but maybe I'm missing something. every place that calls i18n.G() would have to have access to this context [11:01] mvo: in my minid at least it's part of the same refactor of daemon to get rid of gorilla [11:01] yes, major [11:01] 'have a daemon2 package and transition things' major [11:02] Chipaca: but it would be more, no? i mean, we would have to pass the context even into e.g. snapstate.Install() and similar? as those generate i18n.G() messages? [11:02] Chipaca: "rainman" sounds like a nice song title [11:04] Chipaca: don't get me wrong, not asking how it could be done, just if I have a thinko somewhere [11:05] mvo: everything needs a context [11:05] Chipaca: ok, thanks [11:10] I tried to install the edge core snap and got the following error: - Setup snap "core" (2894) security profiles (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": fork/exec /usr/lib/snapd/snap-update-ns: no such file or directory) [11:15] cmd.go:140: exe doesn't have snap mount dir prefix: "/usr/lib/snapd/snapd" vs "/snap" and handlers.go:208: Reported install problem for "core" as 95e9cec8-97a9-11e7-9958-fa163e192766 OOPSID [11:15] are the only things I found from journalctl [11:17] itsfemme[m]: hey, can you tell me which distribution are you on [11:18] subgraph os, which is a derivative of debian stretch [11:18] PR snapd#3907 opened: cmd/snapctl: allow snapctl -h without a context (regression fix) [11:20] itsfemme[m]: does subgraph os rebuild packages from source? [11:20] itsfemme[m]: personally, would you mind contriuting to http://github.com/zyga/os-release-zoo [11:20] itsfemme[m]: can you show me the source package of snapd from subgraph os? it looks curious [11:21] Chipaca: a (slightly) crazy idea https://github.com/mvo5/snappy/commit/029f38be38ff9c634cb21d10e30ff6dba094ca34 [11:21] Not all packages, it uses the debian repo with its own repo for kernels and additional apps [11:21] * mvo lunches [11:21] itsfemme[m]: is snapd rebuild or reused? [11:22] reused [11:22] itsfemme[m]: which version do you have in the package? [11:23] this is the repo https://devrepo.subgraph.com/subgraph/ [11:24] * itsfemme[m] sent a long message: itsfemme[m]_2017-09-12_11:23:59.txt [11:25] I have PaX (from grsecurity) enabled but I didn't see anything from that in journalctl [11:27] interesting [11:27] so snapd restarted into 2.27.6 [11:27] but snap (the client) did not [11:27] what does snap restarting means? [11:27] pedronis: I mean re-exec [11:28] itsfemme[m]: for now, can you please open a forum topic [11:28] that's a super confusing way to call that :) [11:28] itsfemme[m]: this will be eaier to track [11:28] pedronis: sorry, I didn't mean that [11:28] itsfemme[m]: I guess someone should try subgraph and see what's going on [11:28] * ogra_ wouldnt be surprised if gsecurity patches had influence on seccomp, apparmor and cgroups behaviour [11:29] yes, that's possible [11:29] I mean I use all those things daily [11:29] (sadly its is closed source so you wont easily find out :P ) [11:29] itsfemme[m]: what's the kernel version you are on? [11:29] it's not closed source you can go to the repo and get the kernel source [11:30] 4.9.33-subgraph [11:31] thank you [11:32] But as I said, I use apparmor, namespaces and seccomp to sandbox my daily applications so I know those work [11:36] itsfemme[m]: thank you for the report, I'm pulling the release to see how it looks like [11:37] itsfemme[m]: I would appreciate if you could open a thread on the snapcraft forum [11:37] I will also check out debian stable and sid to see if this affects the parent [11:39] itsfemme[m], i thought the current source is only available against money (only a subset is public) ? [11:41] * ogra_ only knows what he read in linus rants about GPL violations actually ... ICBW for sure :) [11:43] it would definitely be good to make sure it all works though (regardless of licenses, politics or rants :) )... [11:46] mvo: I don't think we can use gls for this; there is AFAIK no connection between a request and the goroutine the handlers run on [11:46] * Chipaca ~> lunch [11:49] mvo: I'm not sure I want to look what gls does [11:50] mvo: what's the inpulse to work on those? gnome software? [11:50] mvo: also: Accept-Language is the header to use :-) [11:50] pedronis: the i18n pr up right now [11:51] pedronis: snapd#3906 [11:51] PR #3906: many: use snapcore/snapd/i18n instead of i18n/dumb [11:51] * Chipaca ~> really lunch [11:51] Chipaca: sounds like a huge distraction to me right now [11:52] even worse if instead of that we make a hackish exercise [11:54] Chipaca: given we have async stuff and global bits it's all a bit unclear how this should be properly designed [11:55] Chipaca: there's a lot going in snapd that is not tied to a request, or only indirectly, or could be potentially visited from different locales (think snap changes) [11:59] PR snapd#3890 closed: overlord: use overlord.Mock in more tests, make sure we check the outcome of Settle [12:25] pedronis: yeah, not saying we should do any of this gls stuff, just thinking aloud as it seems to be a bit difficult right now to get a handle on this per-connection i18n [12:26] mvo: I'd vote for explicit, context-based i18n since traditional approach to implicit (thread local state) is harder in go [12:26] Found unused ./vendor packages: [12:26] vu github.com/mvo5/net/bpf [12:27] zyga-ubuntu: yes, update your vendor dir, thats fine [12:27] mvo: as I said I feart apart the tech expect, there are interesting conceptual questions if we start having per request i18n [12:27] it's probably weeks of work to get that right [12:27] pedronis: yes [12:28] zyga-ubuntu: re context-based i18n> seems like everyone agrees with this [12:28] anyway, I won't persuse this, it was just a short explore round [12:28] mvo: its seems we would need to do i18n very close to where we build the response [12:29] not all over the place as we do now [12:29] PR snapcraft#1523 closed: node plugin: record installed node packages in manifest [12:29] pedronis: yes [12:29] pedronis: or pass the context deeply everywhere which seems insane-ish [12:29] that doesn't help [12:29] some strings have not direct request [12:29] pedronis: right, which is tricky once you have format strings in the i18n, e.g. something in snapstate: fmt.Errorf(i18n.G("cannot install %q snap"), snapName) [12:30] like all the stuff in changes [12:30] pedronis: yes, I agree [12:30] and tasks [12:30] mvo: we would need complex ways to pass strings around [12:30] as I said [12:30] weeks of work [12:30] pedronis: yes [12:30] pedronis: we are in agreement :) [12:30] I wonder if we can start with some common problems and come up with a cheaper solution for that [12:30] so _some_ errors could get context-sensitive i18n [12:30] we need to mark them but translate them late [12:30] but not all [12:31] N_(...) [12:31] and keep the info of what needs translating [12:31] etc etc [12:31] pedronis: and also store interpolation [12:31] yes [12:31] lots of fun [12:31] seems a bit the wrong time to dive into that [12:31] too much other stuff [12:31] +1 [12:31] yes [12:32] I agree [12:32] speaking of other stuff> arm/armhf/powerpc fail to build in master right now :/ [12:32] unless someone external goes to explore and then works on this exclusively without breaking everything for a while [12:32] mvo: fun [12:32] mvo: wut? [12:32] "fun" [12:33] mvo: let's raise a glass to unpopular architectures [12:33] at least I could merge my Mock branch, I think I had to retry 5+ times (or more, I really don't remember) [12:33] lol "unpopular" [12:33] ikey: heh [12:33] ikey: good to see you [12:33] ta, you too [12:33] it's all relative [12:33] ikey: I've installed solus and I loved the experience :) [12:33] ikey: I played with the build tools a little [12:33] oh im so sorry [12:33] xD [12:34] ikey: but I could not find the snapd package (I cloned everything using the helper make) [12:34] cachio: hey, can I get commit access to spread-cron please :) [12:34] ikey: I wanted to help with co-maintenance [12:34] oh you legend [12:34] ikey: and to update snapd to 2.27.6 [12:34] https://dev.solus-project.com/source/snapd/ [12:34] everything is nested on our dev portal [12:35] the "main" file is https://dev.solus-project.com/source/snapd/browse/master/package.yml [12:35] its basically bash script decorated with sexy yaml [12:35] omg zygaception [12:35] ikey: should this have been cloned by make pull? [12:36] uhm so the "make pull" thing relies on the old common/packages notion [12:36] you can clearly see the pisi influence :) [12:36] ah [12:36] :) [12:36] no you can't Son_Goku [12:36] some stale docs I ran into then [12:36] pisi is XML. [12:36] what is pisi [12:36] the changelog is still in pisi format :) [12:36] eopkg is forked from pisi [12:36] Son_Goku, what? [12:36] what changelog..? [12:36] zyga-ubuntu, pisi is what eopkg is forked from [12:36] err, pspec [12:36] pspec_x86_64.xml [12:36] thats automatically generated for introspection [12:37] its not actually used by the build [12:37] ypkg emits the eopkg itself [12:37] ah, so you're not writing it :) [12:37] in the old days we used to rely on the machine files [12:37] oh god no [12:37] haha [12:37] ypkg was to get us away from that old crap [12:37] * Son_Goku remembers rpmxmlbuild [12:37] and make packaging sane [12:37] ikey: got it [12:37] zyga-ubuntu, so yeah we infra-changed and some things broke ™ [12:37] ikey, there was a point where rpm spec files could be written as XML :P [12:38] Son_Goku, intentionally?! [12:38] ikey: how do I send patches to that packaging? [12:38] yep, back in the early rpm 4.0.x ~ 4.3.x days [12:38] zyga-ubuntu, you're gonna want to install "arcanist" [12:38] jbj implemented it to make people back off about wanting a schema for rpm spec [12:38] https://solus-project.com/articles/packaging/submitting-a-package/en/ [12:39] see the arcanist links down below [12:39] basically you mangle and alter your clone of our repo [12:39] get your commit in order [12:39] and send it with "arc diff" (once arc is setup) [12:39] then it creates a new patch against snapd in our infra [12:39] ikey: probably the next go around, there will be an rpmyamlbuild :) [12:39] Son_Goku, yeah yaml is "so hot right now" :P [12:39] mvo, let me check [12:39] ikey: I'll try [12:40] you gotta have a dev site account fwiw [12:40] * zyga-ubuntu needs to clean his desk [12:40] you can log in with github anyway [12:40] ikey: how do I get that? [12:40] ikey: someone is already working on making rpm output yaml in addition to xml [12:40] ah [12:40] I did log in [12:40] saves farting about [12:40] ok so do the "Setting up Arcanist bit" [12:40] er. misquoting but ya [12:40] basically it sets up arcanist globally for the solus instance [12:41] fwiw if you have a proper checkout with $dir/common $dir/snapd, etc, you can do "make" to actually build the package [12:41] i assume you've got solbuild setup at this point? [12:41] (because it wouldn't be solus without a shedload of badly named tools.) [12:42] ikey: I do [12:42] suhweet [12:42] you can `sudo solbuild update -p unstable-x86_64` to keep the base image updated fwiw [12:42] makes subsequent builds faster [12:43] (if you install `solbuild-config-unstable` you can skip the -p parameter nonsense) [12:43] always amazes me that solus users have never questioned why i opted to include the architecture field in everything for an x86_64 distro [12:44] mvo, seriously, kill powerpc ... we never supported it, you cant even build snaps for it so it is totally pointless to have it [12:45] there is so much time and energy wasted on it ... [12:46] ikey: hmm, what did I do wrong? zyga@lambert ~/packaging/snapd $ make [12:46] make build [12:46] make[1]: Entering directory '/home/zyga/packaging/snapd' [12:46] sudo solbuild build package.yml -p unstable-x86_64; [12:46] Profile is not installed: Did you forget to init? [12:46] make[1]: Leaving directory '/home/zyga/packaging/snapd' [12:46] make abireport [12:46] make[1]: Entering directory '/home/zyga/packaging/snapd' [12:46] abireport -p abi_ -D `dirname package.yml` scan-packages `dirname package.yml` [12:46] Error locating packages: No packages in directory . [12:46] make[1]: *** [../Makefile.common:15: abireport] Error 1 [12:46] mvo, I think niemeyer can give you permissions [12:46] make[1]: Leaving directory '/home/zyga/packaging/snapd' [12:46] make: *** [../Makefile.common:12: complete] Error 2 [12:46] oh, darn, sorry, hexchat doesn't auto-pastebin [12:47] cachio: ok, if you could merge my PR on spread-cron, that would be great [12:48] pedronis: does http://paste.ubuntu.com/25520782/ ring any bell(s)? its the failure on arm/arm64 [12:48] PR snapd#3860 closed: packaging: don't include any macros in comments [12:48] mvo, done [12:48] cachio: \o/ [12:48]