/srv/irclogs.ubuntu.com/2017/06/09/#snappy.txt

cachio_Chipaca, all the tests passed00:08
Chipacacachio_: merge away!00:09
cachio_Chipaca, I cant00:13
Chipacacachio_: oh!00:13
cachio_Chipaca, tx :)00:13
mupPR snapd#3448 closed: tests: fix for the test postrm-purge <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3448>00:14
mupPR 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:12
mupPR snapd#3420 closed: many: slight improvement of some snap error messaging <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3420>01:42
=== chihchun_afk is now known as chihchun
=== JanC_ is now known as JanC
zygagood morning06:08
* zyga had a terrible dream 06:09
morphismorning!06:10
morphiszyga, mvo: one of you can merge https://github.com/snapcore/snapd/pull/3406 now?06:10
mupPR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>06:10
zygamorphis: yes, just fiddling with expired github login06:11
morphis:-)06:11
zygamorphis: good morning, how are you?06:11
morphiszyga: fine, you?06:11
zygaso so, weather has deteriorated today it seems06:12
morphisgets stormy again :-)06:13
mvomorphis: done06:15
mvomorphis: thank you for this work!06:15
morphismvo: awesome!06:15
mupPR 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
morphismvo: it's just the beginning06:16
morphishttps://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/95006:20
* zyga cannot login to github06:21
zygadrat06:21
zygathis will be a boring day if I cannot log in06:21
mupPR snapd#3449 opened: tests/lib: generalize RPM build support <Created by morphis> <https://github.com/snapcore/snapd/pull/3449>06:24
morphiszyga: what did you do?06:24
zyga2fa I cannot access06:24
zygawell, I have backup but I cannot reach it yet06:24
zyga(backup is in Poland)06:24
zygaI'll try again soon06:25
mupPR snapd#3450 opened: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>06:26
mupPR 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
zygaoh, nice06:27
zygamorphis: https://github.com/snapcore/snapd/pull/3450/files seems like a copy-paste comment06:28
mupPR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>06:28
mupPR 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
morphiszyga: :-)06:28
morphisfeel like a few smaller PRs are better06:28
morphiskeeps travis busy but the review small and focused06:29
zyga+106:29
mupPR snapd#3453 opened: tests/main/manpages: install missing man package <Created by morphis> <https://github.com/snapcore/snapd/pull/3453>06:30
mupPR snapd#3454 opened: spread: add fedora snap bin dir to global PATH <Created by morphis> <https://github.com/snapcore/snapd/pull/3454>06:32
morphiszyga: complete list: https://forum.snapcraft.io/t/spread-testing-for-fedora-and-opensuse/950/2?u=morphis06:32
mupPR snapd#3455 opened: tests/main: use pkgdb function in more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3455>06:33
mupPR 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:36
* zyga tries to recover hist 2fa 06:58
zygare07:09
zygaok, access regained07:09
abeatoogra_, 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
mupPR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>07:15
mupPR snapd#3442 closed: snap: ensure security polices are re-created <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3442>07:30
=== koza|away is now known as koza
zygamorphis: quick review on https://github.com/snapcore/snapd/pull/3452#pullrequestreview-4308762707:51
mupPR 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
zygaand doing others07:51
morphiszyga: fixe07:54
popeymorphis: morning, any chance you can help out an arch user? https://www.reddit.com/r/linuxquestions/comments/6euoj8/snaps_are_not_running/07:55
morphisAntergos .. what is that? :-)07:56
morphispopey: ah based on Arch07:56
morphisyeah the snapd package on arch is somewhat broken07:56
morphissomething somebody needs to look into, it's on my list which is quite full already07:57
popeysorry to hear that07:57
zygamorphis: I installed arch and could tweak some things but I cannot commit it08:00
morphisme neither, we need Timothy for that08:00
morphistried to reach out to him again but no reply08:00
ogra_abeato, scripts/ sounds fine, then source it respectively08:10
popeymorphis: is it possible to find someone else if we're blocked on Timothy's time?08:10
morphispopey: not sure, zyga may know08:11
morphismy Arch times are long over and never really looked into the snapd situation there yet08:12
morphispopey: 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 over08:12
morphispopey, zyga: maybe we should start reporting bugs against that package08:13
morphishttps://bugs.archlinux.org/index.php?string=snapd08:13
zygapopey: I think any trusted packager can update it08:17
zygamorphis: we might just file a bug with "packaging enhancements"08:17
zyga(and a diff attached)08:17
morphiszyga: yeah08:18
mupPR snapd#3456 opened: many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3456>08:19
popeyzyga: 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:24
morphispopey: +108:25
morphiszyga: so can you update hte package and file a bug?08:25
mupPR snapd#3457 opened: tests: add refresh --time output check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3457>08:27
mupPR snapd#3383 closed: tests: fix spread flaky tests linode <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3383>08:29
morphistravis hates me again ..08:34
mupPR snapd#3458 opened: tests: check that locale-control is not present on core <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3458>08:36
zyga_exit08:48
zygapopey: I'll see what I can do about the package08:49
mupPR snapd#3459 opened: tests: add whoami check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3459>08:49
zygahey fgimenez, I just had a look at https://github.com/snapcore/snapd/pull/3459/files08:51
mupPR snapd#3459: tests: add whoami check <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3459>08:51
zygafgimenez: could you please change that to more "regular" shell [ ] && [ ] syntax08:52
fgimenezhey zyga sure, np, i blindly c&p it from tests/main/login08:55
zygafgimenez: 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 justified08:56
fgimenezzyga: agreed, i'll update login too08:56
zygaThanks!08:56
fgimenezthank you zyga, pushed09:02
zygaoh master why do you hate my PRs09:04
zygadid you hear the latest joke?09:04
zygaI pushed a PR and tests passed on the first go09:04
zygafgimenez: you can use `-n` instad of `! -z`09:08
fgimenezzyga: sure! let me fix it09:08
zygafgimenez: or just "$a" != ""09:08
zygawhatever you like :)09:08
zygaok, while waiting for spread I'll look at refreshing the arch package a little09:10
popeyzyga: thanks09:13
fgimenezzyga: just [ "$a" ] is enough, right?09:13
zygafgimenez: I don't think it is09:13
zygaor maybe it is09:13
zygabut feels more murky09:14
zygaSTRING is equivalent to -n STRING09:14
fgimenezzyga: ok, i'll go for the -n then, thx09:14
zygamy comment was motivated by doing simple and obvious things (hence the suggestion for -n over ! -n or for using != "" explicitly)09:14
=== ogra_ is now known as ogra
mupPR 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:21
zygamvo: reviewed09:29
zygamvo: I only feel strongly about the need to refresh other security backends (we do only two today)09:29
zygamvo: and the need to treat "unknown" as special09:29
zygaThank you for fighting this!09:29
abeatomvo, ogra, https://github.com/snapcore/core-build/pull/13 re-pushed09:31
mupPR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>09:31
ograondra, 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 one09:32
zygapopey: do you know where the git source of snapd packaging for arch is?09:34
zygaI cannot find this anyomre09:34
mvoabeato: thank you , I have a look09:38
mvozyga: thank you too!09:38
abeatomvo, cool, thanks09:38
fgimenezzyga: sure, thanks for pointing that out! already pushed09:41
zygafgimenez: thank you!09:42
popeyzyga: no idea, sorry09:46
zygaI think I have it in my browser history, I was looking at it yesterday09:47
* zyga looks09:47
mvoabeato: the PR looks much better, thanks a bunch for the refactor! once the points from zyga are addressed I think it can go in09:49
abeatomvo, nice!09:49
ondraogra yeah, that part is harmless, I'm having more changes in pipeline for avahi09:51
ograondra, well, it makes it fail to start09:52
mvozyga: if you want unknown to be different every time, it might be easiest to make it "unknown (random-XXXXXX)"09:52
mvozyga: then nothing in the higher layers needs to care09:52
ondraogra 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 name09:52
zygamvo: or just return nil, when it is nil we should regenerate09:52
zygamvo: this feels even easier than deserialization09:52
ondraogra hmm, let me quickly remove it09:52
mvozyga: yeah, that works too09:52
ograondra, it should really not do that09:53
ondraogra should not do what?09:53
ograondra, 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 model09:53
ondraogra BTW I'm preparing avahi-control interface, so once can configure avahi over that09:54
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 apart09:55
ogra)09:55
ogra(and i assume other people do that too)09:55
ondraogra problem with host name is that that is same on all fresh images09:55
ondraogra model will at least give you what type of device it is09:55
ograondra, yes, but you hardcode it ... if the hostname isnt localhost it should not use the model then09:56
ogra(in my network with three pi3 boards always online it would already explode badly)09:56
ondraogra well this one is on configure hook anyway, so it will track hostname changes09:56
ograok09:56
ondraogra no t won't explode09:57
ondraogra this is only addition string on service09:57
ograwell, it will pick random boards for pi3.local09:57
ondraogra so you can have 100 devices with same additional string09:57
ondraogra no, it will set set pi3 there09:57
ograon all three boards09:57
ondraogra it only attaches tag to ssh service with device name09:58
morphiszyga: any idea about https://paste.ubuntu.com/24814501/ ? this isn't about seccomp, there are no denials09:58
ograondra, oh, so it isnt actual avahi ?09:58
ondraogra it's not using it for hostname09:58
ograis that why i dont see a daemon ?09:58
morphiszyga: hm wait, I broke something09:58
ondraogra it is in avahi, but it's not using that string( device name) for avahi host name09:59
ograah09:59
zygamorphis: dmesg | grep 132609:59
ondraogra ssh service already has text tag so you can identify all ubuntu core devices09:59
ondraogra well all avahi instances running from snap09:59
ograyeah, but that doesnt  help if the actual mdns daemon isnt running10:00
ondraogra if it's failing that is bug10:00
ondraogra that tag is used by snappy-discover10:00
ograah10:01
morphiszyga: what is 1326?10:01
ondraogra which will list you all devices on your network which run avahi as snap10:01
ograright ...10:01
ondraogra and in that list, idea was not to just have it as snappy device, but at least also see what model it is10:01
zygaAUDIT_SECCOMP10:01
ograso looking at the snap i see an command-avahi-daemon.wrapper ... but systemctl doesnt show it10:01
ondraogra so it will show you 5 snappy device, where 3 will have pi3 tag10:01
ograseems there is actually a bug then10:01
ograogra@sabrelite:~$ systemctl |grep avahi|grep service10:02
ograogra@sabrelite:~$10:02
* zyga breaks for quick breakfast10:02
ondraogra just did clean install in amd64 core and avahi runing10:02
ograwell, not on armhf10:03
ondraogra will test arm10:03
ograogra@sabrelite:~$ ps ax|grep avahi10:03
ogra 3848 pts/0    S+     0:00 grep --color=auto avahi10:03
ograogra@sabrelite:~$10:03
ograogra@sabrelite:~$ snap list avahi10:03
ograName   Version  Rev  Developer  Notes10:03
ograavahi  0.6.32   44   ondra      -10:03
zygamvo: very unusual error https://travis-ci.org/snapcore/snapd/builds/241117099?utm_source=github_status&utm_medium=notification10:04
ondraogra is there any safe way to lift model or gadget name?10:04
zygasnap confine did not refuse to run10:04
ograondra, only if your hok could call "snap" which we deny i think10:05
zygaisn't this in some way related to us generating the profile for snap-confine now?10:05
zyga(from core010:05
zygamay be a race10:05
ograzyga, wow, that was really a quick breakfast ... only 2min10:06
ogra:P10:06
mvozyga: indeed, *sigh*10:06
ondraogra hmm clean install on cm3 and works10: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
ondraogra I get /snap/avahi/44/meta/hooks/configure: line 48: /bin/nc: Permission denied but it continues, installs and runs10:07
ogradoesnt here10:08
NicolinoCurallihi guys: is the snap-id for core 99T7MUlRhtI3U0QFgl5mXXESAiSwt776?10:08
ogra99T7MUlRhtI3U0QFgl5mXXESAiSwt77610:08
ograyep10:08
ograbtw .... "snap info core" shoudl show it10:09
NicolinoCurallionly on edge10:09
ograah, indeed10:09
NicolinoCurallii need a confirm10:09
mvoyes, only on edge10:09
mvoI mean only there it is visible currently10:09
ograwell. snap-id is the same in all channels :)10:09
ograso yes, the one above is fine10:09
ograondra, wow ... so uninstall and reinstall of the snap works ... sems there is some kind of race10:11
ondraogra damn too late10:13
ondraogra wanted to ask you for one log file10:13
ograah, crap, sorry10:14
ondraogra hook at first install populates default config in writable path10:14
ondraogra which for some reason failed on your device10:14
ondraogra 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 not10:15
ondraogra no worries :)10:15
ograwell, i'm re-installing often, i'll keep an eye out for oother issues like this next time10:15
ondraogra but if you see it again, then check /var/snap/avahi/common/configure-hook.log10:15
ograi assume you want the configure-hook.log ?10:16
ondraogra this should tell us what happened in configure hook10:16
ograheh ... *snap*10:16
ondraogra yeah when it fails, then grab that log10:16
* zyga sees a new VCS in 2017 and wonders if this is a good thing10:21
zygahttps://pijul.org/10:21
zygaoh, darcs is back10:22
zygainteresting10:22
zygamaybe without haskel it will actually perform10:22
pstolowskiinteresting indeed that people still see the need for new vcs10:23
zygawell10:26
zygadarcs was amazing10:26
zygait just didn't get a decent implementation10:26
zyga(at the time when I tried it, darcs2 was feeling better but we moved to hg then)10:26
zygabut the vcs itself is less and less interesting10:26
zygawhere is the tooling for it?10:26
zygastill, interesting10:26
zygais there a snap? :D10:26
zygathere should be one10:27
pstolowski:)10:27
zygamvo: can you please have a look at https://github.com/snapcore/snapd/pull/344410:29
mupPR snapd#3444: interfaces: compose the base declaration from interfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3444>10:29
ograabeato, 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 have10:31
zygamvo: I feel this has 1.9 already (since jdstrand didn't give me a full approval)10:31
zygamvo: 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 puzzle10:32
zyga(and then fix existing interface PRs!)10:32
abeatoogra, there is a difficulty here, which is that the initramfs does not know if it has been loaded from recovery or from boot partition10:32
abeatoogra, the only easy way I found to know that was via kernel command line10:32
ograi'm sure we can somehow find that out10:32
abeatosure, but how? :)10:33
ogradoesnt the kernel hand through the boot reasoon when it is called with reboot recovery ?10:33
abeatonope10:33
abeatono extra args added10:33
ograwell, but snap_mode knows we were rebooted into recovery10:35
ograbecause it is set to try10:35
ograso just match on that10:35
abeatoogra, except when it is "trying", but failed...10:36
ograa) 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_mode10:36
abeatosnap_mode is for detecting the install status of core/kernel, using it for other stuff is a slippery slope10:36
ograwell, i dont really like to modify the cmdline twice10:38
ograespecially the currently working one10:39
abeatoogra, that will not work, if non-emtpy it can be that we are recovery or boot, that is unknown10:39
abeatoogra, 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
ograworst case we could touch a file in the initrd when creating it as recovery ... that still better than changing the safe cmdline10:40
ograah, so you hardcode it there ?10:40
ogratechnically that variable is set in initramfs.coonf10:41
abeatoyes, 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
ograwhcih you can actually set dynamicall yat build time of the initrd10:41
abeatoyes, hardcoded in the boot partition10:41
ograso when creating the recovery initrd we can simply set the var there ... and it will default to BOOT=boot-script10:42
ograthat way you dont need it at all on any cmdline10:43
ograabeato, https://github.com/snapcore/core-build/blob/master/initramfs/conf/ubuntu-core-rootfs10:44
ograwe just need to replace that file dynamically when creating the recovery-initrd.img10:44
ograso recovery always has BOOT=boot-script and noon-recovery does BOOT=ubuntu-core-rootfs10:45
abeatoogra, 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 image10:45
ograthat saves the extra var and the additiopnal cmdline fiddling10:45
abeato*has10:45
ogra(wheer did you plan to do that btw)10:45
ogra(the setting oof the cmdline i mean)10:46
abeatowe 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-script10:46
ograwell, i'D still like us to stay consistent here ... we dont set boot= anywhere in ubuntu except via the initramfs.conf file10:48
abeato(remeber we switched boot with recovery, the kernel is updated in the recovey partition)10:48
ograright10:48
abeatoogra, it is perfectly fine to modify the conf file instead of the kernel cmdline for boot.img in our build scripts10:49
ograthe point that bothers me is that we set soimething on the cmdline :)10:49
abeatoif you think that is better10:49
abeatoso no issue here :)10:49
ograi think it is consistent with the rest of the distro10:49
abeatoit does not affect the PR anyway10:49
ograright10:49
abeatosure, I will change that10:49
ograregarding 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
zygaI'll contribute some in a moment10:50
abeatore: real testing, it has had quite a bit, I simulated update failures in different ways, for instance10:51
ograadding 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 run10:51
ograso you want an initrd, unpack it ... and run the unittests chroooted inside that at the very least10:51
zygaogra: we will see, I don't know yet10:51
ograelse you dont really test if i.e. the binaries your scripts use are there etc10:52
ograand you need to fake all the device bits ... findfs checking for labels etc10:52
ograi'm not sure that buys us much TBH ... over actual testing of a boot and shellcheck to make sure there are no typos10:53
dakerhi, snapcraft question: how can i tell snapcraft to put folders/files in the $SNAP_USER_DATA ?10:56
mvoogra: 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 it10:57
ogradaker, with a wrapper script10:57
mvoworth even10:57
dakerogra: any example ?10:57
ogramvo, oh, yeah, not saying they arent worth it but he asked for them in context of the PR :)10:57
zygadaker: not automatically, but you can with the configure script10:58
ogramvo, 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 up10:58
zygadaker: though it will run _after_ services started10:58
zygadaker: ah, for SNAP_USER_DATA (not the USER) you need a wrapper10:59
* abeato happy to leave that for other PRs ;)10:59
dakerzyga: example :)10:59
ogradaker, https://github.com/ogra1/laidout (doesnt copy anything ... a cp $SNAP/default-config $SNAP_USER_DATA/config would be needed)11:01
dakerogra: thanks! i'll try it11:01
ogradaker, ah, here i copy some java config in place in line 31 https://github.com/ogra1/jtiledownloader/blob/master/wrapper11:02
zygadaker: wrap the real command you want to run in a helper program (script) that does the initial setpu11:02
dakerzyga: ogra ok11:03
mupPR snapd#3461 opened: debian: add missing "make -C data/systemd clean" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3461>11:09
=== ogra_ is now known as ogra
=== ogra is now known as ogra_
mupPR snapd#3462 opened: systemd: refactor service ops to also be exposed more directly <Created by chipaca> <https://github.com/snapcore/snapd/pull/3462>11:35
Chipacaouh11:36
* Chipaca smacks forehead11:36
mupPR snapd#3463 opened: Snap services 2 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3463>11:39
* Chipaca smacks github's forehead11:39
ogra_is it forehead-friday ?11:40
Chipacaogra_: yes11:42
Chipacavery yes, in fact11:43
* ogra_ slaps his forehead too in solidarity with the UK11:43
Chipacaogra_: uff... if it were for the uk shenanigans my forehead would have a berm around the edge from all the slapping11:46
ogra_heh11:46
mupPR snapcraft#1361 opened: pluginhandler: don't clobber path on local import failure <Created by zyga> <https://github.com/snapcore/snapcraft/pull/1361>12:03
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 source12:11
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:12
morphisfgimenez: 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:39
fgimenezmorphis: sure, i'm finishing the sru verification, once that's done i'll take a look12:42
morphisfgimenez: thanks!12:42
kozaogra_, hey and thanks for mail; got disconnected and my ssh/irssi to linode setup reacts with a delay to such events12:45
ogra_koza, no worries ... i just wanted to make sure you definitely get the answer ...12:45
kozaogra_, appreciated12: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:46
kozaogra_, oh right email notification :-)12:47
ogra_yeah :)12:47
fgimenezmorphis: 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/24098384712:49
morphisfgimenez: interesting12:49
fgimenezmorphis: ok opensuse this seems to be the problem http://paste.ubuntu.com/24815216/12:50
fgimenezon opensuse12:50
morphishm, I see12:51
morphismaybe go is too old?12:51
fgimenezmorphis: no idea, also not sure if the quoting is right in that case12:53
morphishm12:55
=== om26er_ is now known as om26er
niemeyerChipaca: Standup?13:03
Chipacaniemeyer: yes!13:05
om26erHi! who is the contact to talk about https://build.snapcraft.io/ ?13:23
mupPR snapd#3444 closed: interfaces: compose the base declaration from interfaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3444>13:28
zygajdstrand: https://github.com/snapcore/snapd/pull/3464 :-)13:32
mupPR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>13:32
zygaom26er: many people, can you be more specific?13:32
mupPR snapd#3464 opened: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>13:32
abeatoogra_, hey, I've created a script for better dates, see https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/169698113:34
mupBug #1696981: fixrtc is ineffective when there is no battery for the RTC <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1696981>13:34
jdstrandzyga: ack, added to list13:34
zygajdstrand: thank you!13:35
ogra_abeato, ummm ... the description is weird13:35
zygajdstrand: it's pretty tedious but should be easy to review patch by patc13:35
zygajdstrand: as those are structured sanely, I hope13:35
jdstrandI haven't looked at it, but know what to expect13:35
jdstrand:)13:35
ogra_abeato, fixrtc is exactly only for the one usecase where no RTC battery is around ...13:35
ogra_abeato, that makes your changelog entry a bit weird13:36
abeatoogra_, yeah, but as discussed it does not work that well. see my comments in https://github.com/snapcore/core-build/pull/1313:36
mupPR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>13:36
om26erzyga, we need to publish our software and it build.snapcraft currently builds for 2 arches, amd64 and armhf, we need support for arm6413:36
om26erso wanted to know if that will come in future13:37
zygaom26er: it's available already AFAIK13:37
zygaom26er: you can build a snap for aarch64 aka arm6413: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
zygaom26er: (via build.snapcraft.io)13:37
abeatoogra_, 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 battery13:37
abeatoogra_, it does not for this device at least13:38
ogra_abeato, and i would still like to find out why the original fixrtc doesnt DTRT13:38
ogra_instead of just adding anothr script13:38
om26erzyga, hmm, by default it built for amd64 and armhf, do we need to change something ?13:38
ogra_abeato, can you capture the data from dumpefs from the initrd when in local-top at least ?13:39
zygaom26er: I think that's something you can tweak on the website13:39
ogra_abeato, and attach that to the bug13:39
zygaom26er: not sure, but I know the builders for aarch64 are around13:39
om26erzyga, ok, will look into that.13:39
abeatoogra_, 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 epoch13:39
abeatoogra_, but let me paste that13:39
ogra_abeato, yes, and the current fixrtc script should take that into account13: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:40
abeatoogra_, we could access files by moving fixrtc to local-bottom13:41
ogra_abeato, well, but that is to late13:41
ogra_we need the clock set before we try to mount13:42
abeatoogra_, then we need this other script13:42
ogra_and there is no reason why you shouldnt get that info13:42
ogra_dumppe2fs should always return *something* and we should be able to react to that13:42
ogra_abeato, i think we just dont handle this special case corretly in the current script ... but to adjust we need the data13:43
abeatoogra_, http://paste.ubuntu.com/24815516/13:43
ogra_Last mount time:          Thu Jan  1 03:42:04 197013:44
abeatoyep13:44
ogra_that should be enough to do something about it13:44
ogra_we know we're at the epoch13:44
abeatosure, and we want something better, isn't it? ;)13:45
abeatotest@localhost:~$ date13:45
abeatoFri Jun  9 13:44:22 UTC 201713:45
abeatothat is the current time in the machine, it is not like it is in the epoch ^^13:45
ogra_abeato, http://paste.ubuntu.com/24815530/ line 99 and following13:46
ogra_we just need to make the if a bit broader13:47
ogra_and if you feel like push the hardcoded timestamp a bit forward ...13:47
abeatoogra_, 1999 is still not good enough, I want the snap assertions to be valid13:48
ogra_well, push it to 2017 then13:48
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 anyway13:49
abeatoogra_, that is true, but I am thinking about the factory case here, no network, and somebody adding system-user assertions with a USB stick13:50
ogra_and if you are not and your image is a month old the hardcoded date will still be wrong13:50
abeatogetting a date from the filesystem helps there13:50
abeatoand it is not wrong13:50
ogra_not much13:50
* zyga lunch13:50
ogra_it will be stuck at the image creation date13:50
abeatoyeah, but that is in fact enough to make sure the assertions are valid, ad they are part of the image13:51
ogra_so depending how old your image is it will still not have a proper date for a freshly created assertion13:51
ogra_(the one on the usb stick)13:51
abeatowell, yes, but is an improvement (time to think now in time assertions to update time in non-connected devices ;)13:52
ogra_abeato, well, your script also only uses "2017-06-09" ...13:53
ogra_which is the date it will always fall back to13:53
ogra_so i dont see why we cant use that in the actual fixrtc script13:53
abeatoogra_, that is an initial hint, then in searches for better dates in the file system13:53
ogra_i also dont like to tie it to snap packages13:54
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 generic13:55
abeatowell, it is not perfect, but nothing but a network connection would do things right. It is just an improvment on the current situation13:55
abeatoogra_, I check "/"13:55
abeato+        if [ -d "$rootfolder" ]; then13:56
ogra_you check /root :)13:56
abeatothat is moved to "/" later in the initramfs13:56
ogra_oh, ignore me :P13:56
ogra_indeed13:57
abeato:)13:57
ogra_well, could we just limit limit that bottom script to this ?13:57
abeatoogra_, ok, I can remove the snapsfolder part13:57
ogra_and fix the -premount script accordingly to react to the epoch in line 9113:57
abeatoalright13:57
ogra_and have another test in the bottom script ... if th edtae we did set in -premount is new enough just skip13:58
ogra_*the date13:58
ogra_i.e. if the date is as new as the creation time of /13:58
abeatothat is actually done with the current logic, but yeah13: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/etc13:59
abeatonope13:59
ogra_ok13:59
ogra_then it is fine13:59
abeatocool14:00
abeatowill do the changes, thanks14:00
ogra_thanks for doing it (and for putting up with me :) )14:01
abeato:)14:01
abeatoogra_, where is http://paste.ubuntu.com/24815760/ coming from? It is actually not part of the fixrtc scrip in the initramfs-tools package14:34
ogra_abeato, from the one we have in the image PPA14:34
ogra_the "n/a" isnt upstreamed yet14:34
abeatooh, I see14:34
ogra_abeato, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial14:35
ogra_(yes, i' an evil lazy slacker ... should have SRUed that long ago)14:35
abeatolol, we all are...14:36
=== chihchun is now known as chihchun_afk
mupPR snapd#3465 opened: hooks: re-org of some hooks types <Created by stolowski> <https://github.com/snapcore/snapd/pull/3465>14:43
pstolowskiniemeyer, ^ the hooks re-org branch I talked about in the standup14:44
om26erzyga, fyi, there is no UI to change which arches to build on build.snapcraft.14:46
ogra_no, it always builds amd64 and armhf regardless14:46
om26erwould be really great we were able to distribute our package for arm64 as well as our target is embedded systems.14:46
ogra_for other arches use LP14:47
ogra_(or wait until build.s.io grew such a feature)14:47
om26erdoes LP also support auto publish to store ?14:47
ogra_yes14:47
om26erwe could probably wait a bit, if arm64 build support is planned for build.snapcraft14:48
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/pi214:49
ogra_(and that fgoes automatically into the edge channel)14:50
ogra_*goes14:50
fgimenezhey 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?14:59
=== koza is now known as koza|away
fgimenezmvo: 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 posted15:11
dakerpopey: https://forum.snapcraft.io/t/nginx-rtmp-streaming-server-snap/96115:11
fgimenezmvo: btw the sru validation is finished, should i wait for the results or mark it as verification-done now?15:12
mvofgimenez: lets wait a tiny bit for the results of bluez15:13
abeatoogra_, new patch uploaded to lp: #169698115:14
mupBug #1696981: fixrtc is ineffective when there is no battery for the RTC <initramfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1696981>15:14
niemeyerpstolowski: Thanks, replied there15:17
pstolowskiniemeyer, I saw your comment, thank you15:18
pstolowskizyga, responded to your comments to 334015:20
fgimenezmvo: 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:23
fgimenezmvo: the session is open in case you want to take a look15:24
zygare15:26
zygafgimenez: looking now15:26
zygafgimenez: looks like missing dbus abstraction, looking15:27
fgimenezzyga: 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=115:27
zygafgimenez: yes, looking at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/system_observe.go I don't see the abstractions included15:28
zygajdstrand: ^ should there be #include <abstractions/dbus-session-strict> in system_observe.go?15:29
* jdstrand looks15:33
jdstrandzyga, fgimenez: it is missing and should have "#include <abstractions/dbus-strict>"15:35
fgimenezzyga: jdstrand, yep, system bus15:35
jdstrand(that is for the system bus. not dbus-session-strict, which is for the session bus)15:35
fgimenezthank jdstrand, for the sru this can't be considered a regression, right? although there was another rule already there that shouldn't work before15:37
fgimenez*thanks15:37
jdstrandfgimenez: 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 rules15:39
morphiskyrofa: do you know if there is any way during a build with snapcraft to find out which architecture we're building for?15:39
fgimenezjdstrand: cool thx! i can propose the fix together with the test and ping you for the review, is that ok?15:40
jdstrandfgimenez: absolutely. thanks!15:40
kyrofamorphis, depends on where "we" are: in snapcraft (e.g. a plugin)? Or the thing being built?15:40
morphiskyrofa: right now I am doing a wget call into a install: statement15:41
morphiss/into/in/15:41
kyrofamorphis, and what happens there needs to change depending on arch?15:41
morphiskyrofa: I need to download a different file per arch, let say test_amd64.img on x86 and test_armhf.img on armhf15:42
kyrofamorphis, 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 yet15:42
morphiskyrofa: ok, nice!15:43
kyrofamorphis, as a workaround, you can create a local plugin for that part and then you can use the plugin API to get that information15:43
morphiskyrofa: I can workaround by doing different snap builds from different branches for now15:43
kyrofaThat works too, but is annoying, I'm sorry15:43
morphiskyrofa: hm, you have any good example for that?15:43
kyrofamorphis, no, but it's easy enough I'll write one for you ;)15:43
kyrofaOne minute15:43
morphiskyrofa: my hero :-)15:44
* kyrofa turns on mission impossible music15:44
morphis:-D15:45
* zyga feels sick again15:56
zygadarn food15:56
jdstrandzyga: :( feel better15:59
zygajdstrand: thank you15:59
kyrofamorphis, here: https://github.com/kyrofa/arch-specific-plugin16:00
kyrofamorphis, that will error out because it's trying to pull a tarball from https://arch-specific, but you get the idea16:01
zygakyrofa: hey, when is the next release of snapcraft?16:02
morphiskyrofa: nice, thanks!16:02
kyrofazyga, dput just happened, trying to get into proposed16:03
zygaaha16:03
zyganice!16:03
zygakyrofa: can you have a quick look at https://github.com/snapcore/snapcraft/pull/136116:03
mupPR snapcraft#1361: pluginhandler: don't clobber path on local import failure <Created by zyga> <https://github.com/snapcore/snapcraft/pull/1361>16:03
zygaI'm not sure why tests are failing16:04
zygaand you could review it, it's tiny16:04
kyrofazyga, yeah looks good to me. Probably a store flake as usual16:04
kyrofazyga, yep. We usually have to rerun our tests at least twice16:05
kyrofaI restarted them16:05
zygathanks!16:06
zygakyrofa: because of store issues?16:06
kyrofazyga, yeah16:07
zygawow16:07
kyrofaIt wastes literally hours a day16:07
zygawhat kind of store issues are you seeing?16:08
kyrofaconnection resets16:08
kyrofazyga, https://forum.snapcraft.io/t/101-connection-resets/77516:11
pstolowskiniemeyer, 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:14
niemeyerpstolowski: We have several cases of cross dependency between these packages already.. I'd be surprised to see this case being unlike all of them16:15
mupPR core-build#13 closed: Androidboot support <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/13>16:15
zyganiemeyer: can you have a 2nd look on https://github.com/snapcore/snapd/pull/3399 please16:16
mupPR snapd#3399: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>16:16
niemeyerpstolowski: If it is, can we please have a proper analysis about why that's the case?16:16
zyganiemeyer: I believe it is as you requested  now16:16
niemeyerYep, will look, thanks16:16
zygathank you!16:16
* zyga gets back to feeling sick and testing16:16
ogra_kyrofa, just stop routing through norway ... then Peer can reset your connection all the time16:17
ogra_*can not16:17
ogra_(sorry, already in EOW mood :P )16:17
kyrofa:P16:21
kyrofaThat darn peer16:21
ogra_alsoo if you get 101 resets, just write a looop with 102 iterations :P16:22
ogra_(really sorry, i should stop for the day :P )16:22
kyrofaogra_, haha, that's how I read that thread, too16:24
kyrofa101 paper cuts, 101 connection resets16:24
ogra_yeah :)16:24
Chipacahmmm16:28
Chipacazyga: you there?16:28
zygayes16:28
zygawhat's up?16:28
Chipacazyga: snap refresh --channel edge core16:28
Chipacazyga: and then16:28
Chipacazyga: snap refresh --channel beta core16:28
zygarefreshing16:28
zygaoh16:28
Chipacazyga: does the "preserve namespace" nastyness i was getting16:29
zygaintereting16:29
mupPR snapd#3459 closed: tests: add whoami check <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3459>16:29
Chipacazyga: huzzah for reproducers!16:29
zygaedge snapd16:29
zygaChipaca: thank you16:29
zygaChipaca: I think we nailed that to us following current symlink16:29
zygaChipaca: vs knowing the rev to internal tools in cmd/cmd.go16:29
zygaChipaca: just not fixed16:29
zygayes16:31
zygait's definitely that16:31
pstolowskiniemeyer, 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 hooks16:35
mupPR snapd#3466 opened: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3466>16:37
fgimenezmvo: i've just proposed the changes to reproduce the bluez issue snapd#346616:37
mupPR snapd#3466: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3466>16:37
pstolowskizyga, any chance you have another look at https://github.com/snapcore/snapd/pull/3340 ?16:38
mupPR snapd#3340: many: snapctl outside hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3340>16:38
zygalooking16:38
zygapstolowski: done16:45
zygapstolowski: almost there16:45
mvofgimenez: thank you! I have a look monday, slightly sad about this. but many thanks for finding a reproducer16:48
* mvo dinner16:48
zygafgimenez: do you have a log of what is going on when the bluez code fails?16:49
zygafgimenez: any denials or something similra?16:49
zyga*similar16:49
fgimenezzyga: 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 revert16:51
zygaaha16:52
zygayes, that looks like another new thing related to netlink mediation16:53
* zyga wonders what mvo's revert plan for that will be16:53
zygafgimenez: thank you!16:53
fgimenezzyga: yw :)16:53
pstolowskizyga, done16:59
zygapstolowski: I noticed, reading already16:59
zygapstolowski: +117:01
zygathank you :)17:01
pstolowskizyga, thanks :)17:05
=== zyga_ is now known as zyga-fedora
=== zyga is now known as zyga-suse
mupPR snapd#3340 closed: many: snapctl outside hooks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3340>18:39
niemeyerzyga-suse: Sent a review on the interface PR.. let me know if you want to talk about it please18:44
zyga-susesure18:44
zyga-suselet me de-conflict and look18:44
zyga-suseniemeyer: nothing controversial, I will iterate on this quickly, maybe it can land before your EOD18:48
zyga-suseniemeyer: one question, are we OK with changing the response this way without changing the URL?18:49
zyga-suseniemeyer: snap /v2/interface vs /v3/interface (for instance)18:49
niemeyerzyga-suse: We're not *changing* the response18:50
Chipacav3wha18:50
niemeyerzyga-suse: See the note about compatibility there18:50
niemeyerzyga-suse: We're not breaking any behavior for existing clients18:50
niemeyerzyga-suse: That's what v3 would be about18:50
zyga-suseah, I see18:55
zyga-susehmm18:55
zyga-suseniemeyer: what would be the response though? currently it is a single object18:57
zyga-suseniemeyer: and in the proposal it would have to be a list18:57
zyga-suseniemeyer: do you mean if some options are not given we return the legacy response18:57
zyga-suseniemeyer: and if they are, we return the new response18:58
niemeyerzyga-suse: That's expllcitly what is stated there I think:18:58
niemeyer"""18:58
niemeyerWe 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 more18:58
niemeyerpolished "connections" one, per our conversations.18:58
niemeyer"""18:58
zyga-suseI don't get it, the result, right now, is a single object that has two lists inside (plugs and slots)18:59
zyga-susehow does that allow us to return information about a single non-plug, non-slot interface?19:00
zyga-suseby returning a shim object with one element?19:00
zyga-susesorry if I'm asking silly things, just tired I guess19:00
niemeyerzyga-suse: Can you point out what is unclear in the above statemnet?19:00
niemeyerzyga-suse: it's explicitly stating how and when we change the result19:00
niemeyerzyga-suse: You should probably take some good rest.. we can discuss this again on Monday19:01
zyga-suseI guess I'm not familiar with the /snaps endpoint19:01
zyga-suseyeah, I think you are right19:01
zyga-suseI'll review the snaps API19:01
zyga-suseand fight this fresh tomorrow19:01
niemeyerzyga-suse: Monday!  Go take some rest :)19:02
zyga-suseoh, it's Friday19:02
zyga-suseman19:02
zyga-suseyes :)19:02
* zyga-suse lost track19:02
ssbashhi guys19:51
niemeyerssbash: Heya19:56
ssbashI'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
ssbashhttp://paste.ubuntu.com/24817687/20:01
ssbashMy guess is that it should be a stage package, but im not sure how to configure that since its a local lib.20:02
niemeyerssbash: Looks like traditional Python module path issues20:02
niemeyerssbash: You probably need to fiddle with sys.path to tell Python whre your libraries are located20:03
ssbashok ill give that a try. Thanks for your feedback.20:05
mupPR snapd#3467 opened: interfaces/greengrass-support: add support for Amazon Greengrass as a snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3467>20:45
mupPR 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:00
Tribaalhi snappies, that PR ^^ is mine - happy to discuss in here if needed22:01
=== tvoss_ is now known as tvoss
=== mup_ is now known as mup
=== souther_ is now known as souther

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!