[00:08] <cachio_> Chipaca, all the tests passed
[00:09] <Chipaca> cachio_: merge away!
[00:13] <cachio_> Chipaca, I cant
[00:13] <Chipaca> cachio_: oh!
[00:13] <cachio_> Chipaca, tx :)
[00:14] <mup> PR snapd#3448 closed: tests: fix for the test postrm-purge <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3448>
[01:12] <mup> PR snapd#3446 closed: errtracker: Include /etc/apparmor.d/usr.lib.snap-confine md5sum in err reports <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3446>
[01:42] <mup> PR snapd#3420 closed: many: slight improvement of some snap error messaging <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3420>
[06:08] <zyga> good morning
[06:09]  * zyga had a terrible dream 
[06:10] <morphis> morning!
[06:10] <morphis> zyga, mvo: one of you can merge https://github.com/snapcore/snapd/pull/3406 now?
[06:10] <mup> PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
[06:11] <zyga> morphis: yes, just fiddling with expired github login
[06:11] <morphis> :-)
[06:11] <zyga> morphis: good morning, how are you?
[06:11] <morphis> zyga: fine, you?
[06:12] <zyga> so so, weather has deteriorated today it seems
[06:13] <morphis> gets stormy again :-)
[06:15] <mvo> morphis: done
[06:15] <mvo> morphis: thank you for this work!
[06:15] <morphis> mvo: awesome!
[06:16] <mup> PR snapd#3406 closed: tests,packaging: add package build support for openSUSE <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3406>
[06:16] <morphis> mvo: it's just the beginning
[06:20] <morphis> https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950
[06:21]  * zyga cannot login to github
[06:21] <zyga> drat
[06:21] <zyga> this will be a boring day if I cannot log in
[06:24] <mup> PR snapd#3449 opened: tests/lib: generalize RPM build support <Created by morphis> <https://github.com/snapcore/snapd/pull/3449>
[06:24] <morphis> zyga: what did you do?
[06:24] <zyga> 2fa I cannot access
[06:24] <zyga> well, I have backup but I cannot reach it yet
[06:24] <zyga> (backup is in Poland)
[06:25] <zyga> I'll try again soon
[06:26] <mup> PR snapd#3450 opened: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>
[06:27] <mup> PR snapd#3451 opened: tests/main: use dir abstraction in a few more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3451>
[06:27] <zyga> oh, nice
[06:28] <zyga> morphis: https://github.com/snapcore/snapd/pull/3450/files seems like a copy-paste comment
[06:28] <mup> PR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>
[06:28] <mup> PR snapd#3452 opened: tests/main: check for confinement in a few more interface tests <Created by morphis> <https://github.com/snapcore/snapd/pull/3452>
[06:28] <morphis> zyga: :-)
[06:28] <morphis> feel like a few smaller PRs are better
[06:29] <morphis> keeps travis busy but the review small and focused
[06:29] <zyga> +1
[06:30] <mup> PR snapd#3453 opened: tests/main/manpages: install missing man package <Created by morphis> <https://github.com/snapcore/snapd/pull/3453>
[06:32] <mup> PR snapd#3454 opened: spread: add fedora snap bin dir to global PATH <Created by morphis> <https://github.com/snapcore/snapd/pull/3454>
[06:32] <morphis> zyga: complete list: https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950/2?u=morphis
[06:33] <mup> PR snapd#3455 opened: tests/main: use pkgdb function in more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3455>
[06:36] <mup> PR snapd#3411 closed: tests/main: enable a first set of test cases for Fedora and openSUSE <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3411>
[06:58]  * zyga tries to recover hist 2fa 
[07:09] <zyga> re
[07:09] <zyga> ok, access regained
[07:15] <abeato> 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] <mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[07:30] <mup> PR snapd#3442 closed: snap: ensure security polices are re-created <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3442>
[07:51] <zyga> morphis: quick review on https://github.com/snapcore/snapd/pull/3452#pullrequestreview-43087627
[07:51] <mup> PR snapd#3452: tests/main: check for confinement in a few more interface tests <Created by morphis> <https://github.com/snapcore/snapd/pull/3452>
[07:51] <zyga> and doing others
[07:54] <morphis> zyga: fixe
[07:55] <popey> 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] <morphis> Antergos .. what is that? :-)
[07:56] <morphis> popey: ah based on Arch
[07:56] <morphis> yeah the snapd package on arch is somewhat broken
[07:57] <morphis> something somebody needs to look into, it's on my list which is quite full already
[07:57] <popey> sorry to hear that
[08:00] <zyga> morphis: I installed arch and could tweak some things but I cannot commit it
[08:00] <morphis> me neither, we need Timothy for that
[08:00] <morphis> tried to reach out to him again but no reply
[08:10] <ogra_> abeato, scripts/ sounds fine, then source it respectively
[08:10] <popey> morphis: is it possible to find someone else if we're blocked on Timothy's time?
[08:11] <morphis> popey: not sure, zyga may know
[08:12] <morphis> my Arch times are long over and never really looked into the snapd situation there yet
[08:12] <morphis> 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] <morphis> popey, zyga: maybe we should start reporting bugs against that package
[08:13] <morphis> https://bugs.archlinux.org/index.php?string=snapd
[08:17] <zyga> popey: I think any trusted packager can update it
[08:17] <zyga> morphis: we might just file a bug with "packaging enhancements"
[08:17] <zyga> (and a diff attached)
[08:18] <morphis> zyga: yeah
[08:19] <mup> PR snapd#3456 opened: many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3456>
[08:24] <popey> 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] <morphis> popey: +1
[08:25] <morphis> zyga: so can you update hte package and file a bug?
[08:27] <mup> PR snapd#3457 opened: tests: add refresh --time output check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3457>
[08:29] <mup> PR snapd#3383 closed: tests: fix spread flaky tests linode <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3383>
[08:34] <morphis> travis hates me again ..
[08:36] <mup> PR snapd#3458 opened: tests: check that locale-control is not present on core <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3458>
[08:48] <zyga_> exit
[08:49] <zyga> popey: I'll see what I can do about the package
[08:49] <mup> PR snapd#3459 opened: tests: add whoami check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3459>
[08:51] <zyga> hey fgimenez, I just had a look at https://github.com/snapcore/snapd/pull/3459/files
[08:51] <mup> PR snapd#3459: tests: add whoami check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3459>
[08:52] <zyga> fgimenez: could you please change that to more "regular" shell [ ] && [ ] syntax
[08:55] <fgimenez> hey zyga sure, np, i blindly c&p it from tests/main/login
[08:56] <zyga> 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] <fgimenez> zyga: agreed, i'll update login too
[08:56] <zyga> Thanks!
[09:02] <fgimenez> thank you zyga, pushed
[09:04] <zyga> oh master why do you hate my PRs
[09:04] <zyga> did you hear the latest joke?
[09:04] <zyga> I pushed a PR and tests passed on the first go
[09:08] <zyga> fgimenez: you can use `-n` instad of `! -z`
[09:08] <fgimenez> zyga: sure! let me fix it
[09:08] <zyga> fgimenez: or just "$a" != ""
[09:08] <zyga> whatever you like :)
[09:10] <zyga> ok, while waiting for spread I'll look at refreshing the arch package a little
[09:13] <popey> zyga: thanks
[09:13] <fgimenez> zyga: just [ "$a" ] is enough, right?
[09:13] <zyga> fgimenez: I don't think it is
[09:13] <zyga> or maybe it is
[09:14] <zyga> but feels more murky
[09:14] <zyga> STRING is equivalent to -n STRING
[09:14] <fgimenez> zyga: ok, i'll go for the -n then, thx
[09:14] <zyga> my comment was motivated by doing simple and obvious things (hence the suggestion for -n over ! -n or for using != "" explicitly)
[09:21] <mup> PR snapd#3460 opened: ifacestate: only re-generate all security profiles if the system-key changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/3460>
[09:29] <zyga> mvo: reviewed
[09:29] <zyga> mvo: I only feel strongly about the need to refresh other security backends (we do only two today)
[09:29] <zyga> mvo: and the need to treat "unknown" as special
[09:29] <zyga> Thank you for fighting this!
[09:31] <abeato> mvo, ogra, https://github.com/snapcore/core-build/pull/13 re-pushed
[09:31] <mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[09:32] <ogra> 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] <zyga> popey: do you know where the git source of snapd packaging for arch is?
[09:34] <zyga> I cannot find this anyomre
[09:38] <mvo> abeato: thank you , I have a look
[09:38] <mvo> zyga: thank you too!
[09:38] <abeato> mvo, cool, thanks
[09:41] <fgimenez> zyga: sure, thanks for pointing that out! already pushed
[09:42] <zyga> fgimenez: thank you!
[09:46] <popey> zyga: no idea, sorry
[09:47] <zyga> I think I have it in my browser history, I was looking at it yesterday
[09:47]  * zyga looks
[09:49] <mvo> 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] <abeato> mvo, nice!
[09:51] <ondra> ogra yeah, that part is harmless, I'm having more changes in pipeline for avahi
[09:52] <ogra> ondra, well, it makes it fail to start
[09:52] <mvo> zyga: if you want unknown to be different every time, it might be easiest to make it "unknown (random-XXXXXX)"
[09:52] <mvo> zyga: then nothing in the higher layers needs to care
[09:52] <ondra> 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] <zyga> mvo: or just return nil, when it is nil we should regenerate
[09:52] <zyga> mvo: this feels even easier than deserialization
[09:52] <ondra> ogra hmm, let me quickly remove it
[09:52] <mvo> zyga: yeah, that works too
[09:53] <ogra> ondra, it should really not do that
[09:53] <ondra> ogra should not do what?
[09:53] <ogra> 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] <ondra> ogra BTW I'm preparing avahi-control interface, so once can configure avahi over that
[09:55] <ogra> (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] <ogra> )
[09:55] <ogra> (and i assume other people do that too)
[09:55] <ondra> ogra problem with host name is that that is same on all fresh images
[09:55] <ondra> ogra model will at least give you what type of device it is
[09:56] <ogra> ondra, yes, but you hardcode it ... if the hostname isnt localhost it should not use the model then
[09:56] <ogra> (in my network with three pi3 boards always online it would already explode badly)
[09:56] <ondra> ogra well this one is on configure hook anyway, so it will track hostname changes
[09:56] <ogra> ok
[09:57] <ondra> ogra no t won't explode
[09:57] <ondra> ogra this is only addition string on service
[09:57] <ogra> well, it will pick random boards for pi3.local
[09:57] <ondra> ogra so you can have 100 devices with same additional string
[09:57] <ondra> ogra no, it will set set pi3 there
[09:57] <ogra> on all three boards
[09:58] <ondra> ogra it only attaches tag to ssh service with device name
[09:58] <morphis> zyga: any idea about https://paste.ubuntu.com/24814501/ ? this isn't about seccomp, there are no denials
[09:58] <ogra> ondra, oh, so it isnt actual avahi ?
[09:58] <ondra> ogra it's not using it for hostname
[09:58] <ogra> is that why i dont see a daemon ?
[09:58] <morphis> zyga: hm wait, I broke something
[09:59] <ondra> ogra it is in avahi, but it's not using that string( device name) for avahi host name
[09:59] <ogra> ah
[09:59] <zyga> morphis: dmesg | grep 1326
[09:59] <ondra> ogra ssh service already has text tag so you can identify all ubuntu core devices
[09:59] <ondra> ogra well all avahi instances running from snap
[10:00] <ogra> yeah, but that doesnt  help if the actual mdns daemon isnt running
[10:00] <ondra> ogra if it's failing that is bug
[10:00] <ondra> ogra that tag is used by snappy-discover
[10:01] <ogra> ah
[10:01] <morphis> zyga: what is 1326?
[10:01] <ondra> ogra which will list you all devices on your network which run avahi as snap
[10:01] <ogra> right ...
[10:01] <ondra> 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] <zyga> AUDIT_SECCOMP
[10:01] <ogra> so looking at the snap i see an command-avahi-daemon.wrapper ... but systemctl doesnt show it
[10:01] <ondra> ogra so it will show you 5 snappy device, where 3 will have pi3 tag
[10:01] <ogra> seems there is actually a bug then
[10:02] <ogra> ogra@sabrelite:~$ systemctl |grep avahi|grep service
[10:02] <ogra> ogra@sabrelite:~$
[10:02]  * zyga breaks for quick breakfast
[10:02] <ondra> ogra just did clean install in amd64 core and avahi runing
[10:03] <ogra> well, not on armhf
[10:03] <ondra> ogra will test arm
[10:03] <ogra> ogra@sabrelite:~$ ps ax|grep avahi
[10:03] <ogra>  3848 pts/0    S+     0:00 grep --color=auto avahi
[10:03] <ogra> ogra@sabrelite:~$
[10:03] <ogra> ogra@sabrelite:~$ snap list avahi
[10:03] <ogra> Name   Version  Rev  Developer  Notes
[10:03] <ogra> avahi  0.6.32   44   ondra      -
[10:04] <zyga> mvo: very unusual error https://travis-ci.org/snapcore/snapd/builds/241117099?utm_source=github_status&utm_medium=notification
[10:04] <ondra> ogra is there any safe way to lift model or gadget name?
[10:04] <zyga> snap confine did not refuse to run
[10:05] <ogra> ondra, only if your hok could call "snap" which we deny i think
[10:05] <zyga> isn't this in some way related to us generating the profile for snap-confine now?
[10:05] <zyga> (from core0
[10:05] <zyga> may be a race
[10:06] <ogra> zyga, wow, that was really a quick breakfast ... only 2min
[10:06] <ogra> :P
[10:06] <mvo> zyga: indeed, *sigh*
[10:07] <ondra> ogra hmm clean install on cm3 and works
[10:07] <ogra> " Failed to open file '/var/snap/avahi/common/etc/avahi/avahi-daemon.conf': No such file or directory"
[10:07] <ogra> (from sudo journalctl -u snap.avahi.avahi-daemon)
[10:07] <ondra> ogra I get /snap/avahi/44/meta/hooks/configure: line 48: /bin/nc: Permission denied but it continues, installs and runs
[10:08] <ogra> doesnt here
[10:08] <NicolinoCuralli> hi guys: is the snap-id for core 99T7MUlRhtI3U0QFgl5mXXESAiSwt776?
[10:08] <ogra> 99T7MUlRhtI3U0QFgl5mXXESAiSwt776
[10:08] <ogra> yep
[10:09] <ogra> btw .... "snap info core" shoudl show it
[10:09] <NicolinoCuralli> only on edge
[10:09] <ogra> ah, indeed
[10:09] <NicolinoCuralli> i need a confirm
[10:09] <mvo> yes, only on edge
[10:09] <mvo> I mean only there it is visible currently
[10:09] <ogra> well. snap-id is the same in all channels :)
[10:09] <ogra> so yes, the one above is fine
[10:11] <ogra> ondra, wow ... so uninstall and reinstall of the snap works ... sems there is some kind of race
[10:13] <ondra> ogra damn too late
[10:13] <ondra> ogra wanted to ask you for one log file
[10:14] <ogra> ah, crap, sorry
[10:14] <ondra> ogra hook at first install populates default config in writable path
[10:14] <ondra> ogra which for some reason failed on your device
[10:15] <ondra> 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] <ondra> ogra no worries :)
[10:15] <ogra> well, i'm re-installing often, i'll keep an eye out for oother issues like this next time
[10:15] <ondra> ogra but if you see it again, then check /var/snap/avahi/common/configure-hook.log
[10:16] <ogra> i assume you want the configure-hook.log ?
[10:16] <ondra> ogra this should tell us what happened in configure hook
[10:16] <ogra> heh ... *snap*
[10:16] <ondra> 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] <zyga> https://pijul.org/
[10:22] <zyga> oh, darcs is back
[10:22] <zyga> interesting
[10:22] <zyga> maybe without haskel it will actually perform
[10:23] <pstolowski> interesting indeed that people still see the need for new vcs
[10:26] <zyga> well
[10:26] <zyga> darcs was amazing
[10:26] <zyga> it just didn't get a decent implementation
[10:26] <zyga> (at the time when I tried it, darcs2 was feeling better but we moved to hg then)
[10:26] <zyga> but the vcs itself is less and less interesting
[10:26] <zyga> where is the tooling for it?
[10:26] <zyga> still, interesting
[10:26] <zyga> is there a snap? :D
[10:27] <zyga> there should be one
[10:27] <pstolowski> :)
[10:29] <zyga> mvo: can you please have a look at https://github.com/snapcore/snapd/pull/3444
[10:29] <mup> PR snapd#3444: interfaces: compose the base declaration from interfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3444>
[10:31] <ogra> 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] <zyga> mvo: I feel this has 1.9 already (since jdstrand didn't give me a full approval)
[10:32] <zyga> 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] <zyga> (and then fix existing interface PRs!)
[10:32] <abeato> 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] <abeato> ogra, the only easy way I found to know that was via kernel command line
[10:32] <ogra> i'm sure we can somehow find that out
[10:33] <abeato> sure, but how? :)
[10:33] <ogra> doesnt the kernel hand through the boot reasoon when it is called with reboot recovery ?
[10:33] <abeato> nope
[10:33] <abeato> no extra args added
[10:35] <ogra> well, but snap_mode knows we were rebooted into recovery
[10:35] <ogra> because it is set to try
[10:35] <ogra> so just match on that
[10:36] <abeato> ogra, except when it is "trying", but failed...
[10:36] <ogra> 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] <abeato> snap_mode is for detecting the install status of core/kernel, using it for other stuff is a slippery slope
[10:38] <ogra> well, i dont really like to modify the cmdline twice
[10:39] <ogra> especially the currently working one
[10:39] <abeato> ogra, that will not work, if non-emtpy it can be that we are recovery or boot, that is unknown
[10:40] <abeato> 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] <ogra> 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] <ogra> ah, so you hardcode it there ?
[10:41] <ogra> technically that variable is set in initramfs.coonf
[10:41] <abeato> yes, for the boot partition only, which is not updated anytime (remeber, it is the bootloader to all effects)
[10:41] <ogra> (the BOOT variable i mean)
[10:41] <ogra> whcih you can actually set dynamicall yat build time of the initrd
[10:41] <abeato> yes, hardcoded in the boot partition
[10:42] <ogra> so when creating the recovery initrd we can simply set the var there ... and it will default to BOOT=boot-script
[10:43] <ogra> that way you dont need it at all on any cmdline
[10:44] <ogra> abeato, https://github.com/snapcore/core-build/blob/master/initramfs/conf/ubuntu-core-rootfs
[10:44] <ogra> we just need to replace that file dynamically when creating the recovery-initrd.img
[10:45] <ogra> so recovery always has BOOT=boot-script and noon-recovery does BOOT=ubuntu-core-rootfs
[10:45] <abeato> 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] <ogra> that saves the extra var and the additiopnal cmdline fiddling
[10:45] <abeato> *has
[10:45] <ogra> (wheer did you plan to do that btw)
[10:46] <ogra> (the setting oof the cmdline i mean)
[10:46] <abeato> 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] <ogra> 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] <abeato> (remeber we switched boot with recovery, the kernel is updated in the recovey partition)
[10:48] <ogra> right
[10:49] <abeato> ogra, it is perfectly fine to modify the conf file instead of the kernel cmdline for boot.img in our build scripts
[10:49] <ogra> the point that bothers me is that we set soimething on the cmdline :)
[10:49] <abeato> if you think that is better
[10:49] <abeato> so no issue here :)
[10:49] <ogra> i think it is consistent with the rest of the distro
[10:49] <abeato> it does not affect the PR anyway
[10:49] <ogra> right
[10:49] <abeato> sure, I will change that
[10:50] <ogra> 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] <zyga> I'll contribute some in a moment
[10:51] <abeato> re: real testing, it has had quite a bit, I simulated update failures in different ways, for instance
[10:51] <ogra> 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] <ogra> so you want an initrd, unpack it ... and run the unittests chroooted inside that at the very least
[10:51] <zyga> ogra: we will see, I don't know yet
[10:52] <ogra> else you dont really test if i.e. the binaries your scripts use are there etc
[10:52] <ogra> and you need to fake all the device bits ... findfs checking for labels etc
[10:53] <ogra> 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] <daker> hi, snapcraft question: how can i tell snapcraft to put folders/files in the $SNAP_USER_DATA ?
[10:57] <mvo> 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] <ogra> daker, with a wrapper script
[10:57] <mvo> worth even
[10:57] <daker> ogra: any example ?
[10:57] <ogra> mvo, oh, yeah, not saying they arent worth it but he asked for them in context of the PR :)
[10:58] <zyga> daker: not automatically, but you can with the configure script
[10:58] <ogra> 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] <zyga> daker: though it will run _after_ services started
[10:59] <zyga> 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] <daker> zyga: example :)
[11:01] <ogra> daker, https://github.com/ogra1/laidout (doesnt copy anything ... a cp $SNAP/default-config $SNAP_USER_DATA/config would be needed)
[11:01] <daker> ogra: thanks! i'll try it
[11:02] <ogra> daker, ah, here i copy some java config in place in line 31 https://github.com/ogra1/jtiledownloader/blob/master/wrapper
[11:02] <zyga> daker: wrap the real command you want to run in a helper program (script) that does the initial setpu
[11:03] <daker> zyga: ogra ok
[11:09] <mup> PR snapd#3461 opened: debian: add missing "make -C data/systemd clean" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3461>
[11:35] <mup> PR snapd#3462 opened: systemd: refactor service ops to also be exposed more directly <Created by chipaca> <https://github.com/snapcore/snapd/pull/3462>
[11:36] <Chipaca> ouh
[11:36]  * Chipaca smacks forehead
[11:39] <mup> PR snapd#3463 opened: Snap services 2 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3463>
[11:39]  * Chipaca smacks github's forehead
[11:40] <ogra_> is it forehead-friday ?
[11:42] <Chipaca> ogra_: yes
[11:43] <Chipaca> very yes, in fact
[11:43]  * ogra_ slaps his forehead too in solidarity with the UK
[11:46] <Chipaca> ogra_: uff... if it were for the uk shenanigans my forehead would have a berm around the edge from all the slapping
[11:46] <ogra_> heh
[12:03] <mup> PR snapcraft#1361 opened: pluginhandler: don't clobber path on local import failure <Created by zyga> <https://github.com/snapcore/snapcraft/pull/1361>
[12:11] <ogra_> koza, hey ... http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ or http://people.canonical.com/~ogra/snappy/all-snaps/daily-stable/current/ have the hummingboard images ... we're still missing interfaces in the gadget ... https://github.com/ogra1/hummingboard-gadget/ has the gadget source
[12:12] <ogra_> koza, i started working with fabo on getting proper build scripts in place in the linaro lite setup (which requires to build in docker, i'm waiting for him to get us a proper setup)
[12:39] <morphis> fgimenez: do you have time to do a review on my PRs listed in https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950/2 ?
[12:42] <fgimenez> morphis: sure, i'm finishing the sru verification, once that's done i'll take a look
[12:42] <morphis> fgimenez: thanks!
[12:45] <koza> ogra_, hey and thanks for mail; got disconnected and my ssh/irssi to linode setup reacts with a delay to such events
[12:45] <ogra_> koza, no worries ... i just wanted to make sure you definitely get the answer ...
[12:46] <koza> ogra_, appreciated
[12:46] <ogra_> koza, note the last line in the model assertion paste is wrong (in case you want to use it to build an image yourself) i only just noticed that my server spilled a message there ...
[12:47] <koza> ogra_, oh right email notification :-)
[12:47] <ogra_> yeah :)
[12:49] <fgimenez> morphis: btw, the suite is failing on opensuse and fedora when running against the staging store, could you please take a look? https://travis-ci.org/snapcore/spread-cron/builds/240983847
[12:49] <morphis> fgimenez: interesting
[12:50] <fgimenez> morphis: ok opensuse this seems to be the problem http://paste.ubuntu.com/24815216/
[12:50] <fgimenez> on opensuse
[12:51] <morphis> hm, I see
[12:51] <morphis> maybe go is too old?
[12:53] <fgimenez> morphis: no idea, also not sure if the quoting is right in that case
[12:55] <morphis> hm
[13:03] <niemeyer> Chipaca: Standup?
[13:05] <Chipaca> niemeyer: yes!
[13:23] <om26er> Hi! who is the contact to talk about https://build.snapcraft.io/ ?
[13:28] <mup> PR snapd#3444 closed: interfaces: compose the base declaration from interfaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3444>
[13:32] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/3464 :-)
[13:32] <mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
[13:32] <zyga> om26er: many people, can you be more specific?
[13:32] <mup> PR snapd#3464 opened: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
[13:34] <abeato> ogra_, hey, I've created a script for better dates, see https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981
[13:34] <mup> Bug #1696981: fixrtc is ineffective when there is no battery for the RTC <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1696981>
[13:34] <jdstrand> zyga: ack, added to list
[13:35] <zyga> jdstrand: thank you!
[13:35] <ogra_> abeato, ummm ... the description is weird
[13:35] <zyga> jdstrand: it's pretty tedious but should be easy to review patch by patc
[13:35] <zyga> jdstrand: as those are structured sanely, I hope
[13:35] <jdstrand> I haven't looked at it, but know what to expect
[13:35] <jdstrand> :)
[13:35] <ogra_> abeato, fixrtc is exactly only for the one usecase where no RTC battery is around ...
[13:36] <ogra_> abeato, that makes your changelog entry a bit weird
[13:36] <abeato> ogra_, yeah, but as discussed it does not work that well. see my comments in https://github.com/snapcore/core-build/pull/13
[13:36] <mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[13:36] <om26er> zyga, we need to publish our software and it build.snapcraft currently builds for 2 arches, amd64 and armhf, we need support for arm64
[13:37] <om26er> so wanted to know if that will come in future
[13:37] <zyga> om26er: it's available already AFAIK
[13:37] <zyga> om26er: you can build a snap for aarch64 aka arm64
[13:37] <ogra_> abeato, yes, i remember them ... my point is that the missing RTC isnt what makes the local-top fixrtc not work but broken mount data of the disk ...
[13:37] <zyga> om26er: (via build.snapcraft.io)
[13:37] <abeato> ogra_, I can change the description, tbh it is not clear to mee if the current fixrtc script really fixes the issue if there is no rtc battery
[13:38] <abeato> ogra_, it does not for this device at least
[13:38] <ogra_> abeato, and i would still like to find out why the original fixrtc doesnt DTRT
[13:38] <ogra_> instead of just adding anothr script
[13:38] <om26er> zyga, hmm, by default it built for amd64 and armhf, do we need to change something ?
[13:39] <ogra_> abeato, can you capture the data from dumpefs from the initrd when in local-top at least ?
[13:39] <zyga> om26er: I think that's something you can tweak on the website
[13:39] <ogra_> abeato, and attach that to the bug
[13:39] <zyga> om26er: not sure, but I know the builders for aarch64 are around
[13:39] <om26er> zyga, ok, will look into that.
[13:39] <abeato> ogra_, the explantion on why it does not work is that the mount time is always wrong, as "/" is being mounted always in a moment near to the epoch
[13:39] <abeato> ogra_, but let me paste that
[13:40] <ogra_> abeato, yes, and the current fixrtc script should take that into account
[13:40] <ogra_> abeato, we originally developed it for android partitioning for never booted devices so it should work in any case ... if it doesnt, we should try to fix what we have, not add something new (that only as last resort)
[13:41] <abeato> ogra_, we could access files by moving fixrtc to local-bottom
[13:41] <ogra_> abeato, well, but that is to late
[13:42] <ogra_> we need the clock set before we try to mount
[13:42] <abeato> ogra_, then we need this other script
[13:42] <ogra_> and there is no reason why you shouldnt get that info
[13:42] <ogra_> dumppe2fs should always return *something* and we should be able to react to that
[13:43] <ogra_> abeato, i think we just dont handle this special case corretly in the current script ... but to adjust we need the data
[13:43] <abeato> ogra_, http://paste.ubuntu.com/24815516/
[13:44] <ogra_> Last mount time:          Thu Jan  1 03:42:04 1970
[13:44] <abeato> yep
[13:44] <ogra_> that should be enough to do something about it
[13:44] <ogra_> we know we're at the epoch
[13:45] <abeato> sure, and we want something better, isn't it? ;)
[13:45] <abeato> test@localhost:~$ date
[13:45] <abeato> Fri Jun  9 13:44:22 UTC 2017
[13:45] <abeato> that is the current time in the machine, it is not like it is in the epoch ^^
[13:46] <ogra_> abeato, http://paste.ubuntu.com/24815530/ line 99 and following
[13:47] <ogra_> we just need to make the if a bit broader
[13:47] <ogra_> and if you feel like push the hardcoded timestamp a bit forward ...
[13:48] <abeato> ogra_, 1999 is still not good enough, I want the snap assertions to be valid
[13:48] <ogra_> well, push it to 2017 then
[13:49] <ogra_> effectively it gains you nothing anyway ... you need to be online to initialize the device ... if you are online you will get a proper date anyway
[13:50] <abeato> ogra_, that is true, but I am thinking about the factory case here, no network, and somebody adding system-user assertions with a USB stick
[13:50] <ogra_> and if you are not and your image is a month old the hardcoded date will still be wrong
[13:50] <abeato> getting a date from the filesystem helps there
[13:50] <abeato> and it is not wrong
[13:50] <ogra_> not much
[13:50]  * zyga lunch
[13:50] <ogra_> it will be stuck at the image creation date
[13:51] <abeato> yeah, but that is in fact enough to make sure the assertions are valid, ad they are part of the image
[13:51] <ogra_> so depending how old your image is it will still not have a proper date for a freshly created assertion
[13:51] <ogra_> (the one on the usb stick)
[13:52] <abeato> well, yes, but is an improvement (time to think now in time assertions to update time in non-connected devices ;)
[13:53] <ogra_> abeato, well, your script also only uses "2017-06-09" ...
[13:53] <ogra_> which is the date it will always fall back to
[13:53] <ogra_> so i dont see why we cant use that in the actual fixrtc script
[13:53] <abeato> ogra_, that is an initial hint, then in searches for better dates in the file system
[13:54] <ogra_> i also dont like to tie it to snap packages
[13:55] <ogra_> i.e. *if* you check a file (which is shuddering ugly, but if there is no other way ...) then check creation time of / on the fs or of /etc or something else generic
[13:55] <abeato> well, it is not perfect, but nothing but a network connection would do things right. It is just an improvment on the current situation
[13:55] <abeato> ogra_, I check "/"
[13:56] <abeato> +        if [ -d "$rootfolder" ]; then
[13:56] <ogra_> you check /root :)
[13:56] <abeato> that is moved to "/" later in the initramfs
[13:56] <ogra_> oh, ignore me :P
[13:57] <ogra_> indeed
[13:57] <abeato> :)
[13:57] <ogra_> well, could we just limit limit that bottom script to this ?
[13:57] <abeato> ogra_, ok, I can remove the snapsfolder part
[13:57] <ogra_> and fix the -premount script accordingly to react to the epoch in line 91
[13:57] <abeato> alright
[13:58] <ogra_> and have another test in the bottom script ... if th edtae we did set in -premount is new enough just skip
[13:58] <ogra_> *the date
[13:58] <ogra_> i.e. if the date is as new as the creation time of /
[13:59] <abeato> that is actually done with the current logic, but yeah
[13:59] <ogra_> also ... if you check /root ... doesnt that actually return the creation time of the mountpoint (i.e. the initrd creation time) ?
[13:59] <ogra_> perhaps you should check the stamp of /root/etc
[13:59] <abeato> nope
[13:59] <ogra_> ok
[13:59] <ogra_> then it is fine
[14:00] <abeato> cool
[14:00] <abeato> will do the changes, thanks
[14:01] <ogra_> thanks for doing it (and for putting up with me :) )
[14:01] <abeato> :)
[14:34] <abeato> ogra_, where is http://paste.ubuntu.com/24815760/ coming from? It is actually not part of the fixrtc scrip in the initramfs-tools package
[14:34] <ogra_> abeato, from the one we have in the image PPA
[14:34] <ogra_> the "n/a" isnt upstreamed yet
[14:34] <abeato> oh, I see
[14:35] <ogra_> abeato, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[14:35] <ogra_> (yes, i' an evil lazy slacker ... should have SRUed that long ago)
[14:36] <abeato> lol, we all are...
[14:43] <mup> PR snapd#3465 opened: hooks: re-org of some hooks types <Created by stolowski> <https://github.com/snapcore/snapd/pull/3465>
[14:44] <pstolowski> niemeyer, ^ the hooks re-org branch I talked about in the standup
[14:46] <om26er> zyga, fyi, there is no UI to change which arches to build on build.snapcraft.
[14:46] <ogra_> no, it always builds amd64 and armhf regardless
[14:46] <om26er> would be really great we were able to distribute our package for arm64 as well as our target is embedded systems.
[14:47] <ogra_> for other arches use LP
[14:47] <ogra_> (or wait until build.s.io grew such a feature)
[14:47] <om26er> does LP also support auto publish to store ?
[14:47] <ogra_> yes
[14:48] <om26er> we could probably wait a bit, if arm64 build support is planned for build.snapcraft
[14:49] <ogra_> om26er, https://github.com/snapcore/pi2-gadget mirrors to -> https://code.launchpad.net/~canonical-foundations/snap-pi2/+git/github-mirror ... then builds -> https://code.launchpad.net/~canonical-foundations/+snap/pi2
[14:50] <ogra_> (and that fgoes automatically into the edge channel)
[14:50] <ogra_> *goes
[14:59] <fgimenez> hey zyga, i'm getting this denial http://paste.ubuntu.com/24815879/ while trying to test this rule https://github.com/snapcore/snapd/blob/master/interfaces/builtin/system_observe.go#L70, any idea what might be going on?
[15:11] <fgimenez> mvo: the core-revert test including bluez is about to finish (I needed to retrigger it to set up the env vars properly to do stable -> candidate -> stable) will keep you posted
[15:11] <daker> popey: https://forum.snapcraft.io/t/nginx-rtmp-streaming-server-snap/961
[15:12] <fgimenez> mvo: btw the sru validation is finished, should i wait for the results or mark it as verification-done now?
[15:13] <mvo> fgimenez: lets wait a tiny bit for the results of bluez
[15:14] <abeato> ogra_, new patch uploaded to lp: #1696981
[15:14] <mup> Bug #1696981: fixrtc is ineffective when there is no battery for the RTC <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1696981>
[15:17] <niemeyer> pstolowski: Thanks, replied there
[15:18] <pstolowski> niemeyer, I saw your comment, thank you
[15:20] <pstolowski> zyga, responded to your comments to 3340
[15:23] <fgimenez> mvo: ok, i get the same timeout reported in the bug, these are the syslog contents http://paste.ubuntu.com/24815993/ looks like we have now "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process"
[15:24] <fgimenez> mvo: the session is open in case you want to take a look
[15:26] <zyga> re
[15:26] <zyga> fgimenez: looking now
[15:27] <zyga> fgimenez: looks like missing dbus abstraction, looking
[15:27] <fgimenez> zyga: thanks! the test snap used is in this changeset in case you want to look into it https://github.com/snapcore/snapd/compare/master...fgimenez:extend-system-observe-test-dbus-introspection?expand=1
[15:28] <zyga> fgimenez: yes, looking at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/system_observe.go I don't see the abstractions included
[15:29] <zyga> jdstrand: ^ should there be #include <abstractions/dbus-session-strict> in system_observe.go?
[15:33]  * jdstrand looks
[15:35] <jdstrand> zyga, fgimenez: it is missing and should have "#include <abstractions/dbus-strict>"
[15:35] <fgimenez> zyga: jdstrand, yep, system bus
[15:35] <jdstrand> (that is for the system bus. not dbus-session-strict, which is for the session bus)
[15:37] <fgimenez> thank jdstrand, for the sru this can't be considered a regression, right? although there was another rule already there that shouldn't work before
[15:37] <fgimenez> *thanks
[15:39] <jdstrand> fgimenez: no it is not a regression. even if both dbus rules were added this time it still isn't a regression, it is just an incomplete set of rules
[15:39] <morphis> kyrofa: do you know if there is any way during a build with snapcraft to find out which architecture we're building for?
[15:40] <fgimenez> jdstrand: cool thx! i can propose the fix together with the test and ping you for the review, is that ok?
[15:40] <jdstrand> fgimenez: absolutely. thanks!
[15:40] <kyrofa> morphis, depends on where "we" are: in snapcraft (e.g. a plugin)? Or the thing being built?
[15:41] <morphis> kyrofa: right now I am doing a wget call into a install: statement
[15:41] <morphis> s/into/in/
[15:41] <kyrofa> morphis, and what happens there needs to change depending on arch?
[15:42] <morphis> kyrofa: I need to download a different file per arch, let say test_amd64.img on x86 and test_armhf.img on armhf
[15:42] <kyrofa> morphis, I'm afraid snapcraft doesn't export any variables relating to target arch. However, doing different things depending on arch is a feature we have on the roadmap... just not there yet
[15:43] <morphis> kyrofa: ok, nice!
[15:43] <kyrofa> morphis, as a workaround, you can create a local plugin for that part and then you can use the plugin API to get that information
[15:43] <morphis> kyrofa: I can workaround by doing different snap builds from different branches for now
[15:43] <kyrofa> That works too, but is annoying, I'm sorry
[15:43] <morphis> kyrofa: hm, you have any good example for that?
[15:43] <kyrofa> morphis, no, but it's easy enough I'll write one for you ;)
[15:43] <kyrofa> One minute
[15:44] <morphis> kyrofa: my hero :-)
[15:44]  * kyrofa turns on mission impossible music
[15:45] <morphis> :-D
[15:56]  * zyga feels sick again
[15:56] <zyga> darn food
[15:59] <jdstrand> zyga: :( feel better
[15:59] <zyga> jdstrand: thank you
[16:00] <kyrofa> morphis, here: https://github.com/kyrofa/arch-specific-plugin
[16:01] <kyrofa> morphis, that will error out because it's trying to pull a tarball from https://arch-specific, but you get the idea
[16:02] <zyga> kyrofa: hey, when is the next release of snapcraft?
[16:02] <morphis> kyrofa: nice, thanks!
[16:03] <kyrofa> zyga, dput just happened, trying to get into proposed
[16:03] <zyga> aha
[16:03] <zyga> nice!
[16:03] <zyga> kyrofa: can you have a quick look at https://github.com/snapcore/snapcraft/pull/1361
[16:03] <mup> PR snapcraft#1361: pluginhandler: don't clobber path on local import failure <Created by zyga> <https://github.com/snapcore/snapcraft/pull/1361>
[16:04] <zyga> I'm not sure why tests are failing
[16:04] <zyga> and you could review it, it's tiny
[16:04] <kyrofa> zyga, yeah looks good to me. Probably a store flake as usual
[16:05] <kyrofa> zyga, yep. We usually have to rerun our tests at least twice
[16:05] <kyrofa> I restarted them
[16:06] <zyga> thanks!
[16:06] <zyga> kyrofa: because of store issues?
[16:07] <kyrofa> zyga, yeah
[16:07] <zyga> wow
[16:07] <kyrofa> It wastes literally hours a day
[16:08] <zyga> what kind of store issues are you seeing?
[16:08] <kyrofa> connection resets
[16:11] <kyrofa> zyga, https://forum.snapcraft.io/t/101-connection-resets/775
[16:14] <pstolowski> niemeyer, I've added a comment to my hooks re-org, I think this situation is more complicated than we had in configstate (but i'm happy to stand corrected)
[16:15] <niemeyer> pstolowski: We have several cases of cross dependency between these packages already.. I'd be surprised to see this case being unlike all of them
[16:15] <mup> PR core-build#13 closed: Androidboot support <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/13>
[16:16] <zyga> niemeyer: can you have a 2nd look on https://github.com/snapcore/snapd/pull/3399 please
[16:16] <mup> PR snapd#3399: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>
[16:16] <niemeyer> pstolowski: If it is, can we please have a proper analysis about why that's the case?
[16:16] <zyga> niemeyer: I believe it is as you requested  now
[16:16] <niemeyer> Yep, will look, thanks
[16:16] <zyga> thank you!
[16:16]  * zyga gets back to feeling sick and testing
[16:17] <ogra_> kyrofa, just stop routing through norway ... then Peer can reset your connection all the time
[16:17] <ogra_> *can not
[16:17] <ogra_> (sorry, already in EOW mood :P )
[16:21] <kyrofa> :P
[16:21] <kyrofa> That darn peer
[16:22] <ogra_> alsoo if you get 101 resets, just write a looop with 102 iterations :P
[16:22] <ogra_> (really sorry, i should stop for the day :P )
[16:24] <kyrofa> ogra_, haha, that's how I read that thread, too
[16:24] <kyrofa> 101 paper cuts, 101 connection resets
[16:24] <ogra_> yeah :)
[16:28] <Chipaca> hmmm
[16:28] <Chipaca> zyga: you there?
[16:28] <zyga> yes
[16:28] <zyga> what's up?
[16:28] <Chipaca> zyga: snap refresh --channel edge core
[16:28] <Chipaca> zyga: and then
[16:28] <Chipaca> zyga: snap refresh --channel beta core
[16:28] <zyga> refreshing
[16:28] <zyga> oh
[16:29] <Chipaca> zyga: does the "preserve namespace" nastyness i was getting
[16:29] <zyga> intereting
[16:29] <mup> PR snapd#3459 closed: tests: add whoami check <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3459>
[16:29] <Chipaca> zyga: huzzah for reproducers!
[16:29] <zyga> edge snapd
[16:29] <zyga> Chipaca: thank you
[16:29] <zyga> Chipaca: I think we nailed that to us following current symlink
[16:29] <zyga> Chipaca: vs knowing the rev to internal tools in cmd/cmd.go
[16:29] <zyga> Chipaca: just not fixed
[16:31] <zyga> yes
[16:31] <zyga> it's definitely that
[16:35] <pstolowski> niemeyer, oh, I found a little trick we do in configstate with setting snapstate.Configure function pointer. that "solves" the dependency issue which would otherwise arise with snapstate setting up hooks
[16:37] <mup> PR snapd#3466 opened: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3466>
[16:37] <fgimenez> mvo: i've just proposed the changes to reproduce the bluez issue snapd#3466
[16:37] <mup> PR snapd#3466: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3466>
[16:38] <pstolowski> zyga, any chance you have another look at https://github.com/snapcore/snapd/pull/3340 ?
[16:38] <mup> PR snapd#3340: many: snapctl outside hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3340>
[16:38] <zyga> looking
[16:45] <zyga> pstolowski: done
[16:45] <zyga> pstolowski: almost there
[16:48] <mvo> fgimenez: thank you! I have a look monday, slightly sad about this. but many thanks for finding a reproducer
[16:48]  * mvo dinner
[16:49] <zyga> fgimenez: do you have a log of what is going on when the bluez code fails?
[16:49] <zyga> fgimenez: any denials or something similra?
[16:49] <zyga> *similar
[16:51] <fgimenez> zyga: this is syslog http://paste.ubuntu.com/24815993/ there are some denials in there but the relevant error seems to be "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process" after the revert
[16:52] <zyga> aha
[16:53] <zyga> yes, that looks like another new thing related to netlink mediation
[16:53]  * zyga wonders what mvo's revert plan for that will be
[16:53] <zyga> fgimenez: thank you!
[16:53] <fgimenez> zyga: yw :)
[16:59] <pstolowski> zyga, done
[16:59] <zyga> pstolowski: I noticed, reading already
[17:01] <zyga> pstolowski: +1
[17:01] <zyga> thank you :)
[17:05] <pstolowski> zyga, thanks :)
[18:39] <mup> PR snapd#3340 closed: many: snapctl outside hooks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3340>
[18:44] <niemeyer> zyga-suse: Sent a review on the interface PR.. let me know if you want to talk about it please
[18:44] <zyga-suse> sure
[18:44] <zyga-suse> let me de-conflict and look
[18:48] <zyga-suse> niemeyer: nothing controversial, I will iterate on this quickly, maybe it can land before your EOD
[18:49] <zyga-suse> niemeyer: one question, are we OK with changing the response this way without changing the URL?
[18:49] <zyga-suse> niemeyer: snap /v2/interface vs /v3/interface (for instance)
[18:50] <niemeyer> zyga-suse: We're not *changing* the response
[18:50] <Chipaca> v3wha
[18:50] <niemeyer> zyga-suse: See the note about compatibility there
[18:50] <niemeyer> zyga-suse: We're not breaking any behavior for existing clients
[18:50] <niemeyer> zyga-suse: That's what v3 would be about
[18:55] <zyga-suse> ah, I see
[18:55] <zyga-suse> hmm
[18:57] <zyga-suse> niemeyer: what would be the response though? currently it is a single object
[18:57] <zyga-suse> niemeyer: and in the proposal it would have to be a list
[18:57] <zyga-suse> niemeyer: do you mean if some options are not given we return the legacy response
[18:58] <zyga-suse> niemeyer: and if they are, we return the new response
[18:58] <niemeyer> zyga-suse: That's expllcitly what is stated there I think:
[18:58] <niemeyer> """
[18:58] <niemeyer> We can provide "connected" via a "select" field, analogous to the one we use for snaps, and then allow specifying "select=all" so that we preserve the result as-is when "select" is not provided, preserving compatibility with existing clients (including the current Interfaces method which will now become Connections). Eventually we can obsolete that result as we'll likely kill the "interfaces" command and introduce a more
[18:58] <niemeyer> polished "connections" one, per our conversations.
[18:58] <niemeyer> """
[18:59] <zyga-suse> I don't get it, the result, right now, is a single object that has two lists inside (plugs and slots)
[19:00] <zyga-suse> how does that allow us to return information about a single non-plug, non-slot interface?
[19:00] <zyga-suse> by returning a shim object with one element?
[19:00] <zyga-suse> sorry if I'm asking silly things, just tired I guess
[19:00] <niemeyer> zyga-suse: Can you point out what is unclear in the above statemnet?
[19:00] <niemeyer> zyga-suse: it's explicitly stating how and when we change the result
[19:01] <niemeyer> zyga-suse: You should probably take some good rest.. we can discuss this again on Monday
[19:01] <zyga-suse> I guess I'm not familiar with the /snaps endpoint
[19:01] <zyga-suse> yeah, I think you are right
[19:01] <zyga-suse> I'll review the snaps API
[19:01] <zyga-suse> and fight this fresh tomorrow
[19:02] <niemeyer> zyga-suse: Monday!  Go take some rest :)
[19:02] <zyga-suse> oh, it's Friday
[19:02] <zyga-suse> man
[19:02] <zyga-suse> yes :)
[19:02]  * zyga-suse lost track
[19:51] <ssbash> hi guys
[19:56] <niemeyer> ssbash: Heya
[20:01] <ssbash> I'm having trouble having my python script accessing a custom python lib. Do you guys know what I can do to fix it in my snapcraft.yaml file?
[20:01] <ssbash> http://paste.ubuntu.com/24817687/
[20:02] <ssbash> My guess is that it should be a stage package, but im not sure how to configure that since its a local lib.
[20:02] <niemeyer> ssbash: Looks like traditional Python module path issues
[20:03] <niemeyer> ssbash: You probably need to fiddle with sys.path to tell Python whre your libraries are located
[20:05] <ssbash> ok ill give that a try. Thanks for your feedback.
[20:45] <mup> PR snapd#3467 opened: interfaces/greengrass-support: add support for Amazon Greengrass as a snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3467>
[22:00] <mup> PR snapcraft#1362 opened: Only install golang-go if it is not found in PATH <Created by chrisglass> <https://github.com/snapcore/snapcraft/pull/1362>
[22:01] <Tribaal> hi snappies, that PR ^^ is mine - happy to discuss in here if needed