=== leftyfb_ is now known as leftyfb === leftyfb_ is now known as leftyfb [02:03] * Son_Goku waves at sabdfl [02:03] hey sabdfl [02:03] how are you doing this evening? === nsg_ is now known as nsg [06:07] morning [07:13] good morning! [07:14] I found a silly reason for the symlink issue, there were two checks and I only patched one last week [07:14] zyga: hey [07:14] I noticed late on Friday and started fixing it but stopped because it has huge diff on unit tests [07:14] I will finish that now quickly [07:14] zyga: that's good news [07:14] yeah, it's from and older part of the code that existed before we had any creation code [07:15] it just checked if things exist and are of the right type [07:15] zyga: mhm, ping me if you need a review [07:17] zyga: in other news, there's another user reporting issues with nvidia on arch with new drivers, i've ordered gt1030 card just now, so i'll probably take a look tomorrow or on wednesday [07:17] yeah, I saw that [07:17] excellent! [07:17] I didn't knew 1030s existed, how much was it? [07:19] ~340pln/80eur [07:19] and it's a 30W card [07:28] that's pretty neat! [07:28] and it will be on modern drivers [07:28] thank you for doing that, it will definitely help the team [08:05] good morning, snaooy [08:05] morning! === pstolowski|afk is now known as pstolowski [08:08] kalikiana: pstolowski: morning guys [08:08] zyga: what's the plan with #4509? [08:08] PR #4509: interfaces/builtin: add support for software-watchdog interface [08:08] damn, not that one [08:08] oh? [08:08] zyga: #4781 [08:08] PR #4781: wrappers: refactor desktop file sanitizer to support autostart files [08:09] zyga: must by my unlycky day, not that one obviously :P [08:09] zyga: #4571 [08:09] PR #4571: data, cmd, packaging: use autotools to generate artifacts under data [08:09] haha [08:09] looking again :) [08:09] I _think_ the desire is to drop autotools [08:10] so for now this can stay as refrence but we probably won't land it [08:11] ok [08:11] hm so hand written makefiles then? [08:15] zyga: i can look into it, i'm not super busy with anything atm anyway [08:15] yeah, go for it! [08:15] I'm a big fan of pure make [08:15] so I'll gladly review [08:34] ok, I will do two patches [08:34] one that is tiny and can land quickly [08:35] and one that removes obsolete code that can land later without rushes [08:38] just running tests now [08:39] a few lines changed, vs what I got last Fridat [08:39] (100s, probably close to 1K) [08:41] PR snapd#4866 opened: tests: make autopkgtest tests more targeted [08:44] mborzecki, mvo: https://github.com/snapcore/snapd/pull/4867 [08:44] PR #4867: cmd/snap-update-ns: don't fail on existing symlinks [08:44] that's the symlink part of the bug [08:44] fingers crossed [08:44] PR snapd#4867 opened: cmd/snap-update-ns: don't fail on existing symlinks [08:45] now refocusing on not writing to places that leak to host filesystems [08:46] PR snapd#4861 closed: store: reorg auth refresh (2.32) [08:48] PR snapd#4862 closed: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references (2.32) [08:54] PR snapd#4865 closed: many: propagate contexts enough to be able to mark store operations done from the Ensure loop (2.32) [08:54] good morning, all! [08:56] hey Chipaca ! good morning [08:57] that ! feels like a gnarly binop [08:57] mvo: hiya :-) how was your friday? [08:57] morning Chipaca ! [08:57] pstolowski: :-) [08:58] Chipaca: mostly good, about 1h of small panic because of something that looked like a serious snapd bug but turned out to be a glich in the data [08:58] hey pstolowski [09:03] mvo: no, no, how was your _friday_ [09:03] mvo: o/ [09:03] mvo: that thing where you _weren't_ working [09:03] Chipaca: *cough* [09:05] Chipaca: hey, thanks for benchmarking the text wrapper thing, must have been a lot of fun :) [09:05] mborzecki: I learned some stuff :-) [09:06] Chipaca: out of curiosity, have you tried the profiler? :P [09:07] mborzecki: the web clicky thing? not on this code [09:07] mborzecki: on other code yes [09:08] Chipaca: ah, ok, it's neat though, like how it always amazes non-go guys during presentations [09:08] mborzecki: for this I used the profile flags on go test, and got to a version that was doing over 100MB/s with 0 allocs [09:09] all rather academic but fun [09:09] (academic because in real use it's terminal i/o so unless you're on a non-xft xterm, it's got no way of hitting 100MB/s :-) ) [09:10] also academic because most descriptions shouldn't hit a megabyte :-) [09:10] haha nice :) [09:11] zyga: mvo: systemCoreSnapUnalias? [09:14] mmm [09:14] well, +1 because bikeshed :) [09:15] hahah [09:15] well, renamed & pushed, too late now [09:16] mborzecki: yeah, fine with me [09:16] zyga: FYI snapped things don't work with nvidia prime in intel mode [09:16] (also +1 for zyga ) [09:16] zyga: mvo: thank you for the reviews :) [09:16] yw [09:16] Chipaca: can you please tell me and mborzecki more? [09:17] Chipaca: that PRIME? [09:17] mborzecki: zyga: have laptop with nvidia prime, which is not a condom nor a subscription service for quicker delivery [09:18] mborzecki: zyga: non-snapped 3d apps work fine in both modes, although of course faster in nvidia mode [09:18] mborzecki: zyga: snapped 3d apps fail to work in intel mode [09:19] Chipaca: what is the error message? [09:20] minecraft: https://pastebin.ubuntu.com/p/7pxkxkVVTK/ [09:20] although, hold on, ohmygiraffe works [09:20] is that 3d? [09:21] Chipaca: it has a plug for opengl [09:22] hmm, hmm. so maybe the minecraft snap is buggy, and not our 3d support [09:22] Chipaca: can you `MESA_DEBUG=1 snap run ohmygiraffe` and see what's in the logs? [09:23] mborzecki: in which logs? on the terminal I just get “Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable” [09:23] Chipaca: and how about LIBGL_DEBUG=verbose ? [09:24] mborzecki: https://pastebin.ubuntu.com/p/WDT3TDpNcj/ [09:27] Chipaca: looks like it's using intel/mesa now [09:27] mborzecki: yes, it's in intel mode [09:27] the snapped minecraft crashes in this mode (regular minecraft doesn't) [09:27] Chipaca: can you also try some other snap, say supertuxkart [09:27] yes [09:28] Chipaca: it would be interesting to compare an app that crashes inside and outside the snap [09:28] is this on xenial btw? [09:28] zyga: it doesn't crash outside the snap :-) [09:28] right [09:28] so the debug log of that [09:28] and where it differs is a hint [09:28] zyga: yes, xenial, but xenial as factory-installed [09:29] btw. is glxinfo included in any snap? [09:29] glxinfo in nvidia mode here isn't happy, fwiw [09:29] something about bad libGL version [09:30] supertuxkart crashes [09:30] I think we need to support glvnd natively and remove bundled libraries from snaps [09:30] Chipaca: woo, badly? backtrace? [09:31] hmmm, somehow supertuxkart loaded the nvrm module [09:31] weird [09:32] mborzecki: https://pastebin.ubuntu.com/p/6x45s6RNnH/ [09:32] mborzecki: no backtrace [09:33] Chipaca: `[warn ] [IrrDriver Temp Logger]: Level 2: Could not create GLX rendering context`. same as minecraft [09:33] PR snapd#4866 closed: tests: make autopkgtest tests more targeted [10:09] hi, I'm trying to run snap on Archlinux with apparmor but I get denial when trying to start an app AVC apparmor="DENIED" operation="open" profile="snap.qownnotes.qownnotes" name="/var/lib/snapd/snap/qownnotes/906/meta/snap.yaml" pid=32283 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [10:10] https://www.irccloud.com/pastebin/14klzXuE/ [10:10] vidal72[m]: did you build apparmor enabled kernel? [10:10] mborzecki: ^ [10:12] yes, I use apparmor for a long time, this denial comes from apparmor [10:12] here is appamror profile for this app https://paste.ubuntu.com/p/zwB4Yb57nB/ [10:12] which kernel are you on now? [10:12] 4.16-rc6 [10:13] interesting [10:13] zyga: where do you see this error you pasted with https://www.irccloud.com/pastebin/14klzXuE/ ? [10:13] so there are permissions to m snap-exec [10:13] but not to x it [10:13] pstolowski: in my bionic box when running run-checks.sh [10:13] pstolowski: run-checks.sh --unit, to be precise [10:14] vidal72[m]: if you edit the profile and replace line 194 with [10:14] /usr/lib/snapd/snap-exec mr, [10:14] and reload the profile with apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.qownnotes.qownnotes [10:14] does it fix the issue? [10:17] that error looks like a copycat of a problem with tests that I fixed a few weeks ago; we were trying to lunch zenity/kdialog for real in unit tests [10:24] zyga: no, same message [10:25] vidal72[m]: could you please publish your kernel config and tree somewhere? [10:25] I cannot answer why this happens instantly [10:31] PR snapd#4868 opened: [WIP] secure bind mount implementation for use with user mounts [10:32] zyga: did you get a chance to try the patch. So far it seems to be working good for me, if its good for you throw a comment on the bug and I'll get it sent into the the kt [10:32] zyga: here's my config https://paste.ubuntu.com/p/5rw2Fxxsps/ [10:33] I read the patch and built it but I didn't do any testing yet, I will have the results for my tomorrow, sorry I had a busy weekend [10:33] I'll update the bug today [10:33] vidal72[m]: thank you, can you please open a thread on forum.snapcraft.io with the basic information and your kernel config and git tree reference [10:34] and I will explore that this week [10:34] zyga: np, and no hurry I just don't want to let it get dropped in the tsunami of other issues, so if you don't get to it this week I will poke you again next [10:34] zyga: ok [10:34] jjohansen: understood, thank you very much for the patch [10:34] I was looking for some kind of race condition but now I understand how it works better [10:38] do'h [10:38] I found a very embarrasing bug [10:38] zyga: yeah, well it seems that when I did the convertion the racy update of i_link got dropped. My first few attempts at fixing this involved locking and an rcu callback to free the i_link value, needless to say I wasn't happy with those [10:38] the bug exsits because I'm not using something I wrote for this specific purpose [10:40] (different bug, something I realized on friday and debugged just now) [10:44] i've uplaoded a snap for debugging issues with graphics, using this snapcraft.yaml https://github.com/bboozzoo/graphics-debug-tools-snap/blob/master/snapcraft.yaml once I requested x11 and opengl it got stuck in manual review, the reason being lack of *.desktop file :/ (there'll hardly be any for cli tools) [10:45] zyga: when is the fix for the DENIED on actions_avail happening? [10:46] I didn't discuss this with jdstrand yet, I'm not sure what is the right way [10:46] since jamie is back this week it will be on my plate to ask [10:52] mborzecki: I can help [10:53] mborzecki: its in [10:53] mvo: thank you [11:10] xnox, mwhudson the autopkgtests run on s390x shows some unusal errors and panics (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/s/snapd/20180319_102843_5bafc@/log.gz) - are there known issues with golang1.10 on s390x ? [11:12] mvo: https://github.com/snapcore/snapd/pull/4867 updated with unit tests and green [11:12] PR #4867: cmd/snap-update-ns: don't fail on existing symlinks [11:12] +1 to merge? [11:13] zyga: yes [11:13] zyga: thanks for adding the test [11:18] zyga, hey, could yo uplease take a look to #4835? [11:18] PR #4835: tests: add bionic system to google backend [11:18] zyga, it is almost ready [11:19] hmmm [11:19] the extra code for stoppping the stopping of the mount unit is worrying, why do we need it? [11:22] zyga, this is mvo [11:23] zyga, it is to deal with a problem that comes from 2.31 [11:25] Should that be done by snapd instead so that is not just in test code [11:25] zyga, we were researching but the only way to fix that was mounting again the units after install [11:25] mvo: can you explain the problem please? [11:27] zyga: sure, so 2.31.X has the snap.mount unit. but 2.32 does not have it anymore. this means that on upgrade dpkg will run the "prerm" of the *old* 2.31.X deb. The default is to stop mount units there. this leads to all childs being unmounted [11:27] zyga: because it is the old prerm we cannot prevent this umount [11:27] zyga: I mean, that would be the ideal solution, do something to prevent this and just leave it running [11:28] zyga: the alternative is to undo what it was doing [11:28] right, I understand the prerm issue [11:28] so the question is this; is this a real issue that needs to be dealt in more than just test code [11:28] ah [11:28] sorry [11:28] I'm blind, this is in .postinst [11:28] so it's all fine [11:28] I read this as somthing in prepare-restore.sh [11:28] +1 :-) [11:29] zyga: ok [11:29] zyga: fwiw, I'm *not* happy with this code [11:29] zyga: and it only affects bionic and -proposed users [11:30] zyga: so the alternative might be to just ask them to reboot. but at the same time, the fixup will also only run for these users so even if the code is buggy for some its not worse than before (I think) [11:30] * zyga whispers "it will be there forever" to mvo's ear [11:30] * mvo drops into a coma [11:31] cachio: 2.31.2 got accepted into -proposed - if you have time (not super urgent) please do the sru validation [11:32] mvo, sure [11:32] zyga, so, is it ok to merge bionic? [11:33] doing some comments there [11:33] hold on please [11:33] mvo, beta validation is ready [11:33] OI am waiting for confirmation from qa team [11:35] cachio, mvo: 4835 reviewed [11:36] zyga, thanks [11:37] cachio: cool, I will prepare 2.32(-final) then and focus on test fixes etc [11:38] zyga: anything that needs to land from your side in 2.32 still? [11:38] yes [11:38] two PRs I'm afraid [11:38] and everything that is tagged [11:38] note that I did _not_ cherry pick anything yet [11:38] so I'm afraid still a few PRs to go [11:38] mvo: https://github.com/snapcore/snapd/pull/4867 is one that's ready to land [11:38] PR #4867: cmd/snap-update-ns: don't fail on existing symlinks [11:39] mvo: https://github.com/snapcore/snapd/pull/4765 is a bigger one from the sprint [11:39] PR #4765: interfaces: harden snap-update-ns profile [11:39] mvo: and two more (small) that I'm brewing [11:39] PR snapd#4867 closed: cmd/snap-update-ns: don't fail on existing symlinks [11:40] mvo: I will try to prepare them both by 14:00 today [11:41] and after all the fixes are in master I will look at backport PRs [11:42] mvo: does that sound acceptable? [11:45] zyga: sounds good, lets talk during the standup. [11:45] ok [11:49] * cachio afk [11:50] mvo, looks, i have no clue. [11:52] xnox: I think I asked before, but is there a porter box for s390x? [12:03] mvo, yes [12:06] zyga: I managed to fix it by changing @{INSTALL_DIR}="/snap" to @{INSTALL_DIR}="/{,var/lib/snapd/}snap" but now I have [12:06] ANOM_ABEND auid=1000 uid=1000 gid=100 ses=1 pid=2319 comm="QOwnNotes" exe="/snap/qownnotes/906/usr/bin/QOwnNotes" sig=6 res=1 [12:07] vidal72[m]: I have never seen such a message (ANOM_ABEND) [12:09] vidal72[m]: if nothing helps you can use one of the many other install methods of QOwnNotes. ;) http://www.qownnotes.org/installation [12:09] zyga: "Triggered when a processes ends abnormally (with a signal that could cause a core dump, if enabled)." [12:09] I see [12:10] did you get any other denial? [12:10] perhaps it was killed by seccomp [12:10] those would be logged by the audit logger [12:10] vidal72[m]: I think the install dir is a clear omission on our end, [12:10] do other snaps work? [12:11] zyga: no, only this single message [12:12] zyga: I didn't tried other as I'm strugling to make this one work (first which I tried), I have some other small fixes to usr.lib.snapd.snap-confine [12:13] vidal72[m]: please send a PR if you can [12:13] try the hello snap [12:13] it's very basic [12:13] mvo, btw, zyga has access to the Fedora test/porter boxes if you want to work on quirky things with ppc and arm: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers [12:15] pbek: thx, I can succesfully use qownotes, just not as snap [12:16] mvo, and zyga can probably get access to Fedora s390x boxes by requesting them in #fedora-s390x [12:16] thank you Son_Goku [12:16] I _hope_ we won't have to use them :) [12:16] but it's good that we have them if we have to [12:22] ok, one more bug fixed, now looking at the last one [12:22] actually, let's break for 5 [12:22] back.hurt() [12:32] PR snapcraft#2005 closed: pluginhandler: special case go patchelf failures for classic confinement [12:35] PR snapd#4869 opened: cmd/snap-update-ns: use x-snapd.{synthetic,needed-by} in practice [12:36] * Chipaca -> lunch [12:36] zyga: :-(((( [12:36] what's wrong John? [12:36] zyga: take more care of your back [12:37] yeah, I should take a walk [12:38] PR snapcraft#2006 closed: many: use packaging logic to get patchelf [12:39] PR snapd#4870 opened: tests: drop old debug code [12:42] * Chipaca -> lunch-making [12:57] PR snapcraft#2008 opened: Release changelog for 2.40 [12:57] zyga: hello-world works, in qownnotes the error is: snap run qownnotes [12:57] Fatal: QXcbConnection: Could not connect to display :0 ((null):0, (null)) [12:57] [1] 5648 abort (core dumped) snap run qownnotes [12:57] I use xorg [12:57] PR snapd#4850 closed: many: fix shellcheck warnings in bionic [12:57] interesting, that may hint at a different issue now [12:58] mborzecki: can you run qownnotes on your arch system? [12:58] tseliot: installing [12:58] damn, wrong person :P [12:58] zyga: installing [13:01] pstolowski, cachio: standup time :) [13:07] PR snapd#4835 closed: tests: add bionic system to google backend [13:32] PR snapd#4871 opened: cmd/snap-confine: fix Archlinux compatibility [13:33] zyga: I created PR with fixes for usr.lib.snapd.snap-confine on Arch ^^ [13:34] vidal72[m]: thank you, I will look at them in a moment [13:34] vidal72[m]: added one comment [13:40] zyga: I answered [13:46] zyga: I'm talking about this: https://github.com/torvalds/linux/commit/2a4c22426955d4fc04069811997b7390c0fb858e [13:46] ah, that's very interesting [13:46] yeah, I think your change looks good [13:46] I asked a colleague for a 2nd review [13:47] vidal72[m]: can you please sign the CLA https://www.ubuntu.com/legal/contributors [13:49] zyga: I tried but it wants me to put something in "Please add the Canonical Project Manager or contact" field [13:49] * kalikiana lunch [13:53] zyga: https://github.com/snapcore/snapd/pull/4832 [13:53] PR #4832: tests: move fedora 27 to google backend [14:00] mvo: I'll take a dog+lunch break now and will be back to fix bugs after that [14:06] off to pick up the kids from school and the dog from a vet [14:10] abeato: added to the list. note, just got back from holiday so going through backlog [14:21] PR snapd#4870 closed: tests: drop old debug code [14:43] jdstrand: good morning, welcome back [14:51] hey zyga, thanks :) [14:52] jdstrand, zyga: I'm heading to bed, but I pushed up https://github.com/snapcore/snapd/pull/4868 based on the discussions at the sprint [14:52] PR #4868: [WIP] secure bind mount implementation for use with user mounts [14:53] it' [14:53] s got good test coverage, but the question is whether it satisfies the security concerns [14:58] jamesh: I saw, thank you for starting and pushing that work! [14:58] jamesh: I _suspect_ so, I'll discuss this with jdstrand [15:04] mwhudson: just fyi - https://github.com/golang/go/issues/24449 - there is a s390x issue with go1.10 [15:23] mvo, so 1.9 is still in bionic, and in main. can you revert to build-depend on 1.9 and/or use 1.9? [15:25] xnox: I will just disable coverage on s390x for now and then see what upstream is doing [15:25] mvo, ok. [15:25] xnox: but yeah, going to 1.9 might be an option if there is no upstream reaction [15:30] PR snapd#4872 opened: tests: add workaround for s390x failure [15:46] mvo: when you have a moment could you look at #4829 again, as I said in my comment to your comment I have to generalize a bit [15:46] PR #4829: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store === chihchun is now known as chihchun_afk [15:49] sigh, [15:59] this last error is just annoying [15:59] it's not hard but not easy either [16:08] ogra_: can I haz help to validate https://bugs.launchpad.net/netplan/+bug/1741910 ? [16:08] Bug #1741910: ath6kl_sdio does not support unbinding [16:08] (I don't have any ath6kl_sdio here) [16:08] how dare you ! [16:08] :) [16:08]