[01:00] hello [01:33] erio: `source-branch` should do the trick [01:33] joc: mind looking into https://travis-ci.org/snapcore/snapcraft/jobs/435246430#L1574 during your morning? [01:41] whoa [01:41] hey sergiusens [01:42] thanks [01:43] if you ever find time, I really really need help doing this snap https://github.com/ericoporto/ags-snap [01:45] I can't find a way to consistently build it on my computer vs on build.snapcraft.io [01:46] a ton of my adventure is reported here: https://forum.snapcraft.io/t/need-help-to-snapcraft-alsa/7647 [01:46] and here: https://github.com/ericoporto/ags-snap/issues/4 [01:47] the whole source of bugs is alsa [01:49] I couldn't figure out how to make parts being built to link and include each other in a way it works [01:49] I've been online trying to make this for 40h already, gotta sleep. [02:02] sergiusens: joc is off next week FYI [05:14] morning [05:14] * Son_Goku waves [05:14] I'm finally heading to sleep [05:18] mborzecki, I'm working on a rollback patch for snapd packaging in Fedora so that the SELinux policy compiles again on EL7 [05:18] Son_Goku: yay, thank you! [05:18] Son_Goku: need any help? [05:18] at the moment I'm fine [05:18] just tired and sick [05:19] the confirmation that I can't get around the dumb issue with glibc-static is what made me give up on trying to workaround it while preserving hardening flags [05:19] mborzecki, could you also file a bug report about that against RHEL 7? [05:20] Son_Goku: ok [05:20] mborzecki: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=glibc&version=7.5 [05:20] feel free to CC me on the bug after you file it [05:21] that works by email address, so use my regular gmail address (it's the one I commit in snapd as) [05:21] Son_Goku: on friday i ran into more issues, though with mounts this time, spent some time debugging it with zyga, 3.10x seems particularly picky about unmounting stuff [05:21] yeah, there's a lot of weird things going on there [05:21] Son_Goku: sure, will do [05:21] it'd be ironic if things worked better on the kernel-alt variant for ppc64le and s390x simply because that's kernel 4.14 [05:22] oh [05:22] the two arches I can't test at all :P [05:22] RHEL 7 uses 3.10 kernel for the arches it launched with [05:22] but all the newer arches use a 4.14 kernel [05:24] that'd be fun [05:24] yep [05:24] aarch64, s390x, ppc64le use 4.14 kernel now [05:24] x86_64 uses 3.10 kernel [05:25] s390x and ppc64le give you the choice of kernels [05:25] Son_Goku: maybe i'll just open a PR with centos today to keep track of what's happening there [05:25] PR with centos? [05:25] how are you going to do that? [05:25] centos doesn't patch or change the sources from RHEL [05:25] if you have a patch to fix the issue, propose it and attach to the RHEL bug [05:25] Son_Goku: i mean i'd open a PR to snapd with centos added to spread suite [05:25] ah [05:26] that's probably not a good idea right now, given how broken it is [05:26] but we do need spread images with centos+epel enabled [05:26] afaik, those don't currently exist [05:28] Son_Goku: whcih packages from epel you're insterested in? [05:28] squashfuse [05:29] kyrofa maintains it in Fedora and EPEL [05:29] mhm [05:30] also, golang is probably going to move to epel once it is dropped from RHEL [05:30] Son_Goku: they're dropping golang? [05:31] RHEL is planning to replace the golang package with the go-toolset SCL, which provides golang SCLized [05:31] https://developers.redhat.com/blog/2017/10/31/getting-started-go-toolset/ [05:31] ah, so software collections basically? [05:31] yep [05:32] scls will be updated each year with the latest version of those stacks from stable Fedora [05:32] so that means golang 1.10 or 1.11 will show up [05:32] and once golang is out of RHEL, it can be reintroduced in EPEL [05:33] and kept up to date with Fedora, just as rust is [05:34] mhm, makes sense [05:34] amzn will then be affected too, unless they keep their go packages [05:35] Amazon is likely basing their go stack on Fedora [05:35] (and update) [05:35] I believe their Rust packages are also derived from ours [05:36] heh, mix & mash all the bits [05:36] i guess whatever works for them and their customers :) [05:38] sure [05:38] most large EL users wind up using large portions of Fedora for their purposes anyway [05:38] EPEL is ridiculously popular :) [05:39] Son_Goku: zyga mentioned some stats that were shown during flock [05:40] yeah [05:45] Son_Goku: did you get an email from rhbz? [05:46] Son_Goku: bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=1634486 [05:46] yep [05:46] yep, got it [06:33] good morning [06:34] * zyga is grumpy but happy [06:34] well [06:34] happy because the day is nice, it's very cold but sunny [06:34] grumpy because apple resellers suck [06:36] hey mborzecki [06:41] zyga: they didn't replace the mbp? [06:41] well, it's more than that [06:41] first of all, I don't have it yet [06:41] they don't respond to email [06:41] I guy in another ispot said that apple NACKed the DOA claim because it was more than 5 days after purchase [06:41] but the laptop was paid for already? [06:41] and the service NACK the nack and ... nothing [06:41] yes [06:42] so nobody wants to fix it [06:42] and nobody bothered to tell me [06:42] I'll go there today for a refund or a new unit [06:42] it's just %@!#!@ that I have to bother [06:42] and you didn't get it back? [06:42] no, it's still "in service" [06:42] because they don't know what to do with it [06:42] daamn [06:42] yeah [06:42] customer service [06:42] anyway, I'll know more later [06:42] real apple service is better [06:43] it's just reseller adding the complexity that suck [06:43] and real apple service told me to contact them if this fails [06:43] really, the only thing missing is proper apple store somewhere in .pl [06:43] because reseller quality varies [06:43] and is not that controlled [06:43] oh [06:43] and the "service" broke the LCD [06:43] so... [06:43] I'm very very grumpy [06:44] do they even train their staff? [06:44] (where service is reseller-service) [06:44] not apple [06:47] hmm [06:47] odd [06:47] I have a shellcheck failure [06:47] on _one_ system only (18.04) [06:47] as if shellcheck was updated there now [06:47] ah wait, that's not the case [06:47] it's just confusing output of shellcheker [06:48] mborzecki: the spellchecking script for yaml should really not spam about 1000s of things it doesn't consider as fatal errors [06:48] how am I supposed to find the one it complained about? [06:48] spread-shellcheck [06:49] no, from the log [06:49] ther's a summary at the end [06:49] I know I can re-run the experiment and see [06:49] ERROR:root:validation failed for the following non-whitelisted files: [06:49] - tests/main/layout-symlink-bind-revert/task.yaml [06:49] yup, there you go [06:49] but the actual error is buried in that full log [06:49] well, I know that's the only file I added [06:49] well, that's because we have'nt landed everything yet [06:50] I'm arguing that it should not show the other output at all in this mode [06:50] it's just noise [06:51] what reminds me i should probably revisit that branch again now [06:51] yeah, perhaps we can just land it all quickly [07:05] mornings [07:05] hey pawel === mborzeck1 is now known as mborzecki [07:18] hmmm [07:19] syscall.Unlinkat has different signature than what the kernel claims [07:19] there's no flags :/ [07:31] PR snapd#5884 closed: overlord/snapshotstate: store the SnapID in snapshot, block restore if changed [07:44] I sent a PR with a test in it, I'm working on fixing the issues but if anyone wants to read it and merge it please be my guest https://github.com/snapcore/snapd/pull/5883 [07:44] PR #5883: tests,cmd/snap-update-ns: add test showing mount update bug [07:47] pedronis: good morning! it looks like 5878 is good to go except for the one "NoStore" test that jamie asked for(?) [07:50] pedronis: we can do that test in a followup if you prefer it this way btw (to avoid another spread-wait-for-green cycle) [07:53] I'd say I'm freezing but it's not quite sub-zero yet [07:53] but it's not warm anymore either [08:02] mvo: he asked some other things if possible, I'll look a bit and decide whether to them there or follow up [08:02] pedronis: thanks [08:05] mo'in [08:06] mvo: seems he was explicit about wanting the test before merging, otoh the other stuff is problaby later follow up material, it will touch preexisting tests [08:06] pedronis: ok [08:07] (more comments, remove vestigial code, maybe rename CheckInterfaces) [08:14] mvo: pushed, thanks for the review btw [08:31] PR snapd#5892 opened: tests: shellchecks part 9 [08:47] mborzecki: nice, thanks for more shellcheck fixes [08:51] Morning all [08:55] * zyga fires spread and goes to warm up with tea [08:55] hey everyone new :) [08:56] hey niemeyer , good morning [09:01] PR snapd#5878 closed: overlord/ifacestate: make sure to pass in the Model assertion when enforcing policies [09:02] how do you remove apparmor profile withouth a file? [09:02] ? [09:03] ah [09:03] heh [09:03] I understand your question [09:03] you cannot [09:03] niemeyer: hi [09:03] because a profile "file" is just a definition of arbitrarily named actual profiles [09:03] you can remove those if you know their name [09:03] but the "customary" way of doing that is to parse the profile again and remove the actual profiles from the kernel based on the parsed data [09:04] mborzecki: I went grepping around, it seems indeed we have cover the SnapID usages that were problematic already, and aliases code seems to use local snap names already, so it looks like it should work but test would be useful [09:04] to remove an actual profile you just write its name to a special file in sysfs [09:04] pedronis: thanks, i'll write a test for aliases nontheless [09:05] mborzecki: yea, we need a test about installing a 2nd version of a snap with auto-aliases and what happens with install, install --unaliases, and then prefer [09:05] pedronis: agreed [09:05] mborzecki: what prompted this? [09:07] zyga: apparmor package landed in community, so i rebooted with appamor enabled and some profiles were loaded, but aa-status output could not account for all of them, so i went fishing, and for instane when i removed a snap i saw a profile getting loaded, but once remove was done the profile was still there (?) [09:07] oh? [09:07] maybe we have a bug [09:08] zyga: idk, still looking, that's why i wanted to remove all the snap.* profiles that are there but should not be :) === chihchun is now known as chihchun_afk [09:08] mborzecki: go to sysfs [09:08] then to apparmor part of that [09:08] there's a bunch of dot files there [09:08] you can enumerate profiles [09:08] and remove them as I explained [09:09] mhm, trying [09:12] mborzecki: perhaps we remove the file before removing the profiles from the kernel? [09:12] mborzecki: on top of that we must see the old text in them [09:12] mborzecki: before they are changed [09:12] mborzecki: youck [09:14] mborzecki: if this is the case we need to change some things to make that possible [09:15] mborzecki: I'll wrap this up and we can talk [09:17] niemeyer: when you have a moment (not urgent) could you please add "github.com/snapcore/pi-gadget" to the things that mup watches? === chihchun_afk is now known as chihchun [09:18] mvo: Of course, will do [09:20] ta [09:21] niemeyer: it would be good if could review #5882 (it has a +1 from jamie already) [09:21] PR #5882: many: support and consider store friendly-stores when checking device scope constraints [09:21] pedronis: Sweet, thank you [09:37] if anyone has external usb camera - https://forum.snapcraft.io/t/have-a-pluggable-usb-camera-help-me-collect-some-data/7654 [09:37] yay, the leftover placeholders are gone now [09:37] now just to patch the affected unit tests [09:38] pstolowski: actually, any internal camera should be fine [09:38] they are usually attached via usb, no? [09:39] pstolowski: as such they go though the entire hot plug event system [09:41] zyga: how can i see remove event for it? in any case, i'd like samples anyway, i'd like to see vendor/products/serials and other attrs [09:41] pstolowski: unplug it [09:44] zyga: ah, indeed, udevadm trigger -c remove /dev/video0, nice, thank you [09:45] zyga: anyway... i'm interested in more smaples.. i see an anomaly with lime sdr, wonder if it happens to other devices [09:45] * zyga nods [09:48] devices i tried so far report a wealth of attributes when removed - including serial numbers - basically mirroring what i get when i plug them. but lime sdr for some reason only reports a subset when removed, in particular serial number is not reported even though it is present on 'add' [09:49] pstolowski: interesting [09:49] perhaps proprietary udev thing like Nvidia? [09:49] yep.. [09:50] zyga: don't know about nvidia, can you tell me more? [09:50] pstolowski: yeah, it's not registered in udev [09:50] pstolowski: because GPL symbols and what not, I don't recall the details [09:51] pstolowski: but presumably because it doesn't register in sysfs [09:58] zyga: ack. it's weird, on remove i'm getting vendor and product names from udev db, just not serial... as long as device is plugged udevadm info reports all the nice data, i really don't get the logic behind this [09:58] pstolowski: look at /run [09:58] see if the serial is written there [09:58] remove can only report what is there [09:58] and what the kernel says [09:59] https://www.irccloud.com/pastebin/WeQxnDRO/ [09:59] appears to be there [09:59] zyga: ^ [10:00] hmmm :D [10:00] then yeah, now I'd jump at udev [10:00] as in, read the source [10:00] :) [10:13] PR snapd#5893 opened: interfaces/apparmor: report apparmor support level and policy [10:13] zyga: ^^ [10:14] reading [10:21] pstolowski: Reviewed #5759.. the key is a bit too simplistic atm.. we'll need to get something slightly better there [10:21] PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug [10:24] brb [10:25] niemeyer: thanks. yes, the second part of your comment (versioning) crossed my mind at some point [10:26] pstolowski: Yeah, this is a real issue.. without something along those lines we cannot ever improve on the keying logic [10:26] niemeyer: yep, that's valid concern indeed. [10:38] pstolowski: #5782 reviewed too, with two suggestions [10:38] PR #5782: ifacestate: helpers for generating slot names for hotplug [10:39] re [10:39] zyga: https://paste.ubuntu.com/p/D6Fz5Fw3pb/ yeah, so the files are removed early, then apparmor_parser --remove has nothing to remove, but does not error out (?) [10:40] uh [10:40] I think it'd be nice if we remembered (in the state perhaps?) what was set up [10:40] the name of the actual profiles [10:40] niemeyer: by the way, a (random) remark about these keys: they are not "global" across interfaces, they are grouped by interface type at higher level of hotplug logic, so they need to be unique only within given interface; so, say key "1234" of "serial-port" interface might be different than "1234" of "camera" interface. this doesn't change any aspect of what you commented on, just mentioning becuase it's not apparent from [10:40] that PR [10:41] in either case we must have visibility into profile names [10:41] pstolowski: That's awkward [10:41] niemeyer: i can explain [10:41] pstolowski: At least it's the initial gut feeling [10:41] niemeyer: that goes back to what we discussed about the ability for any interface to provide own HotplugDeviceKey method [10:42] mborzecki: we can ask apparmor_parser for the names stored in a file [10:42] pstolowski: I can understand the key generation being unique, but seems suspect to have the storage of those keys being done at the interface level [10:42] mborzecki: apparmor_parser --names [10:42] mborzecki: the question is how to sequence that into the current framework [10:43] pstolowski: Or do you mean the keys are still centrally managed, but that the central map includes the type as part of the key? [10:43] pstolowski: That would be nice [10:43] zyga: heh, i'm looking what we have avaialbe in the handlers, and it's only snapsup :/ [10:44] mborzecki: can you expand on that idea, what were you hoping to find? [10:44] zyga: checking if there's snap.Info avaialble anywhere near there [10:44] mborzecki: and then? [10:44] niemeyer: no, storage is not done at interface level. hotplug machinery uses either the device key computed by the method from my PR, or - if interface has own method - it takes interface-calculated key string instead. and yes, that's centrally managed, basically interface type name becomes part of the internal map as well. [10:45] pstolowski: I still don't quite understand the picture.. it says storage is done at interface level, but then it says that it's centrally managed [10:46] pstolowski: What is done at the interface level, and how is it centrally managed then? [10:47] zyga: then you have apps, so you know the file names, security tags etc. but that's not really helping this particular case [10:47] zyga: how does it work on ubuntu when profile files are removed? [10:49] one sec [10:49] pstolowski: I do understand that the key is created by the interface, per our agreements.. that's sensible [10:49] mborzecki: you mean as in regular packages? [10:49] niemeyer: interface can implement HotplugDeviceKey method which returns a string representing a key, made of attributes od the device event, that's all. the returned key string is then used by hotplug machinery in internal maps, but interface type name is used together with the key [10:50] mborzecki: that's a good question, I _think_ it's handled by apparmor debhelper things [10:50] mborzecki: and because those files are shipped in /etc they are confffiles [10:50] mborzecki: so probably not removed until you purge [10:50] mborzecki: so perhaps that's how it works [10:50] or just nobody noticed if the profiles stay in the kernel after removal [10:50] pstolowski: Aha, okay.. sorry for not getting it. That's great. [10:50] zyga: and how about snaps? the code clearlyl removes profile files before attemptint to call apparmor_parser --remove [10:51] mborzecki: well, it clearly does not work [10:51] :P [10:51] it's just that the fact that the profile are in the kernel is not immediately obvious or problematic [10:51] so nothing was reporting any issues [10:52] niemeyer: thinking about your comment re devicekey, i wonder if it shouldn't become a proper object, rather than a loose string [10:52] pstolowski: If we use a digest, we might just prepend a "0" to the output so we know that's version zero.. this allows us to evolve the logic of keying later so we take into account current keys [10:52] ll [10:53] pstolowski: I'd try to keep it simple while we can [10:53] niemeyer: okay [10:53] niemeyer: btw, lime sdr has an annoying quirk that i discussed earlier this morning ^ [10:54] niemeyer: well, it can be udev quirk [10:58] PR snapd#5877 closed: cmd/snap-update-ns,osutil: move helpers to osutil [11:05] reviews for https://github.com/snapcore/pi-gadget/pulls would be great, should be pretty trivial [11:07] mvo: done [11:07] zyga: \o/ [11:16] * zyga runs some more spread tests before proposing another fix [11:17] netplan is passé? https://www.phoronix.com/scan.php?page=news_item&px=nettools-new-linux-network [11:19] diddledan: https://github.com/c-util/c-list/blob/dda36d30c7d655b4d61358519168fa7ce0e9dae9/src/c-list.h [11:19] I feel happy now [11:19] it's not just me ;-) [11:19] (it's referenced from n-dhcp-...) [11:20] * zyga returns to spread [11:27] PR snapd#5889 closed: make run-checks --static pass again w/shellcheck installed [11:28] mvo: if you want to see the stages in operation, https://travis-ci.org/snapcore/snapd/builds/435555961 is on === chihchun is now known as chihchun_afk [11:41] Chipaca: nice [11:41] cwayne: anyone who can cover for that thing that broke on plainbox? [11:41] mborzecki: my comment to mvo, or my comment to you about journalctl -o json? [11:41] mborzecki: either way, thanks :-) [11:41] Chipaca: hah, the stages [11:42] mborzecki: stealing ideas (and tests!) from snapcraft [11:42] mhm [11:42] mborzecki: just don't tell sergiusens or his head'll grow [11:43] (let's call it "cross-pollination", as snapcraft is also picking up some ideas from our test suite) [11:44] Chipaca: hah. [11:46] Sergio, Sergio, he's our man, if he can't be bothered, Kyle can :-p [11:47] msdos 2.0 is on github: https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-MS-DOS-GitHub [11:47] PRs welcome? [11:47] diddledan: licensing is unclear tho [11:47] yeah [11:48] also we already have a dosbox part, right? [11:48] right? [11:48] according to the repo LICENSE.md file it's MIT now... [11:48] ref: https://github.com/Microsoft/MS-DOS/blob/master/LICENSE.md [11:48] diddledan: https://github.com/Microsoft/MS-DOS/issues/2 [11:49] pedronis: quick question, i've installed test-snapd-auto-aliases_foo, now when doing snap install --unaliased test-snapd-auto-aliases_1.snap it fails complaining it cannot enable automatic aliases for test-snapd-auto-aliases because those are already enabled for _foo, but i passed --unaliased, so i'd expect it to install the snap nonetheless [11:49] oic [11:55] mborzecki: ok, sounds like there is something to fix then [11:57] pedronis: after a quick look, checking for conflicts with enabled aliases does not look at the --unaliased of the snap being installed, but checks AutoAliasDisabled of snaps that are already present [11:58] mborzecki: that sounds strange [11:58] can't be the full picture [11:59] pedronis: yeah, i'm more than likely to miss something, anyways, need to dig into the code [12:00] hiya! :-) === pstolowski is now known as pstolowski|lunch [12:02] PR snapd#5782 closed: ifacestate: helpers for generating slot names for hotplug [12:02] I noticed a bunch of three loop mounts in nautilus this morning, which turned out to be lxd snaps. a bit more investigation and it turned out to be loop mounts where the backend file had been removed. looks like the loops didn't get teared down during the refresh or something? [12:03] I had to reboot just now, which obviously removed the issue :-/ [12:04] there might be something in logs though, if anyone feel up for a debugging session... [12:06] mborzecki: afaict unaliased set snapst.AutoAliasDisabled of the being installed snap to false and then checks the conflicts [12:06] considering that value [12:07] pstolowski|lunch: how many reports about webcams are you after? We can post on the snapcraft socials, drawing people into that post [12:07] pstolowski|lunch: given it's a really easy way for people to contribute, might be nice to promote? [12:08] popey: just a few is really all i need for now, but thanks for asking! [12:08] no worries [12:09] Nafallo, they go away after a reboot, i told stgraber about it a while ago [12:10] (i think i had three lxd updates since my last reboot ... they pile up in the launcher :) ) [12:10] off to pick up the kids [12:11] ogra: so a known one. excellent :-) [12:12] well, i didnt file a bug iirc [12:13] ogra: gogogog ;-) [12:14] audacity 2.3.0 just went to the stable channel [12:17] woooo [12:18] diddledan: shame the version string is a bit verbose [12:19] yeah, that's because I didn't trim the git tag - I wanted to use a portable script that any repo can use [12:20] note the `$SNAPCRAFT_PROJECT_NAME` to allow it to work on any project https://www.irccloud.com/pastebin/nvi3aI7B/ [12:21] I don't like the comment wording though. it confuses me. I stole the script from wormhole [12:22] hm, just looks a bit nasty having the version number in the snap info [12:22] (the name in the version number obv) [12:23] surely we want the version number :-p it's the name we don't want :-p [12:23] yeah that ↑ [12:42] hmm, i have some very weird behavious of a configure hook [12:42] #! /bin/sh [12:42] set -e [12:42] IP="$(snapctl get serverip)" [12:42] [ -n "$IP" ] && echo "setting Server IP to $IP" [12:42] thats all thats in there ... [12:43] it automatically rolls back my snap when i try to install it [12:43] is snapctl automatically exiting 1 when there is no value set ? [12:43] (so that the set -e kills the hook ) [12:44] ogra: does snapctl require the snap name? [12:44]