=== chihchun_afk is now known as chihchun [05:59] morning [06:16] Bug #1743301 opened: cannot install apps using snap on Korora [08:04] mvo: morning [08:04] mvo: something for snap-advise https://bugs.launchpad.net/snapd/+bug/1742677 [08:04] Bug #1742677: snap run should error nicely when snap isn't installed [08:07] good morning [08:08] mborzecki: thanks, checking [08:08] kalikiana: good morning [08:08] mborzecki: and good morning to you! [08:10] mornings! [08:12] kalikiana: pstolowski: morning [08:12] o/ [08:12] mvo: good morning [08:12] \o [08:13] mvo: I have a question to you as a apt maintainer, [08:13] mvo: when a hdd is corrupted and dpkg database is partially blown away, is it sensible to try to reinstall some packages [08:13] mvo: or should I just backup home and reinstall the whole thing [08:17] zyga: well, thats a tough one :) most of the time liberal use of "apt install --reinstall $stuff" makes things work again [08:17] zyga: hey [08:18] 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] 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] and good morning pstolowski [08:23] I tried a small reinstall but apt dpkg complained about some packages have empty list of files, [08:23] I'll do full reinstall :/ [08:26] zyga: well, empty list of files should not be a hard error [08:26] zyga: can you pastebin the error ? [08:26] zyga: *if* you want to resovle this tihs way [08:26] dpkg: unrecoverable fatal error, aborting [08:27] zyga: there were some more before that I'm sure [08:27] (then localized), list of files in package "libc6-dbg:amd64" contains empty file name [08:27] hey there [08:27] is bug #1742687 likely a regression in snapd? [08:27] Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 [08:27] the title might be misleading, he's using 2.30 which is not in other ubuntu series [08:28] seb128: perhaps, I think the url opening moved to snapctl (but I may be mistaken) [08:29] zyga, could somebody familiar with that part of the codebase check if there is an issue? [08:29] 09:29:05 up 12:42, 7 users, load average: 14.75, 13.00, 11.22 :/ building snapd yocto image on x220 [08:30] zyga: you could try "dpkg --purge libc6-dbg" but probably not worth it [08:30] seb128: yes, for sure [08:30] thx [08:30] mvo: that doesn't work [08:30] same error [08:31] 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] k [08:31] zyga: and then re-try the --reinstall ? [08:32] mvo: that file doesn't exist at all [08:32] ah, no sorry [08:32] zyga: no "/var/lib/dpkg/info/libc6-dbg\:amd64.list " ? [08:32] shell has issues with : in filenames :/ [08:32] heh [08:32] mvo: I'll ski [08:32] mvo: inside I see a DBUS XML profile [08:32] zyga: haha [08:32] mvo: my disk is a messed up soup [08:33] zyga: there you go [08:33] mvo: I'm making a bootable usb now [08:33] :/ [08:33] zyga: well, you could try to repair this one [08:33] zyga: of course if that is all over the place> FAIL [08:33] mvo: fsck printed a huge list of changes [08:33] mvo: I think that's not a happy disk [08:34] ok [08:35] zyga: smart did't raise a warning or anything? [08:35] zyga: good luck - do you happen to have an 18.04 vm? or sebs bug? [08:35] mborzecki: not a single one [08:35] mborzecki: I'm running small test [08:35] mvo: I don't have 18.04 vm yet, no [08:35] ok [08:37] zyga: at least tell us the band of the disk, and why it ahppens to be a seagate? :) [08:37] mborzecki: wd [08:37] mborzecki: they all eventually fail :/ [08:37] it's a 1TB blue [08:37] 832 start/stop cycles [08:38] 3 months and 1 day of uptime total [08:38] so... [08:38] :/ [08:38] * mborzecki goes to check smart log on his nas disks [08:40] * zyga tarballs home and DDs 17.10 installer to usb [08:41] mvo: do you think I could reinstall 18.04 instead [08:41] I wonder if that could help with the bug in a meaningful way [08:42] seb128: http://cdimage.ubuntu.com/releases/17.10.1/release/ - is the 17.10.1 release due to meltdown? [08:43] zyga: sure, can't hurt to install 18.04 [08:43] zyga, no [08:43] zyga: 17.10.1 might also be because of the bios issue with lenovo [08:43] what mvo said [08:43] ah, I see [08:43] I'll do 18.04 [08:43] let's see what's coming === jdstrand_ is now known as jdstrand [09:35] hey there Chipaca [09:35] zyga: o/! [09:35] zyga: how's things? [09:37] 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] PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services [09:38] mborzecki: is this for stopping and removing those things on purge? [09:38] Chipaca: yes [09:39] Chipaca: so so :) doing a reinstall now, hoping that my HDD isn't totally crazy :) [09:39] Chipaca: just picking up some PRs to review while I wait [09:40] mborzecki: I don't think that's controversial; that's what the deb package was supposed to do in its postrm [09:40] 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:42] Chipaca: s/supposed to do/doing/ - no ? [09:42] mvo: I assume it is also what it does, if that's your question :-) [09:42] 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] mvo: I'd have to look at the current postrm to say for sure :-D [09:42] Chipaca: yes, it does that [09:42] Chipaca: aha, thats fine. I was wondering if there is a bug in the postrm [09:43] mvo: there's an expression in Spanish, 'no meto las manos en el fuego por nadie' :-) [09:43] Chipaca: there is an expression in german: "Ich verstehe kein Spanisch" [09:43] Chipaca: ;) anyway, thanks! [09:44] mborzecki: it does that also for mount units btw [09:44] (the deb postrm) [09:44] mvo: there's an expression in French, "ils sont fous ces allemands" [09:45] 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:46] mborzecki: I mean, any code sharing would have to be done via some magic that copies things into postrm [09:46] mvo: sound ugly [09:46] Chipaca: heh :) I think I know enough french for this one ;) [09:46] mborzecki: yeah, britle and terrible [09:47] it could be done in the Makefile / rules [09:48] * mvo hugs Chipaca and apologizes for trolling him on a monday morning [09:48] pedronis: yeah, I think its doable, we just need to be careful and it will be a little bit ugly [09:49] (of course it is, SMOP and all that :) [09:50] mborzecki: haha [09:50] mborzecki: nice ;) [09:50] PR snapd#4486 opened: snap: make `snap run not-install` output advise for not installed commands [09:52] mborzecki: just curl mgmg.snapcraft.io [09:52] mborzecki: just curl mgmg.snapcraft.io | sudo sh [09:52] mborzecki: ;-) [09:52] mborzecki: no need to worry about postrm [09:52] ;-) [09:52] man, my typing sucks on this laptop [09:53] hmm ok, seems like there's a bug in #4480 [09:53] PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services [09:53] mborzecki: is bug #1741474 something to set to "fix commited" ? [09:53] Bug #1741474: Migrating from snapd to snapd-git results in 'broken' snaps [09:55] mvo: yeah, think it's ok to switch the status [09:56] mborzecki: thank you! and thanks for the fix [09:57] mvo: oh, it's not me, it's philm from manjaro who updated the packages [09:57] anyways, they are in sync with ones from AUR now [09:59] mborzecki: ta [10:10] mvo: can 4424 land? [10:11] 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:12] pstolowski: is landing new interfaces problematic for you? [10:12] pstolowski: can I land 4365? (do a qucik review maybe) [10:13] * zyga requests review for 4329 [10:13] 4329 is from nov 2017 and fixes a bug [10:13] zyga, by all means we should land new interfaces, i'll update my branch if needed [10:14] zyga, let's just avoid any unnecessary refactorings around interfaces at this point and it will be fine [10:15] so yes please land 4365 [10:16] pstolowski: kk [10:17] zyga: yes, I looked at the new package I'm using, what's the procedure for new deps ? [10:17] pedronis: I don't think we have any really, I just wanted to double check someone from the team read that package [10:17] jamesh: hey [10:17] zyga: hi [10:18] zyga: yes, I read the package, it doesn't do networking, has good coverage [10:18] seems to do the job [10:18] 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] there are much more complicated packages for this, but seems overkill for these case [10:18] jamesh: can I help you some way? [10:19] *this case [10:19] pedronis: that sounds good to me [10:21] zyga: pedronis: pushed a fix to #4480 can you take a look? [10:21] PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services [10:21] mborzecki: aha [10:21] PR snapd#4365 closed: interfaces/mir: allow Wayland socket and non-root sockets [10:23] mborzecki: commentd [10:26] 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:27] 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] pedronis: oh? [10:28] 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] the bundled bit I'm not sure what is about [10:29] Chipaca: ^ [10:29] ah, me neither [10:29] I added the BuildRequires because without it it wouldn't work :-) [10:30] I don't know the significance of the rest [10:30] Chipaca: well I didn't even add that, because fedora is off :/ [10:30] 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:31] pedronis: you can still run it by hand :-D [10:31] Chipaca: and see it fail for other reasons anyway? [10:31] pedronis: running a test by hand has high chances of working [10:31] I mean, we turned off fedora for reasons [10:31] zyga: #4329, the code there is called with cgroup frozen? [10:31] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) [10:32] pedronis: running all the tests has high chances of failing [10:32] pedronis: ¯\_(ツ)_/¯ [10:32] Chipaca: anyway, should we cargo cult the rest for boltdb? [10:32] pedronis: I'd rather ask somebody that knows [10:32] I suppose all deps should be the same [10:33] that's a good supposition, and we can go with it if neil doesn't show today [10:33] ok? [10:33] re [10:33] yea [10:33] jamesh: cool [10:34] jamesh: I don't know if *just* making it shared will be enough tho [10:34] Chipaca: could you look at #4481 [10:34] PR #4481: image: let consume snapcraft export-login files from tooling [10:34] jamesh: otherwise the code that makes /media shared would be much much easier to write originally [10:34] pedronis: on it [10:34] thank you [10:34] jamesh: do a practical test please (ideally patch the /media spread test to also have a dummy per-user mount profile to see) [10:35] mborzecki: no [10:36] mborzecki: just with the per-ns lock held [10:36] 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:37] jamesh: I might be wrong but I think this is why the /media setup that we have now ended up so convoluted [10:37] jamesh: (I stash away /media to recover it later) [10:38] 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:39] Chipaca: that's why I'm holding off adding command line options [10:39] 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:40] nothing urgent and i didn't mean it needed doing right now [10:40] the arch yes [10:40] * zyga is grumpy because the good green tea has run out [10:40] snapshots also run in the absence of snapd :-D [10:40] just explaining why I didn't add command line options so far [10:40] and the store carrying it is on the other side of the city [10:40] zyga: send your snappy-enabled drones [10:41] Chipaca: arduino with a sign "will write model assertions for tea" [10:42] zyga: hey now, no unlawfully competing with ogra_ [10:42] Chipaca: I think ogra would write beer, that's a different market segment [10:42] we can coexist peacefully [10:46] augh! i should've gone to physio [10:51] zyga: I think you're right. I thought I had something working, but it doesn't seem to be propagating. [10:52] zyga: I do wonder if anything using the desktop interface would ever be affected by this though [10:52] 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] e.g. display security in current Ubuntu doesn't let root connect to the user's display [10:53] zyga: so I need to track down what all the top level mounts are then [10:53] jamesh: no, no need [10:53] jamesh: just opendir and iterate over top level elements [10:54] and skip media [10:55] zyga: but the top level directories aren't all going to be mount points [10:55] not a problem [10:55] ah [10:55] actually, you are right [10:55] that is a problem [10:55] rshare doesn't handle non-mount entries [10:55] bummer :/ [10:56] 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:59] 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] jamesh: I honesntly don't even see how that can work [10:59] jamesh: it's far more complex than what we have now [10:59] jamesh: I'll dismiss that without any poc code [11:00] ..., 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:01] zyga, correct .... and also ... i dont touch systems without MMU ;) [11:01] jamesh: (even back of the envelope pseudocode) === chihchun is now known as chihchun_afk [11:05] 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:06] zyga: went through #4329, left some comments [11:06] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) [11:06] 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] mborzecki: thank you [11:09] mborzecki: looking now [11:09] jamesh: maybe it's easier than I assume by I really would like to see some pseudocode written (e.g. forum thread) [11:09] jamesh: I suspect the devil is in the details here, it's very delicate piece of code [11:12] 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:13] 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:14] 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] okay [11:15] hey cachio ! welcome back [11:15] mvo, hey, thanks [11:15] cachio: wow, hey [11:15] mvo, glad to be here again [11:16] zyga, hey, long time [11:17] cachio: I hope you had great time :) [11:17] zyga, yes it was, thanks [11:20] mvo, any plan for beta validation? [11:20] cachio: yeah, probably tomorrow, we had a bit of a setback because of spectre/meldown, no edge builds for a couple of days [11:21] mvo, ok [11:22] cachio: welcome back, the internet has melted and is chased by some spectres [11:23] zyga, hehehe, yes [11:23] Are you still blocked on the remaining ppa:snappy-dev/ubuntu/edge builds? [11:24] zyga, no way to scape from that [11:24] E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list [11:25] zyga, is there any change in snapd for deal with those issues? [11:25] quoth the raven, WAT [11:25] 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:26] cachio: no, just extra delays around [11:27] cachio: probably new toolchains soon [11:27] cachio: maybe a rebuild required, not sure [11:27] zyga, ok [11:27] 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:28] cjwatson: its a sync from github.com/snapcore/snapd [11:28] mvo: (we can whitelist builds, but we have to treat the builders as if they have no effective virtualisation at the moment) [11:28] PR snapd#4487 opened: cmd/snap: snap refresh --timer, hide --time [11:28] mvo: hmm, any reason it's not a Launchpad git-to-git import? Is it gated in some way? [11:28] cjwatson: and we only allow code in that we reviewed and that passed our test suite (and CLA) [11:30] 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] cjwatson: (this is why the git tree is called snapd-vendor, i.e. snapd+vendor-code) [11:30] ah, ok [11:31] mvo: does your process for updating vendor/vendor.json at least involve eyeballing the upstream diff? [11:31] (uncomfortable moment) [11:32] ;-) [11:32] 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:33] cjwatson: anyway, I understand the current situation, I'm ok with waiting for more kernel/isolation fixes [11:34] 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] cjwatson: obviously it depends on how long it will take if fixes are weeks away we need to consider what to do [11:35] would be nice if that could get an exception [11:45] mvo,ogra_: I think at least these current ones are OK. Scheduled [11:45] thx!! [11:46] cjwatson: thank you! [11:50] * kalikiana going for lunch in ~10 === ogra_ is now known as ogra [12:03] PR snapd#4488 opened: snap: make `snap find --section` show all sections [12:06] is tehre a way to tell if --argument was passed in command line? [12:07] mborzecki: hmm? [12:07] where? [12:08] 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:09] (and the subject is mis-leading ... its about the debian 9 kernel and apparmor) [12:10] yeah, I see [12:10] * pstolowski lunch [12:12] 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:13] mborzecki: I don't know, there may be a way to do that with go-flags (optional argument) [12:14] * zyga coffee [12:14] time to reinstall next, backup done [12:22] came up with some workaround: https://paste.ubuntu.com/26391469/ this is for https://bugs.launchpad.net/snapd/+bug/1742960 [12:22] Bug #1742960: snap find --section does not list sections [12:23] haha, see that mvo has opened a PR already :) [12:28] * zyga keeps fingers crossed that bionic reinstall will work for this week and that hdd is not totally busted [12:28] especially that smart was OK [12:28] not sure what caused this [12:28] at least I will have a fresh filesystem there [12:39] kernel crashed on reboot [12:39] well [12:39] that's a good sign [12:39] ... [12:39] not [12:40] hmm [12:40] it's still doing something [12:41] just spews ... [12:49] ok [12:49] ok [12:49] this disk is gone [12:49] just broke after install [12:49] SMART my ass [12:49] * zyga is grumpy now [12:52] * Chipaca hugs zyga [12:52] salvage what you can, drill it through, throw it in the dumpster :/ [12:52] mborzecki: I have a full backup, so that's not a problem [12:52] i was going to suggest opening it and peeing on it, but i decided against it [12:53] mborzecki: and it "works" a little, just fails writes often [12:53] every now and then [12:53] Chipaca: I need some of that alien pee [12:53] zyga: that's your call [12:55] zyga: so now you can play with running linux on the chip that's inside the drive [12:55] zyga: http://spritesmods.com/?art=hddhack&page=1 [12:56] mborzecki: or buy those discounted fireworks [13:14] re [13:41] 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] pachulo: not yet no [13:45] Chipaca: is there any rough guess? like: before the end of 2018? [13:45] pachulo: I'd expect it to be done before 18.10 [13:45] pachulo: but after 18.04 [13:47] pachulo: JamieBennett might be in a better position to offer a firmer answer, if one exists [13:48] niemeyer, one of my PRs that needs your re-review: https://github.com/snapcore/snapd/pull/4440 [13:48] PR #4440: state: unknown tasks handler [13:50] niemeyer: https://github.com/snapcore/snapd/pull/4487 and https://github.com/snapcore/snapd/pull/4476 [13:50] PR #4487: cmd/snap: snap refresh --timer, hide --time [13:50] PR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule [13:59] PR snapd#4481 closed: image: let consume snapcraft export-login files from tooling [13:59] zyga: fwiw, I can reproduce the dbus error on bionic, it does not make sense to me our rule looks good [14:00] mvo: interesting, I can "try" on my current broken system [14:00] 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:01] zyga: do you have any hints how to debug this? [14:02] ok, thanks Chipaca [14:03] mvo: hold on, let me reproduce locally [14:03] are there go build flags that can be used to build something only on 14.04? [14:03] zyga: hm,hm, apparmor_parser -r /path/to/apparmor/profile seems to fix it :( [14:03] ouch :/ [14:03] that's not good [14:03] which profile did you reload, that of the app, right? [14:03] zyga: correct [14:04] 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:05] mvo: we can switch I suppose, the package I picked has a even simpler interface (but more code) [14:07] 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:08] mvo: I need to go have my daily walk, I let you think a bit more [14:08] pedronis: I can to a POV port if you want (lets talk after your walk) [14:09] hm we don't seem to clean up udev rules in postrm and snap-mgmt [14:09]