| === leftyfb_ is now known as leftyfb | ||
| === leftyfb_ is now known as leftyfb | ||
| * Son_Goku waves at sabdfl | 02:03 | |
| Son_Goku | hey sabdfl | 02:03 |
|---|---|---|
| Son_Goku | how are you doing this evening? | 02:03 |
| === nsg_ is now known as nsg | ||
| mborzecki | morning | 06:07 |
| zyga | good morning! | 07:13 |
| zyga | I found a silly reason for the symlink issue, there were two checks and I only patched one last week | 07:14 |
| mborzecki | zyga: hey | 07:14 |
| zyga | I noticed late on Friday and started fixing it but stopped because it has huge diff on unit tests | 07:14 |
| zyga | I will finish that now quickly | 07:14 |
| mborzecki | zyga: that's good news | 07:14 |
| zyga | yeah, it's from and older part of the code that existed before we had any creation code | 07:14 |
| zyga | it just checked if things exist and are of the right type | 07:15 |
| mborzecki | zyga: mhm, ping me if you need a review | 07:15 |
| mborzecki | 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 |
| zyga | yeah, I saw that | 07:17 |
| zyga | excellent! | 07:17 |
| zyga | I didn't knew 1030s existed, how much was it? | 07:17 |
| mborzecki | ~340pln/80eur | 07:19 |
| mborzecki | and it's a 30W card | 07:19 |
| zyga | that's pretty neat! | 07:28 |
| zyga | and it will be on modern drivers | 07:28 |
| zyga | thank you for doing that, it will definitely help the team | 07:28 |
| kalikiana | good morning, snaooy | 08:05 |
| pstolowski|afk | morning! | 08:05 |
| === pstolowski|afk is now known as pstolowski | ||
| mborzecki | kalikiana: pstolowski: morning guys | 08:08 |
| mborzecki | zyga: what's the plan with #4509? | 08:08 |
| mup | PR #4509: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509> | 08:08 |
| mborzecki | damn, not that one | 08:08 |
| zyga | oh? | 08:08 |
| mborzecki | zyga: #4781 | 08:08 |
| mup | PR #4781: wrappers: refactor desktop file sanitizer to support autostart files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4781> | 08:08 |
| mborzecki | zyga: must by my unlycky day, not that one obviously :P | 08:09 |
| mborzecki | zyga: #4571 | 08:09 |
| mup | PR #4571: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571> | 08:09 |
| zyga | haha | 08:09 |
| zyga | looking again :) | 08:09 |
| zyga | I _think_ the desire is to drop autotools | 08:09 |
| zyga | so for now this can stay as refrence but we probably won't land it | 08:10 |
| mborzecki | ok | 08:11 |
| mborzecki | hm so hand written makefiles then? | 08:11 |
| mborzecki | zyga: i can look into it, i'm not super busy with anything atm anyway | 08:15 |
| zyga | yeah, go for it! | 08:15 |
| zyga | I'm a big fan of pure make | 08:15 |
| zyga | so I'll gladly review | 08:15 |
| zyga | ok, I will do two patches | 08:34 |
| zyga | one that is tiny and can land quickly | 08:34 |
| zyga | and one that removes obsolete code that can land later without rushes | 08:35 |
| zyga | just running tests now | 08:38 |
| zyga | a few lines changed, vs what I got last Fridat | 08:39 |
| zyga | (100s, probably close to 1K) | 08:39 |
| mup | PR snapd#4866 opened: tests: make autopkgtest tests more targeted <Created by mvo5> <https://github.com/snapcore/snapd/pull/4866> | 08:41 |
| zyga | mborzecki, mvo: https://github.com/snapcore/snapd/pull/4867 | 08:44 |
| mup | PR #4867: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4867> | 08:44 |
| zyga | that's the symlink part of the bug | 08:44 |
| zyga | fingers crossed | 08:44 |
| mup | PR snapd#4867 opened: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4867> | 08:44 |
| zyga | now refocusing on not writing to places that leak to host filesystems | 08:45 |
| mup | PR snapd#4861 closed: store: reorg auth refresh (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4861> | 08:46 |
| mup | PR snapd#4862 closed: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4862> | 08:48 |
| mup | PR snapd#4865 closed: many: propagate contexts enough to be able to mark store operations done from the Ensure loop (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4865> | 08:54 |
| Chipaca | good morning, all! | 08:54 |
| mvo | hey Chipaca ! good morning | 08:56 |
| Chipaca | that ! feels like a gnarly binop | 08:57 |
| Chipaca | mvo: hiya :-) how was your friday? | 08:57 |
| pstolowski | morning Chipaca ! | 08:57 |
| Chipaca | pstolowski: :-) | 08:57 |
| mvo | 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 |
| mvo | hey pstolowski | 08:58 |
| Chipaca | mvo: no, no, how was your _friday_ | 09:03 |
| pstolowski | mvo: o/ | 09:03 |
| Chipaca | mvo: that thing where you _weren't_ working | 09:03 |
| mvo | Chipaca: *cough* | 09:03 |
| mborzecki | Chipaca: hey, thanks for benchmarking the text wrapper thing, must have been a lot of fun :) | 09:05 |
| Chipaca | mborzecki: I learned some stuff :-) | 09:05 |
| mborzecki | Chipaca: out of curiosity, have you tried the profiler? :P | 09:06 |
| Chipaca | mborzecki: the web clicky thing? not on this code | 09:07 |
| Chipaca | mborzecki: on other code yes | 09:07 |
| mborzecki | Chipaca: ah, ok, it's neat though, like how it always amazes non-go guys during presentations | 09:08 |
| Chipaca | 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:08 |
| Chipaca | all rather academic but fun | 09:09 |
| Chipaca | (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:09 |
| Chipaca | also academic because most descriptions shouldn't hit a megabyte :-) | 09:10 |
| mborzecki | haha nice :) | 09:10 |
| mborzecki | zyga: mvo: systemCoreSnapUnalias? | 09:11 |
| zyga | mmm | 09:14 |
| zyga | well, +1 because bikeshed :) | 09:14 |
| mborzecki | hahah | 09:15 |
| mborzecki | well, renamed & pushed, too late now | 09:15 |
| mvo | mborzecki: yeah, fine with me | 09:16 |
| Chipaca | zyga: FYI snapped things don't work with nvidia prime in intel mode | 09:16 |
| mvo | (also +1 for zyga ) | 09:16 |
| mborzecki | zyga: mvo: thank you for the reviews :) | 09:16 |
| mvo | yw | 09:16 |
| zyga | Chipaca: can you please tell me and mborzecki more? | 09:16 |
| mborzecki | Chipaca: that PRIME? | 09:17 |
| Chipaca | mborzecki: zyga: have laptop with nvidia prime, which is not a condom nor a subscription service for quicker delivery | 09:17 |
| Chipaca | mborzecki: zyga: non-snapped 3d apps work fine in both modes, although of course faster in nvidia mode | 09:18 |
| Chipaca | mborzecki: zyga: snapped 3d apps fail to work in intel mode | 09:18 |
| mvo | Chipaca: what is the error message? | 09:19 |
| Chipaca | minecraft: https://pastebin.ubuntu.com/p/7pxkxkVVTK/ | 09:20 |
| Chipaca | although, hold on, ohmygiraffe works | 09:20 |
| Chipaca | is that 3d? | 09:20 |
| mborzecki | Chipaca: it has a plug for opengl | 09:21 |
| Chipaca | hmm, hmm. so maybe the minecraft snap is buggy, and not our 3d support | 09:22 |
| mborzecki | Chipaca: can you `MESA_DEBUG=1 snap run ohmygiraffe` and see what's in the logs? | 09:22 |
| Chipaca | 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 |
| mborzecki | Chipaca: and how about LIBGL_DEBUG=verbose ? | 09:23 |
| Chipaca | mborzecki: https://pastebin.ubuntu.com/p/WDT3TDpNcj/ | 09:24 |
| mborzecki | Chipaca: looks like it's using intel/mesa now | 09:27 |
| Chipaca | mborzecki: yes, it's in intel mode | 09:27 |
| Chipaca | the snapped minecraft crashes in this mode (regular minecraft doesn't) | 09:27 |
| mborzecki | Chipaca: can you also try some other snap, say supertuxkart | 09:27 |
| Chipaca | yes | 09:27 |
| zyga | Chipaca: it would be interesting to compare an app that crashes inside and outside the snap | 09:28 |
| zyga | is this on xenial btw? | 09:28 |
| Chipaca | zyga: it doesn't crash outside the snap :-) | 09:28 |
| zyga | right | 09:28 |
| zyga | so the debug log of that | 09:28 |
| zyga | and where it differs is a hint | 09:28 |
| Chipaca | zyga: yes, xenial, but xenial as factory-installed | 09:28 |
| mborzecki | btw. is glxinfo included in any snap? | 09:29 |
| Chipaca | glxinfo in nvidia mode here isn't happy, fwiw | 09:29 |
| Chipaca | something about bad libGL version | 09:29 |
| Chipaca | supertuxkart crashes | 09:30 |
| zyga | I think we need to support glvnd natively and remove bundled libraries from snaps | 09:30 |
| mborzecki | Chipaca: woo, badly? backtrace? | 09:30 |
| Chipaca | hmmm, somehow supertuxkart loaded the nvrm module | 09:31 |
| Chipaca | weird | 09:31 |
| Chipaca | mborzecki: https://pastebin.ubuntu.com/p/6x45s6RNnH/ | 09:32 |
| Chipaca | mborzecki: no backtrace | 09:32 |
| mborzecki | Chipaca: `[warn ] [IrrDriver Temp Logger]: Level 2: Could not create GLX rendering context`. same as minecraft | 09:33 |
| mup | PR snapd#4866 closed: tests: make autopkgtest tests more targeted <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4866> | 09:33 |
| vidal72[m] | 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:09 |
| zyga | https://www.irccloud.com/pastebin/14klzXuE/ | 10:10 |
| zyga | vidal72[m]: did you build apparmor enabled kernel? | 10:10 |
| zyga | mborzecki: ^ | 10:10 |
| vidal72[m] | yes, I use apparmor for a long time, this denial comes from apparmor | 10:12 |
| vidal72[m] | here is appamror profile for this app https://paste.ubuntu.com/p/zwB4Yb57nB/ | 10:12 |
| zyga | which kernel are you on now? | 10:12 |
| vidal72[m] | 4.16-rc6 | 10:12 |
| zyga | interesting | 10:13 |
| pstolowski | zyga: where do you see this error you pasted with https://www.irccloud.com/pastebin/14klzXuE/ ? | 10:13 |
| zyga | so there are permissions to m snap-exec | 10:13 |
| zyga | but not to x it | 10:13 |
| zyga | pstolowski: in my bionic box when running run-checks.sh | 10:13 |
| zyga | pstolowski: run-checks.sh --unit, to be precise | 10:13 |
| zyga | vidal72[m]: if you edit the profile and replace line 194 with | 10:14 |
| zyga | /usr/lib/snapd/snap-exec mr, | 10:14 |
| zyga | and reload the profile with apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.qownnotes.qownnotes | 10:14 |
| zyga | does it fix the issue? | 10:14 |
| pstolowski | 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:17 |
| vidal72[m] | zyga: no, same message | 10:24 |
| zyga | vidal72[m]: could you please publish your kernel config and tree somewhere? | 10:25 |
| zyga | I cannot answer why this happens instantly | 10:25 |
| mup | PR snapd#4868 opened: [WIP] secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868> | 10:31 |
| jjohansen | 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 |
| vidal72[m] | zyga: here's my config https://paste.ubuntu.com/p/5rw2Fxxsps/ | 10:32 |
| zyga | 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 |
| zyga | I'll update the bug today | 10:33 |
| zyga | 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:33 |
| zyga | and I will explore that this week | 10:34 |
| jjohansen | 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 |
| vidal72[m] | zyga: ok | 10:34 |
| zyga | jjohansen: understood, thank you very much for the patch | 10:34 |
| zyga | I was looking for some kind of race condition but now I understand how it works better | 10:34 |
| zyga | do'h | 10:38 |
| zyga | I found a very embarrasing bug | 10:38 |
| jjohansen | 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 |
| zyga | the bug exsits because I'm not using something I wrote for this specific purpose | 10:38 |
| zyga | (different bug, something I realized on friday and debugged just now) | 10:40 |
| mborzecki | 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:44 |
| Chipaca | zyga: when is the fix for the DENIED on actions_avail happening? | 10:45 |
| zyga | I didn't discuss this with jdstrand yet, I'm not sure what is the right way | 10:46 |
| zyga | since jamie is back this week it will be on my plate to ask | 10:46 |
| mvo | mborzecki: I can help | 10:52 |
| mvo | mborzecki: its in | 10:53 |
| mborzecki | mvo: thank you | 10:53 |
| mvo | 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:10 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/4867 updated with unit tests and green | 11:12 |
| mup | PR #4867: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4867> | 11:12 |
| zyga | +1 to merge? | 11:12 |
| mvo | zyga: yes | 11:13 |
| mvo | zyga: thanks for adding the test | 11:13 |
| cachio | zyga, hey, could yo uplease take a look to #4835? | 11:18 |
| mup | PR #4835: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835> | 11:18 |
| cachio | zyga, it is almost ready | 11:18 |
| zyga | hmmm | 11:19 |
| zyga | the extra code for stoppping the stopping of the mount unit is worrying, why do we need it? | 11:19 |
| cachio | zyga, this is mvo | 11:22 |
| cachio | zyga, it is to deal with a problem that comes from 2.31 | 11:23 |
| zyga | Should that be done by snapd instead so that is not just in test code | 11:25 |
| cachio | zyga, we were researching but the only way to fix that was mounting again the units after install | 11:25 |
| zyga | mvo: can you explain the problem please? | 11:25 |
| mvo | 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 |
| mvo | zyga: because it is the old prerm we cannot prevent this umount | 11:27 |
| mvo | zyga: I mean, that would be the ideal solution, do something to prevent this and just leave it running | 11:27 |
| mvo | zyga: the alternative is to undo what it was doing | 11:28 |
| zyga | right, I understand the prerm issue | 11:28 |
| zyga | so the question is this; is this a real issue that needs to be dealt in more than just test code | 11:28 |
| zyga | ah | 11:28 |
| zyga | sorry | 11:28 |
| zyga | I'm blind, this is in .postinst | 11:28 |
| zyga | so it's all fine | 11:28 |
| zyga | I read this as somthing in prepare-restore.sh | 11:28 |
| zyga | +1 :-) | 11:28 |
| mvo | zyga: ok | 11:29 |
| mvo | zyga: fwiw, I'm *not* happy with this code | 11:29 |
| mvo | zyga: and it only affects bionic and -proposed users | 11:29 |
| mvo | 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:30 | |
| mvo | cachio: 2.31.2 got accepted into -proposed - if you have time (not super urgent) please do the sru validation | 11:31 |
| cachio | mvo, sure | 11:32 |
| cachio | zyga, so, is it ok to merge bionic? | 11:32 |
| zyga | doing some comments there | 11:33 |
| zyga | hold on please | 11:33 |
| cachio | mvo, beta validation is ready | 11:33 |
| cachio | OI am waiting for confirmation from qa team | 11:33 |
| zyga | cachio, mvo: 4835 reviewed | 11:35 |
| cachio | zyga, thanks | 11:36 |
| mvo | cachio: cool, I will prepare 2.32(-final) then and focus on test fixes etc | 11:37 |
| mvo | zyga: anything that needs to land from your side in 2.32 still? | 11:38 |
| zyga | yes | 11:38 |
| zyga | two PRs I'm afraid | 11:38 |
| zyga | and everything that is tagged | 11:38 |
| zyga | note that I did _not_ cherry pick anything yet | 11:38 |
| zyga | so I'm afraid still a few PRs to go | 11:38 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/4867 is one that's ready to land | 11:38 |
| mup | PR #4867: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4867> | 11:38 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/4765 is a bigger one from the sprint | 11:39 |
| mup | PR #4765: interfaces: harden snap-update-ns profile <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 11:39 |
| zyga | mvo: and two more (small) that I'm brewing | 11:39 |
| mup | PR snapd#4867 closed: cmd/snap-update-ns: don't fail on existing symlinks <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4867> | 11:39 |
| zyga | mvo: I will try to prepare them both by 14:00 today | 11:40 |
| zyga | and after all the fixes are in master I will look at backport PRs | 11:41 |
| zyga | mvo: does that sound acceptable? | 11:42 |
| mvo | zyga: sounds good, lets talk during the standup. | 11:45 |
| zyga | ok | 11:45 |
| * cachio afk | 11:49 | |
| xnox | mvo, looks, i have no clue. | 11:50 |
| mvo | xnox: I think I asked before, but is there a porter box for s390x? | 11:52 |
| xnox | mvo, yes | 12:03 |
| vidal72[m] | zyga: I managed to fix it by changing @{INSTALL_DIR}="/snap" to @{INSTALL_DIR}="/{,var/lib/snapd/}snap" but now I have | 12:06 |
| vidal72[m] | 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:06 |
| zyga | vidal72[m]: I have never seen such a message (ANOM_ABEND) | 12:07 |
| pbek | vidal72[m]: if nothing helps you can use one of the many other install methods of QOwnNotes. ;) http://www.qownnotes.org/installation | 12:09 |
| vidal72[m] | zyga: "Triggered when a processes ends abnormally (with a signal that could cause a core dump, if enabled)." | 12:09 |
| zyga | I see | 12:09 |
| zyga | did you get any other denial? | 12:10 |
| zyga | perhaps it was killed by seccomp | 12:10 |
| zyga | those would be logged by the audit logger | 12:10 |
| zyga | vidal72[m]: I think the install dir is a clear omission on our end, | 12:10 |
| zyga | do other snaps work? | 12:10 |
| vidal72[m] | zyga: no, only this single message | 12:11 |
| vidal72[m] | 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:12 |
| zyga | vidal72[m]: please send a PR if you can | 12:13 |
| zyga | try the hello snap | 12:13 |
| zyga | it's very basic | 12:13 |
| Son_Goku | 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:13 |
| vidal72[m] | pbek: thx, I can succesfully use qownotes, just not as snap | 12:15 |
| Son_Goku | mvo, and zyga can probably get access to Fedora s390x boxes by requesting them in #fedora-s390x | 12:16 |
| zyga | thank you Son_Goku | 12:16 |
| zyga | I _hope_ we won't have to use them :) | 12:16 |
| zyga | but it's good that we have them if we have to | 12:16 |
| zyga | ok, one more bug fixed, now looking at the last one | 12:22 |
| zyga | actually, let's break for 5 | 12:22 |
| zyga | back.hurt() | 12:22 |
| mup | PR snapcraft#2005 closed: pluginhandler: special case go patchelf failures for classic confinement <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2005> | 12:32 |
| mup | PR snapd#4869 opened: cmd/snap-update-ns: use x-snapd.{synthetic,needed-by} in practice <Created by zyga> <https://github.com/snapcore/snapd/pull/4869> | 12:35 |
| * Chipaca -> lunch | 12:36 | |
| Chipaca | zyga: :-(((( | 12:36 |
| zyga | what's wrong John? | 12:36 |
| Chipaca | zyga: take more care of your back | 12:36 |
| zyga | yeah, I should take a walk | 12:37 |
| mup | PR snapcraft#2006 closed: many: use packaging logic to get patchelf <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2006> | 12:38 |
| mup | PR snapd#4870 opened: tests: drop old debug code <Created by zyga> <https://github.com/snapcore/snapd/pull/4870> | 12:39 |
| * Chipaca -> lunch-making | 12:42 | |
| mup | PR snapcraft#2008 opened: Release changelog for 2.40 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2008> | 12:57 |
| vidal72[m] | zyga: hello-world works, in qownnotes the error is: snap run qownnotes | 12:57 |
| vidal72[m] | Fatal: QXcbConnection: Could not connect to display :0 ((null):0, (null)) | 12:57 |
| vidal72[m] | [1] 5648 abort (core dumped) snap run qownnotes | 12:57 |
| vidal72[m] | I use xorg | 12:57 |
| mup | PR snapd#4850 closed: many: fix shellcheck warnings in bionic <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4850> | 12:57 |
| zyga | interesting, that may hint at a different issue now | 12:57 |
| zyga | mborzecki: can you run qownnotes on your arch system? | 12:58 |
| mborzecki | tseliot: installing | 12:58 |
| mborzecki | damn, wrong person :P | 12:58 |
| mborzecki | zyga: installing | 12:58 |
| zyga | pstolowski, cachio: standup time :) | 13:01 |
| mup | PR snapd#4835 closed: tests: add bionic system to google backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835> | 13:07 |
| mup | PR snapd#4871 opened: cmd/snap-confine: fix Archlinux compatibility <Created by Erick555> <https://github.com/snapcore/snapd/pull/4871> | 13:32 |
| vidal72[m] | zyga: I created PR with fixes for usr.lib.snapd.snap-confine on Arch ^^ | 13:33 |
| zyga | vidal72[m]: thank you, I will look at them in a moment | 13:34 |
| zyga | vidal72[m]: added one comment | 13:34 |
| vidal72[m] | zyga: I answered | 13:40 |
| vidal72[m] | zyga: I'm talking about this: https://github.com/torvalds/linux/commit/2a4c22426955d4fc04069811997b7390c0fb858e | 13:46 |
| zyga | ah, that's very interesting | 13:46 |
| zyga | yeah, I think your change looks good | 13:46 |
| zyga | I asked a colleague for a 2nd review | 13:46 |
| zyga | vidal72[m]: can you please sign the CLA https://www.ubuntu.com/legal/contributors | 13:47 |
| vidal72[m] | 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:49 | |
| mborzecki | zyga: https://github.com/snapcore/snapd/pull/4832 | 13:53 |
| mup | PR #4832: tests: move fedora 27 to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832> | 13:53 |
| zyga | mvo: I'll take a dog+lunch break now and will be back to fix bugs after that | 14:00 |
| mborzecki | off to pick up the kids from school and the dog from a vet | 14:06 |
| jdstrand | abeato: added to the list. note, just got back from holiday so going through backlog | 14:10 |
| mup | PR snapd#4870 closed: tests: drop old debug code <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4870> | 14:21 |
| zyga | jdstrand: good morning, welcome back | 14:43 |
| jdstrand | hey zyga, thanks :) | 14:51 |
| jamesh | 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 |
| mup | PR #4868: [WIP] secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868> | 14:52 |
| jamesh | it' | 14:53 |
| jamesh | s got good test coverage, but the question is whether it satisfies the security concerns | 14:53 |
| zyga | jamesh: I saw, thank you for starting and pushing that work! | 14:58 |
| zyga | jamesh: I _suspect_ so, I'll discuss this with jdstrand | 14:58 |
| mvo | mwhudson: just fyi - https://github.com/golang/go/issues/24449 - there is a s390x issue with go1.10 | 15:04 |
| xnox | 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:23 |
| mvo | xnox: I will just disable coverage on s390x for now and then see what upstream is doing | 15:25 |
| xnox | mvo, ok. | 15:25 |
| mvo | xnox: but yeah, going to 1.9 might be an option if there is no upstream reaction | 15:25 |
| mup | PR snapd#4872 opened: tests: add workaround for s390x failure <Created by mvo5> <https://github.com/snapcore/snapd/pull/4872> | 15:30 |
| pedronis | 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 |
| mup | PR #4829: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store <Created by pedronis> <https://github.com/snapcore/snapd/pull/4829> | 15:46 |
| === chihchun is now known as chihchun_afk | ||
| zyga | sigh, | 15:49 |
| zyga | this last error is just annoying | 15:59 |
| zyga | it's not hard but not easy either | 15:59 |
| cyphermox | ogra_: can I haz help to validate https://bugs.launchpad.net/netplan/+bug/1741910 ? | 16:08 |
| mup | Bug #1741910: ath6kl_sdio does not support unbinding <verification-needed-xenial> <netplan:Fix Committed by cyphermox> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1741910> | 16:08 |
| cyphermox | (I don't have any ath6kl_sdio here) | 16:08 |
| ogra_ | how dare you ! | 16:08 |
| ogra_ | :) | 16:08 |
| ogra_ | szre, will test :) | 16:08 |
| ogra_ | *sure even | 16:08 |
| cyphermox | ta | 16:08 |
| ogra_ | cyphermox, hmm, i can only test xenial, we do not have non-core images for any of the devices (and core is 16.04 only atm) | 16:14 |
| mvo | pedronis: I saw this, do you mean you want to keep the name and (maybe) consider changing it later? | 16:14 |
| pedronis | mvo: no, I changed things more, see PR | 16:15 |
| mvo | pedronis: aha, nevermind, just saw it, sorry | 16:15 |
| vidal72[m] | zyga: should I make PR which changes default @{INSTALL_DIR}="/snap" to @{INSTALL_DIR}="/{,var/lib/snapd/}snap" ? (not sure where it's set) | 16:15 |
| mvo | pedronis: nice, I like the diff | 16:15 |
| cyphermox | ogra_: only needed on xenial | 16:15 |
| ogra_ | ok | 16:15 |
| zyga | vidal72[m]: yes, feel free to push that to this PR or open a new one | 16:15 |
| zyga | vidal72[m]: and thank you for contributing! I'm super happy you are an arch user that cares about apparmor | 16:16 |
| cyphermox | zyga: vidal72[m]: nice, someone mentioned that to me as well yesterday for Fedora | 16:16 |
| vidal72[m] | Probably the only one who uses apparmor with snap... | 16:17 |
| zyga | vidal72[m]: I'm curious if there's any movement inside arch to enable apparmor in the distribution | 16:17 |
| zyga | did you have to package apparmor userspace tools or are those available already? | 16:17 |
| vidal72[m] | zyga: don't think so, userspace tools are avalaible in AUR (unofficial user repository) | 16:19 |
| zyga | vidal72[m]: I see | 16:19 |
| Pharaoh_Atem | zyga: generally speaking, Arch doesn't want audit enabled in the main kernel | 16:19 |
| zyga | well, it's good to have you, welcome :) | 16:20 |
| Pharaoh_Atem | the originally had SELinux enabled (with no policy), but the arch devs disliked audit being enabled | 16:20 |
| Pharaoh_Atem | the official hardened project prefers SELinux as well | 16:20 |
| vidal72[m] | zyga: I see it's defined in https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template_vars.go#L38 and https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/backend_test.go#L387 but I don't know how | 16:29 |
| vidal72[m] | "/{,var/lib/snapd/}snap" should be expressed in go | 16:29 |
| mup | PR # closed: snapd#3963, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4538, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4600, snapd#4672, snapd#4682, snapd#4700, | 16:30 |
| mup | snapd#4721, snapd#4750, snapd#4765, snapd#4767, snapd#4771, snapd#4772, snapd#4778, snapd#4781, snapd#4790, snapd#4805, snapd#4816, snapd#4819, snapd#4829, snapd#4832, snapd#4833, | 16:30 |
| mup | snapd#4840, snapd#4841, snapd#4842, snapd#4843, snapd#4844, snapd#4845, snapd#4854, snapd#4858, snapd#4863, snapd#4864, snapd#4868, snapd#4869, snapd#4871, snapd#4872 | 16:30 |
| zyga | hmmm | 16:30 |
| zyga | this is actually a bit more interesting now, that I think of it | 16:30 |
| zyga | when starting a snap application we do a bind mount from /var/lib/snapd/snap to /snap | 16:31 |
| mup | PR # opened: snapd#3963, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4538, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4600, snapd#4672, snapd#4682, snapd#4700, | 16:31 |
| mup | snapd#4721, snapd#4750, snapd#4765, snapd#4767, snapd#4771, snapd#4772, snapd#4778, snapd#4781, snapd#4790, snapd#4805, snapd#4816, snapd#4819, snapd#4829, snapd#4832, snapd#4833, | 16:31 |
| mup | snapd#4840, snapd#4841, snapd#4842, snapd#4843, snapd#4844, snapd#4845, snapd#4854, snapd#4858, snapd#4863, snapd#4864, snapd#4868, snapd#4869, snapd#4871, snapd#4872 | 16:31 |
| zyga | and apparmor should really be conifing /snap/whatever and never care about that other path | 16:31 |
| zyga | so whatever is going on here, makes things break elsewhere so that this happens | 16:31 |
| zyga | vidal72[m]: please don't make this change yet | 16:31 |
| Pharaoh_Atem | whoa | 16:32 |
| Pharaoh_Atem | wtf | 16:32 |
| zyga | Pharaoh_Atem: mup restarted / github broke | 16:32 |
| vidal72[m] | zyga: ok | 16:32 |
| cyphermox | zyga: I think the point was that the bind mount could be elsewhere than /snap, such as /var/lib/snapd/snap-mount (for example) | 16:33 |
| cyphermox | zyga: just so that other distros who really insist on FHS can be happy. | 16:33 |
| cyphermox | (but yeah, it needs a bit of thought) | 16:34 |
| Pharaoh_Atem | right, for example /var/lib/snapd/snap is where stuff is in Fedora, Arch, etc. | 16:34 |
| zyga | cyphermox: yes it can but before the application starts and before the application apparmor profile takes over we relocate that to /snap | 16:34 |
| zyga | so it's not supposed to happen this way | 16:34 |
| Pharaoh_Atem | yeah, but that doesn't happen for classically confined stuff | 16:34 |
| Pharaoh_Atem | you don't do internal relocation | 16:34 |
| zyga | yes, but is that snap classically confined? | 16:35 |
| zyga | vidal72[m]: is that snap classically confined (snap info will know) | 16:35 |
| zyga | I strongly doubt that becasue classic template doesn't care about INSTALL PATH | 16:35 |
| zyga | or INSTALL_DIR (sorry) | 16:35 |
| vidal72[m] | zyga: I found that it needs at first /var/lib/snapd/snap/qownnotes/906/meta/snap.yaml and then /snap/qownnotes/906/bin/desktop-launch so both /snap snd /var/lib/snapd/snap are needed | 16:36 |
| vidal72[m] | it uses strict sandbox | 16:36 |
| vidal72[m] | I don't have /snap top direcory on my system | 16:37 |
| zyga | vidal72[m]: I know but that directory exists later at runitme | 16:38 |
| zyga | vidal72[m]: if it ever sees /var/lib/snapd/snap then the bug is elsewhere | 16:38 |
| zyga | vidal72[m]: please try this: snap run --shell hello | 16:39 |
| zyga | then inside that shell run ls /snap | 16:39 |
| zyga | it's there at runtime even if your host system doesn't have it | 16:39 |
| cyphermox | zyga: isn't /snap only created at package install time? | 16:40 |
| zyga | cyphermox: no, it's never created | 16:40 |
| zyga | it's not in the host at any time | 16:40 |
| cyphermox | I disagree. | 16:40 |
| zyga | that /snap is really /var/lib/snapd/snap/core/current/snap | 16:41 |
| cyphermox | it was clearly in the snapd debian/dirs file, and /snap exists on my system :) | 16:41 |
| cyphermox | zyga: are you talking about an ubuntu-core system? | 16:41 |
| zyga | no | 16:41 |
| zyga | this is true in any system | 16:41 |
| zyga | cyphermox: ah, the confusion is that we are talking about the arch package | 16:42 |
| zyga | and things are different there because a while ago some arch maintainers decided to opt out of /snap in the package | 16:42 |
| cyphermox | right | 16:42 |
| cyphermox | Pharaoh_Atem: ^^ maybe you and vidal72[m] should talk | 16:43 |
| zyga | vidal72[m]: so to recap, I don't know what happens yet | 16:43 |
| zyga | vidal72[m]: but that snap should never need that permission so please don't change that part in template_vars.go | 16:43 |
| zyga | cyphermox: I suspect it's either something custom to vidal72[m]'s system or to the new 4.16 kernel | 16:44 |
| cyphermox | zyga: I don't need to know, I'm not at all familiar with Arch | 16:44 |
| vidal72[m] | zyga: with @{INSTALL_DIR}="/snap" snap run hello-world | 16:47 |
| vidal72[m] | fails as always; with @{INSTALL_DIR}="/{,var/lib/snapd/}snap" ls /snap fails with: ls: cannot open directory '/snap': Permission denied (blocked by apparmor) | 16:47 |
| vidal72[m] | *snap run --shell hello-world | 16:48 |
| mvo | hm, is there a way to see when "snap info go" channel edge devel-b61b1d2 was uploaded? | 16:51 |
| vidal72[m] | zyga: but /snap dir exist inside shell | 16:52 |
| zyga | vidal72[m]: right, that just shows what I meant | 16:53 |
| zyga | please open a forum thread to dicuss this so that it's not lost in this IRC chat | 16:53 |
| * mvo hugs mwhudson for having up-to-date edge snaps for golang, so helpful | 16:54 | |
| pedronis | mvo: ~ on the 19th | 16:54 |
| mvo | pedronis: ha! great, so super up-to-date | 16:55 |
| mvo | pedronis: thank you | 16:55 |
| vidal72[m] | zyga: I do, do you know what's going on with travis faild in https://github.com/snapcore/snapd/pull/4871 | 16:56 |
| mup | PR #4871: cmd/snap-confine: fix Archlinux compatibility <Created by Erick555> <https://github.com/snapcore/snapd/pull/4871> | 16:56 |
| zyga | not yet, let me look | 16:56 |
| mvo | pedronis: 4829 is good to go I think, feel free to merge/squash | 16:58 |
| mvo | pedronis: same for 4854 | 16:58 |
| pedronis | mvo: thanks, running some tests for something else and then I'll clicking on things | 16:58 |
| mvo | pedronis: ta | 16:59 |
| mvo | pedronis: no rush, just wanted to mention it :) | 16:59 |
| zyga | vidal72[m]: that's not related to your PR | 16:59 |
| zyga | hmm | 16:59 |
| mup | PR snapd#4829 closed: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4829> | 17:01 |
| mup | PR snapd#4854 closed: devicestate: add DeviceManager.Registered returning a channel closed when the device is known to be registered <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4854> | 17:02 |
| zyga | vidal72[m]: restarted tests in your PR, I have never seen that failure, maybe some issue in the recent changes to the testing system | 17:03 |
| mup | PR snapd#4873 opened: many: delay classic registration until first store interaction <Created by pedronis> <https://github.com/snapcore/snapd/pull/4873> | 17:21 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapcraft#2007 closed: catkin plugin: replace python calls in all profile.d scripts <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2007> | 17:38 |
| vidal72[m] | zyga: it failed again with similiar error :) | 17:57 |
| niemeyer | cachio: spread#53 looks pretty reasonable.. added some comments | 18:27 |
| mup | PR spread#53: Check uptime on system to determine if reboot was done <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/53> | 18:27 |
| cachio | niemeyer, nice, I'll take a look | 18:30 |
| cachio | thanks | 18:30 |
| vidal72[m] | is it normal that gnome app (gnome-mines) hasn't x11 slot? | 18:42 |
| vidal72[m] | zyga: wow I found what was breaking snap apps - I had disabled Xorg abstract socket!!! | 18:46 |
| zyga | vidal72[m]: where did you disable that? | 18:47 |
| vidal72[m] | I run xorg from sddm with "-nolisten local" config option | 18:49 |
| zyga | ah | 18:52 |
| zyga | :-) | 18:52 |
| vidal72[m] | zyga: i opened topic about @{INSTALL_DIR} issue: https://forum.snapcraft.io/t/apparmor-issues-with-default-install-dir/4568 | 19:24 |
| zyga | thank you vidal72[m], looking | 19:27 |
| mup | PR snapcraft#2009 opened: Base check for classic <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2009> | 19:38 |
| Lin-Buo-Ren | https://forum.snapcraft.io/t/documentation-issue-regarding-the-setup-lxd-section-part-of-get-started-with-snapcraft/4467 | 20:01 |
| ahasenack | hi, | 20:10 |
| ahasenack | somehow I got a snap with no version number | 20:10 |
| ahasenack | and snapd seems to not like it | 20:11 |
| ahasenack | Mar 19 17:09:12 nsnx snapd[8171]: 2018/03/19 17:09:12.233531 helpers.go:110: invalid snap version: cannot be empty | 20:11 |
| ahasenack | root@nsnx:~# snap list --all | 20:11 |
| ahasenack | error: cannot list local snaps! cannot find installed snap "core" at revision 4110 | 20:11 |
| ahasenack | are these two things relateD? | 20:11 |
| ahasenack | just "snap list" works, and shows the unversioned snap | 20:11 |
| jnamldk | when i run keepassx snappy, i get this error "cannot create lock directory /run/snapd/lock: Permission denied"; seems AppArmor fails to create the desired paths, any workaroud? | 20:29 |
| nacc | niemeyer: snapd in bionic just broke all my snaps :( | 20:44 |
| nacc | $ git-ubuntu --help | 20:44 |
| nacc | internal error, please report: running "git-ubuntu" failed: cannot find installed snap "git-ubuntu" at revision 402 | 20:44 |
| ahasenack | just what I got above | 20:44 |
| nacc | it worked immediately before the snapd update to snapd:amd64 (2.31.1+18.04, 2.32+18.04~pre5) | 20:44 |
| Odd_Bloke | I was having (differently presenting) problems and refreshing to the beta core snap fixed them. | 20:46 |
| Odd_Bloke | nacc: ahasenack: ^ | 20:46 |
| nacc | Odd_Bloke: interesting | 20:47 |
| niemeyer | nacc, ahasenack: There was a known bug due to the interaction of a prerm script and a baf behavior of systemd on mount units.. This is supposed to be fixed, I believe.. Easiest workaround is to just reboot | 20:48 |
| niemeyer | The cause is a snap.mount unit that is stopped by the prerm, when it shouldn't be since it's specific to containers.. systemd doesn't start, but stops the unit, and that chains into stopping every snap mount under it | 20:49 |
| nacc | niemeyer: will try it | 20:52 |
| nacc | niemeyer: confirmed, reboot fixed the issue | 20:57 |
| niemeyer | nacc: Phew | 20:58 |
| niemeyer | nacc: Sorry for the trouble.. we're on top of that one already.. I'll confirm with Michael tomorrow the versions affected | 20:59 |
| nacc | niemeyer: thanks! | 20:59 |
| niemeyer | nacc: In theory the fix should be going out, or be out already | 20:59 |
| nacc | niemeyer: ok; yeah i didn't see anything in bionic-proposed to test (when i looked earlier) | 20:59 |
| ahasenack | I'll reboot... at eod :) | 21:01 |
| Chipaca | ahasenack: if you need anything earlier, systemctl start snap.<stuff>.mount should fix it | 21:09 |
| Chipaca | ahasenack: (tab completion will help figure out the <stuff> bit) | 21:10 |
| ahasenack | thx | 21:13 |
| === zarcade_droid is now known as ^arcade_droid | ||
| vidal72[m] | are snaps supposed to create apparmor denials during normal usage? | 21:28 |
| Chipaca | vidal72[m]: they're not supposed to, but some might | 21:29 |
| Chipaca | vidal72[m]: why? | 21:29 |
| vidal72[m] | Chipaca: cluttering logs will make managing them harder for me. Is sandbox defined by mantainer or is it created automatically? | 21:33 |
| Chipaca | vidal72[m]: if it's bad enough to affect the logs it should be fixable | 21:33 |
| Chipaca | vidal72[m]: the ones we don't mind too much are things like java apps that try all sorts of crazy things on startup (but gracefully degrade to things that work and then are happy) | 21:33 |
| Chipaca | vidal72[m]: typically there'll be more chatter in the log about profile loads than denials, at least in my use | 21:35 |
| vidal72[m] | Chipaca: chatter are no problem, denials are - especially if you set notification about them :) I have qt app which try access /sys/devices/* at startup. | 21:37 |
| zyga | vidal72[m]: hey, about your system, normally snaps don't generate many denials but you are working with apparmor enabled and unpatched kernel, I think we are still missing one feature patch in mainline and this may switch all of confinment into big compain but don't deny mode | 21:38 |
| zyga | vidal72[m]: can you paste find /sys/kernel/security/apparmor | 21:39 |
| Chipaca | vidal72[m]: there might be an appropriate interface to let the app access /sys/devices (but probably not *, if that was literal) | 21:39 |
| Chipaca | vidal72[m]: OTOH if it's really doing that, you could detect you're in a snap and not do it :-) | 21:40 |
| vidal72[m] | zyga: my kernel is patched :) https://paste.ubuntu.com/p/JMJ9VGQZjS/ | 21:41 |
| Chipaca | vidal72[m]: do you also have the seccomp patches for complain mode? | 21:42 |
| vidal72[m] | Chipaca: I have only those https://gitlab.com/apparmor/apparmor/tree/master/kernel-patches/v4.15 | 21:43 |
| vidal72[m] | Chipaca: this app tries to acces my gpu under /sys/devices/ | 21:45 |
| * vidal72[m] sent a long message: vidal72[m]_2018-03-19_21:45:32.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/ndxqEpzSbAFVWSaHTjifuQKZ> | 21:45 | |
| Chipaca | niemeyer: not sure if my explanation of the <runes> prefix makes sense, or if I should just drop it; please advise | 21:45 |
| Chipaca | vidal72[m]: ooh, i think mborzecki might want to have a look at that | 21:46 |
| Chipaca | vidal72[m]: (he'll be around in 9h or so) | 21:47 |
| zyga | vidal72[m]: yes it looks like it | 21:47 |
| zyga | Chipaca: the patches are in the upstream kernel (for seccomp) | 21:47 |
| zyga | userspace just needs upstream release | 21:48 |
| zyga | vidal72[m]: I'm puzzled but not to confuse issues please report each issue separately on the forum | 21:48 |
| * zyga gets back to being AFK | 21:48 | |
| * Chipaca also is mostly afk, reading scifi and wondering whether to brave the cold to get some tea, or just stay put | 21:48 | |
| === mcphail_ is now known as mcphail | ||
| vidal72[m] | I guess it's caused by lack of opengl slot for this app. Is it possible to grant slot access manually? | 22:01 |
| zyga | vidal72[m]: you'd have to repackage the app | 22:14 |
| zyga | vidal72[m]: you can only connect and disconnect to existing slots | 22:14 |
| vidal72[m] | zyga: ok, I try to contact the developer | 22:15 |
| sdfsdf | ay | 22:33 |
| niemeyer | Chipaca: The current state and the actual implementation both look nice, actually.. I'm just not sure we need those functions, but for a different reason. I've sent a more detailed review. Let me know what you think | 22:35 |
| Chipaca | niemeyer: ok | 22:36 |
| Chipaca | niemeyer: where did you send it? | 22:36 |
| niemeyer | Chipaca: I thought it was in the PR itself | 22:36 |
| niemeyer | If not, please let me know | 22:36 |
| Chipaca | niemeyer: is it the one starting "Looking through this function"? | 22:36 |
| niemeyer | Chipaca: Yeah | 22:37 |
| Chipaca | niemeyer: ah, answered that before answering the others | 22:37 |
| niemeyer | Chipaca: Not sure I get what you mean there | 22:39 |
| sdfsdf | can I put a full lamp stack in snaps | 22:39 |
| niemeyer | Chipaca: strings has a LastIndexFunc whose func argument is a rune | 22:39 |
| Chipaca | niemeyer: yes | 22:39 |
| niemeyer | Chipaca: Do you mean it's broken? | 22:39 |
| kyrofa | sdfsdf, yep | 22:39 |
| Chipaca | niemeyer: no, it's not broken | 22:39 |
| sdfsdf | kyrofa: any guides? | 22:39 |
| kyrofa | sdfsdf, take a look at the Nextcloud snap, for example | 22:39 |
| sdfsdf | Snaps are a new idea to me | 22:39 |
| Chipaca | niemeyer: what do you do LastIndexFunc of? | 22:39 |
| kyrofa | sdfsdf, it's a little old, but yeah: https://kyrofa.com/posts/installing-nextcloud-can-be-a-snap | 22:40 |
| Chipaca | niemeyer: that is: you want the last unicode.IsSpace before the end of the terminal | 22:40 |
| niemeyer | Chipaca: I'm probably missing the trick of the logic | 22:40 |
| niemeyer | Chipaca: The logic there is doing: | 22:40 |
| niemeyer | idx = runesLastIndexSpace(text[:width+1]) | 22:41 |
| Chipaca | yes | 22:41 |
| niemeyer | How's that different from | 22:41 |
| niemeyer | strings.LastIndexFunc(text[:width+1], unicode.IsSpace) | 22:41 |
| niemeyer | or similar | 22:41 |
| sdfsdf | kyrofa: Can snaps access the full fat filesystem | 22:42 |
| kyrofa | sdfsdf, by default, no they're pretty locked down. You can get more access by using various interfaces, though | 22:42 |
| Chipaca | niemeyer: say text is " • árbol", and width is 5 | 22:43 |
| sdfsdf | I'm thinking about doing development with Ubuntu Core but I guess I'll use 16.04 LTS | 22:43 |
| sdfsdf | Then make a snap | 22:43 |
| Chipaca | niemeyer: or 10 even :-) i'm generous | 22:43 |
| kyrofa | sdfsdf, yeah development on classic Ubuntu is a little easier, but you can use the `classic` snap in Ubuntu Core to get access to a more "classic" environment, e.g. apt etc., which helps with development | 22:44 |
| niemeyer | Chipaca: Ok | 22:44 |
| niemeyer | ? | 22:44 |
| Chipaca | niemeyer: text[:width+1], if text is a string, is " • árb" | 22:44 |
| Chipaca | niemeyer: whereas there are less than width runes in text | 22:45 |
| Chipaca | so you could just print it | 22:45 |
| Chipaca | niemeyer: if width is 5, text[:width+1] with text as a string gives you " •�" | 22:46 |
| niemeyer | Chipaca: This is assuming a brok?en prior implementation of width | 22:46 |
| niemeyer | Chipaca: I think? | 22:46 |
| Chipaca | niemeyer: the width is the number of columns of the terminal | 22:46 |
| Chipaca | niemeyer: the terminal doesn't know how many bytes you are going to need in your variable-width encoding to encode the characters you want to show :-) | 22:47 |
| niemeyer | Chipaca: It sounds like you are referring to the behavior which is explicitly listed in the current implementation as being a bug still.. let me play that in a different way: | 22:47 |
| niemeyer | Chipaca: If width was 80, and the current text was defined to exceed 80, we'd want to cut it to less than 80 at the space.. | 22:48 |
| Chipaca | niemeyer: yes | 22:48 |
| niemeyer | Chipaca: That's what the logic there does.. it was determined to be in excess when we reach that line already | 22:48 |
| Chipaca | niemeyer: yes | 22:48 |
| niemeyer | Chipaca: at len(text) > width { | 22:48 |
| niemeyer | Chipaca: This is the same as runeCount(text) > width | 22:49 |
| Chipaca | but that comparison is only possible if text is a []rune | 22:49 |
| Chipaca | yes | 22:49 |
| niemeyer | Chipaca: Which is what is being done for the padding already.. | 22:49 |
| Chipaca | yes | 22:49 |
| Chipaca | niemeyer: the comment about it being broken might be confusing you, so let me explain that one first | 22:50 |
| Chipaca | niemeyer: what's broken is that the current implementation counts each rune as having widht 1 | 22:50 |
| niemeyer | Chipaca: Yeah, so that's where I was coming from.. it sounds like the logic might be easily implemented with logic similar to the one already in use there, without any type conversions or even allocations, since the logic is essentially slicing an existing string | 22:50 |
| Chipaca | niemeyer: but that's not true: some runes have widht zero (composing characters), some have width 2 (a lot of east asian things), some have ambiguous width that nobody knows | 22:50 |
| niemeyer | :) | 22:51 |
| Chipaca | niemeyer: no seriously :-) | 22:51 |
| Chipaca | niemeyer: but that's the map from a rune to the width on the terminal | 22:51 |
| niemeyer | Chipaca: I haven't looked, but from your comment the slightly depressing part is having no means to simply ask for the width | 22:52 |
| niemeyer | Chipaca: But that's an aside | 22:52 |
| Chipaca | niemeyer: and this is the map from the length of the utf8-encoded runes | 22:52 |
| Chipaca | niemeyer: there's a first approximation that's fairly good, if you ignore bugs | 22:52 |
| Chipaca | (but then there are bugs :-) ) | 22:52 |
| niemeyer | Yeah, +1 | 22:52 |
| Chipaca | niemeyer: the first approximation is to have two big unicode tables (like the ones in ctrl16.go and ctrl17.go in puritan) | 22:53 |
| Chipaca | (oh also these tables depend on the unicode version...) | 22:53 |
| Chipaca | (... which depends on the go version... ) | 22:53 |
| Chipaca | (everything is terrible) | 22:53 |
| Chipaca | anyway, that's getting ahead of this | 22:53 |
| Chipaca | this one is simply accounting for the fact that, for example, len("•") is 3 | 22:54 |
| Chipaca | (also that's the most-used non-ascii character in current stable amd64 descriptions) | 22:55 |
| niemeyer | Chipaca: Right, it sounded like the problem was simple enough to be handled with plain strings, similar to what we already have there for padding, but this isn't really a blocker | 23:11 |
| mup | PR snapcraft#2009 closed: Base check for classic <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2009> | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!