=== chihchun_afk is now known as chihchun
mupBug #1743301 opened: cannot install apps using snap on Korora <Snappy:New> <https://launchpad.net/bugs/1743301>06:16
mborzeckimvo: morning08:04
mborzeckimvo: something for snap-advise https://bugs.launchpad.net/snapd/+bug/174267708:04
mupBug #1742677: snap run should error nicely when snap isn't installed <snapd:New> <https://launchpad.net/bugs/1742677>08:04
kalikianagood morning08:07
mvomborzecki: thanks, checking08:08
mvokalikiana: good morning08:08
mvomborzecki: and good morning to you!08:08
mborzeckikalikiana: pstolowski: morning08:12
zygamvo: good morning08:12
zygamvo: I have a question to you as a apt maintainer,08:13
zygamvo: when a hdd is corrupted and dpkg database is partially blown away, is it sensible to try to reinstall some packages08:13
zygamvo: or should I just backup home and reinstall the whole thing08:13
mvozyga: well, thats a tough one :) most of the time liberal use of "apt install --reinstall $stuff" makes things work again08:17
mborzeckizyga: hey08:17
mvozyga: *but* the trouble with corruption is that you never know what is affected, so reinstalling packages is fine but your user data might be corrupted as well08:18
mvozyga: if there is no/little user data or if you can easily restore this in isolation the reinstall of packages is worth a shot08:18
mvoand good morning pstolowski08:18
zygaI tried a small reinstall but apt dpkg complained about some packages have empty list of files,08:23
zygaI'll do full reinstall :/08:23
mvozyga: well, empty list of files should not be a hard error08:26
mvozyga: can you pastebin the error ?08:26
mvozyga: *if* you want to resovle this tihs way08:26
zygadpkg: unrecoverable fatal error, aborting08:26
mvozyga: there were some more before that I'm sure08:27
zyga(then localized), list of files in package "libc6-dbg:amd64" contains empty file name08:27
seb128hey there08:27
seb128is bug #1742687 likely a regression in snapd?08:27
mupBug #1742687: Launching URLs in snapped applications no longer works in 18.04 <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1742687>08:27
seb128the title might be misleading, he's using 2.30 which is not in other ubuntu series08:27
zygaseb128: perhaps, I think the url opening moved to snapctl (but I may be mistaken)08:28
seb128zyga, could somebody familiar with that part of the codebase check if there is an issue?08:29
mborzecki09:29:05 up 12:42,  7 users,  load average: 14.75, 13.00, 11.22 :/ building snapd yocto image on x22008:29
mvozyga: you could try "dpkg --purge libc6-dbg" but probably not worth it08:30
zygaseb128: yes, for sure08:30
zygamvo: that doesn't work08:30
zygasame error08:30
mvozyga: hm, mv /var/lib/dpkg/info/libc6-dbg:amd64.list /tmp/backup and ty again? (double check that I got the path of the .list file right please)08:31
mvozyga: and then re-try the --reinstall ?08:31
zygamvo: that file doesn't exist at all08:32
zygaah, no sorry08:32
mvozyga: no "/var/lib/dpkg/info/libc6-dbg\:amd64.list " ?08:32
zygashell has issues with : in filenames :/08:32
zygamvo: I'll ski08:32
zygamvo: inside I see a DBUS XML profile08:32
mvozyga: haha08:32
zygamvo: my disk is a messed up soup08:32
mvozyga: there you go08:33
zygamvo: I'm making a bootable usb now08:33
mvozyga: well, you could try to repair this one08:33
mvozyga: of course if that is all over the place> FAIL08:33
zygamvo: fsck printed a huge list of changes08:33
zygamvo: I think that's not a happy disk08:33
mborzeckizyga: smart did't raise a warning or anything?08:35
mvozyga: good luck - do you happen to have an 18.04 vm? or sebs bug?08:35
zygamborzecki: not a single one08:35
zygamborzecki: I'm running small test08:35
zygamvo: I don't have 18.04 vm yet, no08:35
mborzeckizyga: at least tell us the band of the disk, and why it ahppens to be a seagate? :)08:37
zygamborzecki: wd08:37
zygamborzecki: they all eventually fail :/08:37
zygait's a 1TB blue08:37
zyga832 start/stop cycles08:37
zyga3 months and 1 day of uptime total08:38
* mborzecki goes to check smart log on his nas disks08:38
* zyga tarballs home and DDs 17.10 installer to usb08:40
zygamvo: do you think I could reinstall 18.04 instead08:41
zygaI wonder if that could help with the bug in a meaningful way08:41
zygaseb128: http://cdimage.ubuntu.com/releases/17.10.1/release/ - is the 17.10.1 release due to meltdown?08:42
mvozyga: sure, can't hurt to install 18.0408:43
seb128zyga, no08:43
mvozyga: 17.10.1 might also be because of the bios issue with lenovo08:43
seb128what mvo said08:43
zygaah, I see08:43
zygaI'll do 18.0408:43
zygalet's see what's coming08:43
=== jdstrand_ is now known as jdstrand
zygahey there Chipaca09:35
Chipacazyga: o/!09:35
Chipacazyga: how's things?09:35
mborzeckiwould appreciate if someone could take a look at https://github.com/snapcore/snapd/pull/4480 the only controversial thing may be stopping and cleaning up *.services files for services that came from snaps, eg. lxd09:37
mupPR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>09:37
Chipacamborzecki: is this for stopping and removing those things on purge?09:38
mborzeckiChipaca: yes09:38
zygaChipaca: so so :) doing a reinstall now, hoping that my HDD isn't totally crazy :)09:39
zygaChipaca: just picking up some PRs to review while I wait09:39
Chipacamborzecki: I don't think that's controversial; that's what the deb package was supposed to do in its postrm09:40
mborzeckizyga: FYI, today's supposed to be blue https://en.wikipedia.org/wiki/Blue_Monday_%28date%29 maybe your hdd just had a breakdown (sorry for dad joke)09:40
mvoChipaca: s/supposed to do/doing/ - no ?09:42
Chipacamvo: I assume it is also what it does, if that's your question :-)09:42
mborzeckiChipaca: deb postrm is still is still a separate script under packaging/, don't have that must experience with debs as to move it to preprm and invoke snap-mgmt --purge09:42
Chipacamvo: I'd have to look at the current postrm to say for sure :-D09:42
pedronisChipaca: yes, it does that09:42
mvoChipaca: aha, thats fine. I was wondering if there is a bug in the postrm09:42
Chipacamvo: there's an expression in Spanish, 'no meto las manos en el fuego por nadie' :-)09:43
mvoChipaca: there is an expression in german: "Ich verstehe kein Spanisch"09:43
mvoChipaca: ;) anyway, thanks!09:43
pedronismborzecki: it does that also for mount units btw09:44
pedronis(the deb postrm)09:44
Chipacamvo: there's an expression in French, "ils sont fous ces allemands"09:44
mvomborzecki: fwiw, unifying postrm and snap-mgmt is tricky because in the dpkg world you can do a "dpkg --remove" and everything from the regular deb is gone just the "post{inst,rm}" etc is left. so any purge would have to be "sourced" (copied) into the postrm09:45
mvomborzecki: I mean, any code sharing would have to be done via some magic that copies things into postrm09:46
mborzeckimvo: sound ugly09:46
mvoChipaca: heh :) I think I know enough french for this one ;)09:46
mvomborzecki: yeah, britle and terrible09:46
pedronisit could be done in the Makefile / rules09:47
* mvo hugs Chipaca and apologizes for trolling him on a monday morning09:48
mvopedronis: yeah, I think its doable, we just need to be careful and it will be a little bit ugly09:48
mvo(of course it is, SMOP and all that :)09:49
zygamborzecki: haha09:50
zygamborzecki: nice ;)09:50
mupPR snapd#4486 opened: snap: make `snap run not-install` output advise for not installed commands <Created by mvo5> <https://github.com/snapcore/snapd/pull/4486>09:50
zygamborzecki: just curl mgmg.snapcraft.io09:52
zygamborzecki: just curl mgmg.snapcraft.io | sudo sh09:52
zygamborzecki: ;-)09:52
zygamborzecki: no need to worry about postrm09:52
zygaman, my typing sucks on this laptop09:52
mborzeckihmm ok, seems like there's a bug in #448009:53
mupPR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>09:53
mvomborzecki: is bug #1741474 something to set to "fix commited" ?09:53
mupBug #1741474: Migrating from snapd to snapd-git results in 'broken' snaps <snapd:Triaged> <https://launchpad.net/bugs/1741474>09:53
mborzeckimvo: yeah, think it's ok to switch the status09:55
mvomborzecki: thank you! and thanks for the fix09:56
mborzeckimvo: oh, it's not me, it's philm from manjaro who updated the packages09:57
mborzeckianyways, they are in sync with ones from AUR now09:57
mvomborzecki: ta09:59
zygamvo: can 4424 land?10:10
mvozyga: let me look at this one more, maybe we don't need to honor this limit if pam is already doing the right thing internally10:11
zygapstolowski: is landing new interfaces problematic for you?10:12
zygapstolowski: can I land 4365? (do a qucik review maybe)10:12
* zyga requests review for 432910:13
zyga4329 is from nov 2017 and fixes a bug10:13
pstolowskizyga, by all means we should land new interfaces, i'll update my branch if needed10:13
pstolowskizyga, let's just avoid any unnecessary refactorings around interfaces at this point and it will be fine10:14
pstolowskiso yes please land 436510:15
zygapstolowski: kk10:16
pedroniszyga: yes, I looked at the new package I'm using, what's the procedure for new deps ?10:17
zygapedronis: I don't think we have any really, I just wanted to double check someone from the team read that package10:17
zygajamesh: hey10:17
jameshzyga: hi10:17
pedroniszyga: yes, I read the package, it doesn't do networking, has good coverage10:18
pedronisseems to do the job10:18
zygajamesh: so, how are we doing for per-user mount ns; with my mind busy on my box being broken I forgot the detailed agreements from last week10:18
pedronisthere are much more complicated packages for this, but seems overkill for these case10:18
zygajamesh: can I help you some way?10:18
pedronis*this case10:19
zygapedronis: that sounds good to me10:19
mborzeckizyga: pedronis: pushed a fix to #4480 can you take a look?10:21
mupPR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>10:21
zygamborzecki: aha10:21
mupPR snapd#4365 closed: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4365>10:21
zygamborzecki: commentd10:23
mborzeckizyga: thanks, the reload doesn't happen in postrm either, i'd say it's up to the caller to do a systemctl daemon-reload10:26
pedronisChipaca: zyga: I see for boltdb we added something like to the spec BuildRequires: golang(github.com/boltdb/bolt)  but I see for other/older package there are other bits as well by grepping about Requires and Provides10:27
Chipacapedronis: oh?10:27
pedronisfor example I see:  BuildRequires: golang(github.com/ojii/gettext.go)  Requires:      golang(github.com/ojii/gettext.go)  Provides:      bundled(golang(github.com/ojii/gettext.go))10:28
pedronisthe bundled bit I'm not sure what is about10:28
pedronisChipaca:  ^10:29
Chipacaah, me neither10:29
ChipacaI added the BuildRequires because without it it wouldn't work :-)10:29
ChipacaI don't know the significance of the rest10:30
pedronisChipaca: well I didn't even add that, because fedora is off :/10:30
jameshzyga: just testing out the change for making /media shared again. I think that was the only thing we decided was needed before merging it10:30
Chipacapedronis: you can still run it by hand :-D10:31
pedronisChipaca: and see it fail for other reasons anyway?10:31
Chipacapedronis: running a test by hand has high chances of working10:31
pedronisI mean, we turned off fedora for reasons10:31
mborzeckizyga: #4329, the code there is called with cgroup frozen?10:31
mupPR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>10:31
Chipacapedronis: running all the tests has high chances of failing10:32
Chipacapedronis: ¯\_(ツ)_/¯10:32
pedronisChipaca: anyway, should we cargo cult the rest for boltdb?10:32
Chipacapedronis: I'd rather ask somebody that knows10:32
pedronisI suppose all deps should be the same10:32
Chipacathat's a good supposition, and we can go with it if neil doesn't show today10:33
zygajamesh: cool10:33
zygajamesh: I don't know if *just* making it shared will be enough tho10:34
pedronisChipaca: could you look at #448110:34
mupPR #4481: image: let consume snapcraft export-login files from tooling <Created by pedronis> <https://github.com/snapcore/snapd/pull/4481>10:34
zygajamesh: otherwise the code that makes /media shared would be much much easier to write originally10:34
Chipacapedronis: on it10:34
pedronisthank you10:34
zygajamesh: do a practical test please (ideally patch the /media spread test to also have a dummy per-user mount profile to see)10:34
zygamborzecki: no10:35
zygamborzecki: just with the per-ns lock held10:36
zygajamesh: when you make / rslave it is a one-way ticket, you cannot make it shared again (AFAIR), subsequent share will just make it a master for other slaves10:36
zygajamesh: I might be wrong but I think this is why the /media setup that we have now ended up so convoluted10:37
zygajamesh: (I stash away /media to recover it later)10:37
pedronisChipaca: I think Gustavo wants us to look into converging more login stuff between snapd and snapcraft and also we really need to teach download to use the creds inside snapd when it make sense10:38
pedronisChipaca: that's why I'm holding off adding command line options10:39
Chipacapedronis: i agree we want that, but we also want snap download to work in the absence of a running snapd (and we want to specify the arch anyway) i think10:39
Chipacanothing urgent and i didn't mean it needed doing right now10:40
pedronisthe arch yes10:40
* zyga is grumpy because the good green tea has run out10:40
Chipacasnapshots also run in the absence of snapd :-D10:40
pedronisjust explaining why I didn't add command line options so far10:40
zygaand the store carrying it is on the other side of the city10:40
Chipacazyga: send your snappy-enabled drones10:40
zygaChipaca: arduino with a sign "will write model assertions for tea"10:41
Chipacazyga: hey now, no unlawfully competing with ogra_10:42
zygaChipaca: I think ogra would write beer, that's a different market segment10:42
zygawe can coexist peacefully10:42
Chipacaaugh! i should've gone to physio10:46
jameshzyga: I think you're right.  I thought I had something working, but it doesn't seem to be propagating.10:51
jameshzyga: I do wonder if anything using the desktop interface would ever be affected by this though10:52
zygajamesh: I think it's not the point though, you can just rslave all top-level elements or rslave / and bind /media over from another place if you keep one handy10:52
jameshe.g. display security in current Ubuntu doesn't let root connect to the user's display10:52
jameshzyga: so I need to track down what all the top level mounts are then10:53
zygajamesh: no, no need10:53
zygajamesh: just opendir and iterate over top level elements10:53
zygaand skip media10:54
jameshzyga: but the top level directories aren't all going to be mount points10:55
zyganot a problem10:55
zygaactually, you are right10:55
zygathat is a problem10:55
zygarshare doesn't handle non-mount entries10:55
zygabummer :/10:55
jameshzyga: as I mentioned on the hangout, I think the long term solution is to construct separate mount namespaces for each user from scratch, working out some way to get the right parts shared10:56
niemeyerpedronis: We've had so many issues with the differences in download that by now I'm seriously wondering if doing the opposite of what we do now wouldn't be a better approach. That is,10:59
zygajamesh: I honesntly don't even see how that can work10:59
zygajamesh: it's far more complex than what we have now10:59
zygajamesh: I'll dismiss that without any poc code10:59
niemeyer..., make download go through snapd by default, and only fallback if snapd is not available, in which case we warn that we're doing it locally and that differences may emerge11:00
ogra_zyga, correct .... and also ... i dont touch systems without MMU ;)11:01
zygajamesh: (even back of the envelope pseudocode)11:01
=== chihchun is now known as chihchun_afk
jameshzyga: well, one option is to have snap-confine save one copy of the mount namespace before calling snap-update-ns, and reuse that if it is found11:05
mborzeckizyga: went through #4329, left some comments11:06
mupPR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>11:06
jameshzyga: then the per-user mount namespace would be cloned off that, and all mounts (both global and per-user) would be performed on top of that11:06
zygamborzecki: thank you11:06
zygamborzecki: looking now11:09
zygajamesh: maybe it's easier than I assume by I really would like to see some pseudocode written (e.g. forum thread)11:09
zygajamesh: I suspect the devil is in the details here, it's very delicate piece of code11:09
pedronisniemeyer: I know we discussed this, we still haven't really prioritized the changes involved, in practice we need both path as you said, it's a matter of what is the default11:12
jameshzyga: anyway.  As the code currently stands, it won't do anything until an interface is modified to use it.  And the desktop interface isn't really appropriate for processes running as root.  So is this a big enough deal to block the initial landing?11:13
zygajamesh: I'd like to see how we could fix that, give me one day to come up with a plan and if not let's land it11:14
mvohey cachio ! welcome back11:15
cachiomvo, hey, thanks11:15
zygacachio: wow, hey11:15
cachiomvo, glad to be here again11:15
cachiozyga, hey, long time11:16
zygacachio: I hope you had great time :)11:17
cachiozyga, yes it was, thanks11:17
cachiomvo, any plan for beta validation?11:20
mvocachio: yeah, probably tomorrow, we had a bit of a setback because of spectre/meldown, no edge builds for a couple of days11:20
cachiomvo, ok11:21
zygacachio: welcome back, the internet has melted and is chased by some spectres11:22
cachiozyga, hehehe, yes11:23
cjwatsonAre you still blocked on the remaining ppa:snappy-dev/ubuntu/edge builds?11:23
cachiozyga, no way to scape from that11:24
ChipacaE: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list11:24
cachiozyga, is there any change in snapd for deal with those issues?11:25
Chipacaquoth the raven, WAT11:25
mvocjwatson: well, sort of, for a new release we would need a core for all our supported arches. i understand the other arches are still disabled until we have new kernels fixes there too(?)11:25
zygacachio: no, just extra delays around11:26
zygacachio: probably new toolchains soon11:27
zygacachio: maybe a rebuild required, not sure11:27
cachiozyga, ok11:27
cjwatsonmvo: What's the process for getting code into this PPA?  I see it goes via some snapd-vendor git repository - can you tell me how code gets there?11:27
mvocjwatson: its a sync from github.com/snapcore/snapd11:28
cjwatsonmvo: (we can whitelist builds, but we have to treat the builders as if they have no effective virtualisation at the moment)11:28
mupPR snapd#4487 opened: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>11:28
cjwatsonmvo: hmm, any reason it's not a Launchpad git-to-git import?  Is it gated in some way?11:28
mvocjwatson: and we only allow code in that we reviewed and that passed our test suite (and CLA)11:28
mvocjwatson: there is one complication - we do sync in the "vendor" tree into this git repo. i.e. all our vendored dependencies. nothing gets updated that we don't explicitly update via vendor/vendor.json but there is code that we did not control in there so it probably does not qualify as "ok" in this day-and-age11:30
mvocjwatson: (this is why the git tree is called snapd-vendor, i.e. snapd+vendor-code)11:30
cjwatsonah, ok11:30
cjwatsonmvo: does your process for updating vendor/vendor.json at least involve eyeballing the upstream diff?11:31
zyga(uncomfortable moment)11:31
mvocjwatson: yes, however we have no strict policy around this and have been not careful about this in the past. on the plus (or minus) side, we only update rarely11:32
mvocjwatson: anyway, I understand the current situation, I'm ok with waiting for more kernel/isolation fixes11:33
ogra_cjwatson, the nplan build in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial would also be needed for the next core (at least on armhf)11:34
mvocjwatson: obviously it depends on how long it will take if fixes are weeks away we need to consider what to do11:34
ogra_would be nice if that could get an exception11:35
cjwatsonmvo,ogra_: I think at least these current ones are OK.  Scheduled11:45
mvocjwatson: thank you!11:46
* kalikiana going for lunch in ~1011:50
=== ogra_ is now known as ogra
mupPR snapd#4488 opened: snap: make `snap find --section` show all sections <Created by mvo5> <https://github.com/snapcore/snapd/pull/4488>12:03
mborzeckiis tehre a way to tell if --argument was passed in command line?12:06
zygamborzecki: hmm?12:07
ograzyga, did you notice https://forum.snapcraft.io/t/how-to-get-snapd-to-work-with-external-mounts/3481 ? (that guy seems to slowly become grumpy)12:08
ogra(and the subject is mis-leading ... its about the debian 9 kernel and apparmor)12:09
zygayeah, I see12:10
* pstolowski lunch12:10
mborzeckizyga: i want to have something like this: `snap find --section`, i.e. have the parser allow `--section` without value even though it's defined as string12:12
zygamborzecki: I don't know, there may be a way to do that with go-flags (optional argument)12:13
* zyga coffee12:14
zygatime to reinstall next, backup done12:14
mborzeckicame up with some workaround: https://paste.ubuntu.com/26391469/ this is for https://bugs.launchpad.net/snapd/+bug/174296012:22
mupBug #1742960: snap find --section does not list sections <snapd:In Progress> <https://launchpad.net/bugs/1742960>12:22
mborzeckihaha, see that mvo  has opened a PR already :)12:23
* zyga keeps fingers crossed that bionic reinstall will work for this week and that hdd is not totally busted12:28
zygaespecially that smart was OK12:28
zyganot sure what caused this12:28
zygaat least I will have a fresh filesystem there12:28
zygakernel crashed on reboot12:39
zygathat's a good sign12:39
zygait's still doing something12:40
zygajust spews ...12:41
zygathis disk is gone12:49
zygajust broke after install12:49
zygaSMART my ass12:49
* zyga is grumpy now12:49
* Chipaca hugs zyga 12:52
mborzeckisalvage what you can, drill it through, throw it in the dumpster :/12:52
zygamborzecki: I have a full backup, so that's not a problem12:52
Chipacai was going to suggest opening it and peeing on it, but i decided against it12:52
zygamborzecki: and it "works" a little, just fails writes often12:53
mborzeckievery now and then12:53
zygaChipaca: I need some of that alien pee12:53
Chipacazyga: that's your call12:53
mborzeckizyga: so now you can play with running linux on the chip that's inside the drive12:55
mborzeckizyga: http://spritesmods.com/?art=hddhack&page=112:55
zygamborzecki: or buy those discounted fireworks12:56
pachuloHi! I have a doubt regarding the "base" system used to build the snaps in launchpad: when will it be changed to 18.04 (from 16.04)? Is there any established date?13:41
Chipacapachulo: not yet no13:41
pachuloChipaca: is there any rough guess? like: before the end of 2018?13:45
Chipacapachulo: I'd expect it to be done before 18.1013:45
Chipacapachulo: but after 18.0413:45
Chipacapachulo: JamieBennett might be in a better position to offer a firmer answer, if one exists13:47
pstolowskiniemeyer, one of my PRs that needs your re-review: https://github.com/snapcore/snapd/pull/444013:48
mupPR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>13:48
mborzeckiniemeyer: https://github.com/snapcore/snapd/pull/4487 and https://github.com/snapcore/snapd/pull/447613:50
mupPR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>13:50
mupPR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476>13:50
mupPR snapd#4481 closed: image: let consume snapcraft export-login files from tooling <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4481>13:59
mvozyga: fwiw, I can reproduce the dbus error on bionic, it does not make sense to me our rule looks good13:59
zygamvo: interesting, I can "try" on my current broken system14:00
mvopedronis: re 4481> we used to use https://packages.debian.org/sid/golang-github-mvo5-goconfigparser-dev in the past for ini parsing, this is packaged for debian and afaict also for fedora14:00
mvozyga: do you have any hints how to debug this?14:01
pachulook, thanks Chipaca14:02
zygamvo: hold on, let me reproduce locally14:03
Chipacaare there go build flags that can be used to build something only on 14.04?14:03
mvozyga: hm,hm, apparmor_parser -r /path/to/apparmor/profile seems to fix it :(14:03
zygaouch :/14:03
zygathat's not good14:03
zygawhich profile did you reload, that of the app, right?14:03
mvozyga: correct14:03
mvozyga: its in a VM so copy/paste is a bit harder but essentially "apparmor_parser -r /var/lib/snapd/appamror/profiles/snap.gimp.gimp"14:04
pedronismvo: we can switch I suppose, the package I picked has a even simpler interface (but more code)14:05
mvopedronis: I am sitting on the fence, less code we need to maintain is good so I'm hesitant advocating for moving back to this code. otoh it will probably make life for the packagers easier14:07
pedronismvo: I need to go have my daily walk, I let you think a bit more14:08
mvopedronis: I can to a POV port if you want (lets talk after your walk)14:08
mborzeckihm we don't seem to clean up udev rules in postrm and snap-mgmt14:09
zygamvo: family calls for lunch now, I'll be back; the apparmor relead feels bad, I will see if I can reproduce (on clean bionic install)14:09
mborzeckioff to get the kids14:13
mvozyga: sure, lets talk in a bit14:14
mvozyga: so, it seems to be related to "peer=(label=unconfined)" when I rmeove this and reload things work. when I add it back things work still14:16
om26erpopey: Hey! mind taking a look at https://github.com/snapcrafters/android-studio/pull/13 ?14:19
mupPR snapcrafters/android-studio#13: Export missing library paths <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/13>14:19
om26erThe change only affects the emulator.14:20
zygamvo: hmmm14:26
zygamvo: that's odd14:26
mvozyga: yes14:26
zygamvo: but the peer is an unconifned snap userd, right?14:26
mvozyga: I assume so - also its strange that I can change/add back and things keep working14:27
mvozyga: how can I find out if it is unconfined?14:27
zygamvo: add that "peer" constraint?14:27
zygamvo: and reload?14:27
zygaor not14:27
mvozyga: thats what I did: first remove the peer constrain, reload -> works14:28
mvozyga: then re-add the exact same constrain as before, reload -> works14:28
zygawhich snap did you use for testing?14:28
mvozyga: gimp14:30
mvozyga: and reboot (with peer=(unconfined)) that worked before the reboot now fails again it seems.14:30
zygaand reboot the OS?14:30
mvozyga: now I just rebooted the vm14:31
zygamvo: reproduced, I didn't change anything though, just installed gimp and attempted to open the developer website14:35
mvozyga: yeah, that fails for me as well14:35
mvozyga: to make it work I had to remove the peer=un constrain14:36
zygahmm, offtopic, installing snaps from gnome software shows the progress as stufk at 99% (after it completes in reality)14:37
zygamvo: so14:40
zygawithout touching the profiles or rebooting14:40
zygaI ran "snap userd" from the shell14:41
zygaand that made it work14:41
zygaso this seems reproducible: activation doesn't work but after it is activated (in any way) it works correctly14:44
zygamvo: activation from either running snap userd manually or activating via d-feet14:44
zygamvo: I think we want to look at how that activation happens14:44
zygamvo: perhaps (somehow, no idea) when activation is processed by apparmor is goes to a confined helper14:44
zygamvo: (maybe that's the new thing in 18.04)14:44
zygamvo: that just transitions to our service14:45
zygamvo: note that the mechanism is just a speculation at this point14:45
* Chipaca -> physio14:48
jdstrandpeer=(unconfined) is not correct syntax14:49
* jdstrand looks14:49
mvozyga: aha, nice14:50
mvozyga: thanks, that explains why it works for me14:50
mvozyga: thanks for figuring this out14:50
mvozyga: will you update the bugreport or shall I?14:50
jdstrandpeer=(label=unconfined)  is correct and what is in the desktop interface14:50
zygamvo: I'm still digging14:50
zygamvo: yes, gladly14:50
zygajdstrand: it doesn't work for activation (apparently)14:50
zygajdstrand: I'm trying to understand how that happens in bionic14:51
zygajdstrand: it works once activated14:51
zygajdstrand: just tested on pristine install14:51
jdstrandzyga: it should work14:51
jdstranduserd is unconfined. dbus daemon may have a bug14:52
jdstrandon non-bionic, is userd already running?14:52
jdstrandie, check if activation is working everywhere14:52
* jdstrand tries on artful14:53
zygajdstrand: I dind't check on pre-bionic yet14:53
zygajdstrand: on bionic I get an apparmor denial14:53
jdstrandzyga: can you paste it?14:53
jdstrandwhat is the binary in ps that I can check foruserd?14:54
jdstrands/userd/ userd/14:54
pedronismvo: I'm back14:54
zygajdstrand: it's "snap userd"14:54
zygajdstrand: one sec, separate box14:54
jdstrandzyga: activation wrks on artful. browser opened just fine14:55
zyga-bionicsty 15 15:34:45 kaedwen dbus-daemon[1242]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/io/snapcraft/Launcher" interface="io.snapcraft.Launcher" member="OpenURL" mask="send" name="io.snapcraft.Launcher" pid=5773 label="snap.gimp.gimp"14:55
zygajdstrand: activation works on bionc if the requester is unconfined14:56
zygajdstrand: and doesn't work with this activation if the requester is confined (I used gimp, same as mvo above)14:56
jdstrandhuh, there is no peer label14:56
jdstrandis that the complete line?14:57
* jdstrand used gimp snap on artful14:57
zygajdstrand: yes14:57
zygajdstrand: something must have changed in bionic14:58
jdstrandzyga: hard to say if that is a libapparmor bug or a dbus daemon issue14:58
jdstrandbut dbus-daemon is not logging the peer_label, so that seems possibly to lean towards dbus-daemon14:59
zygaI'll update the bug with more details and look at how that works14:59
jdstrandzyga: what is the bug number?14:59
zygais that filtering done in userspace by dbus or in kernel space on the socket?14:59
zygajdstrand: my thought exactly, one sec14:59
jdstrandzyga: the kernel mediates access to the unix socket. dbus-daemon mediates the messages and signals14:59
zygajdstrand: is dbusd using libapparmor?15:00
jdstrandzyga: yes15:00
mupBug #1742687: Launching URLs in snapped applications no longer works in 18.04 <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1742687>15:00
jdstrandzyga: for dbus policy, think of the kernel as the database of rules that dbus-daemon can ask if an access is allowed or denied15:01
jdstrandzyga: it does that via libapparmor15:01
zygaI see15:01
zygaI'll have look, thankyou15:02
jdstrandzyga: then dbus-daemon allows/blocks the access15:02
zygajdstrand: btw, I know you are sprinting but could you look at this apparmor profile change: 24 lines of diff , https://github.com/snapcore/snapd/pull/4472/files15:08
mupPR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>15:08
zygacachio: FYI: 2018-01-15 13:03:14 Cannot allocate linode:ubuntu-16.04-32: cannot perform Linode request: Post https://api.linode.com: net/http: TLS handshake timeout15:09
zygacachio: 2018-01-15 13:03:14 Aborted tasks: 116515:09
cachiozyga, ups15:09
cachiozyga, which PR?15:10
zygaI'll restart15:10
zygamaybe just a fluke15:10
cachiozyga, when you have time could you please take a look to #447215:11
mupPR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>15:11
cachiozyga, #430715:12
mupPR #4307: tests: fix "job canceled" issue and improve cleanup for snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4307>15:12
zygacachio: no https://github.com/snapcore/snapd/pull/447215:18
mupPR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>15:18
zygamvo: there's a new patch for apparmor in bionic version of dbus15:21
zygaI'll check that out15:21
zygaand it talks about the connection security credentials15:21
zygaie. exactly what broke15:21
popeydiddledan: https://dashboard.snapcraft.io/snaps/opentyrian/ needs some screenshots :)15:23
mvozyga: cool, thanks for investigating - do you have  link?15:23
zygamvo: for the patch?15:24
zygamvo: it's in the bionic source package, I don't have a link15:24
mvozyga: ok, what is the name of the patch? I get the package15:24
zygamvo: the idea is that ubuntu can use one of two ways to get security context15:24
zygathe old way (apaprmor label)15:24
zygaor the new way (generic dbus container via a mediator that introduces a new socket to dbus)15:25
zygathere's pently of logging there, I just want to see it somehow15:25
mvozyga: aha, ok15:25
zygamvo: the dbus-tests package has dbus that has verbose debugging activate15:27
zygamvo: I think I don't need to build another copy, just make that active15:27
* zyga tries15:27
zygaI can cp a library over and my desktop explodes15:31
zygainteresting :)15:31
popeydiddledan: also, micropolis15:32
diddledandang, you mean I need to start playing some games?! oh the horror!15:33
popeydiddledan: i have taken some if you want them, I'll put them in dropbox15:33
diddledanyou da king of screenies15:34
mvozyga: *cough* mv is your friend15:34
zygamvo: I used cp because I didn't want to remove a file belonging to the package15:35
zygabut anyway, I'm looking for the logs15:35
zygahmm, where is the systemd unit that describes the session bus?15:43
zygadbus deamon on session bus15:43
ograin Xorg it used to be part of the Xsession startup15:44
ogranot sure where it moved in wayland15:44
zygaI think I'm on xorg still actually15:45
ograwell, dig in /etc/X11/Xsession.d/15:45
seb128zyga, what are you trying to figure out?15:45
seb128zyga, DBUS_SESSION_BUS_ADDRESS env variable?15:45
ograseb128, how the session dbus is started15:45
zygaseb128: how to inject DBUS_VERBOSE=1 at the right spot15:46
zygaseb128: I want to enable dbus_verbose calls15:46
diddledanpopey: done15:47
diddledanaccidentally added the tyrian ones to micropolis for a second.15:47
seb128zyga, you need to rebuild dbus for that I think15:48
seb128"       DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus was15:49
seb128       compiled with verbose mode enabled. This is not recommended in15:49
seb128       production builds due to performance impact"15:49
ograhow developer friendly :P15:49
diddledanwow, opentyrian is popular: 2,992 total downloads15:49
zygaseb128: yes I thought the same but I replaced my bianries with those from dbus-tests package15:49
zygaseb128: it contains a second build with that option set15:50
zygaseb128: I think I just need to get the environment right now15:50
seb128zyga, what the dbus-manapage recommends to do is15:50
seb128 DBUS_VERBOSE=1 dbus-daemon --session --print-address15:50
seb128then set  DBUS_SESSION_BUS_ADDRESS=<returned value> <yourprogram>15:51
zygaok, let's try15:51
ograseb128, but will that replace the already running dbus ?15:51
seb128that creates another bus15:51
seb128but if you set the env it just makes your prog uses the new one15:51
ograah, indeed15:51
seb128that might be good enough to debug the snapd issue15:52
ograyeah, zyga will have to restart snapd wth the var set though15:52
zygayes, trying now15:52
diddledanyeesh, gimp: 80,279 total downloads15:52
zygaogra: hmmm, that's curious15:52
zygaI just need that in snap run gim15:52
zyganot in snapd proper15:52
ograwell, you want your userd to be connected to that bus15:53
ogranot sure if thats coming from snapd or from something else15:53
zygaogra: userd is spawned by the session15:53
zygathat's where the bug is15:53
ogra(snapd-xdg-open was so much easier :P )15:53
ograzyga, right15:53
ograso you need the var in the userd startup script and need to restart userd15:54
diddledanis this the 18.04 url problem you're working on?15:54
zygaoh yeah15:54
zygathe glory of logging15:54
zygaall the way up to 1115:54
seb128zyga, my usual hack for those type of situation otherwise "sudo mv binary binary.real" and make "binary" a shell script that export the env and call binary.real :p15:54
zygathank you seb12815:54
seb128yw :)15:54
zygaogra: it's all temporary until that new IPC takes over ;)15:54
ograkdbus :P15:54
zygano, that newer one15:55
zygaremote var something15:55
seb128zyga, don't forget to make the script +x if you do that15:55
Pharaoh_Atemmvo: so it seems that Debian is the weird one for the GCC arm triple15:56
Pharaoh_AtemI just checked Fedora, Mageia, and SUSE, and the arm triple is the same for all three15:57
Pharaoh_Atemthere's nothing that specifies an override or anything15:57
zygano new logs when I xdg-open with all the right bits inside15:57
zygaprobably dbus client code in the core snap is the problem15:57
mvoPharaoh_Atem: thanks for checking! sad that the triplet is so loosely defined15:57
zygajdstrand: I confirmed that dbus-daemon didn't respond in any way (in a super verbose build) to an incoming activation request, I suspect it gets filtered in the kernel before we se15:58
zygajdstrand: I ran "DBUS_VERBOSE=1 dbus-daemon --session --print-address" in one terminal15:59
zygajdstrand: then ran "snap run --shell gimp" in another one15:59
seb128zyga, did you set DBUS_SESSION_BUS_ADDRESS= to the value from the one you started with verbose?15:59
Pharaoh_Atemmvo: in fact, hilariously, there's a patch for Fedora python to fix armhfp detection because it has hardcoded the debian triple in its build process :/16:00
zygaexported DBUS_SESSION_ADDRESS= in another one16:00
zygaseb128: yes16:00
zygaI also set DBUS_VERBOSE=1 on the client side but since it's the core snap, I suspect that is futile16:00
Pharaoh_Atemmvo: I suspect that if you were to build gcc as a snap from vanilla sources, it would produce the triple used on Fedora, Mageia, and openSUSE16:01
zygagcc as a snap would be great16:01
zygaespecially with instances and tracks16:01
Pharaoh_Atemzyga: don't get any ideas16:01
zygaPharaoh_Atem: my idea for today is to get drunk16:01
zygaI just don't have alcohol16:02
zygaso I'll make tea instead16:02
zygaand read a book16:02
zygajust as good16:02
Pharaoh_Atemdenied :)16:02
zygadbus doesn't build for me on bionic16:15
zygaone of the tests fails16:15
seb128ignore the test if it's for local testing?16:15
zygayeah, I guess I have to16:16
ograzyga, also, did you add DBUS_SESSION_BUS_ADDRESS= to the userd startup ?16:18
ograelse it will simply connect to the default session but16:18
ograi doubt a simple export in a shell will apply to a systemd user session start script16:19
zygaogra: userd is supposed to be started by the session16:19
zygaogra: this is what the bug is about16:19
zygaogra: it doens't run at all :)16:20
ograzyga, userd will likely be started by a systemd user session unit16:20
zygano, it didn't start with the session16:20
ograif you dont do the export in the unit it wont have the var set16:20
zygaand doesn't autostart (because of the bug) anyway16:20
zygait will have the var set16:20
zygabecause it's ... started by the session16:20
zygawhich I started16:20
ograoh, its a dbus service ?16:20
zygaand to which I'm talking from snap run --shell gimp16:20
zygayes :)16:20
zygaI don't have a fix yet, something is still fishy16:21
zygaogra: if I start it myself everything works (no bug)16:21
zygait's just activation that breaks16:21
zygasomething is messing up the peer credentials16:21
zygaI'm building without unit tests now16:21
steph250hello all16:26
zygahello steph25016:27
kalikianasteph250: what's up16:28
steph250Trying to setup my 1st snap, on raspberry, but ...16:29
=== Guest69214 is now known as jero--
brunosferHey guys, I'm buying another dev board to deploy ubuntu snappy core but I noticed that DragonBoard 410C was discontinued on seedstudio... Does anyone has any other dev board in mind except Raspberry Pi family?16:42
Chipacaogra: ^16:42
Chipacasteph250: but...?16:42
zygabrunosfer: depends on what your goal is16:43
zygabrunosfer: to make software for core devices or to make core devices16:43
ograbrunosfer, to my knowledge we dont have any plans on later dragonboards etc ...16:45
steph250facing some issue with libraries, like "not found".16:45
zygasteph250: those libraries must be in your snap, your snap needs to contain machinery (environment variables) to find them16:45
zygasteph250: also mvo is exploring making some of those requirements obsolete eventually (snapcraft works around those today)16:46
ograbrunosfer, there are some "community images" at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ that you could use ... but only pi2/3 and dragonboard 410c are officially supported16:46
steph250Not so sure, zyga. Just found some topics on the forum, for the same. Looking into that, at the moment.16:47
zygaso the plot thickens16:49
zygathe snap userd binary is not started by the dbus session bus now (obviously now that I think about it)16:50
zygabut by systemd16:50
zygaso I never hit my debug builds16:50
zygaso now I really want to know where those generated units are16:50
zygaor how do I edit my systemd-stared session bus to contain information about my verbose build16:50
zygamvo: ^ ideas welocme16:51
steph250Trying to see the tutorials... So, starting from "snapcraft init" and ... it fails :-)16:51
zygasteph250: what's your environment?16:51
zygawhere do you run snapcraft?16:51
brunosferzyga: It's to make software for core devices.16:52
zygaideally that would be ubuntu 16.0416:52
mvozyga: snapd userd is auto-started via /usr/share/dbus-1/services16:52
mvozyga: once it is used16:52
zygabrunosfer: then don't bother, get another pi (e.g. pi3 if you had a pi2 before)16:52
brunosferogra: but if the DragonBoard 410C is already discontinued, doesn't make much sense to buy it...16:52
zygamvo: thanks let me look at that16:52
mvozyga: so maybe that is something that in bionic system took over (is that what you are saying)?16:52
steph250freshly installed Raspberry with Jessie16:53
ograbrunosfer, well, we dont have any other board like this in the supported set atm16:53
zygamvo: I'm saying that systemd now starts that16:53
ograi.e. arm64 based16:53
zygamvo: it doesn't let the session auto start anymore16:53
brunosferzyga: my idea is to get a new architecture for testing. I already have the whole Pi family. But I would have to make sure the board I buy supports ubuntu core to deploy the snap I'm building16:53
zygait's not handled by systemd directly (AFAIR, I read about that a while ago)16:53
ogra(though arm64 for embedded is the worst idea anyway... you really want to run armhf on these)16:53
zygabrunosfer: I see, then getting a dragon is probably the "best" way because it's supported16:53
brunosferogra: Yeah, maybe I'll check the Artik16:54
zygabrunosfer: I have one but it's not a fantastic board IMO16:54
zygamvo: now I wonder how to coerce systemd to talk to my session bus16:54
ograzyga, !16:54
brunosferzyga: Yeah, I ordered one some time ago, however, never got it due to be discontinued...16:54
zygamvo: I may switch to that workaround session bus16:54
zygascript that seb128 suggested16:54
ograthe dragonboard is a fantastic arm64 board :)16:54
brunosferzyga: But I was looking to DragonBoard 410C exactly because canonical has an official image.16:55
mvozyga: systemd starts a user process afaik when you login16:55
zygaogra: no etherhet, no sata (with hrw voice), hardcoded ram split for gpu16:55
mvozyga: so systemd --user iirc16:55
zygaogra: I'd rather have 4GB RAM and ethernet16:55
mvozyga: and its per user, not per session16:55
zygaoh? per user16:55
zygamvo: I'll copy the debug shell hack and16:55
zygamvo: and reboot16:55
mvozyga: I thnk so, iirc there is no systemd login session support16:55
zygamvo: I wanted to just redirect how snap userd is activated16:56
zygamvo: I feel I don't get how that really works now16:56
diddledanif you want to change things that are defined in the service then surely you can `systemctl edit snap-userd` or whatever the unit is called?16:57
diddledanthe usual place for system-level definitions for services is at /lib/systemd/system16:59
zygadiddledan: even for user session services?17:03
zygadiddledan: and this seems to be a generated unit from the regular dbus unit generator17:03
* Chipaca wanders off to poke at broken things some more17:04
diddledanlooks like user-level services are at /usr/lib/systemd/user17:06
diddledane.g. zeitgeist17:06
steph250back ;-)17:08
zygasilly me17:11
zygasystemct --user17:14
zygahmm, I don't think systemctl --user really does what I think it does, I don't see any user session things17:20
steph250zyga: whatever I try with "snapcraft init" on RASPBIAN, I get "OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.13, libsodium.so.10, libsodium.so.5, libsodium.so.4,  and tweetnacl.so"17:23
steph250zyga: Any idea ?17:23
Chipacasteph250: raspbian?17:23
Chipacaisn't that arm6?17:23
steph250PI-2, yes17:24
* kalikiana wrapping up for today17:24
ChipacaI don't think we support raspbian17:24
ograChipaca, arm6 != ARMv6 :)17:24
ogra(we dont support either though)17:24
Chipacaogra: should I have said "isn't that ARMv6"?17:25
Chipacaogra: i mean, it's armel17:25
Chipacawe don't support armel, we support armhf17:25
Chipacaso we support the pi 2, but not with raspbian because all the binaries are icky or something17:25
zygasteph250: that's not supported17:25
* Chipaca tries again to wander off to fix things17:26
ograarm6 is actually ARMv317:26
steph250I guessed, yes ...17:26
ografrom around 1991 :)17:26
* zyga shakes fist at dbus17:26
zygaI'll get to the bottom of this bug17:26
ogranobody supports that anymore ... not even armel17:26
steph250so, no way to use SNAPS on raspberry PI2 ?17:26
ograsteph250, ??17:26
ograthere are pi2 ubuntu-core images17:27
zygasteph250: note that raspberry pi 2 can run more modern software just fine, but you cannot use raspbian17:27
ograand here are classic ubuntu-server images that should be able to run snaps17:28
zygaoh boy, my dbus logs a lot17:29
zygagdm doesn't start yet tho17:29
steph250not good news :-(17:30
zygasteph250: sorry, we cannot do anything about that17:31
steph250no issue. any idea why it's not supported ? I mean, would it be possible ?17:32
zygasteph250: because raspbian uses a different ABI that is compatible with older processors17:32
zygasteph250: everyone else uses the newer ABI, snapd can be added to raspbian but snaps wound't work on some machines (pi zero)17:32
zygasteph250: so there's no real support for raspbian yet17:33
steph250this, I saw :-)17:33
diddledanogra: oh, awesome, I didn't know there were classic variants of ubuntu available for the pi17:33
ogradiddledan, only pi2 afaik17:34
zygathe debug build logs but doesn't start gdm17:34
* zyga inspects why17:35
zygasty 15 18:36:41 kaedwen dbus-daemon[1833]: [system] Activating service name='org.freedesktop.login1' requested by ':1.22' (uid=0 pid=3317 comm="/usr/sbin/gdm3 " label="unconfined") (using servicehelper)17:37
zygawhy the space?!17:37
ograprobably there are args it chops off before17:38
ogra(and does that badly)17:38
zygasty 15 18:38:13 kaedwen dbus-daemon[1833]: [system] Activating service name='org.freedesktop.systemd1' requested by ':1.26' (uid=0 pid=3404 comm="/lib/systemd/systemd-logind " label="unconfined") (using servicehelper)17:38
ogra(or there are args it shoudl be adding but doesnt and you have an empty var with a space)17:39
ograi doubt that would make it fail though17:39
zygahmm mhmmm17:40
zygait's my hack with a shell script that execs the real thing17:40
zygabut I don't see how17:40
zygathis is what it does:17:40
zygaexec /usr/lib/dbus-1.0/debug-build/bin/dbus-daemon "$@"17:40
diddledanif $@ is empty then it'll send a string as the first argument with no content17:41
diddledanie. empty string, not "no argument"17:41
zygashoud I use "$*" instead?17:41
zygaI thought "$@" what the "right" way to do things17:42
diddledanwhen $@ has nothing inside it, then "$@" will evaluate to "" which in bash will evaluate to an argument of zero length17:44
diddledanthat is it WILL be an argument17:44
zygabash sucks17:44
zygashell sucks17:44
zygathank you for teaching me17:44
diddledanso if you did `foo ""` then $1 in foo will exist, but be empty. it isn't the same as `foo` where $1 will not exist17:45
zygathis is why it failed17:46
diddledanbit silly really, you're right17:46
diddledanit's a  legacy thing I guess17:47
diddledan"why does it do this thing?" .. "because it always did the thing" .. "should we change it to make sense?" .. "no, because that's how it is done"17:47
zygadiddledan: yes, that's true :)17:48
diddledanI guess sometimes legacy can bite :-p17:48
zyga2251 "aliens to humans: why is $@ expaning to an empty string"17:51
* zyga wishes for FCKSH17:51
zygafricking sensible shell17:52
diddledanthe "sh" is silent, and the "fck" is said like the popular swear17:52
diddledan"I'm having trouble will my bash script" .. "just fck it, instead"17:53
mupPR snapcraft#1872 closed: adding option to decompress tar.lzma cleanly <Created by heesen3> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1872>17:57
cjwatsondiddledan: no, that's wrong - "$@" has magic behaviour and does not expand to a single empty argument in the case of zero arguments17:58
zygaok, my hack boots now17:58
zygacjwatson: ah, so maybe my memory wasn't broken17:59
zygastill, my ssystem is trying to start gdm, failing17:59
cjwatsonzyga: maybe the problem is at the next layer up17:59
zygacjwatson: it's speed, dbus is so slow now that things time out :-(17:59
cjwatsonchapter and verse from bash(1):18:00
cjwatson              When there are no positional parameters, "$@" and $@ expand to18:00
cjwatson              nothing (i.e., they are removed).18:00
diddledanwell that's even more weird legacy then :-p18:00
zygaso I _was_ right to use "$@"18:00
zygaat least I wasn't crazy that I thought it is special somehow18:00
cjwatsonyes, it is the right thing in that sort of wrapper18:00
diddledan"if a variable is empty, does it leave a string?" .. "yes. except when it doesn't"18:01
cjwatson"$@" is the single exception18:01
zygaso I have a hack workaround :)18:02
zygaI booted gdm without debug18:02
zyganow I can switch on debugging for the session where I log in18:02
zygaand I'm logged in18:03
zygaok, let's reproduce the bug now18:03
diddledannow to actually do the debug18:03
diddledan"my debug didn't work." .. "did you debug your debug?"18:03
davidcallekyrofa: fyi, just landed https://docs.snapcraft.io/build-snaps/syntax18:03
zygasty 15 19:04:56 kaedwen systemd-journald[273]: Forwarding to syslog missed 817 messages.18:05
zygahow can I make journal not do that and instead give me the real thing18:05
diddledandavidcalle: for the `version` docs you need to point out that a numeric-only value is incorrect UNLESS it is wrapped in quotes18:06
jdstrandzyga: the kernel should only be mediating the unix socket. it won't get in the way of dbus rules because it isn't looking at them. if activation isn't sorking, it must be in dbus-daemon18:06
diddledani.e. `version: 1.0` is illegal18:06
zygajdstrand: yes, I think it's the new dbus + the ubuntu-only patch that broke it18:07
diddledan`version: '1.0'` is correct18:07
jdstrandzyga: journald also shouldn't be missing messages, it is the messages going to syslog that it may be dropping (aiui). I suggest journalctl --follow | grep DEN on newer release18:08
jdstrandI see too much getting dropped in /var/log/syslog :\18:08
zygajdstrand: http://paste.ubuntu.com/26393153/18:08
zygathis is the full-so-far log from when I try to use xdg-open18:08
diddledandavidcalle: `assumes` says that it takes a list but doesn't tell where to find the valid values for that list.18:09
* zyga tries to get a better log18:09
jdstrandzyga: I suspect the lack of peer_label in the log is a clue18:09
jdstrandzyga: note that dbus is the thing logging18:10
zygathis is a better one18:11
jdstrandif I were looking at this, I would take a look at those <null> entries in the log18:11
zygathanks, I'll look now18:11
zygaI can build and iterate on this now18:11
jdstrandsty 15 19:10:15 kaedwen dbus-daemon[2413]: 2413: 0x7f86619c78c0: 1516039815.743271 [bus/activation.c(1803):bus_activation_activate_service] activation not authorized: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.74" (uid=1000 pid=4280 comm="dbus-send --print-reply --session --dest=io.snapcr" label="snap.gimp.gimp (enforce)") interface="io.18:12
jdstrandI don't *know* that the null is meaningful. I do know that the lack of peer_label is definitely wrong18:14
jdstrandsince the rule specifies a peer label, if dbus-daemon doesn't find it correctly, that would suggest why it might not match18:14
jdstrandzyga ^18:14
zygajdstrand: yes18:18
zygajdstrand: this also matches mvo's experiments where removing peer label requirement "fixed it"18:18
* jdstrand nods18:18
jdstrandremoving it would mean match any peer18:18
zygajdstrand: yep18:19
zyganext up, dive into dbus18:19
zygabut first18:19
zygadoes anyone know Jeremy Bicha18:19
zygahe made the last upload with the new apparmor patch18:20
jdstrandzyga: he participates on the desktop. see #ubuntu-desktop18:20
jdstrandzyga: while Tyler is quite busy with sprint and kernel updates, he did a bunch of the dbus work (he upstreamed it), so he could be a resource (perhaps next week?)18:21
zygajdstrand: thank you! that's a nice idea18:22
zygajdstrand: hmm :)18:23
zygaFrom: Tyler Hicks <tyhicks@canonical.com>18:23
zygathe patch is from tyler18:23
zygaI should have spotted that a long time ago18:23
zygamy bet is that that patch doesn't work18:23
zygaor isn't applied (I'll check but I'd be suprirsed)18:23
zygaso maybe getly ask tyler if it works on his bionic :)18:23
zygaI'll get something to drink and get back to digging18:23
jdstrandpossible. also possible is  libapparmor change. I'm just guessing at this point since I haven't looked at any of this18:24
davidcallediddledan: thanks for the feedback, it's mostly a layout update, content fixes on their way18:24
zygajdstrand: I'll look at changelogs18:24
jdstrandiirc, the patch doesn't have to do with peer labeling, but closing a hole wrt dbus snooping18:24
jdstrandI guess I could pull down the package...18:25
zygahmm, are you sure?18:25
zygaAllows the AppArmor label that is attached to a D-Bus connection to be18:25
zygaqueried using the unique connection name.18:25
zygathat's the patch description ^18:25
zygaI also added it to the forum18:25
jdstrandoh, well, that certainly seems on point. maybe it doesn't need to be applied or needs to be applied differently18:25
zygajdstrand: no worries, I'm just broadcasting my progress18:26
zygajdstrand: I'll look at what's going on there, I never touched dbus guts before18:26
zygabut first, something to drink18:26
jdstrandzyga: I'm betting something changed with how it determines the label of a non-activated service18:28
jdstrand(since it isn't running yet)18:28
jdstrandzyga: good luck! :)18:28
zygammm, good idea18:28
zygathanks, just looking at call graph18:29
zygaok, back18:51
zygashower should help to attack this problem :)18:51
zygaso I see where the peer label is set19:11
zygaI'll debug there19:11
zygaseems like the only place that can go wrong19:11
zyga(or that this code is now unused due to other changes019:11
cachiozyga, there?19:46
cachiozyga, in file cmd/snap-mgmt/snap-mgmt-sh-in, "@SNAP_MOUNT_DIR@" is /snap for fedora19:47
cachiozyga, sorry, for opensuse19:48
cachiozyga, is it ok, right?19:48
NateGrahamHello Snappers! I'm a KDE developer working on Discover, our softwar center, and I'm trying to improve Snap support. I'm hoping someone can help me debug an issue on my test system19:49
NateGrahamWhen I try to install a snap, I get an error on the console:19:49
NateGraham(process:1984): Snapd-CRITICAL **: snapd_client_install_stream_finish: assertion 'request->request_type == SNAPD_REQUEST_INSTALL_STREAM' failed19:49
NateGrahamthe distro is KDE Neon, which is based on Ubuntu 16.0419:49
NateGraham@Riddell! Do you know if Snap is expected to work in KDE Neon?19:53
RiddellNateGraham: well yes but it gets precious little testing so thanks for looking at it19:53
RiddellNateGraham: do you have snapd installed and kde-frameworks snap installed?19:53
NateGrahamlet me see19:56
NateGrahamI definitely have snapd installed; what's the package name for the framework though?19:58
zygacachio: yes19:59
zygacachio: yes, it's /snap for opensuse19:59
zygaNateGraham: hello!19:59
cachiozyga, tx20:00
zygaNateGraham: do you know what happens under the hood there? what kind of request flies to snapd?20:00
NateGrahamI haven't a clue; I'm new to Snap20:00
zygaI'm a snapd developer though you probably want to talk to Chipaca about that particular problem20:00
zygaNateGraham: which API are you using to talk to snapd?20:00
NateGrahamif you'd like, I can try to focus on a CLI test case so we can nail it down20:01
zygaNateGraham: that's okay, eventually all APIs talk to snapd over a socket, there's one real API internally20:01
zygaNateGraham: though for gnome-software there's extra work on authentication20:01
zygaNateGraham: and there's some polkit around that as well, but I think transparently and internally in snapd20:02
NateGrahamwe're using snapd-glib20:02
zygaNateGraham: that's great20:02
zygait talks to the socket under the hood so you should be good20:02
RiddellNateGraham: kde-frameworks-5 snap needs to be installed  before any Neon snaps will work20:03
zygaRiddell: snapd doesn't yet handle that AFAIK but this functionality is coming via the default provider work that mvo is doing20:03
Riddellzyga: right, that's why it needs to be installed first20:04
zyga(so eventually this fact will be handled internally)20:04
Riddellwhich should be the case with a KDE neon install20:04
NateGrahamRIddell: are you sure that's the package name?20:04
zygaNateGraham: you can manually try if it works "snap install kde-frameworks-5"20:04
RiddellNateGraham: yep, I have..20:04
RiddellName              Version  Rev   Developer  Notes20:04
Riddellcore                       3748  canonical  broken20:04
Riddellkde-frameworks-5           13    kde        broken20:04
zygathat looks bad20:05
NateGrahamoh oh course, this is a snap package, not an apt package, pardon my ignorance20:05
NateGrahamit is indeed already installed20:05
zygaNateGraham: I'm worried by those broken notes20:05
NateGrahamthat's on Riddell's system, not mine :)20:06
NateGrahamthough of course mine may be broken, too20:06
zygaNateGraham: can you pastebin logs from snapd.service please?20:06
RiddellI was fiddling around with them earlier to fix my plasma screenshots which I guess broke them20:06
zygaso they are not generally broken20:07
zygahaving broken core is definitely a problem for installing snaps20:07
zygaso if you can get that in order you may have more luck20:07
RiddellI mounted the snaps manually and I guess it didn't like that20:07
Riddellunmounted rather20:07
zygaotherwise I'm happy to help but I was on my way out already, maybe Chipaca is still up (though also past EOD today)20:07
zygaRiddell: if you mount it does snap list show it as non-broken?20:08
Riddellzyga: I don't know how to mount them again20:08
RiddellI am destroyer of snapd20:08
zygaRiddell: just start the systemd mount unit20:08
zyga(for that particular snap and revision)20:09
Riddellzyga: well a reboot started my issue, but I still can't get my snaps to work20:23
Riddelloh hoorah found one which does run, falkon20:25
Riddellbut mm plasma-discover integration not happy20:25
RiddellNateGraham: so aye maybe snaps not in a great shape just now I'm afraid :(20:25
RiddellNateGraham: at least in kde neon dev unstable that I have plasma discover just loads forever when I search for say falkon and doesn't list the snaps20:25
* Riddell out20:26
NateGrahamdo you have the snap backend installed?20:26
NateGrahamcompiled from git master, that part works for me, at least20:26
seb128zyga, thanks for the work on debugging that dbus issue, let me know if we can help20:32
zygaseb128: I took a break to spend time with family but I think I have a clue to follow now, just need to try a few extra prints20:45
seb128zyga, that commit seems new in  the updated version, https://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.12&id=dc25979eb20:46
seb128from the description might have to do with the topic?20:46
seb128"If the .service file contains AssumedAppArmorLabel=/foo/bar then we will do the AppArmor query on the assumption that the recipient AppArmor label will be as stated. Otherwise, we will do a query with an unspecified label, which means that AppArmor rules that do specify a peer label will never match it."20:46
zygayes, looks new and interestingly contains20:46
zyga+  if (dst_con != NULL)20:46
zyga+    {20:46
zyga+      dst_label = dst_con->label;20:46
zygaso ... maybe :)20:46
seb128jdstrand, ^20:46
zygaI will definitely try that (but watching new startrek with wife now :)20:47
zygabbl :)20:47
seb128zyga, enjoy!20:47
mwhudsoncleanbuild with snapcraft tip or near tip is failing for me20:48
mwhudsonerror: open /var/lib/snapd/hostfs/home/mwhudson/snap/lxd/common/snapcraft2c0cyxw6/core_3748.assert: no such file or directory20:48
mwhudson(building a classic snap, if that matters)20:48
ChipacaI wasn't here, but I am here now. Can I still help?21:06
Chipacaif no reply in a minute, I shall take the dog for a walk.21:07
Chipacaok two minutes21:07
=== apw_ is now known as apw
mwhudsoncleanbuild with snapcraft tip *built as a snap* is failing for me21:59
zygamwhudson: hey22:17
zygamwhudson: do you think you would have some time to update snapd in debian?22:18
zygamwhudson: it seems people still have issues with apparmor there22:18
mwhudsonzyga: there is a new one in sid22:27
mwhudsonzyga: would be interesting to know if it works at all :-)22:27
zygamwhudson: thank you for letting me know, I will try it and reply to the people on the forum22:39
mwhudsonhmm why can i not install the new snapd in this vm22:39
* zyga pulls in 200MB of sid updates22:41
mwhudsonuh no really why22:42
zygawhat's wrong?22:42
mwhudson2.30-3 is in the pool but not the indices22:42
zygathat's ... odd22:42
mwhudsonoh wait22:43
zygasome migration script didn't publish it?22:43
mwhudsonno only the dsc is in the pool, the debs are not22:43
mwhudsonmaybe i'm about to learn something about debian22:43
mwhudsonah yeah look https://buildd.debian.org/status/package.php?p=snapd <- uploaded, not installed22:43
zygamips -- build attempted22:44
mwhudsonyea but they've never built22:44
zygamwhudson: do we have more arch blacklisting to do?22:44
mwhudsonand i didn't  think failed builds prevented publication to unstable22:45
zygamwhudson: so is it just pending publishing or do you need to do another upload with some arches disabled?22:52
zygacurious, I updated apt and then apt found way more updates22:59
zygameh, time to sleep23:00
mwhudsonzyga: i don't know23:03

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!