[00:08] Chipaca, all the tests passed [00:09] cachio_: merge away! [00:13] Chipaca, I cant [00:13] cachio_: oh! [00:13] Chipaca, tx :) [00:14] PR snapd#3448 closed: tests: fix for the test postrm-purge [01:12] PR snapd#3446 closed: errtracker: Include /etc/apparmor.d/usr.lib.snap-confine md5sum in err reports [01:42] PR snapd#3420 closed: many: slight improvement of some snap error messaging === chihchun_afk is now known as chihchun === JanC_ is now known as JanC [06:08] good morning [06:09] * zyga had a terrible dream [06:10] morning! [06:10] zyga, mvo: one of you can merge https://github.com/snapcore/snapd/pull/3406 now? [06:10] PR snapd#3406: tests,packaging: add package build support for openSUSE [06:11] morphis: yes, just fiddling with expired github login [06:11] :-) [06:11] morphis: good morning, how are you? [06:11] zyga: fine, you? [06:12] so so, weather has deteriorated today it seems [06:13] gets stormy again :-) [06:15] morphis: done [06:15] morphis: thank you for this work! [06:15] mvo: awesome! [06:16] PR snapd#3406 closed: tests,packaging: add package build support for openSUSE [06:16] mvo: it's just the beginning [06:20] https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950 [06:21] * zyga cannot login to github [06:21] drat [06:21] this will be a boring day if I cannot log in [06:24] PR snapd#3449 opened: tests/lib: generalize RPM build support [06:24] zyga: what did you do? [06:24] 2fa I cannot access [06:24] well, I have backup but I cannot reach it yet [06:24] (backup is in Poland) [06:25] I'll try again soon [06:26] PR snapd#3450 opened: packaging/{opensuse,fedora}: allow package build with testkeys included [06:27] PR snapd#3451 opened: tests/main: use dir abstraction in a few more test cases [06:27] oh, nice [06:28] morphis: https://github.com/snapcore/snapd/pull/3450/files seems like a copy-paste comment [06:28] PR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included [06:28] PR snapd#3452 opened: tests/main: check for confinement in a few more interface tests [06:28] zyga: :-) [06:28] feel like a few smaller PRs are better [06:29] keeps travis busy but the review small and focused [06:29] +1 [06:30] PR snapd#3453 opened: tests/main/manpages: install missing man package [06:32] PR snapd#3454 opened: spread: add fedora snap bin dir to global PATH [06:32] zyga: complete list: https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950/2?u=morphis [06:33] PR snapd#3455 opened: tests/main: use pkgdb function in more test cases [06:36] PR snapd#3411 closed: tests/main: enable a first set of test cases for Fedora and openSUSE [06:58] * zyga tries to recover hist 2fa [07:09] re [07:09] ok, access regained [07:15] ogra_, hey, wdyt about refactoring mentioned in https://github.com/snapcore/core-build/pull/13 ? Where should a file with common functions reside? scripts/? [07:15] PR core-build#13: Androidboot support [07:30] PR snapd#3442 closed: snap: ensure security polices are re-created === koza|away is now known as koza [07:51] morphis: quick review on https://github.com/snapcore/snapd/pull/3452#pullrequestreview-43087627 [07:51] PR snapd#3452: tests/main: check for confinement in a few more interface tests [07:51] and doing others [07:54] zyga: fixe [07:55] morphis: morning, any chance you can help out an arch user? https://www.reddit.com/r/linuxquestions/comments/6euoj8/snaps_are_not_running/ [07:56] Antergos .. what is that? :-) [07:56] popey: ah based on Arch [07:56] yeah the snapd package on arch is somewhat broken [07:57] something somebody needs to look into, it's on my list which is quite full already [07:57] sorry to hear that [08:00] morphis: I installed arch and could tweak some things but I cannot commit it [08:00] me neither, we need Timothy for that [08:00] tried to reach out to him again but no reply [08:10] abeato, scripts/ sounds fine, then source it respectively [08:10] morphis: is it possible to find someone else if we're blocked on Timothy's time? [08:11] popey: not sure, zyga may know [08:12] my Arch times are long over and never really looked into the snapd situation there yet [08:12] popey: but the basic problem is that he is the maintainer so we need to him or an override from someone else to take the package over [08:13] popey, zyga: maybe we should start reporting bugs against that package [08:13] https://bugs.archlinux.org/index.php?string=snapd [08:17] popey: I think any trusted packager can update it [08:17] morphis: we might just file a bug with "packaging enhancements" [08:17] (and a diff attached) [08:18] zyga: yeah [08:19] PR snapd#3456 opened: many: add interfaces.SystemKey() helper [08:24] zyga: morphis yeah, i think we need some way to move forward on arch. We keep pimping snaps and see people complaining that they don't work on arch, which doesn't look good. [08:25] popey: +1 [08:25] zyga: so can you update hte package and file a bug? [08:27] PR snapd#3457 opened: tests: add refresh --time output check [08:29] PR snapd#3383 closed: tests: fix spread flaky tests linode [08:34] travis hates me again .. [08:36] PR snapd#3458 opened: tests: check that locale-control is not present on core [08:48] exit [08:49] popey: I'll see what I can do about the package [08:49] PR snapd#3459 opened: tests: add whoami check [08:51] hey fgimenez, I just had a look at https://github.com/snapcore/snapd/pull/3459/files [08:51] PR snapd#3459: tests: add whoami check [08:52] fgimenez: could you please change that to more "regular" shell [ ] && [ ] syntax [08:55] hey zyga sure, np, i blindly c&p it from tests/main/login [08:56] fgimenez: thank you, I don't mind bashisms that much but I prefer to use them only when there's no equivalent shell feature and it is justified [08:56] zyga: agreed, i'll update login too [08:56] Thanks! [09:02] thank you zyga, pushed [09:04] oh master why do you hate my PRs [09:04] did you hear the latest joke? [09:04] I pushed a PR and tests passed on the first go [09:08] fgimenez: you can use `-n` instad of `! -z` [09:08] zyga: sure! let me fix it [09:08] fgimenez: or just "$a" != "" [09:08] whatever you like :) [09:10] ok, while waiting for spread I'll look at refreshing the arch package a little [09:13] zyga: thanks [09:13] zyga: just [ "$a" ] is enough, right? [09:13] fgimenez: I don't think it is [09:13] or maybe it is [09:14] but feels more murky [09:14] STRING is equivalent to -n STRING [09:14] zyga: ok, i'll go for the -n then, thx [09:14] my comment was motivated by doing simple and obvious things (hence the suggestion for -n over ! -n or for using != "" explicitly) === ogra_ is now known as ogra [09:21] PR snapd#3460 opened: ifacestate: only re-generate all security profiles if the system-key changes [09:29] mvo: reviewed [09:29] mvo: I only feel strongly about the need to refresh other security backends (we do only two today) [09:29] mvo: and the need to treat "unknown" as special [09:29] Thank you for fighting this! [09:31] mvo, ogra, https://github.com/snapcore/core-build/pull/13 re-pushed [09:31] PR core-build#13: Androidboot support [09:32] ondra, hey ... trying your avahi snap on ym arm boards i get "/snap/avahi/44/meta/hooks/configure: line 48: /bin/nc: Permission denied" ... you probably want to ship nc as stage-packages and adjust the path in the script to use the in-snap one [09:34] popey: do you know where the git source of snapd packaging for arch is? [09:34] I cannot find this anyomre [09:38] abeato: thank you , I have a look [09:38] zyga: thank you too! [09:38] mvo, cool, thanks [09:41] zyga: sure, thanks for pointing that out! already pushed [09:42] fgimenez: thank you! [09:46] zyga: no idea, sorry [09:47] I think I have it in my browser history, I was looking at it yesterday [09:47] * zyga looks [09:49] abeato: the PR looks much better, thanks a bunch for the refactor! once the points from zyga are addressed I think it can go in [09:49] mvo, nice! [09:51] ogra yeah, that part is harmless, I'm having more changes in pipeline for avahi [09:52] ondra, well, it makes it fail to start [09:52] zyga: if you want unknown to be different every time, it might be easiest to make it "unknown (random-XXXXXX)" [09:52] zyga: then nothing in the higher layers needs to care [09:52] ogra that call there was just to lift up device name from model, so it can add it to service description, so once can search for core devices and see actual device model name [09:52] mvo: or just return nil, when it is nil we should regenerate [09:52] mvo: this feels even easier than deserialization [09:52] ogra hmm, let me quickly remove it [09:52] zyga: yeah, that works too [09:53] ondra, it should really not do that [09:53] ogra should not do what? [09:53] ondra, i'm working on a hostnamectrl option for the core snap so that the hostname can be set by that ... so you should actually query the real hostname not something from the model [09:54] ogra BTW I'm preparing avahi-control interface, so once can configure avahi over that [09:55] (and even without the core option i dont have a single board in my house where i didnt use "sudo hostnamectl set-hoostname ..." as the first thing after initial setup to tell the boards apart [09:55] ) [09:55] (and i assume other people do that too) [09:55] ogra problem with host name is that that is same on all fresh images [09:55] ogra model will at least give you what type of device it is [09:56] ondra, yes, but you hardcode it ... if the hostname isnt localhost it should not use the model then [09:56] (in my network with three pi3 boards always online it would already explode badly) [09:56] ogra well this one is on configure hook anyway, so it will track hostname changes [09:56] ok [09:57] ogra no t won't explode [09:57] ogra this is only addition string on service [09:57] well, it will pick random boards for pi3.local [09:57] ogra so you can have 100 devices with same additional string [09:57] ogra no, it will set set pi3 there [09:57] on all three boards [09:58] ogra it only attaches tag to ssh service with device name [09:58] zyga: any idea about https://paste.ubuntu.com/24814501/ ? this isn't about seccomp, there are no denials [09:58] ondra, oh, so it isnt actual avahi ? [09:58] ogra it's not using it for hostname [09:58] is that why i dont see a daemon ? [09:58] zyga: hm wait, I broke something [09:59] ogra it is in avahi, but it's not using that string( device name) for avahi host name [09:59] ah [09:59] morphis: dmesg | grep 1326 [09:59] ogra ssh service already has text tag so you can identify all ubuntu core devices [09:59] ogra well all avahi instances running from snap [10:00] yeah, but that doesnt help if the actual mdns daemon isnt running [10:00] ogra if it's failing that is bug [10:00] ogra that tag is used by snappy-discover [10:01] ah [10:01] zyga: what is 1326? [10:01] ogra which will list you all devices on your network which run avahi as snap [10:01] right ... [10:01] ogra and in that list, idea was not to just have it as snappy device, but at least also see what model it is [10:01] AUDIT_SECCOMP [10:01] so looking at the snap i see an command-avahi-daemon.wrapper ... but systemctl doesnt show it [10:01] ogra so it will show you 5 snappy device, where 3 will have pi3 tag [10:01] seems there is actually a bug then [10:02] ogra@sabrelite:~$ systemctl |grep avahi|grep service [10:02] ogra@sabrelite:~$ [10:02] * zyga breaks for quick breakfast [10:02] ogra just did clean install in amd64 core and avahi runing [10:03] well, not on armhf [10:03] ogra will test arm [10:03] ogra@sabrelite:~$ ps ax|grep avahi [10:03] 3848 pts/0 S+ 0:00 grep --color=auto avahi [10:03] ogra@sabrelite:~$ [10:03] ogra@sabrelite:~$ snap list avahi [10:03] Name Version Rev Developer Notes [10:03] avahi 0.6.32 44 ondra - [10:04] mvo: very unusual error https://travis-ci.org/snapcore/snapd/builds/241117099?utm_source=github_status&utm_medium=notification [10:04] ogra is there any safe way to lift model or gadget name? [10:04] snap confine did not refuse to run [10:05] ondra, only if your hok could call "snap" which we deny i think [10:05] isn't this in some way related to us generating the profile for snap-confine now? [10:05] (from core0 [10:05] may be a race [10:06] zyga, wow, that was really a quick breakfast ... only 2min [10:06] :P [10:06] zyga: indeed, *sigh* [10:07] ogra hmm clean install on cm3 and works [10:07] " Failed to open file '/var/snap/avahi/common/etc/avahi/avahi-daemon.conf': No such file or directory" [10:07] (from sudo journalctl -u snap.avahi.avahi-daemon) [10:07] ogra I get /snap/avahi/44/meta/hooks/configure: line 48: /bin/nc: Permission denied but it continues, installs and runs [10:08] doesnt here [10:08] hi guys: is the snap-id for core 99T7MUlRhtI3U0QFgl5mXXESAiSwt776? [10:08] 99T7MUlRhtI3U0QFgl5mXXESAiSwt776 [10:08] yep [10:09] btw .... "snap info core" shoudl show it [10:09] only on edge [10:09] ah, indeed [10:09] i need a confirm [10:09] yes, only on edge [10:09] I mean only there it is visible currently [10:09] well. snap-id is the same in all channels :) [10:09] so yes, the one above is fine [10:11] ondra, wow ... so uninstall and reinstall of the snap works ... sems there is some kind of race [10:13] ogra damn too late [10:13] ogra wanted to ask you for one log file [10:14] ah, crap, sorry [10:14] ogra hook at first install populates default config in writable path [10:14] ogra which for some reason failed on your device [10:15] ogra that call which you saw failing is on the end, so no matter what by that time default config should have been there, but it was not [10:15] ogra no worries :) [10:15] well, i'm re-installing often, i'll keep an eye out for oother issues like this next time [10:15] ogra but if you see it again, then check /var/snap/avahi/common/configure-hook.log [10:16] i assume you want the configure-hook.log ? [10:16] ogra this should tell us what happened in configure hook [10:16] heh ... *snap* [10:16] ogra yeah when it fails, then grab that log [10:21] * zyga sees a new VCS in 2017 and wonders if this is a good thing [10:21] https://pijul.org/ [10:22] oh, darcs is back [10:22] interesting [10:22] maybe without haskel it will actually perform [10:23] interesting indeed that people still see the need for new vcs [10:26] well [10:26] darcs was amazing [10:26] it just didn't get a decent implementation [10:26] (at the time when I tried it, darcs2 was feeling better but we moved to hg then) [10:26] but the vcs itself is less and less interesting [10:26] where is the tooling for it? [10:26] still, interesting [10:26] is there a snap? :D [10:27] there should be one [10:27] :) [10:29] mvo: can you please have a look at https://github.com/snapcore/snapd/pull/3444 [10:29] PR snapd#3444: interfaces: compose the base declaration from interfaces [10:31] abeato, that boot=bootloader-script ... why do you need that ? if you have detected there is an androidboot with abootimg -i $RECOVERY and you see that snap_mode is set to try, why do you need to additionally modify the commandline ... the idea was to actually not have to invent new vars like this but be able to work with what we already have [10:31] mvo: I feel this has 1.9 already (since jdstrand didn't give me a full approval) [10:32] mvo: I replied to his concern (there's one more branch behind this) and if I could land it I can propose the final piece of the puzzle [10:32] (and then fix existing interface PRs!) [10:32] ogra, there is a difficulty here, which is that the initramfs does not know if it has been loaded from recovery or from boot partition [10:32] ogra, the only easy way I found to know that was via kernel command line [10:32] i'm sure we can somehow find that out [10:33] sure, but how? :) [10:33] doesnt the kernel hand through the boot reasoon when it is called with reboot recovery ? [10:33] nope [10:33] no extra args added [10:35] well, but snap_mode knows we were rebooted into recovery [10:35] because it is set to try [10:35] so just match on that [10:36] ogra, except when it is "trying", but failed... [10:36] a) check if we are androidboot ... b) check if snap_mode is non-empty ... then you can be sure you should invoke the script to actually deal with snap_mode [10:36] snap_mode is for detecting the install status of core/kernel, using it for other stuff is a slippery slope [10:38] well, i dont really like to modify the cmdline twice [10:39] especially the currently working one [10:39] ogra, that will not work, if non-emtpy it can be that we are recovery or boot, that is unknown [10:40] ogra, no, boot=bootloader-recovery is only in the boot partition cmdline (which is not the one that contains the booting kernel as we are always doing boot->recovery->uc16) [10:40] worst case we could touch a file in the initrd when creating it as recovery ... that still better than changing the safe cmdline [10:40] ah, so you hardcode it there ? [10:41] technically that variable is set in initramfs.coonf [10:41] yes, for the boot partition only, which is not updated anytime (remeber, it is the bootloader to all effects) [10:41] (the BOOT variable i mean) [10:41] whcih you can actually set dynamicall yat build time of the initrd [10:41] yes, hardcoded in the boot partition [10:42] so when creating the recovery initrd we can simply set the var there ... and it will default to BOOT=boot-script [10:43] that way you dont need it at all on any cmdline [10:44] abeato, https://github.com/snapcore/core-build/blob/master/initramfs/conf/ubuntu-core-rootfs [10:44] we just need to replace that file dynamically when creating the recovery-initrd.img [10:45] so recovery always has BOOT=boot-script and noon-recovery does BOOT=ubuntu-core-rootfs [10:45] ogra, ok, it can be done that way or via kernel command line, in fact it is not very important. The only important thing is that the boot image will have this difference wiht the recovery image [10:45] that saves the extra var and the additiopnal cmdline fiddling [10:45] *has [10:45] (wheer did you plan to do that btw) [10:46] (the setting oof the cmdline i mean) [10:46] we have build scripts for the images, they create boot.img and recovery.img, being the only difference that boot.img has cmdline with boot=bootloader-script [10:48] well, i'D still like us to stay consistent here ... we dont set boot= anywhere in ubuntu except via the initramfs.conf file [10:48] (remeber we switched boot with recovery, the kernel is updated in the recovey partition) [10:48] right [10:49] ogra, it is perfectly fine to modify the conf file instead of the kernel cmdline for boot.img in our build scripts [10:49] the point that bothers me is that we set soimething on the cmdline :) [10:49] if you think that is better [10:49] so no issue here :) [10:49] i think it is consistent with the rest of the distro [10:49] it does not affect the PR anyway [10:49] right [10:49] sure, I will change that [10:50] regarding the PR you will have too fight with zyga over his request for unittests ... i'm fine with it as is (once it has seen sopme real world tesing) [10:50] I'll contribute some in a moment [10:51] re: real testing, it has had quite a bit, I simulated update failures in different ways, for instance [10:51] adding unit tests there will be some giant work i fear ... to do that right you surely want to run them in the environment they will later run [10:51] so you want an initrd, unpack it ... and run the unittests chroooted inside that at the very least [10:51] ogra: we will see, I don't know yet [10:52] else you dont really test if i.e. the binaries your scripts use are there etc [10:52] and you need to fake all the device bits ... findfs checking for labels etc [10:53] i'm not sure that buys us much TBH ... over actual testing of a boot and shellcheck to make sure there are no typos [10:56] hi, snapcraft question: how can i tell snapcraft to put folders/files in the $SNAP_USER_DATA ? [10:57] ogra: I think its definitely wort checking adding unit tests fwiw, I think its not something that abeato needs to do as its beyond the scope of the PR but something we should look into in the core team. I'm very happy that zyga looks at it [10:57] daker, with a wrapper script [10:57] worth even [10:57] ogra: any example ? [10:57] mvo, oh, yeah, not saying they arent worth it but he asked for them in context of the PR :) [10:58] daker: not automatically, but you can with the configure script [10:58] mvo, and i meant what i said above, they will be useless ifwe dont run them in the right env ... which means an unpacked initrd and chrooted into that with the change applied on top ... thats a rather complex thing to set up [10:58] daker: though it will run _after_ services started [10:59] daker: ah, for SNAP_USER_DATA (not the USER) you need a wrapper [10:59] * abeato happy to leave that for other PRs ;) [10:59] zyga: example :) [11:01] daker, https://github.com/ogra1/laidout (doesnt copy anything ... a cp $SNAP/default-config $SNAP_USER_DATA/config would be needed) [11:01] ogra: thanks! i'll try it [11:02] daker, ah, here i copy some java config in place in line 31 https://github.com/ogra1/jtiledownloader/blob/master/wrapper [11:02] daker: wrap the real command you want to run in a helper program (script) that does the initial setpu [11:03] zyga: ogra ok [11:09] PR snapd#3461 opened: debian: add missing "make -C data/systemd clean" === ogra_ is now known as ogra === ogra is now known as ogra_ [11:35] PR snapd#3462 opened: systemd: refactor service ops to also be exposed more directly [11:36] ouh [11:36] * Chipaca smacks forehead [11:39] PR snapd#3463 opened: Snap services 2 [11:39] * Chipaca smacks github's forehead [11:40] is it forehead-friday ? [11:42] ogra_: yes [11:43] very yes, in fact [11:43] * ogra_ slaps his forehead too in solidarity with the UK [11:46] ogra_: uff... if it were for the uk shenanigans my forehead would have a berm around the edge from all the slapping [11:46] heh [12:03] PR snapcraft#1361 opened: pluginhandler: don't clobber path on local import failure