[05:57] PR snapd#3477 closed: tests: fix snap create-key by restarting automatically rng-tools [06:04] o/ [06:45] zyga: hey! [06:45] zyga: can you merge https://github.com/snapcore/snapd/pull/3470 ? [06:45] PR snapd#3470: interfaces/builtin: sync connected slot and permanent slot snippet [06:48] zyga: hm, the idea of using snap-update-ns to fixup the permissions of /var/lib will unfortunately not work because it looks like we don't run that for the snaps when snapd itself (e.g. fro mthe deb) is updated. context is the incorrect permissions of /var/lib inside the namespace [06:48] zyga: and good morning :) - and good morning to morphis too! [06:48] mvo: morning! [06:50] zyga: I suspect this needs to go into snap-confine itself (the fixup code). slightly sad about this [06:51] mvo: can you have a look at https://github.com/snapcore/snapd/pull/3449 and merge if it is fine for you? [06:51] PR snapd#3449: tests/lib: generalize RPM build support [06:51] morphis: sure [06:52] morphis: done [06:52] mvo: hey [06:52] PR snapd#3470 closed: interfaces/builtin: sync connected slot and permanent slot snippet [06:52] thanks! [06:52] * zyga is sitting amids boxes and unpacked things everywhere [06:52] morphis: sure [06:52] zyga: woah, you are back? [06:53] PR snapd#3449 closed: tests/lib: generalize RPM build support [06:53] mvo: I won't be much help this week [06:53] zyga: no worries [06:53] mvo: I'm sick (cold) *and* sunburned [06:54] zyga: have you moved too? [06:55] mvo: yesterday we had a surprise party from our closest friends [06:55] mvo: no, I'm moving on Thursday [06:55] mvo: extra family members are here to help us move [06:55] mvo: we'll land in Poland on Friday at 1 AM or something like that [07:03] zyga: woah, good luck [07:03] zyga: and get well [07:05] mvo: I'll aks you for a review of the initrd test support soon [07:20] * mvo takes a short break [07:43] mvo, zyga: if you have another min, https://github.com/snapcore/snapd/pull/3450 [07:43] PR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included [08:21] PR snapd#3450 closed: packaging/{opensuse,fedora}: allow package build with testkeys included [08:21] mvo: thanks! [08:24] morphis: yw! [08:51] PR snapd#3487 closed: tests: reenable help test on ubuntu and debian systems [08:51] mvo, any opinion on bug 1698107 ? [08:51] Bug #1698107: Ubuntu Core images should include ntfs-3g [08:54] PR snapd#3222 closed: many: fix test cases to work with different DistroLibExecDir [08:55] ogra: sounds reasonable, it seems like its pretty small [08:56] PR snapd#3391 closed: tests: reboot after upgrading to snapd on the -proposed pocket [08:57] if someone could have a look at 3482 that would be cool, very straightforward review [08:57] mvo: yeah! [08:57] re [08:57] zyga: you wont believe it: https://github.com/snapcore/snapd/pull/3222 [08:57] PR snapd#3222: many: fix test cases to work with different DistroLibExecDir [08:58] morphis: ha! great job for getting it in :) [08:58] morphis: nice, very nice [08:58] * zyga just got rid of the 1st aquarium [08:58] now quick breakfast and back to work [08:58] mvo, yeah.1.5MB uncompressed [08:58] * ogra will add it [09:00] mvo: done [09:00] PR snapd#3482 closed: asserts: support timestamp and optional disabled header on repair [09:00] zyga, i see weird "cookie not found" errors on all my core boards since about last week ... is that snap-confine ? [09:00] ogra: that's the new context thing [09:01] pstolowski: ^^ [09:01] pstolowski: something you may want to know about [09:01] ogra: are those actual errors or just messages that are logged but stuff still works? [09:01] we should at least fix the error message to have a final newline if we want to chow it all the time :) [09:01] PR snapd#3467 closed: interfaces/greengrass-support: add support for Amazon Greengrass as a snap [09:01] *show [09:01] ogra: oh, indeed [09:01] zyga: 3441 has a comment from pedronis, do you think you can address it or shall I have a look, looks like a trivial change [09:02] zyga, it seems to happen if the app actually takes a while to start up ... i can pretty reliably reproduce it by running classic (and initially though it was only there) ... but yesterday i ran htop on a heavy loaded board and saw it for htop as well [09:02] pstolowski, ^^ [09:03] mvo: I'll do it now [09:03] mvo: thank you for spotting that [09:03] zyga: thank you, I think its pretty close [09:03] zyga: 3464 probably needs an ok from gustavo, wdyt? pr itself looks fine (assuming everything is identical just split up :) [09:04] zyga, ogra right. we will complain for already installed snaps that don't have the cookie (since we generate cookies only when snap is installed). but it's a warning only, everything should work [09:04] pstolowski, prefixing it with a "W:" or some such might help ... and the message should really get a final newline/linewrap at the end [09:05] mvo: yes, I have a informal +1 from jdstrand and once we have formal reviews it should go in [09:05] pstolowski: can you check about that newline [09:05] pstolowski: probably error is doing that, error is not used in the code much [09:05] in classic i always like: [09:05] ogra@sabrelite:~$ sudo classic [09:05] cannot open cookie file /var/lib/snapd/cookie/snap.classic(classic)ogra@sabrelite:~$ [09:05] *i always end up like [09:06] zyga: great, if there is agreement I will try to review today [09:06] zyga, ogra ok, will add a new line. but i don't think we use 'W:' to signify warnings anywhere? [09:06] fgimenez: quick question about 3474 - if /etc/gai.conf is not writable on core, why didn't the tests explode on core when it tries to write to /etc/gai.conf ? [09:06] pstolowski: W: ? [09:06] well ... indicate somehow that it isnt an error ... doesnt need to be "W:" [09:07] else we'll get bugs about it [09:07] pstolowski: is this warning helpful in any way to the user? I mean, is there anything that the user can do to get rid of if? [09:07] pstolowski: I guess what I'm asking is - can we somehow fix things so that we don't have to print this message and explain something to the user? [09:07] mvo, reinstall affected snap would remove this warning [09:08] mvo, an alternative would be to generate all the missing cookies (for snaps installed before the feature was introduced) on snapd start [09:08] pstolowski: if its not too much hassle that sounds much better than to ask all $users to do this manually [09:09] * ogra tries ... [09:09] PR snapd#3466 closed: tests: extend core-revert test to cover bluez issues [09:09] pstolowski: I think you just said what has to be done [09:09] pstolowski: it's ain internal implementation deatail [09:10] pstolowski: similar in principle to security refresh [09:10] ogra, if you're trying the reinstall, make sure you don't have any old revisions of that snap installed [09:10] bah, you tell me now :P [09:10] zyga, mvo ok, i'll do that [09:12] hey mvo welcome back! on linode the core system follows a different path than on the external backend, the former starts with a classic system (/etc/gai.conf is writable at that stage) which eventually reboots into a core system, the latter is a core system from the start (with /etc/gai.conf in a read-only partition from the beginning) [09:13] popey, hey ... you recently asked abotu that https://github.com/ogra1/nanopi-neo-gadget (and also https://github.com/ogra1/orangepi-zero-gadget) ... still struggling with a kernel atm ... but i have both boards now [09:14] ogra@sabrelite:~$ sudo classic [09:14] (classic)ogra@sabrelite:~$ [09:14] pstolowski, confirmed ... ^^^ [09:14] ogra, warning is gone, that is? [09:14] yeah [09:14] fgimenez: aha, so this fails when you run it against a real ubuntu-core extrenal device like a pi2? [09:14] ok. ill fix it [09:14] pstolowski: thank you! [09:15] ogra: nice! [09:15] the nanopi is soooo cute! [09:15] zyga: I added one more comment into 3441 (hopefully trivial) [09:15] * ogra is in love :) [09:16] mvo: looking [09:16] mvo: replied [09:16] zyga: thank you. and do let me know if I can take any burden of your shoulder, it sounds like you have a bit of a stressful week ahead of you. i.e. I can fixup anything for you in the PRs [09:17] mvo: yes, exactly [09:18] mvo: just running tests there [09:18] mvo: with kvm it should fail too, any core system using the external backend [09:18] zyga: ta [09:18] mvo: the encoding is done by the response codec I suspect, I'm not doing that myself [09:19] fgimenez: thats fine, I was just wondering why we have not seen it in spread [09:19] mvo: I could just convert it to a string, I think it's not any harm [09:20] PR snapd#3474 closed: tests: fix ipv6 disable for ubuntu-core [09:21] if 3317 gets a second review it can go in too - we may need a gustavo review for this though [09:21] mvo: yes, we need core spread test on actual systems to contrast linode results and prevent the tweaking we do there to mask potential problems, hopefully as soon as we have the jenkins instance up this will be automated [09:21] mvo: thx! :) [09:22] ogra: which one did you get? [09:22] nanopi neo [09:23] i'm pondering to also get the air [09:24] my prob is currently that you cant cross compile our aarch64 kernel and the armhf build doesnt seem to boot [09:24] the air is the super tiny one, right? [09:24] they are both super tiny .. 2cmx2cm or so [09:25] the air is the one with additional wlan ... i think its a tad bit larger [09:25] (due to the wifi chip) [09:26] yeah, I'm interested in the wifi enabled one [09:26] PR snapd#3476 closed: snap-confine: validate SNAP_NAME against security tag [09:27] mvo, thanks ^ I was waiting for tests to pass but you were faster ;) [09:27] fgimenez: another silly question - why do we see the issue with 3488 only on opensuse? [09:27] pstolowski: all the relevant ones passed ;) [09:27] popey, https://www.voelkner.de/products/940892/Nanopi-Neo-Allwinner-512-MB-ohne-Betriebssystem.html is the one i got [09:27] mvo, right. i didn't expect any surprises anyway, the last commit just fixed the comments [09:27] pstolowski: but yeah, sorry for that, I'm in a bit of ocd mode right now, the queue felt a bit overwhemling and we have a lot of low-hanging fruits [09:27] very cute [09:28] thats the air https://www.voelkner.de/products/966493/Nanopi-Neo-Air-512-MB-ohne-Betriebssystem-microSD-Bluetooth-Micro-USB-OTG.html [09:28] Is it possible to install snaps on an ubuntu host from my phone? [09:28] pstolowski: on the bright side, we are down to 27 PRs [09:29] Vamsi, you could install snapweb ... or use a terminal and ssh on your phone [09:29] PR snapd#3445 closed: tests: add linode-sru backend [09:29] Vamsi: we have a REST API for snapd but it is not yet exposed [09:30] mvo, good stuff [09:31] PR snapd#3485 closed: tests: fix nightly suite [09:32] ppisati, do you happen to know how i can cross-build an aargh64 kernel ? i get complains about missing stack protector support in the compiler when i try [09:34] mvo: no idea, it's super strange, here is one of the logs with the failure , http://paste.ubuntu.com/24898301/ "flag provided but not defined: -tags withstagingkeys" [09:34] ogra: sounds like you are trying to compile a recent kernel with an old toolchain [09:35] ppisati, yeah, the nanopi and orangepi are only supported in 4.11 onwards [09:35] ppisati, but i attempted the build inside an artful chroot ... so it should be the latest tootlchain we have (unless there is something in proposed that i'D need) [09:36] ogra: uhm, that should be fine [09:36] ogra: what's the error? [09:37] something about "no support for -fstack-protector-strong" [09:37] i dont have the exact error handy atm [09:39] mvo: look at 3441 again please [09:47] pedronis: ^ as well please [09:56] mvo: zyga: thanks for merging the repair PR, I updated the forum topic to reflect these small tweaks [10:00] PR snapd#3488 closed: tests: prevent quoting error on opensuse [10:03] ppisati, http://paste.ubuntu.com/24898399/ eher is the exact error [10:06] ppisati, the command i'm running is " ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- fakeroot debian/rules binary-headers binary-generic binary-perarch" [10:07] ogra: but there you are actually compiling an amd64 kernel [10:07] ppisati, huh ? [10:07] is CROSS_COMPILE not respected anymore ? [10:08] ogra: that's what i usually use [10:08] ogra: 'export ARCH=arm64; export $(dpkg-architecture -aarm64); export CROSS_COMPILE=aarch64-linux-gnu-' [10:08] and then 'fdrc etcetc' [10:09] * ogra slaps forehead ... [10:09] export $(dpkg-architecture -aarm64) .... [10:09] sorry for the noise ... building now [10:09] jdstrand: good news, the seccomp-bpf PR is green! but still quite a few comments to address [10:09] ogra: np [10:10] pedronis: thank you! [10:11] ppisati, oh, and FYI ... i couldnt get armhf generic to boot on my nanopi or orangepi ... (thats why i try arm64 now) [10:13] ogra: 4.11? [10:13] yep [10:13] ogra: ouch [10:13] i get "Loading kernel ..." and thats it [10:14] ogra: do you have uboot running? you could dump the location of the printk buffer [10:14] how do i do that [10:15] i have earlyprintk and the right console= arg on the cmdline (verified a thousand times) ... so if it prints anything there it should show up [10:15] ogra: http://elinux.org/Debugging_by_printing [10:16] * ogra reads [10:16] ogra: after the conversion do DT, i never got earlyprintk to work [10:16] ah [10:16] k [10:16] ogra: but i didn't try hard, honestly [10:17] i'll resort to the printk hacker if arm64 doesnt work either [10:17] *hack [10:17] seemingly the allwinner toolchains are all aarch64 ... so i have some hope that an arm64 build might work better [10:23] PR snapd#3441 closed: cmd,daemon: add debug command for displaying the base policy [10:44] * zyga -> break [10:56] bah crap ... [10:56] ls unpack/lib/firmware/4.11.0-6-generic/device-tree/allwinner/ [10:56] sun50i-a64-bananapi-m64.dtb sun50i-a64-pine64.dtb sun50i-a64-pine64-plus.dtb [10:56] not so helpful :/ [11:25] zyga: Can you confirm if /var/lib/snapd/snaps exists on all snapd systems? Or if there's an API to get that path (analogous to snap-mount-dir)? [11:30] kalikiana_: dirs.SnapBlobDir? [11:30] is that what you mean? [11:31] kalikiana_: it exists on all systems AFAIK [11:31] kalikiana_: what do you need it for? [11:31] it should exist everywhere [11:31] it's the snap download dir [11:32] Chipaca: This doesn't have SnapBlobDir https://github.com/snapcore/snapd/wiki/REST-API [11:32] Chipaca: I'm injecting snaps from the host into a LXD container [11:32] I'd like to know that this can work on different snapd systems other than Ubuntu [11:33] Son_Goku: Is that documented anywhere? [11:34] the only location that differs is /var/lib/snapd/snap vs /snap [11:34] Debian and Ubuntu and openSUSE use /snap [11:34] Fedora and Arch use /var/lib/snapd/snap [11:35] * zyga feels worse and breaks [11:36] mvo: I may miss standup, tomorrow should be a saner day [11:36] koza, how is the humminngboard ? === rumble is now known as grumble [11:45] mvo, zyga: next one is ready: https://github.com/snapcore/snapd/pull/3455 [11:45] PR snapd#3455: tests/main: use pkgdb function in more test cases [11:49] * Chipaca ~> lunch [12:05] Morning all [12:06] zyga: Thank you [12:06] ogra: Thank you === ahasenac` is now known as ahasenack === ahasenack is now known as Guest20728 [12:12] good morning niemeyer ! [12:16] mvo, to test the new logic for generating cookies on start I may need to write a spread test that stops snapd, removes some data from state.json and starts snapd back, but that sounds a little big ugly... but I can't think of any other way of simulating coming from an old snapd in a test. do you know any tests where we do anything like that? [12:20] pstolowski: the upgrade tests should also test it, but we do have some tests that delete state.json at least [12:20] or play with other /var/lib/snapd stuff [12:20] pstolowski: was about to suggest the upgrade suite [12:20] pedronis, ok. if I delete state.json, doesn't this make snapd unaware of installed snaps? [12:21] pstolowski: sorry, that wasn't my point, just sayign we do play with state.json sometimes [12:21] don't remember punctual edits [12:21] pedronis, ah, I see [12:21] but probably because we didn't need them [12:21] pedronis, I see [12:22] pstolowski: but as mvo said, the upgrade tests should grow some checks about this as well [12:22] I have a bug report for Snapcraft on Debian, but it looks like I can't log into launchpad with a newly created Ubuntu One account [12:22] pstolowski: tests/upgrade/basic/task.yaml [12:22] so I guess that means I have two bug reports now :) [12:23] pcercuei: what's the error? [12:23] pcercuei: (with Launchpad login) [12:23] pedronis, mvo thanks, looking [12:24] cjwatson: Ubuntu One requests some personal information (my full name + email), I select both and click "Yes, log me in"; back on launchpad.net I get a "Oops" page, error ID OOPS-72c555d0a37007d571cd18978befd04a [12:24] Thanks, the OOPS ID was all I needed. [12:25] I'll chase that up for you. [12:26] thanks! [12:27] the actual bug I wanted to report: running latest 'snapcraft' on my Debian ends up with this: [12:27] "dpkg-query: error: --listfiles needs a valid package name but 'libc6' is not: ambiguous package name 'libc6' with more than one installed instance" [12:28] and that's because "dpkg -L libc6" is confused, because I have i686 and x86_64 versions [12:31] pcercuei: this is something for kyrofa - the fix is probably simple, we need to teach snapcraft to always use the dpkg full name (i.e. pkgname:arch) [12:31] pcercuei: thanks a lot for finding this [12:32] mvo: should I still create a ticket? [12:41] pcercuei: yes please, this will make tracking easier [12:42] ogra, hey. still in this pity state. seems that your unit is somewhat special because somebody at Linaro tried other board they had in the office and it just as much as mine that is just a red led. [12:43] koza, hmm, well, i didnt do anything to my unit, i got it from madper as is and only stuck the SD in and booted it after creating the image [12:44] who at linaro did you talk to (do we have any hummingboard specialist i could ping in #linaro ?) [12:44] ogra, whatever has been done you might have the only working hummingboard as of today ;-) [12:44] well, you should at least get some output on serial [12:44] koza, did you try any other image ? [12:45] ogra, serial is dead silent; yeah I have tried the debian image [12:45] same issue ? [12:46] ogra, just a red led [12:46] bah [12:47] koza, another thing ... are you still responsible for bluetooth ? we need to get the Pi3 stuff going at some point [12:48] (first of all hciattach needs to be allowed to talk to the BT device, the gadget is ready, but the bluez package needs adjustments for that i think) [12:50] ogra, I know, have this still in the back of my head; I will prioritize this so that it does not slip again; so when I'm done with the failing bluez kernel tests I will be on it [12:52] koza, ok, no hurry, just wanted to know if thats still in your set of responsibilities (wasnt sure after the re-org) [13:38] niemeyer: the board at https://github.com/resin-io/autohat-board has been developed with kicad http://kicad-pcb.org/, this site compares prices from pcb manufacturers https://pcbshopper.com/ [13:40] and has a good list of them [13:40] fgimenez: Yeah, I think that's one of the most well known open source suites for PCB design.. what I wonder is how far along the manufacturing pipeline this is [13:40] and as a bonus ... we do have a kicad snap in the store ;) [13:43] popey: why does wethr sometimes take ages to 'detect my location'? [13:45] niemeyer: from a random search in https://pcbshopper.com/ it seems that the shipping days range from 5 to 43 http://imgur.com/a/brd4h [13:45] fgimenez: I think we should find out how many boards have been manufactured with those plans so far, and whether they actually work [13:46] mvo: nice! :) [13:47] niemeyer: ok, i'll ask around, will keep you posted [13:47] fgimenez: Thanks! [13:51] PR snapcraft#1368 opened: cli: get_project_options must not discard kwargs [13:53] ogra: snapweb is meant only for Ubuntu right? Is it possible to do so even from an Android phone or iOS phones? [13:56] Vamsi, snapweb is a web UI for the snapd running on the other machine [13:56] you just open it in your phone browser [13:57] (any browser should work ... https://:4200/ [14:00] ogra: So I install snapd on the host and then on the web browser of my android phone I just put the IP address of this host and then install the snaps I need. Is my understanding right? === Guest20728 is now known as ahasenack [14:02] Vamsi, scroll down to "Installing snapweb" http://www.lieberbiber.de/2017/02/22/basic-management-of-an-ubuntu-core-installation/ (a little old but still valid for snapweb) [14:04] and indeed you dont want to go to "localhost:8041/" but to your IP [14:41] Hello! [14:42] PR snapd#3490 opened: client, daemon: using oddjobstate, implement service operations [14:42] Serious request: Would it be possible to download https://public.apps.ubuntu.com/anon/download-snap/canonical/generic-amd64.canonical/generic-amd64.canonical_1.4_all.snap from another source. [14:43] Our build system is broken because of 403 permission denied. [14:43] Sorry to bother you with this old stuff, but we depend on it [14:58] Gunther_: what's giving you a 403? [14:59] the link i posted [15:00] Gunther_: but what is it? why do you want to download it? [15:00] Accessed from ubuntu-device-flash on our jenkins build server. I know this is old and deprecated stuff, but its the way we generate the image for our devices [15:01] we will have to migrate to 16.04 lts, but we did not have time for it :-/ [15:02] wow, thats a very old kernel... full of security holes i bet [15:02] (or was that a gadget ?) [15:03] I know, but we need a custom kernel module too that only works with this one .... [15:04] Gunther_: I'm afraid I don't know how to help you [15:04] * ogra isnt sure that old stuff even exists anymore [15:04] it was accessable until 3 days ago ... [15:05] i definitely cant see it in my packages dashboard (and i see "canonical-pc" and such which was created around the same time (though canonical-pc is also unpublished) [15:06] mvo, do you still see "generic-amd64" anywhere in the dashboard for the shared store account or is that gone for good ? [15:07] i actually thinnk that was a gadget [15:07] (for 15.04 images ) [15:07] Gunther_: what is the thing that's being built with this? [15:07] likes some 15.04 image ... [15:07] given ubuntu-device-flash was mentioned above [15:08] ogra: I mean what device [15:08] *likely [15:08] OS image for a measurement system. [15:08] is this something that is going to go onto shelves [15:08] that is, is this a product? [15:08] yes [15:08] ugh [15:09] so you plan a contribution to the next bigger botnet attack ? [15:09] :) [15:09] :-D [15:09] (seriously ... if that device is anywhere on a network you will likely be vulnerable) [15:09] Gunther_: does your company have some kind of commercial relationship with canonical? [15:09] Thats the master plan ;-). No this kind of device is usually not in the internet [15:10] ok, that makes it less awkward [15:10] Not that I know off. [15:10] rats [15:10] Ogra, I will forward you warning to my manager [15:11] :) [15:11] Not that I didnt warn him/them before ... [15:11] Chipaca: good question, I don't know why it takes ages. [15:11] Chipaca: I find sometimes if I kill it and run it again, it works. Maybe some upstream API issue [15:12] emoj shrug [15:12] open the window shades ... perhaps it knows your location if it can see where you are ;) [15:12] Gunther_: I'd have to ask somebody that actually knew to be sure, but I *think* ubuntu-device-flash will work less and less as ubuntu's phone backend things are turned off [15:13] Gunther_: unless it's a bug -- I'll ask, in any case [15:13] It would help a lot if it would work for additional 2 to 3 months to give us a chance to migrate [15:14] but sometime a hard cut is good too :). [15:14] i think deadline for the system-image server was july [15:14] then it will be shot down [15:15] (there was a mail to the phone ML ... nobody bothered about 15.04 snappy because thats unsupported since ages already) [15:15] (so nobody informed about the shutdown in that area) [15:16] Well thanks guys. I think I know what I will do the next weeks ....... [15:17] roadmr: so, Gunther_ here is getting a 403 when trying to get https://public.apps.ubuntu.com/anon/download-snap/canonical/generic-amd64.canonical/generic-amd64.canonical_1.4_all.snap [15:17] roadmr: AIUI it worked until ~2 days ago [15:17] Chipaca: he's just hitting that URL with curl or something? [15:18] Gunther_: ubuntu-device-flash I *think*, but ask him ;-) [15:18]