| mup | PR snapd#3477 closed: tests: fix snap create-key by restarting automatically rng-tools <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3477> | 05:57 |
|---|---|---|
| zyga | o/ | 06:04 |
| morphis | zyga: hey! | 06:45 |
| morphis | zyga: can you merge https://github.com/snapcore/snapd/pull/3470 ? | 06:45 |
| mup | PR snapd#3470: interfaces/builtin: sync connected slot and permanent slot snippet <Created by morphis> <https://github.com/snapcore/snapd/pull/3470> | 06:45 |
| mvo | 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 |
| mvo | zyga: and good morning :) - and good morning to morphis too! | 06:48 |
| morphis | mvo: morning! | 06:48 |
| mvo | zyga: I suspect this needs to go into snap-confine itself (the fixup code). slightly sad about this | 06:50 |
| morphis | mvo: can you have a look at https://github.com/snapcore/snapd/pull/3449 and merge if it is fine for you? | 06:51 |
| mup | PR snapd#3449: tests/lib: generalize RPM build support <Created by morphis> <https://github.com/snapcore/snapd/pull/3449> | 06:51 |
| mvo | morphis: sure | 06:51 |
| zyga | morphis: done | 06:52 |
| zyga | mvo: hey | 06:52 |
| mup | PR snapd#3470 closed: interfaces/builtin: sync connected slot and permanent slot snippet <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3470> | 06:52 |
| morphis | thanks! | 06:52 |
| * zyga is sitting amids boxes and unpacked things everywhere | 06:52 | |
| mvo | morphis: sure | 06:52 |
| mvo | zyga: woah, you are back? | 06:52 |
| mup | PR snapd#3449 closed: tests/lib: generalize RPM build support <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3449> | 06:53 |
| zyga | mvo: I won't be much help this week | 06:53 |
| mvo | zyga: no worries | 06:53 |
| zyga | mvo: I'm sick (cold) *and* sunburned | 06:53 |
| mvo | zyga: have you moved too? | 06:54 |
| zyga | mvo: yesterday we had a surprise party from our closest friends | 06:55 |
| zyga | mvo: no, I'm moving on Thursday | 06:55 |
| zyga | mvo: extra family members are here to help us move | 06:55 |
| zyga | mvo: we'll land in Poland on Friday at 1 AM or something like that | 06:55 |
| mvo | zyga: woah, good luck | 07:03 |
| mvo | zyga: and get well | 07:03 |
| zyga | mvo: I'll aks you for a review of the initrd test support soon | 07:05 |
| * mvo takes a short break | 07:20 | |
| morphis | mvo, zyga: if you have another min, https://github.com/snapcore/snapd/pull/3450 | 07:43 |
| mup | PR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450> | 07:43 |
| mup | PR snapd#3450 closed: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3450> | 08:21 |
| morphis | mvo: thanks! | 08:21 |
| mvo | morphis: yw! | 08:24 |
| mup | PR snapd#3487 closed: tests: reenable help test on ubuntu and debian systems <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3487> | 08:51 |
| ogra | mvo, any opinion on bug 1698107 ? | 08:51 |
| mup | Bug #1698107: Ubuntu Core images should include ntfs-3g <Snappy:New> <https://launchpad.net/bugs/1698107> | 08:51 |
| mup | PR snapd#3222 closed: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3222> | 08:54 |
| mvo | ogra: sounds reasonable, it seems like its pretty small | 08:55 |
| mup | PR snapd#3391 closed: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3391> | 08:56 |
| mvo | if someone could have a look at 3482 that would be cool, very straightforward review | 08:57 |
| morphis | mvo: yeah! | 08:57 |
| zyga | re | 08:57 |
| morphis | zyga: you wont believe it: https://github.com/snapcore/snapd/pull/3222 | 08:57 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3222> | 08:57 |
| mvo | morphis: ha! great job for getting it in :) | 08:58 |
| zyga | morphis: nice, very nice | 08:58 |
| * zyga just got rid of the 1st aquarium | 08:58 | |
| zyga | now quick breakfast and back to work | 08:58 |
| ogra | mvo, yeah.1.5MB uncompressed | 08:58 |
| * ogra will add it | 08:58 | |
| zyga | mvo: done | 09:00 |
| mup | PR snapd#3482 closed: asserts: support timestamp and optional disabled header on repair <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3482> | 09:00 |
| ogra | zyga, i see weird "cookie not found" errors on all my core boards since about last week ... is that snap-confine ? | 09:00 |
| zyga | ogra: that's the new context thing | 09:00 |
| zyga | pstolowski: ^^ | 09:01 |
| zyga | pstolowski: something you may want to know about | 09:01 |
| zyga | ogra: are those actual errors or just messages that are logged but stuff still works? | 09:01 |
| ogra | we should at least fix the error message to have a final newline if we want to chow it all the time :) | 09:01 |
| mup | PR snapd#3467 closed: interfaces/greengrass-support: add support for Amazon Greengrass as a snap <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3467> | 09:01 |
| ogra | *show | 09:01 |
| zyga | ogra: oh, indeed | 09:01 |
| mvo | 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:01 |
| ogra | 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 |
| ogra | pstolowski, ^^ | 09:02 |
| zyga | mvo: I'll do it now | 09:03 |
| zyga | mvo: thank you for spotting that | 09:03 |
| mvo | zyga: thank you, I think its pretty close | 09:03 |
| mvo | zyga: 3464 probably needs an ok from gustavo, wdyt? pr itself looks fine (assuming everything is identical just split up :) | 09:03 |
| pstolowski | 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 |
| ogra | 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:04 |
| zyga | mvo: yes, I have a informal +1 from jdstrand and once we have formal reviews it should go in | 09:05 |
| zyga | pstolowski: can you check about that newline | 09:05 |
| zyga | pstolowski: probably error is doing that, error is not used in the code much | 09:05 |
| ogra | in classic i always like: | 09:05 |
| ogra | ogra@sabrelite:~$ sudo classic | 09:05 |
| ogra | cannot open cookie file /var/lib/snapd/cookie/snap.classic(classic)ogra@sabrelite:~$ | 09:05 |
| ogra | *i always end up like | 09:05 |
| mvo | zyga: great, if there is agreement I will try to review today | 09:06 |
| pstolowski | zyga, ogra ok, will add a new line. but i don't think we use 'W:' to signify warnings anywhere? | 09:06 |
| mvo | 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 |
| zyga | pstolowski: W: ? | 09:06 |
| ogra | well ... indicate somehow that it isnt an error ... doesnt need to be "W:" | 09:06 |
| ogra | else we'll get bugs about it | 09:07 |
| mvo | 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 |
| mvo | 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 |
| pstolowski | mvo, reinstall affected snap would remove this warning | 09:07 |
| pstolowski | mvo, an alternative would be to generate all the missing cookies (for snaps installed before the feature was introduced) on snapd start | 09:08 |
| mvo | pstolowski: if its not too much hassle that sounds much better than to ask all $users to do this manually | 09:08 |
| * ogra tries ... | 09:09 | |
| mup | PR snapd#3466 closed: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3466> | 09:09 |
| zyga | pstolowski: I think you just said what has to be done | 09:09 |
| zyga | pstolowski: it's ain internal implementation deatail | 09:09 |
| zyga | pstolowski: similar in principle to security refresh | 09:10 |
| pstolowski | ogra, if you're trying the reinstall, make sure you don't have any old revisions of that snap installed | 09:10 |
| ogra | bah, you tell me now :P | 09:10 |
| pstolowski | zyga, mvo ok, i'll do that | 09:10 |
| fgimenez | 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:12 |
| ogra | 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:13 |
| ogra | ogra@sabrelite:~$ sudo classic | 09:14 |
| ogra | (classic)ogra@sabrelite:~$ | 09:14 |
| ogra | pstolowski, confirmed ... ^^^ | 09:14 |
| pstolowski | ogra, warning is gone, that is? | 09:14 |
| ogra | yeah | 09:14 |
| mvo | fgimenez: aha, so this fails when you run it against a real ubuntu-core extrenal device like a pi2? | 09:14 |
| pstolowski | ok. ill fix it | 09:14 |
| mvo | pstolowski: thank you! | 09:14 |
| popey | ogra: nice! | 09:15 |
| ogra | the nanopi is soooo cute! | 09:15 |
| mvo | zyga: I added one more comment into 3441 (hopefully trivial) | 09:15 |
| * ogra is in love :) | 09:15 | |
| zyga | mvo: looking | 09:16 |
| zyga | mvo: replied | 09:16 |
| mvo | 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:16 |
| fgimenez | mvo: yes, exactly | 09:17 |
| zyga | mvo: just running tests there | 09:18 |
| fgimenez | mvo: with kvm it should fail too, any core system using the external backend | 09:18 |
| mvo | zyga: ta | 09:18 |
| zyga | mvo: the encoding is done by the response codec I suspect, I'm not doing that myself | 09:18 |
| mvo | fgimenez: thats fine, I was just wondering why we have not seen it in spread | 09:19 |
| zyga | mvo: I could just convert it to a string, I think it's not any harm | 09:19 |
| mup | PR snapd#3474 closed: tests: fix ipv6 disable for ubuntu-core <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3474> | 09:20 |
| mvo | if 3317 gets a second review it can go in too - we may need a gustavo review for this though | 09:21 |
| fgimenez | 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 |
| fgimenez | mvo: thx! :) | 09:21 |
| popey | ogra: which one did you get? | 09:22 |
| ogra | nanopi neo | 09:22 |
| ogra | i'm pondering to also get the air | 09:23 |
| ogra | my prob is currently that you cant cross compile our aarch64 kernel and the armhf build doesnt seem to boot | 09:24 |
| popey | the air is the super tiny one, right? | 09:24 |
| ogra | they are both super tiny .. 2cmx2cm or so | 09:24 |
| ogra | the air is the one with additional wlan ... i think its a tad bit larger | 09:25 |
| ogra | (due to the wifi chip) | 09:25 |
| popey | yeah, I'm interested in the wifi enabled one | 09:26 |
| mup | PR snapd#3476 closed: snap-confine: validate SNAP_NAME against security tag <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3476> | 09:26 |
| pstolowski | mvo, thanks ^ I was waiting for tests to pass but you were faster ;) | 09:27 |
| mvo | fgimenez: another silly question - why do we see the issue with 3488 only on opensuse? | 09:27 |
| mvo | pstolowski: all the relevant ones passed ;) | 09:27 |
| ogra | popey, https://www.voelkner.de/products/940892/Nanopi-Neo-Allwinner-512-MB-ohne-Betriebssystem.html is the one i got | 09:27 |
| pstolowski | mvo, right. i didn't expect any surprises anyway, the last commit just fixed the comments | 09:27 |
| mvo | 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 |
| popey | very cute | 09:27 |
| ogra | thats the air https://www.voelkner.de/products/966493/Nanopi-Neo-Air-512-MB-ohne-Betriebssystem-microSD-Bluetooth-Micro-USB-OTG.html | 09:28 |
| Vamsi | Is it possible to install snaps on an ubuntu host from my phone? | 09:28 |
| mvo | pstolowski: on the bright side, we are down to 27 PRs | 09:28 |
| ogra | Vamsi, you could install snapweb ... or use a terminal and ssh on your phone | 09:29 |
| mup | PR snapd#3445 closed: tests: add linode-sru backend <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3445> | 09:29 |
| zyga | Vamsi: we have a REST API for snapd but it is not yet exposed | 09:29 |
| pstolowski | mvo, good stuff | 09:30 |
| mup | PR snapd#3485 closed: tests: fix nightly suite <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3485> | 09:31 |
| ogra | 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:32 |
| fgimenez | 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 |
| ppisati | ogra: sounds like you are trying to compile a recent kernel with an old toolchain | 09:34 |
| ogra | ppisati, yeah, the nanopi and orangepi are only supported in 4.11 onwards | 09:35 |
| ogra | 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:35 |
| ppisati | ogra: uhm, that should be fine | 09:36 |
| ppisati | ogra: what's the error? | 09:36 |
| ogra | something about "no support for -fstack-protector-strong" | 09:37 |
| ogra | i dont have the exact error handy atm | 09:37 |
| zyga | mvo: look at 3441 again please | 09:39 |
| zyga | pedronis: ^ as well please | 09:47 |
| pedronis | mvo: zyga: thanks for merging the repair PR, I updated the forum topic to reflect these small tweaks | 09:56 |
| mup | PR snapd#3488 closed: tests: prevent quoting error on opensuse <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3488> | 10:00 |
| ogra | ppisati, http://paste.ubuntu.com/24898399/ eher is the exact error | 10:03 |
| ogra | ppisati, the command i'm running is " ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- fakeroot debian/rules binary-headers binary-generic binary-perarch" | 10:06 |
| ppisati | ogra: but there you are actually compiling an amd64 kernel | 10:07 |
| ogra | ppisati, huh ? | 10:07 |
| ogra | is CROSS_COMPILE not respected anymore ? | 10:07 |
| ppisati | ogra: that's what i usually use | 10:08 |
| ppisati | ogra: 'export ARCH=arm64; export $(dpkg-architecture -aarm64); export CROSS_COMPILE=aarch64-linux-gnu-' | 10:08 |
| ppisati | and then 'fdrc etcetc' | 10:08 |
| * ogra slaps forehead ... | 10:09 | |
| ogra | export $(dpkg-architecture -aarm64) .... | 10:09 |
| ogra | sorry for the noise ... building now | 10:09 |
| mvo | jdstrand: good news, the seccomp-bpf PR is green! but still quite a few comments to address | 10:09 |
| ppisati | ogra: np | 10:09 |
| mvo | pedronis: thank you! | 10:10 |
| ogra | ppisati, oh, and FYI ... i couldnt get armhf generic to boot on my nanopi or orangepi ... (thats why i try arm64 now) | 10:11 |
| ppisati | ogra: 4.11? | 10:13 |
| ogra | yep | 10:13 |
| ppisati | ogra: ouch | 10:13 |
| ogra | i get "Loading kernel ..." and thats it | 10:13 |
| ppisati | ogra: do you have uboot running? you could dump the location of the printk buffer | 10:14 |
| ogra | how do i do that | 10:14 |
| ogra | 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 |
| ppisati | ogra: http://elinux.org/Debugging_by_printing | 10:15 |
| * ogra reads | 10:16 | |
| ppisati | ogra: after the conversion do DT, i never got earlyprintk to work | 10:16 |
| ogra | ah | 10:16 |
| ogra | k | 10:16 |
| ppisati | ogra: but i didn't try hard, honestly | 10:16 |
| ogra | i'll resort to the printk hacker if arm64 doesnt work either | 10:17 |
| ogra | *hack | 10:17 |
| ogra | seemingly the allwinner toolchains are all aarch64 ... so i have some hope that an arm64 build might work better | 10:17 |
| mup | PR snapd#3441 closed: cmd,daemon: add debug command for displaying the base policy <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3441> | 10:23 |
| * zyga -> break | 10:44 | |
| ogra | bah crap ... | 10:56 |
| ogra | ls unpack/lib/firmware/4.11.0-6-generic/device-tree/allwinner/ | 10:56 |
| ogra | sun50i-a64-bananapi-m64.dtb sun50i-a64-pine64.dtb sun50i-a64-pine64-plus.dtb | 10:56 |
| ogra | not so helpful :/ | 10:56 |
| kalikiana_ | 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:25 |
| Chipaca | kalikiana_: dirs.SnapBlobDir? | 11:30 |
| Chipaca | is that what you mean? | 11:30 |
| zyga | kalikiana_: it exists on all systems AFAIK | 11:31 |
| Chipaca | kalikiana_: what do you need it for? | 11:31 |
| Son_Goku | it should exist everywhere | 11:31 |
| Son_Goku | it's the snap download dir | 11:31 |
| kalikiana_ | Chipaca: This doesn't have SnapBlobDir https://github.com/snapcore/snapd/wiki/REST-API | 11:32 |
| kalikiana_ | Chipaca: I'm injecting snaps from the host into a LXD container | 11:32 |
| kalikiana_ | I'd like to know that this can work on different snapd systems other than Ubuntu | 11:32 |
| kalikiana_ | Son_Goku: Is that documented anywhere? | 11:33 |
| Son_Goku | the only location that differs is /var/lib/snapd/snap vs /snap | 11:34 |
| Son_Goku | Debian and Ubuntu and openSUSE use /snap | 11:34 |
| Son_Goku | Fedora and Arch use /var/lib/snapd/snap | 11:34 |
| * zyga feels worse and breaks | 11:35 | |
| zyga | mvo: I may miss standup, tomorrow should be a saner day | 11:36 |
| ogra | koza, how is the humminngboard ? | 11:36 |
| === rumble is now known as grumble | ||
| morphis | mvo, zyga: next one is ready: https://github.com/snapcore/snapd/pull/3455 | 11:45 |
| mup | PR snapd#3455: tests/main: use pkgdb function in more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3455> | 11:45 |
| * Chipaca ~> lunch | 11:49 | |
| niemeyer | Morning all | 12:05 |
| Vamsi | zyga: Thank you | 12:06 |
| Vamsi | ogra: Thank you | 12:06 |
| === ahasenac` is now known as ahasenack | ||
| === ahasenack is now known as Guest20728 | ||
| pstolowski | good morning niemeyer ! | 12:12 |
| pstolowski | 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:16 |
| pedronis | pstolowski: the upgrade tests should also test it, but we do have some tests that delete state.json at least | 12:20 |
| pedronis | or play with other /var/lib/snapd stuff | 12:20 |
| mvo | pstolowski: was about to suggest the upgrade suite | 12:20 |
| pstolowski | pedronis, ok. if I delete state.json, doesn't this make snapd unaware of installed snaps? | 12:20 |
| pedronis | pstolowski: sorry, that wasn't my point, just sayign we do play with state.json sometimes | 12:21 |
| pedronis | don't remember punctual edits | 12:21 |
| pstolowski | pedronis, ah, I see | 12:21 |
| pedronis | but probably because we didn't need them | 12:21 |
| pstolowski | pedronis, I see | 12:21 |
| pedronis | pstolowski: but as mvo said, the upgrade tests should grow some checks about this as well | 12:22 |
| pcercuei | 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 |
| pedronis | pstolowski: tests/upgrade/basic/task.yaml | 12:22 |
| pcercuei | so I guess that means I have two bug reports now :) | 12:22 |
| cjwatson | pcercuei: what's the error? | 12:23 |
| cjwatson | pcercuei: (with Launchpad login) | 12:23 |
| pstolowski | pedronis, mvo thanks, looking | 12:23 |
| pcercuei | 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 |
| cjwatson | Thanks, the OOPS ID was all I needed. | 12:24 |
| cjwatson | I'll chase that up for you. | 12:25 |
| pcercuei | thanks! | 12:26 |
| pcercuei | the actual bug I wanted to report: running latest 'snapcraft' on my Debian ends up with this: | 12:27 |
| pcercuei | "dpkg-query: error: --listfiles needs a valid package name but 'libc6' is not: ambiguous package name 'libc6' with more than one installed instance" | 12:27 |
| pcercuei | and that's because "dpkg -L libc6" is confused, because I have i686 and x86_64 versions | 12:28 |
| mvo | 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 |
| mvo | pcercuei: thanks a lot for finding this | 12:31 |
| pcercuei | mvo: should I still create a ticket? | 12:32 |
| mvo | pcercuei: yes please, this will make tracking easier | 12:41 |
| koza | 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:42 |
| ogra | 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:43 |
| ogra | who at linaro did you talk to (do we have any hummingboard specialist i could ping in #linaro ?) | 12:44 |
| koza | ogra, whatever has been done you might have the only working hummingboard as of today ;-) | 12:44 |
| ogra | well, you should at least get some output on serial | 12:44 |
| ogra | koza, did you try any other image ? | 12:44 |
| koza | ogra, serial is dead silent; yeah I have tried the debian image | 12:45 |
| ogra | same issue ? | 12:45 |
| koza | ogra, just a red led | 12:46 |
| ogra | bah | 12:46 |
| ogra | koza, another thing ... are you still responsible for bluetooth ? we need to get the Pi3 stuff going at some point | 12:47 |
| ogra | (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:48 |
| koza | 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:50 |
| ogra | koza, ok, no hurry, just wanted to know if thats still in your set of responsibilities (wasnt sure after the re-org) | 12:52 |
| fgimenez | 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:38 |
| fgimenez | and has a good list of them | 13:40 |
| niemeyer | 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 |
| ogra | and as a bonus ... we do have a kicad snap in the store ;) | 13:40 |
| Chipaca | popey: why does wethr sometimes take ages to 'detect my location'? | 13:43 |
| fgimenez | 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 |
| niemeyer | fgimenez: I think we should find out how many boards have been manufactured with those plans so far, and whether they actually work | 13:45 |
| jdstrand | mvo: nice! :) | 13:46 |
| fgimenez | niemeyer: ok, i'll ask around, will keep you posted | 13:47 |
| niemeyer | fgimenez: Thanks! | 13:47 |
| mup | PR snapcraft#1368 opened: cli: get_project_options must not discard kwargs <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1368> | 13:51 |
| Vamsi | ogra: snapweb is meant only for Ubuntu right? Is it possible to do so even from an Android phone or iOS phones? | 13:53 |
| ogra | Vamsi, snapweb is a web UI for the snapd running on the other machine | 13:56 |
| ogra | you just open it in your phone browser | 13:56 |
| ogra | (any browser should work ... https://<ip of the machine running snapd>:4200/ | 13:57 |
| Vamsi | 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? | 14:00 |
| === Guest20728 is now known as ahasenack | ||
| ogra | 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:02 |
| ogra | and indeed you dont want to go to "localhost:8041/" but to your IP | 14:04 |
| Gunther_ | Hello! | 14:41 |
| mup | PR snapd#3490 opened: client, daemon: using oddjobstate, implement service operations <Created by chipaca> <https://github.com/snapcore/snapd/pull/3490> | 14:42 |
| Gunther_ | 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:42 |
| Gunther_ | Our build system is broken because of 403 permission denied. | 14:43 |
| Gunther_ | Sorry to bother you with this old stuff, but we depend on it | 14:43 |
| Chipaca | Gunther_: what's giving you a 403? | 14:58 |
| Gunther_ | the link i posted | 14:59 |
| Chipaca | Gunther_: but what is it? why do you want to download it? | 15:00 |
| Gunther_ | 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:00 |
| Gunther_ | we will have to migrate to 16.04 lts, but we did not have time for it :-/ | 15:01 |
| ogra | wow, thats a very old kernel... full of security holes i bet | 15:02 |
| ogra | (or was that a gadget ?) | 15:02 |
| Gunther_ | I know, but we need a custom kernel module too that only works with this one .... | 15:03 |
| Chipaca | 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 | |
| Gunther_ | it was accessable until 3 days ago ... | 15:04 |
| ogra | 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:05 |
| ogra | mvo, do you still see "generic-amd64" anywhere in the dashboard for the shared store account or is that gone for good ? | 15:06 |
| ogra | i actually thinnk that was a gadget | 15:07 |
| ogra | (for 15.04 images ) | 15:07 |
| Chipaca | Gunther_: what is the thing that's being built with this? | 15:07 |
| ogra | likes some 15.04 image ... | 15:07 |
| ogra | given ubuntu-device-flash was mentioned above | 15:07 |
| Chipaca | ogra: I mean what device | 15:08 |
| ogra | *likely | 15:08 |
| Gunther_ | OS image for a measurement system. | 15:08 |
| Chipaca | is this something that is going to go onto shelves | 15:08 |
| Chipaca | that is, is this a product? | 15:08 |
| Gunther_ | yes | 15:08 |
| ogra | ugh | 15:08 |
| ogra | so you plan a contribution to the next bigger botnet attack ? | 15:09 |
| ogra | :) | 15:09 |
| Gunther_ | :-D | 15:09 |
| ogra | (seriously ... if that device is anywhere on a network you will likely be vulnerable) | 15:09 |
| Chipaca | Gunther_: does your company have some kind of commercial relationship with canonical? | 15:09 |
| Gunther_ | Thats the master plan ;-). No this kind of device is usually not in the internet | 15:09 |
| ogra | ok, that makes it less awkward | 15:10 |
| Gunther_ | Not that I know off. | 15:10 |
| Chipaca | rats | 15:10 |
| Gunther_ | Ogra, I will forward you warning to my manager | 15:10 |
| ogra | :) | 15:11 |
| Gunther_ | Not that I didnt warn him/them before ... | 15:11 |
| popey | Chipaca: good question, I don't know why it takes ages. | 15:11 |
| popey | Chipaca: I find sometimes if I kill it and run it again, it works. Maybe some upstream API issue | 15:11 |
| popey | emoj shrug | 15:12 |
| ogra | open the window shades ... perhaps it knows your location if it can see where you are ;) | 15:12 |
| Chipaca | 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:12 |
| Chipaca | Gunther_: unless it's a bug -- I'll ask, in any case | 15:13 |
| Gunther_ | It would help a lot if it would work for additional 2 to 3 months to give us a chance to migrate | 15:13 |
| Gunther_ | but sometime a hard cut is good too :). | 15:14 |
| ogra | i think deadline for the system-image server was july | 15:14 |
| ogra | then it will be shot down | 15:14 |
| ogra | (there was a mail to the phone ML ... nobody bothered about 15.04 snappy because thats unsupported since ages already) | 15:15 |
| ogra | (so nobody informed about the shutdown in that area) | 15:15 |
| Gunther_ | Well thanks guys. I think I know what I will do the next weeks ....... | 15:16 |
| Chipaca | 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 |
| Chipaca | roadmr: AIUI it worked until ~2 days ago | 15:17 |
| roadmr | Chipaca: he's just hitting that URL with curl or something? | 15:17 |
| Chipaca | Gunther_: ubuntu-device-flash I *think*, but ask him ;-) | 15:18 |
| Gunther_ | yes this is. but i also get the 403 ith chrome | 15:18 |
| Chipaca | roadmr: ^ sorry, meant to tell you to ask Gunther_ and got my wires crossed | 15:18 |
| roadmr | ok | 15:18 |
| * ogra notes that Gunther_ opened a forum task too at https://forum.snapcraft.io/t/old-generic-amd64-canonical-image-403-error/1047 | 15:23 | |
| === pstolowski is now known as pstolowski|erran | ||
| morphis | mvo: can you merge https://github.com/snapcore/snapd/pull/3455 ? | 15:49 |
| mup | PR snapd#3455: tests/main: use pkgdb function in more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3455> | 15:49 |
| mvo | morphis: yes, looking good | 15:51 |
| mup | PR snapd#3455 closed: tests/main: use pkgdb function in more test cases <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3455> | 15:51 |
| morphis | thanks | 15:51 |
| mvo | jdstrand: I addressed all the seccomp-bpf PR comments, thanks a lot for your careful review. please do let me know if there is anything I might have overlooked. if you are happy, you can pass it to gustavo for a second review. we need to backport it to the 2.26 branch too, but I will take care of this (it is probably going to be quite a bit of work :/) | 15:54 |
| mvo | thank you morphis | 15:54 |
| morphis | zyga: there? | 15:55 |
| niemeyer | mvo: Out of curiosity, why will the 2.26 merge be problematic? | 15:56 |
| jdstrand | mvo: I'll take a look at it after my next meeting | 15:57 |
| jdstrand | mvo: thanks for addressing all that! I saw your comments on the testsuite. I'll give it some more thought | 15:58 |
| mvo | niemeyer: mostly because the branch has a lot of commits by now and probably some conflicts with 2.26, but I have not invesitgated the details yet, will check tomorrow morning | 16:01 |
| mvo | jdstrand: thanks a lot, happy about suggestion how to make this tessuite easier to read | 16:01 |
| === pstolowski|erran is now known as pstolowski | ||
| Chipaca | niemeyer: any objection to moving the logic for 'snap tasks --last foo' into the daemon? | 16:29 |
| pedronis | Chipaca: any particular reasons? (though I suppose it's saner) | 16:33 |
| Chipaca | pedronis: it's a little saner, and I'm wanting to add --last foo to two other commands (abort and watch) | 16:33 |
| pedronis | ah | 16:34 |
| Chipaca | using them in anger for services made it clear to me it's needed | 16:34 |
| pedronis | yes, I think it's saner | 16:34 |
| pedronis | (because of needing to know about task names) | 16:34 |
| pedronis | though the reverse is true, needing to know about commands, but commands change less than task names I suppose (though even the latter are kind of stable) | 16:35 |
| Chipaca | OTOH... watch itself might not benefit too much from this | 16:36 |
| Chipaca | bah, easy enough to fix i guess :-) but need to make it a little chummy | 16:37 |
| Chipaca | pedronis: i had thought i'd do the translation from commands to changes on the client though | 16:37 |
| pedronis | mmh | 16:38 |
| Chipaca | OTO²H i could just reuse the existing --last impl, and suggest moving it in-server once that is done | 16:38 |
| Chipaca | same work, maybe clearer motiviation this way | 16:38 |
| niemeyer | Chipaca: No objections | 16:45 |
| niemeyer | Chipaca: snapd#3480 reviewed btw.. just that one suggestion for the package name | 16:47 |
| mup | PR snapd#3480: overlord/oddjobstate: new package for running commands as tasks <Created by chipaca> <https://github.com/snapcore/snapd/pull/3480> | 16:47 |
| === Guest24249 is now known as ahayzen | ||
| === ahayzen is now known as Guest14311 | ||
| === Guest14311 is now known as ahayzen | ||
| mup | PR snapd#3491 opened: snapd: generate snap cookies on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/3491> | 16:55 |
| pstolowski | ogra, ^ this should fix the warning from snap-confine we discussed this morning | 16:55 |
| * ogra hugs pstolowski | 16:55 | |
| roadmr | Gunther_: are you around? | 16:59 |
| ogra | roadmr, https://forum.snapcraft.io/t/old-generic-amd64-canonical-image-403-error/1047 (if he isnt anymore) | 16:59 |
| roadmr | ogra: thanks | 16:59 |
| mup | PR snapcraft#1369 opened: Handle I/O errors in os.link (LP: #1689956) <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/1369> | 17:06 |
| Chipaca | niemeyer: two questions for you: any reason we don't make "change" an alias for "tasks" instead of its current hidden snowflakiness? (makes maintenance harder this way) | 17:12 |
| Chipaca | niemeyer: 2. should i just alias search to find | 17:12 |
| niemeyer | Chipaca: +1 on both counts | 17:13 |
| Chipaca | ok | 17:13 |
| niemeyer | Chipaca: I can't possibly see any other meaning for search that isn't the same as find without it being a reason for LOLs | 17:14 |
| niemeyer | Chipaca: We could also tell people that the command is find rather than search, but that's the sort of thing that seems unnecessarily pedantic.. if we know what the user means, we can just do it | 17:15 |
| Chipaca | niemeyer: cmdstate seems fine to me | 17:31 |
| mup | PR snapd#3492 opened: `--last` for abort and watch, and aliases (search→find, change→tasks) <Created by chipaca> <https://github.com/snapcore/snapd/pull/3492> | 17:32 |
| Chipaca | ruh roh | 17:43 |
| Chipaca | niemeyer: is everything ok in linode-land? | 17:43 |
| niemeyer | Chipaca: More auth issues? | 17:43 |
| Chipaca | niemeyer: https://travis-ci.org/snapcore/snapd/builds/244618152 | 17:43 |
| Chipaca | (spoiler: yes) | 17:44 |
| niemeyer | There are no open tickets ATM | 17:44 |
| niemeyer | Let me ping them | 17:45 |
| Chipaca | niemeyer: otoh https://travis-ci.org/snapcore/snapd/builds/244621777 seems to be proceeding fine | 17:46 |
| niemeyer | I've opened a ticket | 17:47 |
| Chipaca | “dear gustavo, plz less hammering of the api, kthxbye” | 17:47 |
| niemeyer | Probably | 17:48 |
| Chipaca | :-p | 17:48 |
| Chipaca | ok i'm going to eod about here | 17:49 |
| Chipaca | if i stay i'm going to either (a) melt, or (b) get dragged into working on the go patch thing until it's too late to do anything more | 17:49 |
| Chipaca | o/ | 17:49 |
| === chihchun is now known as chihchun_afk | ||
| === jaggz- is now known as jaggz | ||
| === Beret- is now known as Beret | ||
| === souther_ is now known as souther | ||
| === thomi_ is now known as thomi | ||
| === Tribaal_ is now known as Tribaal | ||
| === cargonza_ is now known as cargonza | ||
| === ulkesh_ is now known as ulkesh | ||
| niemeyer | cachio: They've dropped a suspect IP from their firewall | 18:32 |
| niemeyer | cachio: Please drop me a note if you see the auth issue again | 18:32 |
| cachio | niemeyer, ok | 18:58 |
| cachio | niemeyer, could you please take a look through the console to the machine (Spread-26): 45.79.159.108 ? | 19:15 |
| cachio | it did not start anymore after the reboot | 19:15 |
| niemeyer | cachio: Looking | 19:15 |
| niemeyer | cachio: Spread-26 is powered off and unallocated | 19:16 |
| cachio | niemeyer, is it any way to recover the disk? | 19:18 |
| cachio | niemeyer, it was discarded before I told you | 19:19 |
| cachio | niemeyer, I'll need to use reuse next time | 19:19 |
| niemeyer | cachio: Not just the disk.. the issue is also having the system powered off.. the console is gone at that point | 19:24 |
| cachio | niemeyer, ok | 19:25 |
| mvo | jdstrand: thanks a bunch for the extra review, when you have a moment, a reply to https://github.com/snapcore/snapd/pull/3431#discussion_r122786010 would be great, I am working through the other comments now (good stuff btw) | 19:27 |
| mup | PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431> | 19:27 |
| azubieta | Hello Guys! I'm a developer of NXOS (http://nxos.org/), whish aims to be a fully snap based linux distribution. Currently we are attempting to port some of the kde plasma apps to snaps in order to make them avalable from our "software center". But we are having serious issues with the connections betwen our snaps and the kf5-frameworks snap. We already get in touch with the kf5-frameworks snaps and he comment us that the problem might be a restriction | 19:28 |
| azubieta | imposed by snapd at the time of the connectin. Would you please assist us in this. Thanks | 19:28 |
| mvo | hm, 4min ago I got "authentication failed" for all the allocated spread systems | 19:28 |
| mvo | fwiw https://travis-ci.org/snapcore/snapd/builds/244657462?utm_source=github_status&utm_medium=notification | 19:29 |
| mvo | cachio: -^ | 19:30 |
| cachio | mvo, thanks | 19:36 |
| cachio | niemeyer, mvo reported that 13 mins ago https://travis-ci.org/snapcore/snapd/builds/244657462?utm_source=github_status&utm_medium=notification | 19:36 |
| cachio | niemeyer, authentication failed again | 19:37 |
| niemeyer | cachio: Thanks | 19:37 |
| jdstrand | mvo: I commented | 19:52 |
| mvo | jdstrand: for some reason I don't seen an update for the question about `setpriority 1\n2`. maybe GH is slow today? | 19:57 |
| niemeyer | cachio: Can you please add that at the top of our travis.yaml, so we can tell the public IP of the build system? | 20:03 |
| niemeyer | cachio: curl -s -o - http://canihazip.com/s | 20:03 |
| cachio | niemeyer, sure | 20:04 |
| niemeyer | cachio: Travis provides a pretty unhelpful "hostname" at the top of the log, but I haven't managed to map that to a real IP yet | 20:04 |
| niemeyer | Need to figure that out so i have some substance to present to Linode | 20:04 |
| cachio | niemeyer, you mean in the script? | 20:06 |
| cachio | section | 20:06 |
| niemeyer | cachio: Or install, I suppose? What's the first section to run? | 20:07 |
| jdstrand | mvo: gh has been weird with this pr for me too. let me get you the answer | 20:07 |
| mvo | jdstrand: it finally appeared | 20:08 |
| jdstrand | mvo: https://github.com/snapcore/snapd/pull/3431#discussion_r122806724 | 20:08 |
| mup | PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431> | 20:08 |
| jdstrand | heh | 20:08 |
| mvo | jdstrand: I think we are driving it to its limits :) | 20:08 |
| jdstrand | mvo: seems so :) | 20:08 |
| cachio | niemeyer, ok | 20:09 |
| jdstrand | mvo: actually I pasted you an answer to something else. anyway, I'm answering stuff :) | 20:10 |
| cachio | niemeyer, PR 3493 | 20:12 |
| mup | PR snapd#3493 opened: tests: showing the ip in the .travis.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3493> | 20:12 |
| cachio | niemeyer, 35.188.99.113 | 20:15 |
| mvo | jdstrand: I also replied to your question about seccomp/profiles vs seccomp/bpf | 20:16 |
| niemeyer | cachio: Oh, already? | 20:16 |
| niemeyer | cachio: That's from a failure? | 20:16 |
| cachio | but, no, for the PR run | 20:16 |
| cachio | are you going to merge it | 20:16 |
| cachio | ? | 20:16 |
| niemeyer | cachio: Ah, cool.. yeah, let's merge it once it goes green so we can get the IP for a failure case | 20:17 |
| cachio | niemeyer, or we should re_run it until we are able to reproduce the error? | 20:17 |
| jdstrand | mvo: yeah, replaying | 20:17 |
| jdstrand | replying | 20:17 |
| niemeyer | cachio: We should probably have added an || true or something similar so we don't get failures out of that line.. but we can do that later | 20:17 |
| cachio | niemeyer, echo ip: $(curl -s -o - http://canihazip.com/s) || true | 20:18 |
| cachio | I can make the change right now | 20:18 |
| mvo | jdstrand: ta | 20:19 |
| jdstrand | mvo: what happens to /var/lib/snapd/seccomp/profiles once the last version of core that uses it is garbage collected? | 20:19 |
| mvo | jdstrand: currently nothing, but we can add cleanup code | 20:19 |
| niemeyer | cachio: It's okay, let's try to get it in without yet another round | 20:19 |
| jdstrand | I meant the plan going forward | 20:19 |
| niemeyer | cachio: We can polish it later | 20:19 |
| cachio | niemeyer, sure | 20:20 |
| niemeyer | This one will already take ~30 mins | 20:20 |
| jdstrand | mvo: this makes documentation and auditing icky. 'if you are using snapd < 2.26, then look here, otherwise look there' | 20:20 |
| jdstrand | I was thinking the bpf stuff would fix that, but it only does going forward from 2.26 | 20:21 |
| jdstrand | also, images that start with 2.26+ end up with /var/lib/snapd/seccomp/bpf which doesn't align with /var/lib/snapd/apparmor/profiles | 20:21 |
| jdstrand | mvo: maybe /var/lib/snapd/seccomp/profiles.bpf and don't name the input files with .in but do name the bpf files with .bpf? | 20:23 |
| mvo | jdstrand: sounds good | 20:23 |
| mvo | jdstrand: I can tweak that, I like that suggestion | 20:23 |
| jdstrand | eg, snap-seccomp /var/lib/snapd/seccomp/profiles.bpf/snap.foo.bar /var/lib/snapd/seccomp/profiles.bpf/snap.foo.bar.bpf | 20:23 |
| jdstrand | at least it feels similar to what we currently have and it is mostly discoverable | 20:24 |
| mvo | jdstrand: sounds good, could you please comment in the PR? I will work on that first thing in the morning. | 20:25 |
| jdstrand | mvo: https://github.com/snapcore/snapd/pull/3431#discussion_r122815064 | 20:27 |
| mup | PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431> | 20:27 |
| jdstrand | mvo: (I was :) | 20:27 |
| mvo | jdstrand: great, thanks a lot. I will call it a day now but will read the PR comment in my morning and work on the dir name change then | 20:30 |
| jdstrand | mvo: ok. thanks for getting to all these things! we are getting closer and closer :) | 20:30 |
| codeplug_ | Hi, is anyone familiar with using bluez in the Snappy Ubuntu Core environment? I'm trying to understand why this bluez stack doesn't come with gatttool... | 20:31 |
| mvo | jdstrand: indeed, it feels good | 20:34 |
| * mvo waves | 20:34 | |
| mup | PR snapd#3493 closed: tests: showing the ip in the .travis.yaml <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3493> | 20:43 |
| cachio | niemeyer, the automatic restart of the rng-tools service seems to not be enough | 21:01 |
| cachio | niemeyer, https://travis-ci.org/snapcore/snapd/builds/244673127#L3493 | 21:01 |
| cachio | entropy = 138 | 21:01 |
| === JanC_ is now known as JanC | ||
| codeplug1 | ??? | 21:28 |
| Chipaca | codeplug1: !!!! | 21:31 |
| Chipaca | niemeyer: more auth issues: https://travis-ci.org/snapcore/snapd/builds/244700389 | 21:31 |
| mup | PR core-build#14 opened: initramfs/testing: add unit tests for initrd scripts <Created by zyga> <https://github.com/snapcore/core-build/pull/14> | 21:32 |
| azubieta | https://forum.snapcraft.io/t/issues-building-kde-plasma-applications-snaps-for-nxos/ | 21:41 |
| niemeyer | Chipaca: Thanks, and this time we have the source IP | 21:49 |
| niemeyer | cachio: We'll need to find out what's actually broken there then | 21:50 |
| cachio | niemeyer, yes, working on that | 21:51 |
| niemeyer | I'm running out of ideas.. Linode is apparently getting requests without the key in some cases, but on the Travis end there's no apparent distinction between the calls :( | 22:52 |
| niemeyer | The failing and the working setup look pretty alike | 22:53 |
| mup | PR snapcraft#1370 opened: integrations: add the snapcraft Dockerfile <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1370> | 23:01 |
| niemeyer | and now everything seems to work fine.. | 23:05 |
| Chipaca | niemeyer: so... maybe it's not linode? https://travis-ci.org/snapcore/snapd/builds/244733765 | 23:33 |
| niemeyer | Chipaca: Yeah, I don't think it is | 23:34 |
| niemeyer | Chipaca: It feels like something out of our control is running concurrently with the usual scripts | 23:34 |
| niemeyer | Chipaca: Perhaps it's not a coincidence that Travis is working on their images | 23:34 |
| Chipaca | niemeyer: should I switch the 'beta' thing on to see if it improves at all? | 23:35 |
| Chipaca | 'group: edge' i think it is actually | 23:35 |
| niemeyer | Chipaca: Worth a shot, although it's awkward that it's breaking on what in theory is the old stuff | 23:35 |
| * Chipaca nods | 23:35 | |
| niemeyer | Chipaca: But this is software, soooo | 23:35 |
| Chipaca | and not consistently either | 23:35 |
| Chipaca | I'll give it one retry | 23:36 |
| Chipaca | niemeyer: no difference | 23:44 |
| Chipaca | reverting the change | 23:44 |
| * Chipaca gives up and goes back to trying to sleep | 23:48 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!