=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [03:13] PR snapcraft#1262 opened: replace : with _ in file names === chihchun_afk is now known as chihchun === ahoneybun is now known as Guest36814 === chihchun is now known as chihchun_afk [04:18] Bug #1576500 changed: Plasma fails to load: "all shell packages missing"

[06:12] PR snapd#3195 closed: interfaces/builtin: allow full access to properties iface of the udisks service [06:13] Bug #1684014 opened: LibreOffice in snap won't print [06:15] mvo: thanks for merging! [06:15] morphis: my pleasure, thanks for doing the PR in the first place :) [06:39] PR snapd#3048 closed: interfaces: add media-hub interface [06:46] PR snapd#3179 closed: packaging: add `built-using` header for 16.04 packaging [07:24] good morning [07:25] mvo: about https://github.com/snapcore/snapd/pull/3198 -- it is an update of existing function to use the new type that was introduced later; it used to take []Entry but now it takes a struct with that inside [07:25] PR snapd#3198: interfaces/mount: pass mount.Profile to mount.NeededChanges [07:25] mvo: I should have documented that inside the PR [07:39] PR snapd#3198 closed: interfaces/mount: pass mount.Profile to mount.NeededChanges [07:58] PR snapd#3203 opened: interfaces/mount: add ReadMountInfo and LoadMountInfo [08:12] mvo, hey, 3197 has a conflict. it can land once fixed [08:14] PR snapd#3204 opened: interfaces/builtin: don't panic if content plug has nil attrs [08:16] pstolowski: something for you https://forum.snapcraft.io/t/snapd-service-doesnt-start/319 [08:16] pstolowski: sure, I will push a fix, I also adding a testh [08:16] test [08:18] * zyga -> break / errands [08:19] Bug #1684041 opened: In core /var/lib/systemd/backlight should be bind mounted to writable [08:24] Someone needs to fix the snapcraft bot on rocketchat [08:49] PR snapd#3205 opened: tests: add openvswitch interface spread test [09:01] urgh [09:01] niemeyer, mup is going crazy in the #snapcraft channel on rocket [09:02] sending the same bug notification every 2sec [09:04] PR snapd#3204 closed: interfaces/builtin: don't panic if content plug has nil attrs [09:05] ogra_: Stopped and investigating. Thanks for the note. [09:05] niemeyer, wow, now i'm impressed ... wouldnt have expected you awake! [09:05] ogra_: Me neither.. [09:05] :) [09:06] lol [09:06] ogra_: Looks like RocketChat broke the protocol again [09:06] ouch [09:07] I bet it was just updated.. [09:07] Yep.. [09:07] 1 hours, 13 seconds [09:36] mvo: are we releasing 2.24 again? [09:37] we need a 2nd review for https://github.com/snapcore/snapd/pull/3149 [09:37] zyga: just a sru fix [09:37] aha [09:37] zyga: the autopkgtests are unhappy currently and the SRU team wants us to do some small tweaks, I'm also preparing a fix for a failure with the stable core snap [09:38] zyga: but this only affects the debs, we could even do it as a distro patch [09:42] \quit [09:48] PR snapd#3206 opened: [2.24] Add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine [09:55] mvo: thanks for merging the panic fix [09:55] mvo: I was thinking, could we call {plug,slot}.Sanitize and register a panic handler so that we fail sanitization if the method misbehaves [09:55] mvo: that part is naturally exposed to user input [09:56] mvo: and while it cannot harm snapd as go is a safe language (except for the unsafe package we don't use here) [09:56] mvo: malicious input can include denial of service attacks, like this one [09:59] zyga: thanks for fixing the panic so quickly [09:59] zyga: a good question about the handler, probably best to check with gustavo, I think it would be fine [09:59] zyga: depends a bit how clean it will be (codewise) I htink [10:00] mvo: I think that's pretty clean, let me make a quick prototype [10:01] PR snapd#3207 opened: tests: relax network-bind interface regexps [10:14] mvo: if this is ubuntu specific, please don't re-release the tarball [10:15] it's not the end of the world if you need to distro patch temporarily [10:15] Son_Goku: yeah, I think we should not even do a regular release, its strictly fixes for autopkgtests that are pretty specific [10:16] indeed [10:17] hey Son_Goku, how are you doing [10:18] well, I just woke up, so kinda cottonmouthy [10:50] mvo: ok, took longer than expected but is pretty short actually [10:51] PR snapd#3208 opened: interfaces: recover panics when sanitizing plugs and slots [10:52] mvo: details on the forum https://forum.snapcraft.io/t/snapd-service-doesnt-start/319/5 [10:52] * zyga takes a break and goes to eat something [10:52] ttyl [11:10] re [11:11] zyga, an opinion on bug 1684063 would be appreciated [11:11] Bug #1684063: core snap/amd64: dynamic linker unusable in classic confinement when using Zesty [11:11] ogra_: looking [11:13] ogra_: replied [11:13] ogra_: look at the reply please [11:14] zyga, seeing it ... hmm, but that means i need to mangle the link ... not great :/ [11:17] ogra_: I think there should be no links [11:18] ogra_: the way snapcraft links snaps should give them the realpath of the linker [11:18] zyga, well, thats a default setup coming from libc [11:18] ogra_: not some symlink [11:18] ogra_: IMO that is irrelevant [11:18] ogra_: if the linker is in /snap/core/current/foo-ld.so [11:18] ogra_: then whatever other symlinks point to it [11:18] ogra_: that is what snapcraft should use [11:20] zyga, well, the problem is that the core snap uses an absolute link to / [11:20] or rather libc does [11:20] so it links outside of the core snap [11:21] Son_Goku: you had success fixing a few few SELinux denials yesterday? [11:21] the binaires would have to use /snap/core/current/lib/x86_64-linux-gnu/ld-2.23.so ... [11:22] instead of /snap/core/current/lib64/ld-linux-x86-64.so.2 ... (which is the default everywhere) [11:22] so you would have to re-build each and every binary [11:26] ogra_: absolute link to / ? [11:26] ogra_: sorry, I don't understand [11:27] ogra_: that is correct [11:27] ogra_: the answer is to rebuild those [11:27] ogra_: that's how it is designed to work [11:27] ogra_: (until we come and re-design it) [11:27] ugh [11:27] but that means you can not use any stage-packages at all in classic snaps [11:27] you would have to build all dependencies from source [11:28] ogra_: yes, until we figure out a better way to have classic confinement working [11:28] morphis: some of the issues are related to the socket not having its label applied correctly [11:28] ogra_: it's a complex problem - there's no silver bullet [11:28] I wonder if systemd can create the socket with the correct label... [11:28] ogra_: what did you mean about symlink mangling? [11:28] zyga, hmm, could you note that on the big as well ? i think thats unexpected [11:28] Son_Goku: can we fix that somehow? [11:28] Son_Goku: yes, we can [11:28] Son_Goku: you mean selinux label? [11:28] yes [11:28] Son_Goku: sure we can, it's a feature in systemd for ages [11:29] zyga: [11:29] ogra@styx:~$ ls -l /snap/core/current/lib64/ld-linux-x86-64.so.2 [11:29] lrwxrwxrwx 1 root root 32 Mär 21 21:06 /snap/core/current/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.23.so [11:29] zyga, see where the link points to ? [11:29] that is my hosts linker [11:30] zyga, if my host has a newer libc ... i.e. 2.24, that link points nowhere [11:30] zyga: is there a config item for this in the service unit? [11:30] morphis: SELinuxContext= [11:30] morphis: AFAIR [11:30] ah [11:30] ogra_: aha [11:30] ogra_: I see [11:30] ogra_: right, [11:31] Son_Goku: so SELinuxContext= is what we should try [11:31] zyga: doesn't look like it for .socket files? [11:31] Son_Goku: https://www.freedesktop.org/software/systemd/man/systemd.socket.html [11:31] there's SELinuxContextFromNet= [11:31] yeah [11:32] that will use the connection from the daemon to determine the label [11:32] ah, that might work [11:32] " When true, systemd will attempt to figure out the SELinux label used for the instantiated service from the information handed by the peer over the network." [11:32] so we need to touch snapd.service and snapd.socket [11:32] snapd itself is already properly labeled, I think [11:33] the issue is that the socket doesn't exist at the point of the policy getting applied [11:33] ogra_: unless sergiusens disagrees I don't think we support prebuilt binaries yet [11:33] so I think snapd.socket is the only thing that needs to be changed [11:33] zyga, you mean no stage-packages in classic ? thats news to me [11:34] (but that would indeed solve the issue) [11:36] hallo, spricht hier jemand deutsch? [11:37] ogra_: yes that's what I mean [11:37] Son_Goku: ok, so who labels snapd if not through the .service file? [11:37] ogra_: how did you expect stage-packages to work/ [11:37] zyga: https://github.com/snapcore/snapd/pull/3156 gets really close :-) [11:37] PR snapd#3156: Support debian in our CI [11:37] morphis: let me see :) [11:37] morphis: the policy, when it is applied, labels /usr/libexec/snapd as snappy_exec_t [11:37] zyga, dunno, i never built a classic snap ever :P [11:37] that happens during the package install [11:38] * ogra_ thinks thats an insanity anyway [11:38] morphis: I have a fedora system that I plan to use for daily development in the next 2-3 weeks; I need to buy some extra hardware and then I can switch [11:38] or at least, it should... [11:38] zyga: two tests are failing which I need to look into but all others should be ok now [11:38] zyga: nice :-) [11:38] Son_Goku: ah I see [11:38] * Son_Goku needs to set up a clean box and test something [11:39] something about these denials is bugging me, because it looks like at least a good chunk of them shouldn't be issues anymore... [11:39] morphis: commented quickly [11:39] morphis: I'll comment again after reading it fully [11:39] please help my. i have follow error with "sudo snap install nextcloud"-command -> https://pastebin.com/DsherkXt [11:39] kotVaska: hey, you may have better luck on forum.snapcraft.io [11:40] kotVaska: I'll gladly help you there [11:40] kotVaska: because others can benefit from this [11:40] zyga: thanks [11:40] kotVaska: please open a new thread under the "snap" category [11:40] thanks! [11:42] zyga: I don't want to register there. [11:43] * zyga though we already had various social network login available [11:44] we still don't [11:44] kotVaska: can you please run `snap version` [11:46] * ogra_ bets the kernel is a mess ... the "vps" in the hostname kind of indicates that :) [11:46] zyga: 2.22.6 [11:46] kotVaska, the full output please [11:46] snap 2.22.6 [11:46] snapd 2.22.6 [11:46] series 16 [11:46] ubuntu 16.04 [11:46] kernel 2.6.32-042stab120.7 [11:46] (should be 5 lines) [11:46] lol [11:46] oh god [11:46] 2.6.32-042stab120.7 [11:46] stab is right [11:46] kotVaska, that cant work [11:46] it's an OpenVZ system [11:46] yes [11:47] kotVaska, talk to your vps provider to use a proper kernel [11:47] you can't run snaps on OpenVZ [11:47] kotVaska: snapd won't work on that kernel [11:47] kotVaska: your kernel is too old, I'm sorry [11:47] they need to upgrade to Virtuozzo 7 [11:47] this is like decades outdated [11:47] if they do that, snaps will work again [11:47] i have a vServer [11:47] * zyga recalls his first job that had a 2.6 kernel ;) [11:47] kotVaska: your hosting provider needs to upgrade to Virtuozzo 7: https://virtuozzo.com/products/virtuozzo/ [11:48] PR snapcraft#1263 opened: Pass through commands into the lxd container [11:51] my provider have "LXC - Linux vServer", " Qemu-KVM vServer" and " OpenVZ vServer" [11:51] i rent openvz vserver [11:52] zyga: where did you still see is-forced-devmode on the PR? [11:52] Qemu-KVM will work, as you'll use the distro's kernel [11:52] that should be gone [11:52] morphis: hmm, [11:52] and LXC may work, if the host is modern [11:52] morphis: not sure what you mean? [11:52] morphis: I commented on the blacklisting of tests on Debian [11:52] morphis: that those had no comments explaining why [11:52] got a mail with a comment "I suspect this part doesn't respect the rules for command help and long description. Have a look at other commands and what they do." [11:52] morphis: ah [11:52] morphis: that's ancient :) [11:52] morphis: it was for a command you wanted to add [11:53] morphis: to check if a distro is in forced devmode [11:53] yeah, I will do that in a second step [11:53] morphis: we (very long time ago) defined some rules of how help for commands must look like [11:53] morphis: including specific wording [11:53] morphis: see all the commands, they have consistent help wording [11:53] ok, any link to that? [11:53] morphis: no, it was before we had anything like a forum/public ML [11:53] morphis: it was in a private email thread [11:54] morphis: just use your imagination, compare to how other commands have help worded [11:54] kotVaska, you sould re-consider that ... this kernel is definitely something very hacked up ... running ubuntu 16.04 on a 2.x kernel was never officially possible .... would be surprising if there were not also other issues that do not surface as easily as this one (not to forget there might be horrid security holes) [11:54] zyga: worth to bring that to the forum or any other documentation place now :-) [11:57] morphis: yeah [11:57] morphis: if you ask the question I'll go through my archive and try to find it [11:57] ogra_: zyga we don't support doing the right thing with runnables from prebuilts when on classic confinement, that is correct [11:57] thanks [11:58] ogra_: it's not hacked up [11:58] it's a container [11:58] don't be misleading [11:58] Son_Goku, dude ... to make 16.04 run on top of a 2.x kernel you will have to massively patch it [11:58] unless the 2.6 kernel itself has been patched and backported [11:59] zyga: thanks [11:59] which is exactly how that is even working [11:59] no matter if it is a container or raw HW [12:00] were there even things like multiple pty's possible in 2.x ? i dont think it was ... there is a ton of corner cases that will affect the behaviour of the userspace here [12:00] the OpenVZ kernel used supports multiple ptys [12:00] this can not legally be called ubuntu [12:00] then the same goes for all your docker images [12:01] if I load a docker image into an OpenVZ system, I didn't touch Ubuntu [12:01] depends if they are blessed by canonical or not ... but i doubt there are doker installs using 2.x anywhere [12:01] a docker image doesn't have to be used by docker [12:01] rkt, nspawn, lxc, openvz, etc. can all consume them [12:02] sure,. i can also consume am ubuntu-base tarball o top of a monolithic 1.x kernel and still cant seel it as ubuntu then [12:02] *sell [12:03] the kernel is a part of the brand [12:04] (you cant sell RH CDs with a replaced kernel either and call it RH) [12:16] another part of update-ns for review: https://github.com/snapcore/snapd/pull/3209 [12:16] PR snapd#3209: interfaces/mount: add partial implementation of Change.Needed [12:16] PR snapd#3209 opened: interfaces/mount: add partial implementation of Change.Needed [12:16] I'll switch to code reviews now and work on chipaca's tab-completion PR now [12:17] ogra_, morphis: ^^ [12:17] low level, feedback appreciated [12:21] zyga, why do you nered all the options for umount ? if it is mounted the mountpoint should be enough for unmounting [12:21] *need [12:25] ogra_: interesting point; I guess we don't want to unmount something _else_ [12:25] ogra_: but not sure if that captures it [12:26] well, that would only affect things that are double-mounted on the same mountpoint (which you likely dont want top happen in the first place) [12:26] *to [12:28] morphis: did you cancel the call just now? [12:28] ogra_: yes, I think you are right [12:28] beyond that i think it looks fine [12:28] ogra_: I think the devil is in mountpoint details though (like bind mounts making stuff more complex) [12:29] i also wonder if you carry over the mount options for filesystems from the original mount when bind mounting ... [12:29] ogra_: yes, those are unchanged [12:29] ogra_: well, there are two sets as you see [12:29] good [12:29] ogra_: superblock and per-mount [12:30] right, i'm rather cobncerned about "noatime,nodiratime,data=ordered" etc ... stuff that makes sure we dont wear out SSDs or eMMCs [12:31] but i guess that is carried forward anyway ... or rather physically used from the original mount [12:33] ogra_: I think that right now it doesn't matter [12:33] ogra_: we only do bind mounts [12:33] ogra_: and the code as written is only a stab at the generic functionality [12:33] yeah [12:54] PR snapd#3210 opened: tests: relax network-bind interface regexps for 2.24 === caribou_ is now known as caribou [13:21] PR snapcraft#1255 closed: Update rust plugin to set RUSTFLAGS [13:24] PR snapcraft#1250 closed: Fixed links to doc [13:27] PR snapcraft#1251 closed: cli: remove empty lines in the unclean parts message [13:46] hi all: it seem that there is a misalignement between https://snapcraft.io/docs/reference/interfaces and the result of snap interfaces on a snap core 1580; ex network-manager is on wiki page but not in snap interfaces output [13:47] NicolinoCuralli, well, depends on the context [13:47] naturally snap connect don0t work for that interface [13:47] NicolinoCuralli, on a classic install where network-manager is pre-installed for your desktoop, the interface is provided by this ... [13:48] ogra_ : i run in a strict mode [13:48] on a core image on some developer board there is no network-manager, thus there is no interface for it until you install the network-manager snap [13:48] so the interface is context dependant [13:49] ogra_ : i understood , thanks [13:49] :) [13:50] NicolinoCuralli: although, you can install the network-manager snap https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/installation [13:50] indeed [14:07] anyone know how to force a refresh that actually loads snappy reposities? I tried but I just get this https://apaste.info/8eil [14:09] donofrio, that is not how snaps work [14:09] there are no local ppackage lists you need to refresh like you have in apt [14:09] (also ubuntu-core is obsolete ... the snap is only called "core" nowadays) [14:10] ogra_, how do I use this good project then....when I try "snap install --classic anbox-installer" from https://github.com/anbox/anbox/blob/master/README.md#installation I just get no snap found ;( [14:10] donofrio, thats a normal ubuntu install ? [14:11] uh yah [14:11] (i dont think classic snaps work anywhere else currently) [14:11] whats the output of "snap version" (shoudl return 5 lines) [14:16] donofrio, oh, also ... nevver use "sudo su -" it will unset a lot of environment ... use sudo -s or sudo -i and not su [14:16] (snapd definitely uses some env that would be dropped by "su -" ) [14:19] (but thats a general rule not snap specific ... su - is always bad unless you want to be in a new env) [14:21] niemeyer, since when does an empty "snap find" actually return one/two packages ? thats new ... [14:21] * ogra_ gets lxd, docker, mongo32 and rocketchat-server as returns here [14:22] i wonder if something regressed in 2.24 in that regard [14:22] ogra_: I think the idea was always to have a stock list of interesting snaps there.. if they're too few, probably something needs fixing [14:22] ogra_: Can you open a topic on forum under "store"? [14:22] ogra_, do you know if ubuntu core 16 has an image in AWS? [14:23] kyrofa, i dont actually ... but i dont see why the normal x86 image wouldnt work ... [14:24] Yeah, I just see blog posts from 2014 saying "hey, it's on AWS!" like it was hard, so... [14:24] * kyrofa actually goes to check for himself [14:25] niemeyer, https://forum.snapcraft.io/t/empty-snap-find-suddenly-returns-four-snaps-but-not-more/323/1 [14:25] kyrofa, it was hard back then ... it needed some special packages added ... but that need was dropped [14:26] (we used to actually build special AWS images in 15.04 snappy ...) [14:26] ogra_, yeah, the only results I'm seeing are in the community AMIs, and that's only 15.04 [14:28] niemeyer, do you know anything about ubuntu core on AWS? [14:28] kyrofa, rharper does perhaps ... being in the cloud team [14:28] kyrofa: Not much to be honest [14:29] niemeyer, trying to figure out how to test a CUDA setup without buying an expensive video card :P [14:29] all i know was that i was asked to drop the AWS hacks before 16 because it would "just work" now [14:29] ogra_, good deal, thank you [14:33] ogra_: Thanks for the topic [14:35] jdstrand: tyhicks can I get your opinion on https://forum.snapcraft.io/t/asset-recording-for-a-built-snap/317?u=sergiusens [14:38] sergiusens: nice! I'll need a little bit of time to think it over [14:38] tyhicks: no rush [14:39] PR snapcraft#1260 closed: meta: version from git support [14:48] sergiusens: I saw it and like tyhicks, plan to think about it and comment [14:48] PR snapcraft#1264 opened: tests: do not print coverage check message [14:52] zyga: can you have a quick look at https://paste.ubuntu.com/24414168/ ; not an expert yet in reading those expect scripts [14:53] zyga: look at the bottom [14:54] morphis: looking [14:55] morphis: those expect-based tests are very unreliable [14:55] morphis: just run it a few times, if it fails still it's interesting [14:55] they reliable fail on debian :-) [14:55] morphis: in that case run those manually in a debug shell [14:55] morphis: and see what you get [14:55] morphis: maybe PS1 discrepancy or something [14:56] hm, that is a good idea [14:57] * zyga goes for a walk, ttyl [14:59] zyga: that's it [14:59] morphis: aha, PS* differences? [14:59] $ bash --norc -i [15:00] that gives different prompts on debian vs. ubuntu [15:01] * zyga completed backup [15:01] ttyl :) [15:12] PR snapcraft#1203 closed: Add some initial checks to intelligently build the initial snapcraft.yaml [15:24]