| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 05:59 |
|---|---|---|
| mup | Bug #1743301 opened: cannot install apps using snap on Korora <Snappy:New> <https://launchpad.net/bugs/1743301> | 06:16 |
| mborzecki | mvo: morning | 08:04 |
| mborzecki | mvo: something for snap-advise https://bugs.launchpad.net/snapd/+bug/1742677 | 08:04 |
| mup | Bug #1742677: snap run should error nicely when snap isn't installed <snapd:New> <https://launchpad.net/bugs/1742677> | 08:04 |
| kalikiana | good morning | 08:07 |
| mvo | mborzecki: thanks, checking | 08:08 |
| mvo | kalikiana: good morning | 08:08 |
| mvo | mborzecki: and good morning to you! | 08:08 |
| pstolowski | mornings! | 08:10 |
| mborzecki | kalikiana: pstolowski: morning | 08:12 |
| zyga | o/ | 08:12 |
| zyga | mvo: good morning | 08:12 |
| kalikiana | \o | 08:12 |
| zyga | mvo: I have a question to you as a apt maintainer, | 08:13 |
| zyga | mvo: when a hdd is corrupted and dpkg database is partially blown away, is it sensible to try to reinstall some packages | 08:13 |
| zyga | mvo: or should I just backup home and reinstall the whole thing | 08:13 |
| mvo | zyga: well, thats a tough one :) most of the time liberal use of "apt install --reinstall $stuff" makes things work again | 08:17 |
| mborzecki | zyga: hey | 08:17 |
| mvo | zyga: *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 well | 08:18 |
| mvo | zyga: if there is no/little user data or if you can easily restore this in isolation the reinstall of packages is worth a shot | 08:18 |
| mvo | and good morning pstolowski | 08:18 |
| zyga | I tried a small reinstall but apt dpkg complained about some packages have empty list of files, | 08:23 |
| zyga | I'll do full reinstall :/ | 08:23 |
| mvo | zyga: well, empty list of files should not be a hard error | 08:26 |
| mvo | zyga: can you pastebin the error ? | 08:26 |
| mvo | zyga: *if* you want to resovle this tihs way | 08:26 |
| zyga | dpkg: unrecoverable fatal error, aborting | 08:26 |
| mvo | zyga: there were some more before that I'm sure | 08:27 |
| zyga | (then localized), list of files in package "libc6-dbg:amd64" contains empty file name | 08:27 |
| seb128 | hey there | 08:27 |
| seb128 | is bug #1742687 likely a regression in snapd? | 08:27 |
| mup | Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1742687> | 08:27 |
| seb128 | the title might be misleading, he's using 2.30 which is not in other ubuntu series | 08:27 |
| zyga | seb128: perhaps, I think the url opening moved to snapctl (but I may be mistaken) | 08:28 |
| seb128 | zyga, could somebody familiar with that part of the codebase check if there is an issue? | 08:29 |
| mborzecki | 09:29:05 up 12:42, 7 users, load average: 14.75, 13.00, 11.22 :/ building snapd yocto image on x220 | 08:29 |
| mvo | zyga: you could try "dpkg --purge libc6-dbg" but probably not worth it | 08:30 |
| zyga | seb128: yes, for sure | 08:30 |
| seb128 | thx | 08:30 |
| zyga | mvo: that doesn't work | 08:30 |
| zyga | same error | 08:30 |
| mvo | zyga: 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 |
| zyga | k | 08:31 |
| mvo | zyga: and then re-try the --reinstall ? | 08:31 |
| zyga | mvo: that file doesn't exist at all | 08:32 |
| zyga | ah, no sorry | 08:32 |
| mvo | zyga: no "/var/lib/dpkg/info/libc6-dbg\:amd64.list " ? | 08:32 |
| zyga | shell has issues with : in filenames :/ | 08:32 |
| zyga | heh | 08:32 |
| zyga | mvo: I'll ski | 08:32 |
| zyga | mvo: inside I see a DBUS XML profile | 08:32 |
| mvo | zyga: haha | 08:32 |
| zyga | mvo: my disk is a messed up soup | 08:32 |
| mvo | zyga: there you go | 08:33 |
| zyga | mvo: I'm making a bootable usb now | 08:33 |
| zyga | :/ | 08:33 |
| mvo | zyga: well, you could try to repair this one | 08:33 |
| mvo | zyga: of course if that is all over the place> FAIL | 08:33 |
| zyga | mvo: fsck printed a huge list of changes | 08:33 |
| zyga | mvo: I think that's not a happy disk | 08:33 |
| mvo | ok | 08:34 |
| mborzecki | zyga: smart did't raise a warning or anything? | 08:35 |
| mvo | zyga: good luck - do you happen to have an 18.04 vm? or sebs bug? | 08:35 |
| zyga | mborzecki: not a single one | 08:35 |
| zyga | mborzecki: I'm running small test | 08:35 |
| zyga | mvo: I don't have 18.04 vm yet, no | 08:35 |
| mvo | ok | 08:35 |
| mborzecki | zyga: at least tell us the band of the disk, and why it ahppens to be a seagate? :) | 08:37 |
| zyga | mborzecki: wd | 08:37 |
| zyga | mborzecki: they all eventually fail :/ | 08:37 |
| zyga | it's a 1TB blue | 08:37 |
| zyga | 832 start/stop cycles | 08:37 |
| zyga | 3 months and 1 day of uptime total | 08:38 |
| zyga | so... | 08:38 |
| mborzecki | :/ | 08:38 |
| * mborzecki goes to check smart log on his nas disks | 08:38 | |
| * zyga tarballs home and DDs 17.10 installer to usb | 08:40 | |
| zyga | mvo: do you think I could reinstall 18.04 instead | 08:41 |
| zyga | I wonder if that could help with the bug in a meaningful way | 08:41 |
| zyga | seb128: http://cdimage.ubuntu.com/releases/17.10.1/release/ - is the 17.10.1 release due to meltdown? | 08:42 |
| mvo | zyga: sure, can't hurt to install 18.04 | 08:43 |
| seb128 | zyga, no | 08:43 |
| mvo | zyga: 17.10.1 might also be because of the bios issue with lenovo | 08:43 |
| seb128 | what mvo said | 08:43 |
| zyga | ah, I see | 08:43 |
| zyga | I'll do 18.04 | 08:43 |
| zyga | let's see what's coming | 08:43 |
| === jdstrand_ is now known as jdstrand | ||
| zyga | hey there Chipaca | 09:35 |
| Chipaca | zyga: o/! | 09:35 |
| Chipaca | zyga: how's things? | 09:35 |
| mborzecki | would 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. lxd | 09:37 |
| mup | PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480> | 09:37 |
| Chipaca | mborzecki: is this for stopping and removing those things on purge? | 09:38 |
| mborzecki | Chipaca: yes | 09:38 |
| zyga | Chipaca: so so :) doing a reinstall now, hoping that my HDD isn't totally crazy :) | 09:39 |
| zyga | Chipaca: just picking up some PRs to review while I wait | 09:39 |
| Chipaca | mborzecki: I don't think that's controversial; that's what the deb package was supposed to do in its postrm | 09:40 |
| mborzecki | zyga: 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 |
| mvo | Chipaca: s/supposed to do/doing/ - no ? | 09:42 |
| Chipaca | mvo: I assume it is also what it does, if that's your question :-) | 09:42 |
| mborzecki | Chipaca: 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 --purge | 09:42 |
| Chipaca | mvo: I'd have to look at the current postrm to say for sure :-D | 09:42 |
| pedronis | Chipaca: yes, it does that | 09:42 |
| mvo | Chipaca: aha, thats fine. I was wondering if there is a bug in the postrm | 09:42 |
| Chipaca | mvo: there's an expression in Spanish, 'no meto las manos en el fuego por nadie' :-) | 09:43 |
| mvo | Chipaca: there is an expression in german: "Ich verstehe kein Spanisch" | 09:43 |
| mvo | Chipaca: ;) anyway, thanks! | 09:43 |
| pedronis | mborzecki: it does that also for mount units btw | 09:44 |
| pedronis | (the deb postrm) | 09:44 |
| Chipaca | mvo: there's an expression in French, "ils sont fous ces allemands" | 09:44 |
| mvo | mborzecki: 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 postrm | 09:45 |
| mvo | mborzecki: I mean, any code sharing would have to be done via some magic that copies things into postrm | 09:46 |
| mborzecki | mvo: sound ugly | 09:46 |
| mvo | Chipaca: heh :) I think I know enough french for this one ;) | 09:46 |
| mvo | mborzecki: yeah, britle and terrible | 09:46 |
| pedronis | it could be done in the Makefile / rules | 09:47 |
| * mvo hugs Chipaca and apologizes for trolling him on a monday morning | 09:48 | |
| mvo | pedronis: yeah, I think its doable, we just need to be careful and it will be a little bit ugly | 09:48 |
| mvo | (of course it is, SMOP and all that :) | 09:49 |
| zyga | mborzecki: haha | 09:50 |
| zyga | mborzecki: nice ;) | 09:50 |
| mup | PR 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 |
| zyga | mborzecki: just curl mgmg.snapcraft.io | 09:52 |
| zyga | mborzecki: just curl mgmg.snapcraft.io | sudo sh | 09:52 |
| zyga | mborzecki: ;-) | 09:52 |
| zyga | mborzecki: no need to worry about postrm | 09:52 |
| zyga | ;-) | 09:52 |
| zyga | man, my typing sucks on this laptop | 09:52 |
| mborzecki | hmm ok, seems like there's a bug in #4480 | 09:53 |
| mup | PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480> | 09:53 |
| mvo | mborzecki: is bug #1741474 something to set to "fix commited" ? | 09:53 |
| mup | Bug #1741474: Migrating from snapd to snapd-git results in 'broken' snaps <snapd:Triaged> <https://launchpad.net/bugs/1741474> | 09:53 |
| mborzecki | mvo: yeah, think it's ok to switch the status | 09:55 |
| mvo | mborzecki: thank you! and thanks for the fix | 09:56 |
| mborzecki | mvo: oh, it's not me, it's philm from manjaro who updated the packages | 09:57 |
| mborzecki | anyways, they are in sync with ones from AUR now | 09:57 |
| mvo | mborzecki: ta | 09:59 |
| zyga | mvo: can 4424 land? | 10:10 |
| mvo | zyga: let me look at this one more, maybe we don't need to honor this limit if pam is already doing the right thing internally | 10:11 |
| zyga | pstolowski: is landing new interfaces problematic for you? | 10:12 |
| zyga | pstolowski: can I land 4365? (do a qucik review maybe) | 10:12 |
| * zyga requests review for 4329 | 10:13 | |
| zyga | 4329 is from nov 2017 and fixes a bug | 10:13 |
| pstolowski | zyga, by all means we should land new interfaces, i'll update my branch if needed | 10:13 |
| pstolowski | zyga, let's just avoid any unnecessary refactorings around interfaces at this point and it will be fine | 10:14 |
| pstolowski | so yes please land 4365 | 10:15 |
| zyga | pstolowski: kk | 10:16 |
| pedronis | zyga: yes, I looked at the new package I'm using, what's the procedure for new deps ? | 10:17 |
| zyga | pedronis: I don't think we have any really, I just wanted to double check someone from the team read that package | 10:17 |
| zyga | jamesh: hey | 10:17 |
| jamesh | zyga: hi | 10:17 |
| pedronis | zyga: yes, I read the package, it doesn't do networking, has good coverage | 10:18 |
| pedronis | seems to do the job | 10:18 |
| zyga | jamesh: 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 week | 10:18 |
| pedronis | there are much more complicated packages for this, but seems overkill for these case | 10:18 |
| zyga | jamesh: can I help you some way? | 10:18 |
| pedronis | *this case | 10:19 |
| zyga | pedronis: that sounds good to me | 10:19 |
| mborzecki | zyga: pedronis: pushed a fix to #4480 can you take a look? | 10:21 |
| mup | PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480> | 10:21 |
| zyga | mborzecki: aha | 10:21 |
| mup | PR 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 |
| zyga | mborzecki: commentd | 10:23 |
| mborzecki | zyga: thanks, the reload doesn't happen in postrm either, i'd say it's up to the caller to do a systemctl daemon-reload | 10:26 |
| pedronis | Chipaca: 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 Provides | 10:27 |
| Chipaca | pedronis: oh? | 10:27 |
| pedronis | for 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 |
| pedronis | the bundled bit I'm not sure what is about | 10:28 |
| pedronis | Chipaca: ^ | 10:29 |
| Chipaca | ah, me neither | 10:29 |
| Chipaca | I added the BuildRequires because without it it wouldn't work :-) | 10:29 |
| Chipaca | I don't know the significance of the rest | 10:30 |
| pedronis | Chipaca: well I didn't even add that, because fedora is off :/ | 10:30 |
| jamesh | zyga: just testing out the change for making /media shared again. I think that was the only thing we decided was needed before merging it | 10:30 |
| Chipaca | pedronis: you can still run it by hand :-D | 10:31 |
| pedronis | Chipaca: and see it fail for other reasons anyway? | 10:31 |
| Chipaca | pedronis: running a test by hand has high chances of working | 10:31 |
| pedronis | I mean, we turned off fedora for reasons | 10:31 |
| mborzecki | zyga: #4329, the code there is called with cgroup frozen? | 10:31 |
| mup | PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329> | 10:31 |
| Chipaca | pedronis: running all the tests has high chances of failing | 10:32 |
| Chipaca | pedronis: ¯\_(ツ)_/¯ | 10:32 |
| pedronis | Chipaca: anyway, should we cargo cult the rest for boltdb? | 10:32 |
| Chipaca | pedronis: I'd rather ask somebody that knows | 10:32 |
| pedronis | I suppose all deps should be the same | 10:32 |
| Chipaca | that's a good supposition, and we can go with it if neil doesn't show today | 10:33 |
| Chipaca | ok? | 10:33 |
| zyga | re | 10:33 |
| pedronis | yea | 10:33 |
| zyga | jamesh: cool | 10:33 |
| zyga | jamesh: I don't know if *just* making it shared will be enough tho | 10:34 |
| pedronis | Chipaca: could you look at #4481 | 10:34 |
| mup | PR #4481: image: let consume snapcraft export-login files from tooling <Created by pedronis> <https://github.com/snapcore/snapd/pull/4481> | 10:34 |
| zyga | jamesh: otherwise the code that makes /media shared would be much much easier to write originally | 10:34 |
| Chipaca | pedronis: on it | 10:34 |
| pedronis | thank you | 10:34 |
| zyga | jamesh: do a practical test please (ideally patch the /media spread test to also have a dummy per-user mount profile to see) | 10:34 |
| zyga | mborzecki: no | 10:35 |
| zyga | mborzecki: just with the per-ns lock held | 10:36 |
| zyga | jamesh: 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 slaves | 10:36 |
| zyga | jamesh: I might be wrong but I think this is why the /media setup that we have now ended up so convoluted | 10:37 |
| zyga | jamesh: (I stash away /media to recover it later) | 10:37 |
| pedronis | Chipaca: 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 sense | 10:38 |
| pedronis | Chipaca: that's why I'm holding off adding command line options | 10:39 |
| Chipaca | pedronis: 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 think | 10:39 |
| Chipaca | nothing urgent and i didn't mean it needed doing right now | 10:40 |
| pedronis | the arch yes | 10:40 |
| * zyga is grumpy because the good green tea has run out | 10:40 | |
| Chipaca | snapshots also run in the absence of snapd :-D | 10:40 |
| pedronis | just explaining why I didn't add command line options so far | 10:40 |
| zyga | and the store carrying it is on the other side of the city | 10:40 |
| Chipaca | zyga: send your snappy-enabled drones | 10:40 |
| zyga | Chipaca: arduino with a sign "will write model assertions for tea" | 10:41 |
| Chipaca | zyga: hey now, no unlawfully competing with ogra_ | 10:42 |
| zyga | Chipaca: I think ogra would write beer, that's a different market segment | 10:42 |
| zyga | we can coexist peacefully | 10:42 |
| Chipaca | augh! i should've gone to physio | 10:46 |
| jamesh | zyga: I think you're right. I thought I had something working, but it doesn't seem to be propagating. | 10:51 |
| jamesh | zyga: I do wonder if anything using the desktop interface would ever be affected by this though | 10:52 |
| zyga | jamesh: 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 handy | 10:52 |
| jamesh | e.g. display security in current Ubuntu doesn't let root connect to the user's display | 10:52 |
| jamesh | zyga: so I need to track down what all the top level mounts are then | 10:53 |
| zyga | jamesh: no, no need | 10:53 |
| zyga | jamesh: just opendir and iterate over top level elements | 10:53 |
| zyga | and skip media | 10:54 |
| jamesh | zyga: but the top level directories aren't all going to be mount points | 10:55 |
| zyga | not a problem | 10:55 |
| zyga | ah | 10:55 |
| zyga | actually, you are right | 10:55 |
| zyga | that is a problem | 10:55 |
| zyga | rshare doesn't handle non-mount entries | 10:55 |
| zyga | bummer :/ | 10:55 |
| jamesh | zyga: 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 shared | 10:56 |
| niemeyer | pedronis: 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 |
| zyga | jamesh: I honesntly don't even see how that can work | 10:59 |
| zyga | jamesh: it's far more complex than what we have now | 10:59 |
| zyga | jamesh: I'll dismiss that without any poc code | 10: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 emerge | 11:00 |
| ogra_ | zyga, correct .... and also ... i dont touch systems without MMU ;) | 11:01 |
| zyga | jamesh: (even back of the envelope pseudocode) | 11:01 |
| === chihchun is now known as chihchun_afk | ||
| jamesh | zyga: 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 found | 11:05 |
| mborzecki | zyga: went through #4329, left some comments | 11:06 |
| mup | PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329> | 11:06 |
| jamesh | zyga: 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 that | 11:06 |
| zyga | mborzecki: thank you | 11:06 |
| zyga | mborzecki: looking now | 11:09 |
| zyga | jamesh: maybe it's easier than I assume by I really would like to see some pseudocode written (e.g. forum thread) | 11:09 |
| zyga | jamesh: I suspect the devil is in the details here, it's very delicate piece of code | 11:09 |
| pedronis | niemeyer: 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 default | 11:12 |
| jamesh | zyga: 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 |
| zyga | jamesh: 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 it | 11:14 |
| jamesh | okay | 11:14 |
| mvo | hey cachio ! welcome back | 11:15 |
| cachio | mvo, hey, thanks | 11:15 |
| zyga | cachio: wow, hey | 11:15 |
| cachio | mvo, glad to be here again | 11:15 |
| cachio | zyga, hey, long time | 11:16 |
| zyga | cachio: I hope you had great time :) | 11:17 |
| cachio | zyga, yes it was, thanks | 11:17 |
| cachio | mvo, any plan for beta validation? | 11:20 |
| mvo | cachio: yeah, probably tomorrow, we had a bit of a setback because of spectre/meldown, no edge builds for a couple of days | 11:20 |
| cachio | mvo, ok | 11:21 |
| zyga | cachio: welcome back, the internet has melted and is chased by some spectres | 11:22 |
| cachio | zyga, hehehe, yes | 11:23 |
| cjwatson | Are you still blocked on the remaining ppa:snappy-dev/ubuntu/edge builds? | 11:23 |
| cachio | zyga, no way to scape from that | 11:24 |
| Chipaca | E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list | 11:24 |
| cachio | zyga, is there any change in snapd for deal with those issues? | 11:25 |
| Chipaca | quoth the raven, WAT | 11:25 |
| mvo | cjwatson: 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 |
| zyga | cachio: no, just extra delays around | 11:26 |
| zyga | cachio: probably new toolchains soon | 11:27 |
| zyga | cachio: maybe a rebuild required, not sure | 11:27 |
| cachio | zyga, ok | 11:27 |
| cjwatson | mvo: 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 |
| mvo | cjwatson: its a sync from github.com/snapcore/snapd | 11:28 |
| cjwatson | mvo: (we can whitelist builds, but we have to treat the builders as if they have no effective virtualisation at the moment) | 11:28 |
| mup | PR snapd#4487 opened: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487> | 11:28 |
| cjwatson | mvo: hmm, any reason it's not a Launchpad git-to-git import? Is it gated in some way? | 11:28 |
| mvo | cjwatson: and we only allow code in that we reviewed and that passed our test suite (and CLA) | 11:28 |
| mvo | cjwatson: 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-age | 11:30 |
| mvo | cjwatson: (this is why the git tree is called snapd-vendor, i.e. snapd+vendor-code) | 11:30 |
| cjwatson | ah, ok | 11:30 |
| cjwatson | mvo: does your process for updating vendor/vendor.json at least involve eyeballing the upstream diff? | 11:31 |
| zyga | (uncomfortable moment) | 11:31 |
| zyga | ;-) | 11:32 |
| mvo | cjwatson: 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 rarely | 11:32 |
| mvo | cjwatson: anyway, I understand the current situation, I'm ok with waiting for more kernel/isolation fixes | 11: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 |
| mvo | cjwatson: obviously it depends on how long it will take if fixes are weeks away we need to consider what to do | 11:34 |
| ogra_ | would be nice if that could get an exception | 11:35 |
| cjwatson | mvo,ogra_: I think at least these current ones are OK. Scheduled | 11:45 |
| ogra_ | thx!! | 11:45 |
| mvo | cjwatson: thank you! | 11:46 |
| * kalikiana going for lunch in ~10 | 11:50 | |
| === ogra_ is now known as ogra | ||
| mup | PR snapd#4488 opened: snap: make `snap find --section` show all sections <Created by mvo5> <https://github.com/snapcore/snapd/pull/4488> | 12:03 |
| mborzecki | is tehre a way to tell if --argument was passed in command line? | 12:06 |
| zyga | mborzecki: hmm? | 12:07 |
| zyga | where? | 12:07 |
| ogra | zyga, 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 |
| zyga | yeah, I see | 12:10 |
| * pstolowski lunch | 12:10 | |
| mborzecki | zyga: 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 string | 12:12 |
| zyga | mborzecki: I don't know, there may be a way to do that with go-flags (optional argument) | 12:13 |
| * zyga coffee | 12:14 | |
| zyga | time to reinstall next, backup done | 12:14 |
| mborzecki | came up with some workaround: https://paste.ubuntu.com/26391469/ this is for https://bugs.launchpad.net/snapd/+bug/1742960 | 12:22 |
| mup | Bug #1742960: snap find --section does not list sections <snapd:In Progress> <https://launchpad.net/bugs/1742960> | 12:22 |
| mborzecki | haha, 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 busted | 12:28 | |
| zyga | especially that smart was OK | 12:28 |
| zyga | not sure what caused this | 12:28 |
| zyga | at least I will have a fresh filesystem there | 12:28 |
| zyga | kernel crashed on reboot | 12:39 |
| zyga | well | 12:39 |
| zyga | that's a good sign | 12:39 |
| zyga | ... | 12:39 |
| zyga | not | 12:39 |
| zyga | hmm | 12:40 |
| zyga | it's still doing something | 12:40 |
| zyga | just spews ... | 12:41 |
| zyga | ok | 12:49 |
| zyga | ok | 12:49 |
| zyga | this disk is gone | 12:49 |
| zyga | just broke after install | 12:49 |
| zyga | SMART my ass | 12:49 |
| * zyga is grumpy now | 12:49 | |
| * Chipaca hugs zyga | 12:52 | |
| mborzecki | salvage what you can, drill it through, throw it in the dumpster :/ | 12:52 |
| zyga | mborzecki: I have a full backup, so that's not a problem | 12:52 |
| Chipaca | i was going to suggest opening it and peeing on it, but i decided against it | 12:52 |
| zyga | mborzecki: and it "works" a little, just fails writes often | 12:53 |
| mborzecki | every now and then | 12:53 |
| zyga | Chipaca: I need some of that alien pee | 12:53 |
| Chipaca | zyga: that's your call | 12:53 |
| mborzecki | zyga: so now you can play with running linux on the chip that's inside the drive | 12:55 |
| mborzecki | zyga: http://spritesmods.com/?art=hddhack&page=1 | 12:55 |
| zyga | mborzecki: or buy those discounted fireworks | 12:56 |
| kalikiana | re | 13:14 |
| pachulo | Hi! 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 |
| Chipaca | pachulo: not yet no | 13:41 |
| pachulo | Chipaca: is there any rough guess? like: before the end of 2018? | 13:45 |
| Chipaca | pachulo: I'd expect it to be done before 18.10 | 13:45 |
| Chipaca | pachulo: but after 18.04 | 13:45 |
| Chipaca | pachulo: JamieBennett might be in a better position to offer a firmer answer, if one exists | 13:47 |
| pstolowski | niemeyer, one of my PRs that needs your re-review: https://github.com/snapcore/snapd/pull/4440 | 13:48 |
| mup | PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440> | 13:48 |
| mborzecki | niemeyer: https://github.com/snapcore/snapd/pull/4487 and https://github.com/snapcore/snapd/pull/4476 | 13:50 |
| mup | PR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487> | 13:50 |
| mup | PR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476> | 13:50 |
| mup | PR 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 |
| mvo | zyga: fwiw, I can reproduce the dbus error on bionic, it does not make sense to me our rule looks good | 13:59 |
| zyga | mvo: interesting, I can "try" on my current broken system | 14:00 |
| mvo | pedronis: 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 fedora | 14:00 |
| mvo | zyga: do you have any hints how to debug this? | 14:01 |
| pachulo | ok, thanks Chipaca | 14:02 |
| zyga | mvo: hold on, let me reproduce locally | 14:03 |
| Chipaca | are there go build flags that can be used to build something only on 14.04? | 14:03 |
| mvo | zyga: hm,hm, apparmor_parser -r /path/to/apparmor/profile seems to fix it :( | 14:03 |
| zyga | ouch :/ | 14:03 |
| zyga | that's not good | 14:03 |
| zyga | which profile did you reload, that of the app, right? | 14:03 |
| mvo | zyga: correct | 14:03 |
| mvo | zyga: 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 |
| pedronis | mvo: we can switch I suppose, the package I picked has a even simpler interface (but more code) | 14:05 |
| mvo | pedronis: 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 easier | 14:07 |
| pedronis | mvo: I need to go have my daily walk, I let you think a bit more | 14:08 |
| mvo | pedronis: I can to a POV port if you want (lets talk after your walk) | 14:08 |
| mborzecki | hm we don't seem to clean up udev rules in postrm and snap-mgmt | 14:09 |
| zyga | mvo: 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 |
| mborzecki | off to get the kids | 14:13 |
| mvo | zyga: sure, lets talk in a bit | 14:14 |
| mvo | zyga: 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 still | 14:16 |
| om26er | popey: Hey! mind taking a look at https://github.com/snapcrafters/android-studio/pull/13 ? | 14:19 |
| mup | PR snapcrafters/android-studio#13: Export missing library paths <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/13> | 14:19 |
| om26er | The change only affects the emulator. | 14:20 |
| zyga | mvo: hmmm | 14:26 |
| zyga | mvo: that's odd | 14:26 |
| mvo | zyga: yes | 14:26 |
| zyga | mvo: but the peer is an unconifned snap userd, right? | 14:26 |
| mvo | zyga: I assume so - also its strange that I can change/add back and things keep working | 14:27 |
| mvo | zyga: how can I find out if it is unconfined? | 14:27 |
| zyga | mvo: add that "peer" constraint? | 14:27 |
| zyga | mvo: and reload? | 14:27 |
| zyga | or not | 14:27 |
| mvo | zyga: thats what I did: first remove the peer constrain, reload -> works | 14:28 |
| mvo | zyga: then re-add the exact same constrain as before, reload -> works | 14:28 |
| zyga | which snap did you use for testing? | 14:28 |
| mvo | zyga: gimp | 14:30 |
| mvo | zyga: and reboot (with peer=(unconfined)) that worked before the reboot now fails again it seems. | 14:30 |
| zyga | and reboot the OS? | 14:30 |
| mvo | zyga: now I just rebooted the vm | 14:31 |
| zyga | mvo: reproduced, I didn't change anything though, just installed gimp and attempted to open the developer website | 14:35 |
| mvo | zyga: yeah, that fails for me as well | 14:35 |
| mvo | zyga: to make it work I had to remove the peer=un constrain | 14:36 |
| zyga | hmm, offtopic, installing snaps from gnome software shows the progress as stufk at 99% (after it completes in reality) | 14:37 |
| zyga | mvo: so | 14:40 |
| zyga | without touching the profiles or rebooting | 14:40 |
| zyga | I ran "snap userd" from the shell | 14:41 |
| zyga | and that made it work | 14:41 |
| zyga | mvo: | 14:43 |
| zyga | so this seems reproducible: activation doesn't work but after it is activated (in any way) it works correctly | 14:44 |
| zyga | mvo: activation from either running snap userd manually or activating via d-feet | 14:44 |
| zyga | mvo: I think we want to look at how that activation happens | 14:44 |
| zyga | mvo: perhaps (somehow, no idea) when activation is processed by apparmor is goes to a confined helper | 14:44 |
| zyga | mvo: (maybe that's the new thing in 18.04) | 14:44 |
| zyga | mvo: that just transitions to our service | 14:45 |
| zyga | mvo: note that the mechanism is just a speculation at this point | 14:45 |
| elopio | Hello! | 14:46 |
| * Chipaca -> physio | 14:48 | |
| jdstrand | peer=(unconfined) is not correct syntax | 14:49 |
| * jdstrand looks | 14:49 | |
| mvo | zyga: aha, nice | 14:50 |
| mvo | zyga: thanks, that explains why it works for me | 14:50 |
| mvo | zyga: thanks for figuring this out | 14:50 |
| mvo | zyga: will you update the bugreport or shall I? | 14:50 |
| jdstrand | peer=(label=unconfined) is correct and what is in the desktop interface | 14:50 |
| zyga | mvo: I'm still digging | 14:50 |
| zyga | mvo: yes, gladly | 14:50 |
| zyga | jdstrand: it doesn't work for activation (apparently) | 14:50 |
| zyga | jdstrand: I'm trying to understand how that happens in bionic | 14:51 |
| zyga | jdstrand: it works once activated | 14:51 |
| zyga | jdstrand: just tested on pristine install | 14:51 |
| jdstrand | zyga: it should work | 14:51 |
| jdstrand | userd is unconfined. dbus daemon may have a bug | 14:52 |
| jdstrand | on non-bionic, is userd already running? | 14:52 |
| jdstrand | ie, check if activation is working everywhere | 14:52 |
| * jdstrand tries on artful | 14:53 | |
| zyga | jdstrand: I dind't check on pre-bionic yet | 14:53 |
| zyga | jdstrand: on bionic I get an apparmor denial | 14:53 |
| jdstrand | zyga: can you paste it? | 14:53 |
| jdstrand | what is the binary in ps that I can check foruserd? | 14:54 |
| jdstrand | s/userd/ userd/ | 14:54 |
| pedronis | mvo: I'm back | 14:54 |
| zyga | jdstrand: it's "snap userd" | 14:54 |
| zyga | jdstrand: one sec, separate box | 14:54 |
| jdstrand | zyga: activation wrks on artful. browser opened just fine | 14:55 |
| zyga-bionic | sty 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 |
| zyga | jdstrand: activation works on bionc if the requester is unconfined | 14:56 |
| zyga | jdstrand: and doesn't work with this activation if the requester is confined (I used gimp, same as mvo above) | 14:56 |
| jdstrand | huh, there is no peer label | 14:56 |
| jdstrand | is that the complete line? | 14:57 |
| * jdstrand used gimp snap on artful | 14:57 | |
| zyga | jdstrand: yes | 14:57 |
| zyga | jdstrand: something must have changed in bionic | 14:58 |
| jdstrand | zyga: hard to say if that is a libapparmor bug or a dbus daemon issue | 14:58 |
| jdstrand | but dbus-daemon is not logging the peer_label, so that seems possibly to lean towards dbus-daemon | 14:59 |
| zyga | I'll update the bug with more details and look at how that works | 14:59 |
| jdstrand | zyga: what is the bug number? | 14:59 |
| zyga | is that filtering done in userspace by dbus or in kernel space on the socket? | 14:59 |
| zyga | jdstrand: my thought exactly, one sec | 14:59 |
| jdstrand | zyga: the kernel mediates access to the unix socket. dbus-daemon mediates the messages and signals | 14:59 |
| zyga | jdstrand: is dbusd using libapparmor? | 15:00 |
| jdstrand | zyga: yes | 15:00 |
| zyga | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1742687 | 15:00 |
| mup | Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1742687> | 15:00 |
| jdstrand | zyga: for dbus policy, think of the kernel as the database of rules that dbus-daemon can ask if an access is allowed or denied | 15:01 |
| jdstrand | zyga: it does that via libapparmor | 15:01 |
| zyga | I see | 15:01 |
| zyga | I'll have look, thankyou | 15:02 |
| jdstrand | zyga: then dbus-daemon allows/blocks the access | 15:02 |
| zyga | jdstrand: 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/files | 15:08 |
| mup | PR #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 |
| zyga | cachio: 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 timeout | 15:09 |
| zyga | cachio: 2018-01-15 13:03:14 Aborted tasks: 1165 | 15:09 |
| cachio | zyga, ups | 15:09 |
| cachio | zyga, which PR? | 15:10 |
| zyga | 4472 | 15:10 |
| zyga | I'll restart | 15:10 |
| zyga | maybe just a fluke | 15:10 |
| cachio | zyga, | 15:11 |
| cachio | zyga, when you have time could you please take a look to #4472 | 15:11 |
| mup | PR #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 |
| cachio | zyga, #4307 | 15:12 |
| mup | PR #4307: tests: fix "job canceled" issue and improve cleanup for snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4307> | 15:12 |
| cachio | sorry | 15:12 |
| zyga | cachio: no https://github.com/snapcore/snapd/pull/4472 | 15:18 |
| mup | PR #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 |
| zyga | mvo: there's a new patch for apparmor in bionic version of dbus | 15:21 |
| zyga | I'll check that out | 15:21 |
| zyga | and it talks about the connection security credentials | 15:21 |
| zyga | ie. exactly what broke | 15:21 |
| popey | diddledan: https://dashboard.snapcraft.io/snaps/opentyrian/ needs some screenshots :) | 15:23 |
| mvo | zyga: cool, thanks for investigating - do you have link? | 15:23 |
| zyga | mvo: for the patch? | 15:24 |
| zyga | mvo: it's in the bionic source package, I don't have a link | 15:24 |
| mvo | zyga: ok, what is the name of the patch? I get the package | 15:24 |
| zyga | aa-get-connection-apparmor-security-context.patch | 15:24 |
| mvo | ta | 15:24 |
| zyga | mvo: the idea is that ubuntu can use one of two ways to get security context | 15:24 |
| zyga | the old way (apaprmor label) | 15:24 |
| zyga | or the new way (generic dbus container via a mediator that introduces a new socket to dbus) | 15:25 |
| zyga | there's pently of logging there, I just want to see it somehow | 15:25 |
| mvo | zyga: aha, ok | 15:25 |
| zyga | mvo: the dbus-tests package has dbus that has verbose debugging activate | 15:27 |
| zyga | mvo: I think I don't need to build another copy, just make that active | 15:27 |
| * zyga tries | 15:27 | |
| popey | 33 | 15:29 |
| zyga | wow | 15:31 |
| zyga | I can cp a library over and my desktop explodes | 15:31 |
| zyga | interesting :) | 15:31 |
| popey | diddledan: also, micropolis | 15:32 |
| diddledan | dang, you mean I need to start playing some games?! oh the horror! | 15:33 |
| popey | diddledan: i have taken some if you want them, I'll put them in dropbox | 15:33 |
| diddledan | cool | 15:33 |
| diddledan | you da king of screenies | 15:34 |
| mvo | zyga: *cough* mv is your friend | 15:34 |
| zyga | mvo: I used cp because I didn't want to remove a file belonging to the package | 15:35 |
| zyga | but anyway, I'm looking for the logs | 15:35 |
| zyga | hmm, where is the systemd unit that describes the session bus? | 15:43 |
| zyga | dbus deamon on session bus | 15:43 |
| ogra | in Xorg it used to be part of the Xsession startup | 15:44 |
| ogra | not sure where it moved in wayland | 15:44 |
| zyga | I think I'm on xorg still actually | 15:45 |
| ogra | well, dig in /etc/X11/Xsession.d/ | 15:45 |
| seb128 | zyga, what are you trying to figure out? | 15:45 |
| seb128 | zyga, DBUS_SESSION_BUS_ADDRESS env variable? | 15:45 |
| ogra | seb128, how the session dbus is started | 15:45 |
| zyga | seb128: how to inject DBUS_VERBOSE=1 at the right spot | 15:46 |
| zyga | seb128: I want to enable dbus_verbose calls | 15:46 |
| diddledan | popey: done | 15:47 |
| popey | thanks! | 15:47 |
| diddledan | accidentally added the tyrian ones to micropolis for a second. | 15:47 |
| popey | lulz | 15:47 |
| seb128 | zyga, you need to rebuild dbus for that I think | 15:48 |
| seb128 | " DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus was | 15:49 |
| seb128 | compiled with verbose mode enabled. This is not recommended in | 15:49 |
| seb128 | production builds due to performance impact" | 15:49 |
| ogra | how developer friendly :P | 15:49 |
| diddledan | wow, opentyrian is popular: 2,992 total downloads | 15:49 |
| zyga | seb128: yes I thought the same but I replaced my bianries with those from dbus-tests package | 15:49 |
| zyga | seb128: it contains a second build with that option set | 15:50 |
| seb128 | ah | 15:50 |
| zyga | seb128: I think I just need to get the environment right now | 15:50 |
| seb128 | zyga, what the dbus-manapage recommends to do is | 15:50 |
| seb128 | DBUS_VERBOSE=1 dbus-daemon --session --print-address | 15:50 |
| seb128 | then set DBUS_SESSION_BUS_ADDRESS=<returned value> <yourprogram> | 15:51 |
| zyga | ok, let's try | 15:51 |
| ogra | seb128, but will that replace the already running dbus ? | 15:51 |
| seb128 | no | 15:51 |
| seb128 | that creates another bus | 15:51 |
| ogra | right | 15:51 |
| seb128 | but if you set the env it just makes your prog uses the new one | 15:51 |
| ogra | ah, indeed | 15:51 |
| seb128 | that might be good enough to debug the snapd issue | 15:52 |
| ogra | yeah, zyga will have to restart snapd wth the var set though | 15:52 |
| zyga | yes, trying now | 15:52 |
| seb128 | right | 15:52 |
| diddledan | yeesh, gimp: 80,279 total downloads | 15:52 |
| zyga | ogra: hmmm, that's curious | 15:52 |
| zyga | I just need that in snap run gim | 15:52 |
| zyga | not in snapd proper | 15:52 |
| ogra | well, you want your userd to be connected to that bus | 15:53 |
| ogra | not sure if thats coming from snapd or from something else | 15:53 |
| zyga | ogra: userd is spawned by the session | 15:53 |
| zyga | that's where the bug is | 15:53 |
| ogra | (snapd-xdg-open was so much easier :P ) | 15:53 |
| ogra | zyga, right | 15:53 |
| ogra | so you need the var in the userd startup script and need to restart userd | 15:54 |
| diddledan | is this the 18.04 url problem you're working on? | 15:54 |
| zyga | oh yeah | 15:54 |
| zyga | the glory of logging | 15:54 |
| zyga | all the way up to 11 | 15:54 |
| seb128 | zyga, 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 :p | 15:54 |
| zyga | thank you seb128 | 15:54 |
| seb128 | yw :) | 15:54 |
| zyga | ogra: it's all temporary until that new IPC takes over ;) | 15:54 |
| ogra | kdbus :P | 15:54 |
| zyga | no, that newer one | 15:55 |
| zyga | remote var something | 15:55 |
| seb128 | zyga, don't forget to make the script +x if you do that | 15:55 |
| Pharaoh_Atem | mvo: so it seems that Debian is the weird one for the GCC arm triple | 15:56 |
| Pharaoh_Atem | I just checked Fedora, Mageia, and SUSE, and the arm triple is the same for all three | 15:57 |
| Pharaoh_Atem | there's nothing that specifies an override or anything | 15:57 |
| zyga | hrm | 15:57 |
| zyga | no new logs when I xdg-open with all the right bits inside | 15:57 |
| zyga | probably dbus client code in the core snap is the problem | 15:57 |
| mvo | Pharaoh_Atem: thanks for checking! sad that the triplet is so loosely defined | 15:57 |
| zyga | jdstrand: 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 se | 15:58 |
| zyga | jdstrand: I ran "DBUS_VERBOSE=1 dbus-daemon --session --print-address" in one terminal | 15:59 |
| zyga | jdstrand: then ran "snap run --shell gimp" in another one | 15:59 |
| seb128 | zyga, did you set DBUS_SESSION_BUS_ADDRESS= to the value from the one you started with verbose? | 15:59 |
| Pharaoh_Atem | mvo: 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 |
| zyga | exported DBUS_SESSION_ADDRESS= in another one | 16:00 |
| zyga | seb128: yes | 16:00 |
| zyga | I also set DBUS_VERBOSE=1 on the client side but since it's the core snap, I suspect that is futile | 16:00 |
| Pharaoh_Atem | mvo: 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 openSUSE | 16:01 |
| zyga | gcc as a snap would be great | 16:01 |
| zyga | especially with instances and tracks | 16:01 |
| Pharaoh_Atem | zyga: don't get any ideas | 16:01 |
| Pharaoh_Atem | :) | 16:01 |
| zyga | Pharaoh_Atem: my idea for today is to get drunk | 16:01 |
| Pharaoh_Atem | approved | 16:02 |
| zyga | I just don't have alcohol | 16:02 |
| zyga | so I'll make tea instead | 16:02 |
| zyga | and read a book | 16:02 |
| zyga | just as good | 16:02 |
| Pharaoh_Atem | denied :) | 16:02 |
| zyga | hrm | 16:04 |
| zyga | hmm | 16:15 |
| zyga | dbus doesn't build for me on bionic | 16:15 |
| zyga | one of the tests fails | 16:15 |
| seb128 | ignore the test if it's for local testing? | 16:15 |
| zyga | yeah, I guess I have to | 16:16 |
| ogra | zyga, also, did you add DBUS_SESSION_BUS_ADDRESS= to the userd startup ? | 16:18 |
| ogra | else it will simply connect to the default session but | 16:18 |
| ogra | *bus | 16:18 |
| ogra | i doubt a simple export in a shell will apply to a systemd user session start script | 16:19 |
| zyga | ogra: userd is supposed to be started by the session | 16:19 |
| zyga | ogra: this is what the bug is about | 16:19 |
| zyga | ogra: it doens't run at all :) | 16:20 |
| ogra | zyga, userd will likely be started by a systemd user session unit | 16:20 |
| zyga | doesnt* | 16:20 |
| zyga | no, it didn't start with the session | 16:20 |
| ogra | if you dont do the export in the unit it wont have the var set | 16:20 |
| zyga | and doesn't autostart (because of the bug) anyway | 16:20 |
| zyga | it will have the var set | 16:20 |
| zyga | because it's ... started by the session | 16:20 |
| zyga | which I started | 16:20 |
| ogra | oh, its a dbus service ? | 16:20 |
| zyga | and to which I'm talking from snap run --shell gimp | 16:20 |
| zyga | yes :) | 16:20 |
| ogra | ah | 16:21 |
| zyga | I don't have a fix yet, something is still fishy | 16:21 |
| zyga | ogra: if I start it myself everything works (no bug) | 16:21 |
| zyga | it's just activation that breaks | 16:21 |
| ogra | right | 16:21 |
| zyga | something is messing up the peer credentials | 16:21 |
| zyga | I'm building without unit tests now | 16:21 |
| steph250 | hello all | 16:26 |
| zyga | hello steph250 | 16:27 |
| kalikiana | steph250: what's up | 16:28 |
| steph250 | Trying to setup my 1st snap, on raspberry, but ... | 16:29 |
| === Guest69214 is now known as jero-- | ||
| brunosfer | Hey 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 |
| Chipaca | ogra: ^ | 16:42 |
| Chipaca | steph250: but...? | 16:42 |
| zyga | brunosfer: depends on what your goal is | 16:43 |
| zyga | brunosfer: to make software for core devices or to make core devices | 16:43 |
| ogra | brunosfer, to my knowledge we dont have any plans on later dragonboards etc ... | 16:45 |
| steph250 | facing some issue with libraries, like "not found". | 16:45 |
| zyga | steph250: those libraries must be in your snap, your snap needs to contain machinery (environment variables) to find them | 16:45 |
| zyga | steph250: also mvo is exploring making some of those requirements obsolete eventually (snapcraft works around those today) | 16:46 |
| ogra | brunosfer, 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 supported | 16:46 |
| steph250 | Not so sure, zyga. Just found some topics on the forum, for the same. Looking into that, at the moment. | 16:47 |
| zyga | ah | 16:49 |
| zyga | so the plot thickens | 16:49 |
| zyga | the snap userd binary is not started by the dbus session bus now (obviously now that I think about it) | 16:50 |
| zyga | but by systemd | 16:50 |
| zyga | so I never hit my debug builds | 16:50 |
| zyga | so now I really want to know where those generated units are | 16:50 |
| zyga | or how do I edit my systemd-stared session bus to contain information about my verbose build | 16:50 |
| zyga | mvo: ^ ideas welocme | 16:51 |
| zyga | *welcome | 16:51 |
| steph250 | Trying to see the tutorials... So, starting from "snapcraft init" and ... it fails :-) | 16:51 |
| zyga | steph250: what's your environment? | 16:51 |
| zyga | where do you run snapcraft? | 16:51 |
| brunosfer | zyga: It's to make software for core devices. | 16:52 |
| zyga | ideally that would be ubuntu 16.04 | 16:52 |
| mvo | zyga: snapd userd is auto-started via /usr/share/dbus-1/services | 16:52 |
| mvo | zyga: once it is used | 16:52 |
| zyga | brunosfer: then don't bother, get another pi (e.g. pi3 if you had a pi2 before) | 16:52 |
| brunosfer | ogra: but if the DragonBoard 410C is already discontinued, doesn't make much sense to buy it... | 16:52 |
| zyga | mvo: thanks let me look at that | 16:52 |
| mvo | zyga: so maybe that is something that in bionic system took over (is that what you are saying)? | 16:52 |
| steph250 | freshly installed Raspberry with Jessie | 16:53 |
| ogra | brunosfer, well, we dont have any other board like this in the supported set atm | 16:53 |
| zyga | mvo: I'm saying that systemd now starts that | 16:53 |
| ogra | i.e. arm64 based | 16:53 |
| zyga | mvo: it doesn't let the session auto start anymore | 16:53 |
| brunosfer | zyga: 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 building | 16:53 |
| zyga | it'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 |
| zyga | brunosfer: I see, then getting a dragon is probably the "best" way because it's supported | 16:53 |
| brunosfer | ogra: Yeah, maybe I'll check the Artik | 16:54 |
| zyga | brunosfer: I have one but it's not a fantastic board IMO | 16:54 |
| zyga | mvo: now I wonder how to coerce systemd to talk to my session bus | 16:54 |
| ogra | zyga, ! | 16:54 |
| brunosfer | zyga: Yeah, I ordered one some time ago, however, never got it due to be discontinued... | 16:54 |
| zyga | mvo: I may switch to that workaround session bus | 16:54 |
| zyga | script that seb128 suggested | 16:54 |
| ogra | the dragonboard is a fantastic arm64 board :) | 16:54 |
| brunosfer | zyga: But I was looking to DragonBoard 410C exactly because canonical has an official image. | 16:55 |
| mvo | zyga: systemd starts a user process afaik when you login | 16:55 |
| zyga | ogra: no etherhet, no sata (with hrw voice), hardcoded ram split for gpu | 16:55 |
| mvo | zyga: so systemd --user iirc | 16:55 |
| zyga | ogra: I'd rather have 4GB RAM and ethernet | 16:55 |
| mvo | zyga: and its per user, not per session | 16:55 |
| zyga | oh? per user | 16:55 |
| zyga | mvo: I'll copy the debug shell hack and | 16:55 |
| zyga | mvo: and reboot | 16:55 |
| mvo | zyga: I thnk so, iirc there is no systemd login session support | 16:55 |
| zyga | mvo: I wanted to just redirect how snap userd is activated | 16:56 |
| zyga | mvo: I feel I don't get how that really works now | 16:56 |
| diddledan | if 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 |
| diddledan | the usual place for system-level definitions for services is at /lib/systemd/system | 16:59 |
| zyga | diddledan: even for user session services? | 17:03 |
| zyga | diddledan: and this seems to be a generated unit from the regular dbus unit generator | 17:03 |
| * Chipaca wanders off to poke at broken things some more | 17:04 | |
| diddledan | looks like user-level services are at /usr/lib/systemd/user | 17:06 |
| diddledan | e.g. zeitgeist | 17:06 |
| steph250 | back ;-) | 17:08 |
| zyga | ah | 17:11 |
| zyga | silly me | 17:11 |
| zyga | systemct --user | 17:14 |
| zyga | hmm, I don't think systemctl --user really does what I think it does, I don't see any user session things | 17:20 |
| steph250 | zyga: 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 |
| steph250 | zyga: Any idea ? | 17:23 |
| Chipaca | steph250: raspbian? | 17:23 |
| Chipaca | isn't that arm6? | 17:23 |
| steph250 | PI-2, yes | 17:24 |
| * kalikiana wrapping up for today | 17:24 | |
| Chipaca | I don't think we support raspbian | 17:24 |
| ogra | Chipaca, arm6 != ARMv6 :) | 17:24 |
| ogra | (we dont support either though) | 17:24 |
| Chipaca | ogra: should I have said "isn't that ARMv6"? | 17:25 |
| ogra | yeh | 17:25 |
| ogra | *yeah | 17:25 |
| Chipaca | ogra: i mean, it's armel | 17:25 |
| Chipaca | we don't support armel, we support armhf | 17:25 |
| Chipaca | so we support the pi 2, but not with raspbian because all the binaries are icky or something | 17:25 |
| Chipaca | :-) | 17:25 |
| zyga | steph250: that's not supported | 17:25 |
| * Chipaca tries again to wander off to fix things | 17:26 | |
| ogra | arm6 is actually ARMv3 | 17:26 |
| steph250 | I guessed, yes ... | 17:26 |
| ogra | from around 1991 :) | 17:26 |
| * zyga shakes fist at dbus | 17:26 | |
| zyga | I'll get to the bottom of this bug | 17:26 |
| ogra | nobody supports that anymore ... not even armel | 17:26 |
| steph250 | so, no way to use SNAPS on raspberry PI2 ? | 17:26 |
| ogra | steph250, ?? | 17:26 |
| ogra | http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ | 17:27 |
| ogra | there are pi2 ubuntu-core images | 17:27 |
| zyga | steph250: note that raspberry pi 2 can run more modern software just fine, but you cannot use raspbian | 17:27 |
| ogra | http://cdimage.ubuntu.com/ubuntu-server/xenial/daily-preinstalled/current/ | 17:27 |
| ogra | and here are classic ubuntu-server images that should be able to run snaps | 17:28 |
| zyga | oh boy, my dbus logs a lot | 17:29 |
| zyga | gdm doesn't start yet tho | 17:29 |
| steph250 | not good news :-( | 17:30 |
| zyga | steph250: sorry, we cannot do anything about that | 17:31 |
| steph250 | no issue. any idea why it's not supported ? I mean, would it be possible ? | 17:32 |
| zyga | steph250: because raspbian uses a different ABI that is compatible with older processors | 17:32 |
| zyga | steph250: everyone else uses the newer ABI, snapd can be added to raspbian but snaps wound't work on some machines (pi zero) | 17:32 |
| zyga | steph250: so there's no real support for raspbian yet | 17:33 |
| steph250 | this, I saw :-) | 17:33 |
| diddledan | ogra: oh, awesome, I didn't know there were classic variants of ubuntu available for the pi | 17:33 |
| ogra | diddledan, only pi2 afaik | 17:34 |
| zyga | hmm | 17:34 |
| zyga | so | 17:34 |
| zyga | the debug build logs but doesn't start gdm | 17:34 |
| * zyga inspects why | 17:35 | |
| zyga | sty 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 |
| zyga | why the space?! | 17:37 |
| ogra | probably there are args it chops off before | 17:38 |
| ogra | (and does that badly) | 17:38 |
| zyga | sty 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 |
| ogra | i doubt that would make it fail though | 17:39 |
| zyga | hmm mhmmm | 17:40 |
| zyga | it's my hack with a shell script that execs the real thing | 17:40 |
| zyga | but I don't see how | 17:40 |
| zyga | this is what it does: | 17:40 |
| zyga | exec /usr/lib/dbus-1.0/debug-build/bin/dbus-daemon "$@" | 17:40 |
| diddledan | if $@ is empty then it'll send a string as the first argument with no content | 17:41 |
| ogra | yeah | 17:41 |
| diddledan | ie. empty string, not "no argument" | 17:41 |
| zyga | oooh? | 17:41 |
| zyga | shit | 17:41 |
| zyga | shoud I use "$*" instead? | 17:41 |
| zyga | I thought "$@" what the "right" way to do things | 17:42 |
| diddledan | when $@ has nothing inside it, then "$@" will evaluate to "" which in bash will evaluate to an argument of zero length | 17:44 |
| diddledan | that is it WILL be an argument | 17:44 |
| zyga | man | 17:44 |
| zyga | bash sucks | 17:44 |
| zyga | shell sucks | 17:44 |
| zyga | thank you for teaching me | 17:44 |
| diddledan | so if you did `foo ""` then $1 in foo will exist, but be empty. it isn't the same as `foo` where $1 will not exist | 17:45 |
| zyga | sure | 17:46 |
| zyga | this is why it failed | 17:46 |
| diddledan | bit silly really, you're right | 17:46 |
| diddledan | it's a legacy thing I guess | 17: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 |
| zyga | diddledan: yes, that's true :) | 17:48 |
| diddledan | I guess sometimes legacy can bite :-p | 17:48 |
| zyga | 2251 "aliens to humans: why is $@ expaning to an empty string" | 17:51 |
| zyga | ... | 17:51 |
| * zyga wishes for FCKSH | 17:51 | |
| zyga | fricking sensible shell | 17:52 |
| diddledan | lol | 17:52 |
| diddledan | the "sh" is silent, and the "fck" is said like the popular swear | 17:52 |
| diddledan | "I'm having trouble will my bash script" .. "just fck it, instead" | 17:53 |
| zyga | hahaha | 17:53 |
| mup | PR 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 |
| cjwatson | diddledan: no, that's wrong - "$@" has magic behaviour and does not expand to a single empty argument in the case of zero arguments | 17:58 |
| zyga | ok, my hack boots now | 17:58 |
| zyga | cjwatson: ah, so maybe my memory wasn't broken | 17:59 |
| zyga | still, my ssystem is trying to start gdm, failing | 17:59 |
| cjwatson | zyga: maybe the problem is at the next layer up | 17:59 |
| zyga | cjwatson: it's speed, dbus is so slow now that things time out :-( | 17:59 |
| cjwatson | chapter and verse from bash(1): | 18:00 |
| cjwatson | When there are no positional parameters, "$@" and $@ expand to | 18:00 |
| cjwatson | nothing (i.e., they are removed). | 18:00 |
| diddledan | well that's even more weird legacy then :-p | 18:00 |
| zyga | so I _was_ right to use "$@" | 18:00 |
| zyga | at least I wasn't crazy that I thought it is special somehow | 18:00 |
| cjwatson | yes, it is the right thing in that sort of wrapper | 18:00 |
| zyga | hmm | 18:01 |
| diddledan | "if a variable is empty, does it leave a string?" .. "yes. except when it doesn't" | 18:01 |
| cjwatson | "$@" is the single exception | 18:01 |
| zyga | ok | 18:02 |
| zyga | so I have a hack workaround :) | 18:02 |
| zyga | I booted gdm without debug | 18:02 |
| zyga | now I can switch on debugging for the session where I log in | 18:02 |
| zyga | woot | 18:02 |
| diddledan | \o/ | 18:02 |
| zyga | and I'm logged in | 18:03 |
| zyga | woooot | 18:03 |
| zyga | ok, let's reproduce the bug now | 18:03 |
| diddledan | now to actually do the debug | 18:03 |
| diddledan | "my debug didn't work." .. "did you debug your debug?" | 18:03 |
| davidcalle | kyrofa: fyi, just landed https://docs.snapcraft.io/build-snaps/syntax | 18:03 |
| zyga | mm | 18:05 |
| zyga | sty 15 19:04:56 kaedwen systemd-journald[273]: Forwarding to syslog missed 817 messages. | 18:05 |
| zyga | how can I make journal not do that and instead give me the real thing | 18:05 |
| diddledan | davidcalle: for the `version` docs you need to point out that a numeric-only value is incorrect UNLESS it is wrapped in quotes | 18:06 |
| jdstrand | zyga: 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-daemon | 18:06 |
| diddledan | i.e. `version: 1.0` is illegal | 18:06 |
| zyga | jdstrand: yes, I think it's the new dbus + the ubuntu-only patch that broke it | 18:07 |
| diddledan | `version: '1.0'` is correct | 18:07 |
| jdstrand | zyga: 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 release | 18:08 |
| jdstrand | I see too much getting dropped in /var/log/syslog :\ | 18:08 |
| zyga | jdstrand: http://paste.ubuntu.com/26393153/ | 18:08 |
| zyga | this is the full-so-far log from when I try to use xdg-open | 18:08 |
| diddledan | davidcalle: `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 log | 18:09 | |
| jdstrand | zyga: I suspect the lack of peer_label in the log is a clue | 18:09 |
| jdstrand | zyga: note that dbus is the thing logging | 18:10 |
| zyga | https://paste.ubuntu.com/26393163/ | 18:11 |
| zyga | this is a better one | 18:11 |
| jdstrand | if I were looking at this, I would take a look at those <null> entries in the log | 18:11 |
| zyga | thanks, I'll look now | 18:11 |
| zyga | I can build and iterate on this now | 18:11 |
| jdstrand | sty 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 |
| jdstrand | I don't *know* that the null is meaningful. I do know that the lack of peer_label is definitely wrong | 18:14 |
| jdstrand | since the rule specifies a peer label, if dbus-daemon doesn't find it correctly, that would suggest why it might not match | 18:14 |
| jdstrand | zyga ^ | 18:14 |
| zyga | jdstrand: yes | 18:18 |
| zyga | jdstrand: this also matches mvo's experiments where removing peer label requirement "fixed it" | 18:18 |
| * jdstrand nods | 18:18 | |
| jdstrand | removing it would mean match any peer | 18:18 |
| zyga | jdstrand: yep | 18:19 |
| zyga | next up, dive into dbus | 18:19 |
| zyga | but first | 18:19 |
| zyga | does anyone know Jeremy Bicha | 18:19 |
| zyga | he made the last upload with the new apparmor patch | 18:20 |
| jdstrand | zyga: he participates on the desktop. see #ubuntu-desktop | 18:20 |
| jdstrand | zyga: 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 |
| zyga | jdstrand: thank you! that's a nice idea | 18:22 |
| zyga | jdstrand: hmm :) | 18:23 |
| zyga | From: Tyler Hicks <tyhicks@canonical.com> | 18:23 |
| zyga | the patch is from tyler | 18:23 |
| zyga | I should have spotted that a long time ago | 18:23 |
| zyga | my bet is that that patch doesn't work | 18:23 |
| zyga | or isn't applied (I'll check but I'd be suprirsed) | 18:23 |
| zyga | so maybe getly ask tyler if it works on his bionic :) | 18:23 |
| zyga | I'll get something to drink and get back to digging | 18:23 |
| jdstrand | possible. also possible is libapparmor change. I'm just guessing at this point since I haven't looked at any of this | 18:24 |
| davidcalle | diddledan: thanks for the feedback, it's mostly a layout update, content fixes on their way | 18:24 |
| zyga | jdstrand: I'll look at changelogs | 18:24 |
| jdstrand | iirc, the patch doesn't have to do with peer labeling, but closing a hole wrt dbus snooping | 18:24 |
| jdstrand | I guess I could pull down the package... | 18:25 |
| zyga | hmm, are you sure? | 18:25 |
| zyga | Allows the AppArmor label that is attached to a D-Bus connection to be | 18:25 |
| zyga | queried using the unique connection name. | 18:25 |
| zyga | that's the patch description ^ | 18:25 |
| zyga | I also added it to the forum | 18:25 |
| jdstrand | oh, well, that certainly seems on point. maybe it doesn't need to be applied or needs to be applied differently | 18:25 |
| zyga | jdstrand: no worries, I'm just broadcasting my progress | 18:26 |
| zyga | jdstrand: I'll look at what's going on there, I never touched dbus guts before | 18:26 |
| zyga | but first, something to drink | 18:26 |
| jdstrand | zyga: I'm betting something changed with how it determines the label of a non-activated service | 18:28 |
| jdstrand | (since it isn't running yet) | 18:28 |
| jdstrand | anyhoo | 18:28 |
| jdstrand | zyga: good luck! :) | 18:28 |
| zyga | mmm, good idea | 18:28 |
| zyga | thanks, just looking at call graph | 18:29 |
| zyga | ok, back | 18:51 |
| zyga | shower should help to attack this problem :) | 18:51 |
| zyga | so I see where the peer label is set | 19:11 |
| zyga | I'll debug there | 19:11 |
| zyga | seems like the only place that can go wrong | 19:11 |
| zyga | (or that this code is now unused due to other changes0 | 19:11 |
| cachio | zyga, there? | 19:46 |
| cachio | zyga, in file cmd/snap-mgmt/snap-mgmt-sh-in, "@SNAP_MOUNT_DIR@" is /snap for fedora | 19:47 |
| cachio | zyga, sorry, for opensuse | 19:48 |
| cachio | zyga, is it ok, right? | 19:48 |
| NateGraham | Hello 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 system | 19:49 |
| NateGraham | When 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' failed | 19:49 |
| NateGraham | the distro is KDE Neon, which is based on Ubuntu 16.04 | 19:49 |
| NateGraham | @Riddell! Do you know if Snap is expected to work in KDE Neon? | 19:53 |
| Riddell | NateGraham: well yes but it gets precious little testing so thanks for looking at it | 19:53 |
| Riddell | NateGraham: do you have snapd installed and kde-frameworks snap installed? | 19:53 |
| NateGraham | let me see | 19:56 |
| NateGraham | I definitely have snapd installed; what's the package name for the framework though? | 19:58 |
| zyga | cachio: yes | 19:59 |
| zyga | cachio: yes, it's /snap for opensuse | 19:59 |
| zyga | NateGraham: hello! | 19:59 |
| cachio | zyga, tx | 20:00 |
| NateGraham | Hello | 20:00 |
| zyga | NateGraham: do you know what happens under the hood there? what kind of request flies to snapd? | 20:00 |
| zyga | I | 20:00 |
| NateGraham | I haven't a clue; I'm new to Snap | 20:00 |
| zyga | I'm a snapd developer though you probably want to talk to Chipaca about that particular problem | 20:00 |
| zyga | NateGraham: which API are you using to talk to snapd? | 20:00 |
| NateGraham | if you'd like, I can try to focus on a CLI test case so we can nail it down | 20:01 |
| zyga | NateGraham: that's okay, eventually all APIs talk to snapd over a socket, there's one real API internally | 20:01 |
| zyga | NateGraham: though for gnome-software there's extra work on authentication | 20:01 |
| zyga | NateGraham: and there's some polkit around that as well, but I think transparently and internally in snapd | 20:02 |
| NateGraham | we're using snapd-glib | 20:02 |
| zyga | NateGraham: that's great | 20:02 |
| zyga | it talks to the socket under the hood so you should be good | 20:02 |
| Riddell | NateGraham: kde-frameworks-5 snap needs to be installed before any Neon snaps will work | 20:03 |
| zyga | Riddell: snapd doesn't yet handle that AFAIK but this functionality is coming via the default provider work that mvo is doing | 20:03 |
| Riddell | zyga: right, that's why it needs to be installed first | 20:04 |
| zyga | (so eventually this fact will be handled internally) | 20:04 |
| Riddell | which should be the case with a KDE neon install | 20:04 |
| zyga | right | 20:04 |
| NateGraham | RIddell: are you sure that's the package name? | 20:04 |
| zyga | NateGraham: you can manually try if it works "snap install kde-frameworks-5" | 20:04 |
| Riddell | NateGraham: yep, I have.. | 20:04 |
| Riddell | Name Version Rev Developer Notes | 20:04 |
| Riddell | core 3748 canonical broken | 20:04 |
| Riddell | kde-frameworks-5 13 kde broken | 20:04 |
| zyga | broken? | 20:04 |
| zyga | that looks bad | 20:05 |
| zyga | hmm | 20:05 |
| NateGraham | oh oh course, this is a snap package, not an apt package, pardon my ignorance | 20:05 |
| NateGraham | it is indeed already installed | 20:05 |
| zyga | NateGraham: I'm worried by those broken notes | 20:05 |
| NateGraham | that's on Riddell's system, not mine :) | 20:06 |
| NateGraham | though of course mine may be broken, too | 20:06 |
| zyga | NateGraham: can you pastebin logs from snapd.service please? | 20:06 |
| Riddell | I was fiddling around with them earlier to fix my plasma screenshots which I guess broke them | 20:06 |
| zyga | ah | 20:06 |
| zyga | so they are not generally broken | 20:07 |
| zyga | having broken core is definitely a problem for installing snaps | 20:07 |
| zyga | so if you can get that in order you may have more luck | 20:07 |
| Riddell | I mounted the snaps manually and I guess it didn't like that | 20:07 |
| NateGraham | https://pastebin.com/a9X5kjBC | 20:07 |
| Riddell | unmounted rather | 20:07 |
| zyga | otherwise 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 |
| zyga | Riddell: if you mount it does snap list show it as non-broken? | 20:08 |
| Riddell | zyga: I don't know how to mount them again | 20:08 |
| Riddell | I am destroyer of snapd | 20:08 |
| zyga | Riddell: just start the systemd mount unit | 20:08 |
| zyga | (for that particular snap and revision) | 20:09 |
| Riddell | zyga: well a reboot started my issue, but I still can't get my snaps to work | 20:23 |
| Riddell | oh hoorah found one which does run, falkon | 20:25 |
| Riddell | but mm plasma-discover integration not happy | 20:25 |
| Riddell | NateGraham: so aye maybe snaps not in a great shape just now I'm afraid :( | 20:25 |
| Riddell | NateGraham: 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 snaps | 20:25 |
| * Riddell out | 20:26 | |
| NateGraham | do you have the snap backend installed? | 20:26 |
| NateGraham | compiled from git master, that part works for me, at least | 20:26 |
| seb128 | zyga, thanks for the work on debugging that dbus issue, let me know if we can help | 20:32 |
| zyga | seb128: 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 prints | 20:45 |
| seb128 | zyga, that commit seems new in the updated version, https://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.12&id=dc25979eb | 20:46 |
| seb128 | from 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 |
| zyga | yes, looks new and interestingly contains | 20:46 |
| zyga | + if (dst_con != NULL) | 20:46 |
| zyga | + { | 20:46 |
| zyga | + dst_label = dst_con->label; | 20:46 |
| zyga | so ... maybe :) | 20:46 |
| seb128 | jdstrand, ^ | 20:46 |
| zyga | I will definitely try that (but watching new startrek with wife now :) | 20:47 |
| zyga | bbl :) | 20:47 |
| seb128 | zyga, enjoy! | 20:47 |
| mwhudson | cleanbuild with snapcraft tip or near tip is failing for me | 20:48 |
| mwhudson | error: open /var/lib/snapd/hostfs/home/mwhudson/snap/lxd/common/snapcraft2c0cyxw6/core_3748.assert: no such file or directory | 20:48 |
| mwhudson | (building a classic snap, if that matters) | 20:48 |
| Chipaca | I wasn't here, but I am here now. Can I still help? | 21:06 |
| Chipaca | if no reply in a minute, I shall take the dog for a walk. | 21:07 |
| Chipaca | ok two minutes | 21:07 |
| === apw_ is now known as apw | ||
| mwhudson | cleanbuild with snapcraft tip *built as a snap* is failing for me | 21:59 |
| zyga | mwhudson: hey | 22:17 |
| zyga | mwhudson: do you think you would have some time to update snapd in debian? | 22:18 |
| zyga | mwhudson: it seems people still have issues with apparmor there | 22:18 |
| mwhudson | zyga: there is a new one in sid | 22:27 |
| mwhudson | zyga: would be interesting to know if it works at all :-) | 22:27 |
| zyga | mwhudson: thank you for letting me know, I will try it and reply to the people on the forum | 22:39 |
| mwhudson | hmm why can i not install the new snapd in this vm | 22:39 |
| * zyga pulls in 200MB of sid updates | 22:41 | |
| mwhudson | uh no really why | 22:42 |
| zyga | what's wrong? | 22:42 |
| mwhudson | 2.30-3 is in the pool but not the indices | 22:42 |
| zyga | that's ... odd | 22:42 |
| mwhudson | oh wait | 22:43 |
| zyga | some migration script didn't publish it? | 22:43 |
| mwhudson | no only the dsc is in the pool, the debs are not | 22:43 |
| mwhudson | maybe i'm about to learn something about debian | 22:43 |
| mwhudson | ah yeah look https://buildd.debian.org/status/package.php?p=snapd <- uploaded, not installed | 22:43 |
| zyga | mips -- build attempted | 22:44 |
| mwhudson | yea but they've never built | 22:44 |
| zyga | mwhudson: do we have more arch blacklisting to do? | 22:44 |
| mwhudson | and i didn't think failed builds prevented publication to unstable | 22:45 |
| zyga | mwhudson: so is it just pending publishing or do you need to do another upload with some arches disabled? | 22:52 |
| zyga | curious, I updated apt and then apt found way more updates | 22:59 |
| zyga | meh, time to sleep | 23:00 |
| zyga | ttyl | 23:00 |
| mwhudson | zyga: i don't know | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!