| kyrofa | sergiusens, snapcraft#1717 armhf had network problems during one of the ROS tests... so that won't tell us anything. Waiting on arm64 | 00:09 |
|---|---|---|
| mup | PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 00:09 |
| * ikey is doing his last clean local builds ready for upload :3 | 00:41 | |
| ikey | so uhm | 01:03 |
| ikey | Pushing solus-runtime-gaming_0.0.0_amd64.snap [===========================] 100% | 01:03 |
| ikey | [1] 9686 segmentation fault snapcraft push solus-runtime-gaming_0.0.0_amd64.snap | 01:03 |
| ikey | idk what happened | 01:03 |
| ikey | processing went kersplat | 01:03 |
| ikey | and i believe thats because it never expected to need a manual review | 01:04 |
| sergiusens | ikey it is python, I don't expect a segmentation fault but a traceback instead | 01:04 |
| ikey | python is special | 01:04 |
| sergiusens | this is much worse of a thing to track down I fear | 01:04 |
| ikey | yeah | 01:05 |
| sergiusens | I will look into it | 01:05 |
| ikey | so who manually reviews snaps? :D | 01:05 |
| sergiusens | ikey among them is jdstrand | 01:05 |
| ikey | oh ok | 01:05 |
| ikey | my assumption is i can't actually upload my lsi snap until the base snap is in as it depends on it | 01:06 |
| sergiusens | ikey so the one that failed to push is the one with a base decl? | 01:10 |
| ikey | yeah | 01:10 |
| ikey | (NEEDS REVIEW) type 'base' not allowed lint-snap-v2_snap_type_redflag | 01:10 |
| ikey | 0 Warnings | 01:10 |
| ikey | 22 Passes | 01:10 |
| sergiusens | kyrofa the arm64 test might take for ever and ever | 01:11 |
| ikey | full error: https://hastebin.com/raw/vayobosulu | 01:11 |
| ikey | setuid binaries won't be usable inside there anyway | 01:11 |
| ikey | it also dislikes symlinks :p | 01:11 |
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| * ikey will nuke them for the next build to clean it up | 01:14 | |
| ikey | wtf i cant use bin in my snap | 01:23 |
| ikey | bin/linux-steam-integration.exec glxgears does not exist lint-snap-v2_command (glxgears) | 01:29 |
| ikey | ok the review system is dumb. | 01:29 |
| ikey | like clinically stupid | 01:30 |
| ikey | command: bin/linux-steam-integration.exec linux-steam-integration.settings | 01:31 |
| ikey | it won't accept that | 01:31 |
| * ikey is unable to upload snaps at all, woo. | 01:33 | |
| * ikey made a workaround ^^ | 01:54 | |
| sergiusens | ikey we in snapcraft wrap those in scripts | 01:55 |
| sergiusens | the `command` | 01:55 |
| ikey | yeah i just made it do the same | 01:55 |
| ikey | https://github.com/solus-project/runtime-snaps/commit/3cdf7f2d9f06187a76e26465551f470561be3de2 | 01:55 |
| ikey | "tada" | 01:55 |
| sergiusens | I don't think that review tool is geared toward reviewing base snaps | 01:55 |
| ikey | oh that rejection was for LSI itself | 01:56 |
| ikey | ive now got LSI actually uploaded and accepted | 01:56 |
| ikey | but yeah it hates base snaps and forbids them | 01:56 |
| ikey | so the solus-runtime-gaming is still pending | 01:56 |
| ikey | ive cleaned up my base runtime for those other errors so im actually going to abandon the initial review and upload the cleaner guy | 01:57 |
| * ikey is totally OCD | 01:57 | |
| ikey | there, rejected | 01:57 |
| * ikey builds the new clean guy | 01:58 | |
| sergiusens | kyrofa your arm64 adt run started! | 01:58 |
| mup | PR snapcraft#1736 closed: recording: pass the build info flag to the container <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1736> | 01:58 |
| kyrofa | sergiusens, yeah you're right... still waiting on that :( | 01:58 |
| kyrofa | Oh! Haha | 01:58 |
| kyrofa | Well that's good. Another four hours... | 01:58 |
| sergiusens | kyrofa I am going to go to bed though or I will be toast tomorrow | 01:59 |
| kyrofa | sergiusens, yeah not worth it | 01:59 |
| kyrofa | We'll pick it up again in the morning. Almost there | 01:59 |
| sergiusens | kyrofa I might wake up super early though | 01:59 |
| sergiusens | I forgot I need to prepare my presentation for pyconar this weekend too | 02:00 |
| sergiusens | oh, and Monday is a holiday | 02:00 |
| sergiusens | so many things to do, so little time | 02:00 |
| kyrofa | Yeah I hear you! | 02:00 |
| kyrofa | sergiusens, sleep well, talk tomorrow :) | 02:00 |
| ikey | o wat dashboard has download stats | 02:00 |
| ikey | i bet i could build a tiny bit of machinery for these lsi bits and have it automate a lot of stuff like the wrappers snapcraft style.. | 02:02 |
| * ikey creates more work for himself | 02:03 | |
| ikey | ok linux-steam-integration rev3 is on edge now | 02:08 |
| ikey | devmode | 02:08 |
| mup | PR snapcraft#1732 closed: tests: dotnet only works on 16.04 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1732> | 02:13 |
| sergiusens | kyrofa I think you looked at the execution location incorrectly snapcraft#1717 armhf -> https://pastebin.ubuntu.com/25964709/ this might be a thing for elopio | 02:14 |
| mup | PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 02:14 |
| === chihchun_afk is now known as chihchun | ||
| ikey | i fixed the remaining issues with the solus-runtime-gaming, has 0 warnings now | 02:34 |
| ikey | just 1 error | 02:34 |
| ikey | its a base snap | 02:34 |
| ikey | and it requested review by itself | 02:34 |
| elopio | kyrofa: sergiusens: found it: https://github.com/snapcore/snapcraft/pull/1717/commits/b1768cc851adc1c94e08a063b2479269805a4580 | 03:31 |
| mup | PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 03:31 |
| elopio | snappy-m-o autopkgtest 1717 xenial:armhf xenial:arm64 | 03:31 |
| snappy-m-o | elopio: I've just triggered your test. | 03:31 |
| kyrofa | sergiusens, elopio nooooooooooooo | 04:00 |
| kyrofa | sergiusens, I didn't scroll back that far, just saw some errors in the middle of catkin tests | 04:01 |
| kyrofa | Well, should be done by morning-ish anyway | 04:02 |
| kyrofa | elopio, thanks for pushing a fix :) | 04:02 |
| === JanC_ is now known as JanC | ||
| === JanC is now known as Guest70158 | ||
| === JanC_ is now known as JanC | ||
| === JanC is now known as Guest67213 | ||
| === JanC__ is now known as JanC | ||
| === JanC__ is now known as JanC | ||
| elopio | snappy-m-o autopkgtest 1717 xenial:armhf xenial:arm64 | 05:00 |
| snappy-m-o | elopio: I've just triggered your test. | 05:00 |
| elopio | snappy-m-o autopkgtest 1717 xenial:arm64 | 06:41 |
| snappy-m-o | elopio: I've just triggered your test. | 06:41 |
| zyga | o/ | 06:46 |
| zyga | mvo: hey, good morning; I'm just waking up here, any fires related to debian image update? | 07:04 |
| mvo | zyga: good morning. all quiet on the debian image | 07:07 |
| mvo | zyga: at least afaict, not many PRs since last night it seems | 07:07 |
| mvo | zyga: but at least some from jamie that did succeed | 07:08 |
| zyga | interesting | 07:08 |
| zyga | I'll boot sid and see if anything was reverted | 07:08 |
| zyga | last night cachio helped me refresh the image so in theory we should be running apparmor now | 07:09 |
| kalikiana | moin moin | 07:09 |
| mvo | zyga: cool | 07:10 |
| mvo | zyga: yeah, I have some 2.30 tasks and need to chase why 2.29 is not in stable yet | 07:10 |
| zyga | mvo: any fires there or just unknown? | 07:11 |
| mvo | zyga: I'm trying to find this out now | 07:12 |
| mvo | zyga: looks like it was a test that was giving unexpected results but upon re-testing its all good and the original traces of the issue are no longer available (which is slightly sad) | 07:16 |
| jibel | hi, vlc from stable is no installable. I reported bug 1732359 in LP but I am not sure it's the right place. | 07:24 |
| mup | Bug #1732359: installation snap vlc / stable fails with: ERROR open /snap/vlc/7/meta/gui/vlc.desktop: no such file or directory <amd64> <apport-bug> <bionic> <third-party-packages> <VLC media player:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1732359> | 07:24 |
| jibel | not* installable | 07:24 |
| mvo | jibel: thanks, looking | 07:26 |
| mvo | jibel: and good morning :)! | 07:26 |
| mvo | jibel: I can reproduce, its a broken symlink in the snap | 07:27 |
| jibel | Good morning mvo | 07:30 |
| jibel | it's weird it reached stable and no one noticed it is not installable | 07:30 |
| mvo | jibel: yeah, also it seems like stable->edge all have the same revision of vlc | 07:32 |
| mvo | jibel: version says "daily" | 07:32 |
| mvo | jibel: I guess we need to reach out to them and suggest to use "daily" for "edge" and not stable :) | 07:32 |
| zyga | mvo: note the revision, 7, meaning it's not daily | 07:32 |
| zyga | mvo: unless they count days at pluto frequency | 07:33 |
| mvo | zyga: why not? | 07:33 |
| mvo | zyga: maybe they just started 7 days ago, I have no insight into this | 07:33 |
| zyga | mvo: it was "daily" and ~5 in heildenberg | 07:33 |
| mvo | (I honestly don't know when they started to publish it) | 07:33 |
| zyga | (sorry for spelling that wrong) | 07:33 |
| mvo | zyga: uhhhh, ok. so daily for a day long ago | 07:33 |
| zyga | it's just "not actively maintianed" | 07:33 |
| mvo | :( | 07:33 |
| zyga | hmm, debian seems to be working | 07:50 |
| zyga | I'll check if we get the right image for real | 07:50 |
| zyga | eh :) | 08:01 |
| zyga | mvo: so cachio or gustavo mixed up the two | 08:01 |
| zyga | mvo: and "sid" and "stretch" are swapped | 08:01 |
| mvo | zyga: heh | 08:02 |
| mvo | zyga: ok, mystery solved | 08:02 |
| zyga | mvo: hmm, actually, it's the same old image | 08:02 |
| zyga | mvo: I changed sources.list in both | 08:02 |
| zyga | we are not on the new images yet | 08:02 |
| zyga | I guess I'll just talk to cachio later today | 08:02 |
| Son_Goku | zyga: so I feel slightly proud of myself | 08:09 |
| Son_Goku | I delved into the world of ELF deps and didn't drown | 08:09 |
| Son_Goku | I didn't really like messing around with ELF data, though :/ | 08:09 |
| mwhudson | top elf tip: alias readelf='readelf --wide' | 08:10 |
| Son_Goku | mwhudson: oh if only it were that simple | 08:12 |
| Son_Goku | I was using libelf directly | 08:12 |
| mwhudson | ah | 08:12 |
| mwhudson | i actually quite like go's debug/elf | 08:13 |
| Son_Goku | it doesn't support reading all the attributes, but it's a nice API | 08:13 |
| zyga | Son_Goku: what are you trying to do? | 08:14 |
| Son_Goku | do you really want to know? | 08:14 |
| zyga | yes | 08:14 |
| zyga | I like elf and things like tat | 08:14 |
| Son_Goku | https://github.com/rpm-software-management/rpm/pull/360 | 08:14 |
| mup | PR rpm-software-management/rpm#360: elfdeps: Add full multiarch deps support <Created by Conan-Kudo> <https://github.com/rpm-software-management/rpm/pull/360> | 08:14 |
| zyga | that | 08:14 |
| zyga | is rpm going multiarch? | 08:15 |
| Son_Goku | well, rpm is going to support it | 08:15 |
| Son_Goku | it's up to distributions if they want to do a multiarch scheme of some kind | 08:16 |
| Son_Goku | elfdeps is actually the only bit of rpm that wasn't multiarch-safe already | 08:17 |
| Son_Goku | as it predates rpm's own multiarch support | 08:17 |
| zyga | thank you for pushing that in your spare time :) | 08:19 |
| Son_Goku | the only thing I'm not sure about is if this handles x32 properly | 08:21 |
| zyga | Son_Goku: I played with x32 lately, I'm actually very fond of this idea | 08:22 |
| zyga | Son_Goku: object size is very compact and you have all the instructions and registers | 08:22 |
| Son_Goku | I don't know what it looks like from ELF | 08:22 |
| zyga | Son_Goku: for vast majority of my work x32 is sufficient | 08:22 |
| zyga | Son_Goku: in which sense? | 08:22 |
| Son_Goku | oh interesting | 08:23 |
| Son_Goku | it comes up as x86-32 | 08:23 |
| Son_Goku | that's probably not good | 08:23 |
| zyga | I think it's called x32 more often | 08:23 |
| zyga | but naming and off by one and so on :) | 08:24 |
| Son_Goku | so here's the interesting bit | 08:24 |
| Son_Goku | it is elfclass32 | 08:24 |
| Son_Goku | but machine is x86_64 | 08:24 |
| zyga | right, because that probably defines various pointer sizes and what not | 08:25 |
| Son_Goku | right | 08:25 |
| zyga | and I also suspect nobody thought of this when elf was designed | 08:25 |
| Son_Goku | I think that's a pretty safe assumption | 08:25 |
| zyga | as people thought it would just grow and grow | 08:25 |
| Son_Goku | oh god, this means I need to special-case this | 08:25 |
| zyga | offtopic, meld and gnome look really amazing | 08:25 |
| sergiusens | snappy-m-o autopkgtest 1717 xenial:arm64 | 08:37 |
| snappy-m-o | sergiusens: I've just triggered your test. | 08:37 |
| Son_Goku | zyga: and now I added handling for x32 | 08:38 |
| zyga | Son_Goku: given that an average consumer PC has 4GB of ram or less, I'd love to see windows use x32 | 08:39 |
| Son_Goku | not going to happen | 08:39 |
| zyga | Son_Goku: so that linux folks with their 32GB machines would notice | 08:39 |
| zyga | Son_Goku: never say never | 08:39 |
| Son_Goku | I probably should add support for x32 to the regular elfdeps mode | 08:39 |
| zyga | Son_Goku: microsoft is quite a surprise source lately | 08:39 |
| Son_Goku | since I am touching that code... | 08:39 |
| zyga | Son_Goku: and on that sense it would also make sense in arm phone world | 08:40 |
| Son_Goku | there, absolutely | 08:40 |
| zyga | Son_Goku: and by extension in iot | 08:40 |
| zyga | 512MB board with 64bit CPU running in x32-like mode | 08:41 |
| === JanC is now known as Guest41818 | ||
| zyga | brb | 08:42 |
| mup | PR snapd#4204 closed: store: enable "base" field from the store <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4204> | 09:19 |
| mwhudson | eh all phone cpus just implement aarch32 still don't they? | 09:31 |
| mwhudson | it seems noone can quite decide if arm64ilp32 is worth it yet | 09:31 |
| zyga | mwhudson: I think the trend is clear for aarch64 being used by most now | 09:31 |
| mwhudson | zyga: i mean, 64-bit phone cpus implement the old arm 32-bit instruction set as well | 09:32 |
| mwhudson | there are server cpus that don't but they also have gobs of ram | 09:32 |
| zyga | mwhudson: yes, that's true | 09:32 |
| ikey | :( my base snap is already outdated and needs redoing | 09:45 |
| mup | PR snapd#4219 opened: snap/validate: extend socket validation tests <Created by albertodonato> <https://github.com/snapcore/snapd/pull/4219> | 09:46 |
| ackk | jdstrand, hi, just saw your messages from yesterday, I pushed ^^ with the changes you requested since the branch was merged already | 09:48 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | i've just logged on to not miss out on anything, but i've got to go off to the doc's for a 10:30 | 09:54 |
| Chipaca | so i won't be around until ~midday, assuming they're on time | 09:54 |
| mvo | Chipaca: good luck! | 09:59 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| mup | PR snapd#4210 closed: many: add magic /snap/README file <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4210> | 10:51 |
| sergiusens | snappy-m-o autopkgtest 1717 xenial:arm64 | 10:53 |
| snappy-m-o | sergiusens: I've just triggered your test. | 10:53 |
| imexil | Hi, I thought to look at the yaml file of the new "official" pulsemixer snap. Anyone can point me where to find it. There isn't any kinf of docker hub equivalent website for snaps, is there? | 10:53 |
| mup | PR snapd#4217 closed: interfaces/browser-support: add shm path for nwjs <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4217> | 10:54 |
| mup | PR snapcraft#1735 closed: unit tests: reset log level after test <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1735> | 10:54 |
| mup | PR snapd#4207 closed: Flesh out NVIDIA support for biarch and multiarch systems <Created by ikeydoherty> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4207> | 10:57 |
| sergiusens | snappy-m-o autopkgtest 1717 xenial:i386 | 11:03 |
| snappy-m-o | sergiusens: I've just triggered your test. | 11:03 |
| kalikiana | hrm, asciicasting is harder than it looks, when you make stupid mistakes like leaving a folder around after the dry run | 11:11 |
| pedronis | mvo: is master broken? I got a couple of emails about it, though recent merges seemed innocent enough | 11:12 |
| mvo | pedronis: yeah, it was a prepare problem that looked like a fluke but I just got the second error mail, I'm looking now | 11:20 |
| mup | PR snapd#4220 opened: snapd: allow hooks to have slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4220> | 11:21 |
| mvo | pedronis: it looks like the opensuse repo has a hickup, I will disable opensuse for the moment I think | 11:21 |
| mvo | 4214 needs a second review - should be easy peasy | 11:36 |
| zyga | mvo: done | 11:38 |
| mvo | zyga: \o/ | 11:41 |
| mup | PR snapd#4214 closed: fakestore: add go-flags to prepare for `new-snap-declaration` cmd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4214> | 11:41 |
| mvo | pedronis: I am updating the roadmap right now, anything I need to add to 2.29 from your side except "make --ignore-validation sticky"? (I was looking for tags "pedronis" :) | 11:54 |
| pedronis | mvo: for 2.29 that's it, and some improvement bits on that are in 2.30 | 11:55 |
| mvo | pedronis: thank you | 11:55 |
| mvo | a bit of a meta question, it would be nice to have a way to tag topics from upcoming to "done" (or done-2.29) this would make writing the roadmap much simpler | 11:56 |
| mvo | (or "done", "2.29") | 11:56 |
| mvo | "upcoming" "2.29" | 11:56 |
| pedronis | interesting, I tend to put in topic "this will be avaliable in 2.xx+" when things have landed, but not easy to search on that | 11:57 |
| pedronis | mvo: in theory we (Gustavo) put stuff in the roadmap topic that we know will come | 11:58 |
| pedronis | but there's often more/smaller stuff too | 11:58 |
| pedronis | also don't know how that process will change | 11:58 |
| pedronis | mvo: I would be ok to have further tags personnaly | 11:58 |
| pedronis | mvo: I think I wrote already that I fell we have too many things in upcoming and is a bit unclear what is really upcoming (next 2 releases or so) | 11:59 |
| pedronis | s/fell/feel/ | 11:59 |
| mvo | pedronis: yes | 12:00 |
| mvo | Chipaca: silly question, do we have a forum topic describing the new ansimeter? | 12:00 |
| kalikiana | sergiusens: I sent you my gist. also note the bug I just found... I'll make a PR for it asap | 12:06 |
| pedronis | mvo: btw there is something weird with roadmap topic links, many don't work for me but if I retype the last bits they work | 12:12 |
| mvo | pedronis: I have the same problem, when I click on them directly they give me an error but when I open them in a new tab thinks work as expected | 12:13 |
| pedronis | mvo: wonder if it's the syntax or something about perms we don't understand | 12:17 |
| mvo | Chipaca, zyga, pstolowski please double check if https://forum.snapcraft.io/t/the-snapd-roadmap/1973 for 2.29 and 2.30 reflects reality or if I forgot anything (cc niemeyer :) | 12:17 |
| mvo | pedronis: yeah, worth raising during the standup I think, maybe gustavo knows (he knows the software best afaict) | 12:18 |
| niemeyer | pedronis: It's okay to have further tags.. the main concern (mine, at least) is always that when it gets too fiddly in general it gets forgotten over time | 12:20 |
| niemeyer | pedronis: As long as we can stick to it, more metadata is good | 12:21 |
| niemeyer | pedronis: As long as it's useful as well, obviousy | 12:21 |
| niemeyer | ... and on that note, I really need to get driving or we won't get there today | 12:23 |
| niemeyer | o/ | 12:23 |
| pedronis | yea, I tend to be ok with process (within reason), but yes unclear we follow already current process | 12:23 |
| niemeyer | Ah, last note, per forum note, if you have some headshot/upper body pictures you're comfortable with (core team), please send it along so I can build a nice slide for the talk | 12:24 |
| pedronis | mvo: this is also 2.30 https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774 and needs more work ? | 12:33 |
| mup | PR snapcraft#1737 opened: cli: pass remote from container_config to clean method <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1737> | 12:40 |
| axino | hi | 12:45 |
| axino | would anyone know how to deal with https://paste.ubuntu.com/25967274/ ? | 12:46 |
| zyga | axino: hey there | 12:49 |
| ogra_ | did you manually tinker with the mount ? | 12:49 |
| zyga | axino: it's a known bug, I looked at it extensively though I don't know if there's something simple that would work around it for you | 12:49 |
| axino | not that I know of | 12:50 |
| zyga | ogra_: it's a bug in 14.04 and inside containers | 12:50 |
| ogra_ | ah, 14.04 ... | 12:50 |
| axino | (this is a xenial container yes) | 12:50 |
| zyga | ogra_: this is a container here actually | 12:50 |
| zyga | axino: not sure if this will help you, but: | 12:50 |
| ogra_ | yes, i noticed the container | 12:50 |
| zyga | axino: you can unmount those things manually (all the mounts in /snap/*/*) | 12:51 |
| zyga | axino: then you should be able to: sudo mount --bind /snap /snap; sudo mount --make-rshared /snap; | 12:51 |
| axino | FWIW I found I could "snap changes" and "snap abort" but it doesn't help | 12:51 |
| zyga | axino: then you should be able to sudo systemctl start each of the mount units | 12:51 |
| zyga | axino: and then it should recover | 12:51 |
| zyga | axino: that's roughly what my in-progress fix is trying to do | 12:51 |
| axino | zyga: should I stop snapd first ? | 12:52 |
| zyga | axino: you can but it doesn't (should not) matter | 12:52 |
| axino | zyga: now the core snap is broken :x | 12:55 |
| zyga | axino: did you mount everything back? | 12:55 |
| zyga | axino: ideally paste the steps you took | 12:55 |
| zyga | axino: look at /etc/systemd/system and start all the mount units back (or mount them manually) | 12:56 |
| axino | zyga: https://pastebin.ubuntu.com/25967312/ | 12:56 |
| axino | (what I used to start the mounts back) | 12:57 |
| ikey | who can i beg or bribe for snap store review? :) | 12:57 |
| axino | err | 12:57 |
| axino | the units I started are gone | 12:57 |
| mvo | pedronis: yes | 12:57 |
| mvo | pedronis: thank you | 12:57 |
| zyga | axino: hmm | 12:57 |
| zyga | axino: what is actually mounted? | 12:57 |
| axino | zyga: it was looking like this https://pastebin.ubuntu.com/25967315/ | 12:57 |
| zyga | no | 12:58 |
| zyga | I mean moubted | 12:58 |
| zyga | not what systemd things | 12:58 |
| zyga | thinks* | 12:58 |
| axino | zyga: https://pastebin.ubuntu.com/25967318/ | 12:58 |
| mvo | niemeyer: how would you feel about adding a "2.30" tag (and same for subsequent releases)? then we could tag topics as "upcoming", "2.30" and the roadmap would be slightly simpler to build | 12:58 |
| zyga | axino: how about /proc/self/mountinfo | 12:58 |
| axino | zyga: https://pastebin.ubuntu.com/25967323/ | 12:59 |
| pedronis | mvo: he answered, I think he said ok if we manage to stick to it | 12:59 |
| mvo | pedronis: aha, cool. sorry missed the reply | 12:59 |
| zyga | axino: ok this looks good now | 13:00 |
| zyga | axino: now go to /etc/systemd/system and look at the mount units you see | 13:00 |
| mvo | niemeyer: thanks about your reply for the tags | 13:00 |
| zyga | start the core one | 13:00 |
| axino | zyga: https://pastebin.ubuntu.com/25967332/ | 13:01 |
| axino | OK starting the last core one | 13:01 |
| zyga | axino: ok, start each one one by one | 13:01 |
| zyga | axino: then start snapd | 13:01 |
| axino | zyga: OK we're back in business | 13:01 |
| zyga | axino: and that should work | 13:01 |
| axino | zyga: thanks o/ | 13:01 |
| zyga | axino: and my fix is doing essentially that, just working on some details | 13:01 |
| axino | ok | 13:02 |
| zyga | axino: thank you for testing this! :) | 13:02 |
| axino | zyga: will that impact every "snap remove" under LXD ? | 13:02 |
| zyga | axino: no | 13:02 |
| zyga | axino: well, the bug affects a lot of things | 13:02 |
| zyga | axino: the fix I made is changing the mount sharing for /snap before the very first app ever runs on a given system/container | 13:02 |
| zyga | axino: then it's all good | 13:02 |
| axino | ok | 13:03 |
| zyga | axino: what we did here was the more costly/complex recovery process | 13:03 |
| Chipaca | mvo: i did not write about ansimeter | 13:04 |
| mup | PR snapcraft#1738 opened: unit tests: make the check for output less strict <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1738> | 13:07 |
| pedronis | Chipaca: did you see this: https://forum.snapcraft.io/t/do-not-print-the-progress-bar-when-running-snap-commands/2816 ? | 13:11 |
| Chipaca | pedronis: i hadn't; commented | 13:13 |
| zyga | jdstrand: around? | 13:26 |
| cachio | mvo, PR #4218 | 13:31 |
| mup | PR snapcraft#1739 opened: Lxd refresh remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739> | 13:31 |
| mup | PR #4218: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4218> | 13:31 |
| cachio | this is the new one | 13:31 |
| cachio | I closed the other one before more people look at it | 13:31 |
| cachio | mvo, https://travis-ci.org/snapcore/snapd/builds/302294954#L4740 | 13:32 |
| cachio | this is the error I see in ubuntu core, with timezone = n/a | 13:32 |
| pedronis | mvo: will you create the 2.30 2.31 tags ? | 13:32 |
| sergiusens | kalikiana how confident are you in your PRs? | 13:43 |
| sergiusens | kalikiana can you add notes on what you tested? | 13:44 |
| kalikiana | sergiusens: I tested only from git - building snaps for testing takes a while... even if theoretically it shouldn't be relevant here, it seems best to check that | 13:44 |
| kalikiana | lemme document what I did | 13:45 |
| sergiusens | kalikiana please check | 13:47 |
| zyga | tea | 13:52 |
| ackk | jdstrand, updated the PR, thanks for the review | 14:07 |
| om26er | flexiondotorg: around ? | 14:15 |
| jdstrand | zyga: hey, yes | 14:34 |
| jdstrand | ackk: thanks! | 14:34 |
| zyga | jdstrand: I updated the secure-file PR | 14:40 |
| Chipaca | pstolowski: what snap can i use to play with config? | 14:41 |
| Chipaca | was looking for 'test-snapd-conf*' but that's not it | 14:41 |
| mvo | pedronis: sorry for the slow reply, I am still trying to figure out how to define new tags | 14:43 |
| Chipaca | pedronis: where? | 14:43 |
| Chipaca | um | 14:43 |
| Chipaca | mvo: where? | 14:43 |
| Chipaca | :-) | 14:43 |
| pstolowski | Chipaca, do you need something for a spread test? | 14:44 |
| mvo | Chipaca: in the forum | 14:44 |
| Chipaca | pstolowski: for playing with snnapshots | 14:44 |
| Chipaca | mvo: you need admin | 14:45 |
| Chipaca | i think | 14:45 |
| mvo | Chipaca: I have this (I think) - maybe not enough of it | 14:45 |
| Chipaca | mvo: what tag do you want to create? mind if i do it for you? | 14:45 |
| mvo | Chipaca: sure, 2.30 | 14:45 |
| mvo | Chipaca: the tag should be "2.30", then we can tag topics as "upcoming", "2.30", "chipaca" | 14:45 |
| mvo | etc | 14:45 |
| Chipaca | mvo: so, there isn't an explicit CRUD for tags; you create the tag when you use it | 14:47 |
| Chipaca | mvo: is there anything i can tag for you? | 14:47 |
| Chipaca | mvo: also: no dots in tags | 14:47 |
| jdstrand | zyga: I saw. it is on my list for today | 14:51 |
| zyga | thanks! | 14:51 |
| flexiondotorg | om26er: Hello | 14:52 |
| pstolowski | Chipaca, ondra may have some examples for you. i think there are still very few of them. you can always package one of our tests/lib/snaps/ for local testing; if you only need to check that config is stored/restored, then you don't really need any logic in configure hook | 14:53 |
| Chipaca | pstolowski: right, that's what i was asking: what in tests/lib/snaps is a good one to use for playing with config | 14:54 |
| pstolowski | Chipaca, any of those I guess - http://pastebin.ubuntu.com/25967995/ - probably those with empty configure will be best | 14:56 |
| pstolowski | Chipaca, and looks like config-versions spread test may be an inspiration? | 14:56 |
| Chipaca | ok, i'll look, thank you | 14:57 |
| om26er | flexiondotorg: re my Android Studio snap, any update ? | 15:05 |
| om26er | https://forum.snapcraft.io/t/classic-confinement-for-android-studio/2634/9 | 15:06 |
| pedronis | Chipaca: 2_30 then ? 2dot30 ? | 15:07 |
| pedronis | can then start with a number? | 15:07 |
| pedronis | *they | 15:07 |
| kalikiana | Hrm. `error: cannot refresh []: cannot refresh snap-declaration for "core": Get | 15:09 |
| kalikiana | https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2: | 15:09 |
| kalikiana | dial tcp: lookup api.snapcraft.io on [::1]:53: read udp [::1]:35870->[::1]:53: | 15:09 |
| kalikiana | read: connection refused` | 15:09 |
| kalikiana | This is "snap refresh" in a LXD container | 15:09 |
| elopio | popey: flexiondotorg: can you please review https://github.com/snapcrafters/vault/pulls | 15:09 |
| pedronis | Chipaca: I'm confused, afaict you cannot create them on the fly | 15:10 |
| zyga | kalikiana: is it just temporary? | 15:10 |
| popey | elopio: looking now | 15:10 |
| kalikiana | zyga: I've reproduced it a few times now. | 15:11 |
| kalikiana | I'm checking if it has anything to do with the particular server | 15:11 |
| Chipaca | pedronis: you can't; I can | 15:11 |
| Chipaca | pedronis: neener neener | 15:11 |
| pedronis | that's good | 15:11 |
| Chipaca | it's super dangerous, for fat-fingered me :-) | 15:12 |
| Chipaca | pedronis: 2-30 would work | 15:12 |
| pedronis | Chipaca: this for example would need 2.30: https://forum.snapcraft.io/t/do-not-print-the-progress-bar-when-running-snap-commands/2816 | 15:12 |
| pedronis | Chipaca: and the things in the roadmap under 2.30 | 15:12 |
| Chipaca | I'll tag that one | 15:13 |
| pedronis | heh sorry | 15:13 |
| pedronis | I miscopied | 15:13 |
| Chipaca | 2_30, or 2-30? | 15:13 |
| pedronis | Chipaca: IÂ meant this one: https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774 | 15:13 |
| pedronis | Chipaca: I'm partial to2_30 | 15:13 |
| Chipaca | boom | 15:13 |
| kalikiana | zyga: seems to be fine in one but not the other... now to wonder what's happening there | 15:17 |
| kalikiana | zyga: now it works | 15:19 |
| mvo | thanks Chipaca | 15:22 |
| kalikiana | sergiusens: I documented my steps for both PRs. First one ran into network issues on Travis so tests re-triggered. Second one still pending. | 15:23 |
| Chipaca | mvo: pedronis: ftr jdstrand can also do this | 15:23 |
| kalikiana | elopio: perhaps you could sanity-check my test code? snapcraft#1737 and snapcraft/pull/1739 | 15:26 |
| mup | PR snapcraft#1737: cli: pass remote from container_config to clean method <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1737> | 15:26 |
| mup | PR snapcraft#1739: Lxd refresh remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739> | 15:26 |
| Chipaca | mvo: and so can you! :-) heh | 15:27 |
| Chipaca | mvo: and ev and noise | 15:27 |
| Chipaca | ¯\_(ツ)_/¯ | 15:27 |
| mvo | Chipaca: oh, we can create tags now? | 15:28 |
| Chipaca | mvo: you should've been able to do it before | 15:28 |
| mvo | Chipaca: what is the magic to do it? I just create one on the fly? | 15:28 |
| Chipaca | mvo: yes | 15:28 |
| mvo | ta | 15:31 |
| * kalikiana tea break | 15:42 | |
| mup | PR snapcraft#1738 closed: unit tests: make the check for output less strict <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1738> | 15:46 |
| * sergiusens is having an excellent time with 39 Celsius and a power outage | 15:51 | |
| Chipaca | sergiusens: ffffffantastic | 15:52 |
| ogra_ | i'd happily trade the 7°C for that | 15:57 |
| Chipaca | ogra_: nuh uh | 15:58 |
| Chipaca | ogra_: you can always put on more clothes | 15:59 |
| Chipaca | ogra_: you can't get more naked than naked | 15:59 |
| ogra_ | putting your feet into a bucket of water helps though ... | 15:59 |
| Chipaca | ogra_: especially if the bucket is in a pool | 16:00 |
| ogra_ | +1 | 16:00 |
| zyga | Chipaca: have you seen that gallery with skinless ppl? | 16:00 |
| Chipaca | zyga: i've had lunch in a museum with skinless people, does that count? | 16:00 |
| Chipaca | also babies in formaldehyde | 16:01 |
| kalikiana | skinless sounds great for hot days | 16:03 |
| zyga | Chipaca: does "cool" qualify as an answer? | 16:03 |
| Chipaca | zyga: ¯\_(ツ)_/¯ | 16:03 |
| Chipaca | zyga: my secondary school was next to a medical science school that had a museum you could just walk into | 16:04 |
| Chipaca | lots of weird stuff | 16:04 |
| Chipaca | anyhoo | 16:04 |
| zyga | Chipaca: "do your homework or you end up in a barrel like the rest of exhibits" the biology teacher said ;-) | 16:05 |
| Chipaca | pstolowski: config doesn't have the idea of per-user data, right? | 16:05 |
| pstolowski | Chipaca, correct | 16:05 |
| zyga | Chipaca: per user snaps would be interesting but also hard | 16:13 |
| Chipaca | zyga: yeah, i think i'm going to store snap's config only if i'm storing the system data, otherwise no | 16:14 |
| Chipaca | (there's a per-user aspect to snapshots, and a system aspect) | 16:14 |
| Chipaca | makes sense to me :-) | 16:14 |
| sergiusens | Chipaca ogra_ I'll take the 7 Celsius any day of the year | 16:26 |
| sergiusens | power just came back! \o/ | 16:26 |
| kyrofa | sergiusens, man we can't catch a break on snapcraft#1717 | 16:27 |
| mup | PR snapcraft#1717: catkin plugin: check for pip packages in part only <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1717> | 16:27 |
| kyrofa | sergiusens, why i386 though? I already got a local pass on amd64 | 16:29 |
| sergiusens | just to see if that log error showed up | 16:30 |
| kyrofa | Ah okay. Well I noticed you merged the PR that's supposed to fix that | 16:30 |
| kyrofa | But it looks like this needs to be merged with master first | 16:30 |
| sergiusens | kyrofa wait for it | 16:31 |
| kalikiana | grrr, network errors on pip on both PRs | 16:34 |
| kalikiana | FYI I need to hop on a train in a few minutes so I can't work late tonight- but I'll check back in for a bit later | 16:35 |
| kyrofa | kalikiana, want me to run one locally? | 16:35 |
| kyrofa | Assuming it's for 2.35 | 16:36 |
| kalikiana | kyrofa: the first one passed on the second attempt, second one pending... so, it works, it's just a waste of time... | 16:36 |
| kyrofa | Okay | 16:36 |
| kalikiana | kyrofa: this is concerning snapcraft#1737 and snapcraft/pull/1739 which are fixing an issue with remote lxd - if you can have a looksie that'd be appreciated | 16:37 |
| mup | PR snapcraft#1737: cli: pass remote from container_config to clean method <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1737> | 16:37 |
| mup | PR snapcraft#1739: Lxd refresh remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739> | 16:37 |
| kyrofa | kalikiana, sure thing, reviewing now | 16:44 |
| * zyga made small progress on layouts :) | 16:45 | |
| mup | Bug #1732494 opened: Impossible to manage package after Trusty --> Xenial upgrade <apport-bug> <i386> <third-party-packages> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1732494> | 16:48 |
| ppisati | elopio: can you help me with the CLA check failing for this pull req? | 16:48 |
| ppisati | elopio: https://github.com/snapcore/snapcraft/pull/1720 | 16:48 |
| mup | PR snapcraft#1720: kernel plugin: introduce kernel-channel to select from which channel … <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1720> | 16:48 |
| kalikiana | kyrofa: Grand, thanks! | 16:48 |
| ppisati | elopio: i think you are the keeper of the 7 keys^W^W^W... i mean unit tests :) | 16:49 |
| mvo | ppisati: heh, you just made me switch my music | 16:50 |
| ppisati | mvo: at least someone got the joke :) | 16:51 |
| mvo | ppisati: :-D /me hums along | 16:52 |
| Chipaca | hahahaha | 16:58 |
| Chipaca | hhaa | 16:58 |
| Chipaca | hqa | 16:58 |
| Chipaca | dhe391edcf :flips table: | 16:58 |
| elopio | ppisati: how weird, it shows no error. I hate this CLA check, like a year ago I asked if it would be possible to move to the github integrated CLA check, but nothing happened :( | 16:59 |
| Chipaca | so... golang on 32-bit archs can only see half of the users on the system | 16:59 |
| Chipaca | of all the *possible* users i mean | 16:59 |
| elopio | ppisati: let me updated your branch, that at least will reduce the number of checks | 17:00 |
| zyga | Chipaca: ? | 17:02 |
| zyga | Chipaca: ?? | 17:03 |
| zyga | Chipaca: why is that? | 17:03 |
| Chipaca | getuid and co return an int | 17:03 |
| Chipaca | uid_t and co are 32 bit unsigned | 17:03 |
| mup | PR snapd#4221 opened: tests: new test for interface network status <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4221> | 17:05 |
| Chipaca | zyga: https://github.com/golang/go/issues/22739 | 17:10 |
| zyga | Chipaca: well that will show those 32 bit users ;) | 17:12 |
| Chipaca | zyga: we are going to be using uids somewhere in that space | 17:12 |
| Chipaca | for our per-snap uids | 17:12 |
| zyga | Chipaca: well, that ended quickly | 17:12 |
| zyga | Chipaca: can we use negative integers? ;-) | 17:12 |
| Chipaca | zyga: no, that's the problem | 17:13 |
| Chipaca | syscall.Getuid returns a negative number | 17:13 |
| Chipaca | and then that's looked up in /etc/passwd | 17:13 |
| Chipaca | guess how well that works | 17:13 |
| Chipaca | :-) | 17:13 |
| kyrofa | Chipaca, oops | 17:14 |
| diddledan | I've got really weird behaviour. I have created a patch which I'm trying to apply in a snapcraft prepare script. Doing the steps manually works, but when I try to do it via snapcraft the git apply call just silently does nothing | 17:14 |
| Chipaca | and the reason you can't create a user with uid -1 is because that's a special flag value that means "don't change the uid" | 17:14 |
| Chipaca | (by -1 i mean 0xf...f obvs) | 17:14 |
| diddledan | my prepare script is: git apply --stat $SNAPCRAFT_STAGE/unrar.patch | 17:15 |
| diddledan | I've confirmed the patch is at $SNAPCRAFT_STAGE/unrar.patch, and I've confirmed that I'm in the build folder with the source I'm trying to patch | 17:15 |
| elopio | popey: one more, please https://github.com/snapcrafters/vault/pull/6 | 17:16 |
| mup | PR snapcrafters/vault#6: Update the grade to stable <Created by elopio> <https://github.com/snapcrafters/vault/pull/6> | 17:16 |
| popey | elopio: done | 17:16 |
| elopio | thank you | 17:20 |
| Chipaca | diddledan: are you in the directory you think you are when you try to do that? | 17:21 |
| diddledan | yes, I've confirmed that | 17:21 |
| diddledan | trying to replicate it in a minimal build doesn't recreate the problem. It's only on my complex build that's failing | 17:24 |
| kyrofa | diddledan, which plugin? | 17:24 |
| diddledan | make | 17:24 |
| kyrofa | diddledan, remember that the prepare scriptlet runs in the build dir, not the source dir | 17:26 |
| diddledan | it's this part that fails on my attempt to build calibre, but pulling it to it's own snapcraft.yaml doesn't fail: | 17:26 |
| diddledan | https://www.irccloud.com/pastebin/wqlPNJXA/ | 17:26 |
| diddledan | the patch is: | 17:27 |
| diddledan | https://www.irccloud.com/pastebin/Mv9VK6TH/ | 17:27 |
| kyrofa | Hmm, yeah I don't see anything wrong there | 17:28 |
| diddledan | full calibre snapcraft.yaml which FAILS (the above parts don't fail when isolated like that) is: | 17:28 |
| diddledan | https://www.irccloud.com/pastebin/MTOl6x2y/ | 17:28 |
| kyrofa | diddledan, dumb question: do you have git installed? | 17:28 |
| kyrofa | (it's not a build-package) | 17:28 |
| mup | PR snapd#4222 opened: tests: add new `fakestore new-snap-{declaration,revision}` helpers <Created by mvo5> <https://github.com/snapcore/snapd/pull/4222> | 17:30 |
| kyrofa | ah, yeah that one will install git | 17:30 |
| diddledan | snapcraft installs git itself automatically. it doesn't need to be manually specified. even if it did need to be specified it's working enough that git is responding in both scenarios | 17:31 |
| diddledan | specifically the behaviour is : when the parts are isolated, the `git apply` works. when in the calibre full yaml the `git apply` silently returns with exit code 0 indicating success but the source is not patched | 17:33 |
| cachio | jdstrand, https://paste.ubuntu.com/25968840/ | 17:38 |
| cachio | Running the test to check network-status interface | 17:38 |
| cachio | https://github.com/snapcore/snapd/pull/4221/files | 17:38 |
| mup | PR #4221: tests: new test for interface network status <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4221> | 17:38 |
| cachio | jdstrand, any idea why it could happening? | 17:38 |
| kyrofa | diddledan, and you're checking the source in the build dir, not the src dir? | 17:41 |
| === cachio is now known as cachio_afk | ||
| sergiusens | elopio kyrofa I am beginning to thing that we should cut where we are; that test is breaking on i386 as well | 17:49 |
| kyrofa | sergiusens, wait, no, that's the plainbox bug I logged | 17:50 |
| kyrofa | I thought I was only seeing it locally though | 17:50 |
| kyrofa | This is the first time I've seen it in the real adt | 17:51 |
| kyrofa | I'll investigate now | 17:52 |
| kyrofa | sergiusens, catkin tests look good there | 17:53 |
| sergiusens | kyrofa ok, thanks | 17:53 |
| Chipaca | ok, EOD'ing | 17:54 |
| kyrofa | I think that PR is probably good, then | 17:54 |
| sergiusens | kyrofa please rebase so that other one can get in | 17:55 |
| kyrofa | Of course | 17:55 |
| mup | PR snapcraft#1717 closed: catkin plugin: check for pip packages in part only <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1717> | 17:56 |
| mup | PR snapcraft#1737 closed: cli: pass remote from container_config to clean method <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1737> | 17:59 |
| sergiusens | kyrofa you are in charge of the boat, I need to go to physiotherapy now... my dream is to see those last remaining PRs merged and the changelog branch updated ;-) | 17:59 |
| kyrofa | sergiusens, you got it | 17:59 |
| kyrofa | snappy-m-o, autopkgtest 1739 xenial:i386 | 18:14 |
| snappy-m-o | kyrofa: I've just triggered your test. | 18:14 |
| kyrofa | elopio, I'm not clear on your comment-- do you feel like snapcraft#1739 needs to change? | 18:14 |
| mup | PR snapcraft#1739: lxd: refresh remote container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739> | 18:14 |
| kyrofa | elopio, hmm.... don't the debian/tests/* scripts run as root? | 18:22 |
| kyrofa | Which means /home/ubuntu/autopkgtest_tmp is owned by root? | 18:22 |
| kyrofa | Although you give it mode 777 I suppose | 18:22 |
| elopio | kyrofa: I'm happy if the message on 1739 is added later. | 18:23 |
| elopio | and yes, you wanred about that so it's 777 now. | 18:23 |
| elopio | we could set the owner to ubuntu if there's any problem. | 18:23 |
| kyrofa | elopio, wondering if the plainbox issue traces back to that, poking now | 18:23 |
| kyrofa | The message on 1739 being the one I mentioned as well? | 18:24 |
| elopio | kyrofa: yes. | 18:24 |
| kyrofa | Agreed | 18:24 |
| elopio | kyrofa: and this is what we do on integrationtests -> mkdir --parents /home/ubuntu/autopkgtest_tmp --mode 777 | 18:24 |
| === rmescandon_ is now known as rmescandon | ||
| kyrofa | elopio, oh man... see all the old snapcraft xenial:amd64 PRs running now... | 18:36 |
| === JoshStrobl is now known as JoshStrobl|Away | ||
| elopio | kyrofa: now the bottleneck is our fault ::( | 18:45 |
| kyrofa | Yeah that hurts | 18:46 |
| kyrofa | Why can we not cancel these?!?!?! | 18:46 |
| elopio | turn it off and on again. | 18:46 |
| zyga | Chipaca: around? | 18:48 |
| kyrofa | elopio, do you know how adt creates lxc containers? | 18:48 |
| kyrofa | It must be special, because I'm getting confinement issues trying to run the plainbox test | 18:49 |
| jdstrand | cachio_afk: what is the specific apparmor denial? | 18:49 |
| zyga | can I get a quick +1 for a trivial: https://github.com/snapcore/snapd/pull/4223 | 18:49 |
| mup | PR #4223: cmd/snap-update-ns: misc cleanups <Created by zyga> <https://github.com/snapcore/snapd/pull/4223> | 18:49 |
| mup | PR snapd#4223 opened: cmd/snap-update-ns: misc cleanups <Created by zyga> <https://github.com/snapcore/snapd/pull/4223> | 18:49 |
| kyrofa | elopio, although looking at the config of the running container, doesn't look special at all. Looks default | 18:49 |
| kyrofa | Alright, plan B | 18:52 |
| elopio | kyrofa: this is the provisioner https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/virt/autopkgtest-virt-lxd#n135 | 18:56 |
| kyrofa | elopio, interesting. Sucks, I can't reproduce the same error outside of the adt suite, so I've paired that suite down to only the single snapd test, but it still needs to run the units and build the deb, haha | 18:58 |
| kyrofa | That's alright, I'll get there | 18:58 |
| kyrofa | But yeah, that proves that there's nothing special about it | 18:59 |
| * zyga is hyped by https://teletype.atom.io/ | 19:01 | |
| Chipaca | zyga: for a little bit | 19:06 |
| Chipaca | zyga: wassup | 19:06 |
| zyga | Chipaca: can you please +1 https://github.com/snapcore/snapd/pull/4223 | 19:06 |
| mup | PR #4223: cmd/snap-update-ns: misc cleanups <Created by zyga> <https://github.com/snapcore/snapd/pull/4223> | 19:06 |
| elopio | kyrofa: my hack to do it faster is change setup.py. Also, use the ppa instead of building from source, but just if you are not changing the deb. | 19:06 |
| zyga | I'll merge it when green and push a feature PR on top | 19:06 |
| zyga | I just didn't want this noise in the same one | 19:06 |
| kyrofa | Oh the setup.py, duh | 19:06 |
| kyrofa | elopio, okay, tests disabled. But how do I tell it to use the PPA? | 19:07 |
| elopio | kyrofa: that's what I'm working on now. I think I'm close: https://github.com/snapcore/snapcraft/pull/1643/files#diff-bc66fbdb036f79e9f15bcbf47a6bc67cR44 | 19:08 |
| mup | PR snapcraft#1643: [WIP] tests: run daily autopkgtest in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1643> | 19:08 |
| kyrofa | Ah yes, nice | 19:08 |
| zyga | jdstrand: FYI: a formal +1 on https://github.com/snapcore/snapd/pull/4170 would help :) | 19:11 |
| mup | PR #4170: cmd/snap-update-ns: add planWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4170> | 19:11 |
| Chipaca | zyga: +1 (beyond the "silly wrapper is silly" comment) | 19:12 |
| zyga | Chipaca: thanks, I just wanted to highligh the mocking aspect, I can reword that if you have ideas | 19:12 |
| zyga | highlight* | 19:12 |
| Chipaca | zyga: i understood it purpose, but the wrapper isn't needed | 19:13 |
| zyga | oh? | 19:14 |
| zyga | aaah | 19:14 |
| zyga | I see now | 19:14 |
| zyga | thanks, I'll do that | 19:14 |
| zyga | Chipaca: seeing this brings back classmethodwrapper horrors | 19:14 |
| Chipaca | mbuahahaa | 19:15 |
| jdstrand | zyga: it is also on the list | 19:15 |
| Chipaca | zyga: if it's any consolation, at least you're not fiddling with the glob table | 19:15 |
| zyga | Chipaca: oh, about that | 19:15 |
| zyga | Chipaca: a puzzle | 19:15 |
| zyga | Chipaca: I failed, maybe you can do better | 19:16 |
| zyga | https://twitter.com/fijall/status/930744285728735232 | 19:16 |
| zyga | Chipaca: ^ | 19:16 |
| zyga | jdstrand: thank you! | 19:16 |
| zyga | ah, the answer is in the responses below now | 19:17 |
| Chipaca | zyga: it's a hacky way of having a global that survives (re)imports | 19:18 |
| Chipaca | e.g. if you do reload() or if you import it with two different paths | 19:18 |
| zyga | I was trying the two different paths idea | 19:18 |
| zyga | I must have remembered this wrong | 19:19 |
| zyga | but inter-package imports did something funky | 19:19 |
| zyga | from .foo import bar | 19:19 |
| zyga | vs from pkg.foo import bar | 19:19 |
| zyga | wow, when did github start doing this: https://github.com/snapcore/snapd/blob/master/COPYING | 19:20 |
| === cachio_afk is now known as cachio | ||
| Chipaca | zyga: it's probably just reload() if the importer doesn't trip up | 19:22 |
| Chipaca | zyga: or! it could be for re-exec | 19:22 |
| cachio | jdstrand, https://paste.ubuntu.com/25969363/ | 19:22 |
| cachio | these are the denials that I saw | 19:22 |
| kyrofa | Dang, now adt is failing with that new error as well. I'm starting to hate plainbox | 19:25 |
| kyrofa | Either it or the way we're using it makes it such a moving target | 19:26 |
| Chipaca | mmm | 19:26 |
| Chipaca | zyga: ¯\_(ツ)_/¯ can't make it work outside of a plain reload -- which might be enough | 19:26 |
| Chipaca | some apppservers reload() the modules of your app when you edit it | 19:27 |
| zyga | Chipaca: I recall using reload but very rarely | 19:38 |
| === dontbeadick is now known as kennyloggins | ||
| * elopio <- lunch | 19:52 | |
| sergiusens | kyrofa how are things going? | 19:59 |
| kyrofa | sergiusens, tests still running. I'm having trouble reproducing plainbox all of a sudden as well | 19:59 |
| kyrofa | It's a different error today :P | 19:59 |
| kyrofa | "cannot create freezer cgroup hierarchy for snap plainbox-simple" | 20:00 |
| kyrofa | Researching now | 20:00 |
| kyrofa | That's coming from snap-confine | 20:01 |
| kyrofa | zyga, any idea why I might be getting "cannot create freezer cgroup hierarchy for snap X" ? | 20:01 |
| kyrofa | zyga, it's in a normal lxd container | 20:01 |
| kyrofa | And then it's so broken I can't remove it | 20:04 |
| zyga | kyrofa: no, | 20:06 |
| zyga | kyrofa: any denials? | 20:06 |
| kyrofa | zyga, crap. Now it succeeded. What the heck... | 20:20 |
| zyga | post on the forum please | 20:21 |
| kyrofa | Software is so quantum. It does X until you look at it, then it does Y just because you're looking at it | 20:24 |
| kyrofa | zyga, did you recently release a new core snap by any chance? | 20:31 |
| zyga | yes | 20:32 |
| zyga | today | 20:32 |
| kyrofa | Yeah this was working yesterday | 20:32 |
| kyrofa | And it just happened again | 20:32 |
| kyrofa | sergiusens, getting THAT error in adt now ^ | 20:32 |
| kyrofa | I'll make a forum post | 20:32 |
| mwhudson | zyga: do you have any ideas for the debian breakage yet? | 20:33 |
| kyrofa | This is interesting: "kernel_os.go:192: cannot get boot vars: open /boot/grub/grubenv: no such file or directory" | 20:33 |
| zyga | mwhudson: I didn't look after that, jjohansen needs to say if this is a bug that we should fix in debian or in the kernel | 20:36 |
| mwhudson | ok | 20:36 |
| zyga | mwhudson: all I know is in the forum for that topic | 20:36 |
| mwhudson | i guess it still makes sense to get 2.29.3.1 ready for uploading to debian even if it's not going to work for a while | 20:36 |
| zyga | yes | 20:36 |
| mwhudson | zyga: --enable-nvidia-multiarch, do we want that on debian? | 20:37 |
| jjohansen | zyga: sorry I haven't figured that out yet. I'm working on it | 20:37 |
| mwhudson | zyga: also should we stop passing --disable-apparmor now? | 20:38 |
| mup | PR snapd#4220 closed: snapd: allow hooks to have slots <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4220> | 20:38 |
| zyga | jjohansen: thank you! | 20:38 |
| zyga | mwhudson: I think so | 20:38 |
| zyga | mwhudson: the core was ablt to handle that for some time now | 20:38 |
| zyga | mwhudson: (since ~august) | 20:38 |
| mwhudson | zyga: which of my two questions are you answering? :) | 20:39 |
| * mwhudson acquires coffee | 20:40 | |
| zyga | mwhudson: <should we stop passing --disable-apparmor> | 20:41 |
| zyga | mwhudson: as for nvidia, ... not sure, perhaps yes but I never tried it because debian doesn't (AFAIK) ship proprietary drivers | 20:42 |
| zyga | mwhudson: probably doesn't hurt | 20:42 |
| mwhudson | mm ok | 20:43 |
| mwhudson | there was a guy in the forum complaining about nvidia problems i think | 20:44 |
| mwhudson | but i don't understand how any of that works :) | 20:44 |
| zyga | mwhudson: I can explain if you want | 20:44 |
| kyrofa | sergiusens, scratch that... I'm getting that error on _every single_ snapd test | 20:44 |
| * mwhudson considers if he cares | 20:45 | |
| mwhudson | zyga: i've used intel graphics for years and have no intention of changing any time soon :) | 20:45 |
| zyga | mwhudson: fair enough :) | 20:50 |
| zyga | I think I should EOD, I'll check some PRs later and try to merge | 20:50 |
| kyrofa | snappy-m-o, autopkgtest 1719 xenial:i386 | 20:55 |
| snappy-m-o | kyrofa: I've just triggered your test. | 20:55 |
| kyrofa | zyga, to be clear, you released to stable today? | 20:56 |
| mwhudson | zyga: pushed something that might build to alioth | 20:58 |
| mwhudson | zyga: now go to bed :) | 20:58 |
| mwhudson | kyrofa: yes, stable was updated today, according to mvo in the forum | 20:58 |
| mwhudson | kyrofa: https://forum.snapcraft.io/t/2-29-release-cycle-started/2562/9 | 20:59 |
| diddledan | kyrofa: sorry, had to pop out. the source isn't patched ANYWHERE. neither the src directory nor the build directory. The git apply simply silently exits without patching any files, despite checking that there is a copy of that file in the directory it's executed within. | 21:01 |
| diddledan | kyrofa: the point I've been trying to state is that the exact same bits work correctly when I pull them into their own snapcraft yaml | 21:02 |
| zyga | kyrofa: not me personally but yes, we as a team pushed 2.29.3 to stable toda | 21:02 |
| kyrofa | zyga, forum post published | 21:02 |
| diddledan | so I know that it works. it doesn't work when I use my full calibre build snapcraft yaml despite the parts being identical to those that work on their own | 21:03 |
| zyga | kyrofa: thank you | 21:03 |
| zyga | kyrofa: after lxd bug, which is close to being fixed, I will look at this | 21:03 |
| kyrofa | Thanks zyga | 21:03 |
| kyrofa | elopio, can you think of any reason why I would get that error when running the test, but not when installing the snap by hand? | 21:09 |
| diddledan | in fact, even separated it doesn't patch anything, so I was wrong there | 21:09 |
| diddledan | the following snapcraft.yaml doesn't patch anything | 21:12 |
| diddledan | https://www.irccloud.com/pastebin/5rktodoh/ | 21:12 |
| diddledan | same patch as before: https://www.irccloud.com/pastebin/Mv9VK6TH/ | 21:12 |
| diddledan | patch lives in ./patches/unrar.patch and snapcraft.yaml lives in ./snap/snapcraft.yaml | 21:13 |
| nacc | "Instead of applying the patch, output diffstat for the input. Turns | 21:14 |
| nacc | off "apply"." | 21:14 |
| nacc | diddledan: why are you passing --stat ? | 21:14 |
| nacc | diddledan: seems like user error to do so :) | 21:14 |
| diddledan | it doesn't work either way | 21:15 |
| zyga | jdstrand: hey, just a word of caution: the tun/tap test is failing randomly | 21:15 |
| zyga | jdstrand: we've seen it fail in lots of branches | 21:15 |
| nacc | diddledan: well, it definitley will not (and should not) do anything with --stat | 21:15 |
| zyga | jdstrand: it goes away on retry sometimes, not sure if you can think of anything in particular that would be specific to that test | 21:15 |
| diddledan | https://www.irccloud.com/pastebin/MTOl6x2y/ is the full project which is failing | 21:16 |
| nacc | diddledan: but wait | 21:16 |
| nacc | diddledan: reading... | 21:16 |
| nacc | diddledan: (tbh, i fid it confusing to use a source that's not git with a git command) | 21:16 |
| nacc | diddledan: i don't think there's any guarantee provided that you actually have git | 21:17 |
| nacc | diddledan: it probably works in general, but just a note | 21:17 |
| nacc | diddledan: did you try to do the build interactively? e.g., stage patches, then try to stage unrar and see what happens? | 21:18 |
| diddledan | I don't know what you mean "do the build interactively" | 21:19 |
| nacc | diddledan: like you can run `snapcraft` and it will build all the steps of the snap (I recommend in a LXD or vm) or you can do `snapcraft stage <part>` and just ahve it stage that part | 21:22 |
| nacc | diddledan: so maybe stage patches, take look at hte stage directory | 21:22 |
| nacc | diddledan: then stage unrar and see what it does | 21:23 |
| diddledan | without --stat I get no feedback, which is expected. BUT the simplified testcase reverts to my assumption in that it works fine, but the complex calibre build fails | 21:23 |
| diddledan | it's the same damned part definition in both casess! | 21:23 |
| nacc | diddledan: do you have a repository i can clone? | 21:24 |
| diddledan | I can make one | 21:24 |
| nacc | diddledan: might be easier (although i'm not a snap expert myself -- i can at least try and recreat your issue) | 21:25 |
| diddledan | https://github.com/diddledan/calibre-snap | 21:26 |
| nacc | diddledan: so i'm not sure if i follow -- is there a simple snapcraft yaml that does show the issue? | 21:26 |
| diddledan | no | 21:26 |
| nacc | ok | 21:26 |
| diddledan | the simplified testcase works fine | 21:26 |
| diddledan | with the same bloomin part definitions!?! | 21:26 |
| diddledan | I'm bashing my head against a wall here :-( | 21:27 |
| diddledan | it doesn't make any sense whatsoever | 21:27 |
| jdstrand | zyga: it is only debian-unstable-64, right? | 21:30 |
| sergiusens | kyrofa subprocess.check_call by hand and see what happens | 21:31 |
| sergiusens | kyrofa why is adt running for snapcraft#1739 ? | 21:32 |
| mup | PR snapcraft#1739: lxd: refresh remote container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1739> | 21:32 |
| kyrofa | sergiusens, I figured we wanted to get at least one pass on everything, no? | 21:32 |
| sergiusens | kyrofa travis already does that ;-) | 21:33 |
| kyrofa | sergiusens, haha, feel free to merge if you're happy with it, but the number of problems we built up because of exactly that is, well, not good | 21:33 |
| zyga | jdstrand: no, it also happened on 16.04-32 once | 21:59 |
| zyga | jdstrand: mvo thinks it is a race | 21:59 |
| zyga | jdstrand: or perhaps a sequence issue where earlier test is causing this one to fail | 22:00 |
| mup | PR snapd#4223 closed: cmd/snap-update-ns: misc cleanups <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4223> | 22:00 |
| jdstrand | zyga: if you want to disable the test and then assign me to fix it, I can look into it | 22:01 |
| mup | PR snapd#4224 opened: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224> | 22:01 |
| zyga | jdstrand: I think that's fine, I'll send a PR | 22:01 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/4224 is interesting, there are a few lines of changes there and lots of tests | 22:02 |
| mup | PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224> | 22:02 |
| zyga | jdstrand: reading the description will make the context for other layout PRs richer | 22:02 |
| nacc | diddledan: sorry, but your yaml makes very little sense to me :) | 22:02 |
| nacc | diddledan: how woudl `git apply` work if you're not i na git repo? | 22:02 |
| diddledan | it works fine | 22:02 |
| nacc | diddledan: you are giving it a raw tarball and asking it to treat it as a git repo? you should be using patch | 22:02 |
| jdstrand | zyga: added to list | 22:02 |
| nacc | diddledan: i don't see how it can (in general) ... the source isn't a git repo | 22:03 |
| diddledan | except in this particular case. if I pull everything except the patches and the unrar parts it works correctly. it only fails in situ with the rest of the yaml | 22:03 |
| nacc | diddledan: if you just use patch, does it work? | 22:03 |
| diddledan | git apply doesn't require a git repo | 22:03 |
| diddledan | I've proven the concept works. it is only in that full yaml that it fails | 22:04 |
| nacc | diddledan: ok | 22:04 |
| mup | PR snapd#4225 opened: cmd/snap-update-ns: tweak changePerform <Created by zyga> <https://github.com/snapcore/snapd/pull/4225> | 22:05 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/4226 this is the tuntap test, please merge that when green | 22:08 |
| mup | PR #4226: tests: disable interfaces-network-control-tuntap <Created by zyga> <https://github.com/snapcore/snapd/pull/4226> | 22:08 |
| mup | PR snapd#4216 closed: interfaces/time*_control: explicitly deny noisy read on /proc/1/environ <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4216> | 22:08 |
| mup | PR snapd#4226 opened: tests: disable interfaces-network-control-tuntap <Created by zyga> <https://github.com/snapcore/snapd/pull/4226> | 22:08 |
| mup | PR snapcraft#1739 closed: lxd: refresh remote container <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1739> | 22:09 |
| mup | PR snapd#4202 closed: cmd: use a preinit_array function rather than parsing /proc/self/cmdline <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4202> | 22:09 |
| zyga | jdstrand: if you want to please collect logs from https://travis-ci.org/snapcore/snapd/builds/302045926?utm_source=github_status&utm_medium=notification | 22:10 |
| zyga | jdstrand: this is where the test failed | 22:10 |
| zyga | jdstrand: the sequence number could be useful for reproducing this | 22:10 |
| zyga | jdstrand: once you collec that, please re-trigger the test | 22:11 |
| zyga | another instance is here: https://travis-ci.org/snapcore/snapd/builds/302478451?utm_source=github_status&utm_medium=notification on ubuntu-core this time | 22:11 |
| nacc | diddledan: so i staged everythinng, actually tried ot build it, got an error | 22:11 |
| diddledan | bingo | 22:11 |
| nacc | i went into the parts/unrar/src directory | 22:11 |
| nacc | ran `git apply ../../patches/install/unrar.patch` and it did nothing | 22:12 |
| zyga | the denial here is [Wed Nov 15 13:41:22 2017] audit: type=1400 audit(1510753282.329:205): apparmor="DENIED" operation="open" profile="snap.test-snapd-tuntap.tuntap" name="/dev/net/tun" pid=9534 comm="tuntap.py" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 | 22:12 |
| nacc | not a snapcraft problem, afaict, git doesn't want to apply the patch | 22:12 |
| nacc | diddledan: patch works | 22:12 |
| diddledan | now, nuke the parts, stage and prime directories and try again with this yaml (which is the same yaml with everything except unrar and the patch removed): | 22:13 |
| diddledan | https://www.irccloud.com/pastebin/to0fUZYt/ | 22:13 |
| diddledan | and your git apply command was missing a ../ which is why your manual apply failed | 22:14 |
| nacc | diddledan: no it wasn't? | 22:15 |
| nacc | parts/patches/install/unrar.patch is what i wanted | 22:15 |
| diddledan | oh maybe not missing a ../ - you're using the one copied into parts/ | 22:15 |
| nacc | diddledan: which is what snapcraft would be doing | 22:15 |
| diddledan | nope, snapcraft is using the one in stage/ | 22:15 |
| nacc | well, in this case the same file | 22:15 |
| nacc | diddledan: so, i'm going to say it one last time, because i've wasted way too much time on this | 22:16 |
| nacc | diddledan: i jsut did exactly what you said | 22:16 |
| nacc | the patch is also not applied | 22:16 |
| nacc | the parts happen to build | 22:16 |
| nacc | but http://paste.ubuntu.com/25970392/ | 22:17 |
| nacc | git-apply fails to apply the patch | 22:17 |
| nacc | patch succeeds | 22:17 |
| nacc | stop using git-apply :) | 22:17 |
| diddledan | seriously, git apply WORKS ON IT'S OWN! | 22:17 |
| nacc | no, it doesn't | 22:17 |
| nacc | look at the above output | 22:18 |
| diddledan | ffs | 22:18 |
| nacc | diddledan: please, just try with plain patch | 22:18 |
| nacc | see if it works | 22:18 |
| nacc | diddledan: if `git-apply` worked, i can provide another paste for this, thenn running git-apply, then running patch would result in patch reporting an error. It does not | 22:19 |
| nacc | diddledan: i will admite freely, i didn't know you could `git-apply` outside of a git repository. I don't know why you would want to, or what it gains you, but I am seeing a difference in behavior between git-apply and patch. I trust patch. | 22:20 |
| kyrofa | +1 on patch | 22:20 |
| nacc | diddledan: http://paste.ubuntu.com/25970412/ ... that's the paste i mentioned | 22:21 |
| diddledan | because you refuse to believe it works: https://paste.ubuntu.com/25970413/ | 22:21 |
| diddledan | that is using the tarball snapcraft downloads and the patch I'm trying to apply | 22:21 |
| diddledan | like I said, it works damned fine until I put it in the calibre snapcraft.yaml | 22:22 |
| nacc | diddledan: is the patch actually applied? | 22:22 |
| diddledan | yes | 22:22 |
| diddledan | or rather it is once I remove the --check because that kills apply like --stat does | 22:23 |
| diddledan | from the source that I just applied the patch to which isn't in a git repo, and had the patch applied with git apply: | 22:24 |
| diddledan | https://www.irccloud.com/pastebin/mXdBs4WB/ | 22:24 |
| diddledan | that is what I want the patch to do, make those two lines look like that! | 22:24 |
| * zyga looks at Nov 15 12:32:38 Pandora kernel: [15491.386617] audit: type=1400 audit(1510777958.562:790): apparmor="DENIED" operation="capable" namespace="root//lxd-brave-muskrat_<var-lib-lxd>" profile="/snap/core/3440/usr/lib/snapd/snap-confine" pid=28464 comm="snap-confine" capability=2 capname="dac_read_search" | 22:26 | |
| zyga | stgraber: (if around) does lxd/lxc do something special to systemd freezer cgroup? | 22:26 |
| nacc | diddledan: ok, i can see the bheavior you are seeing but I don't know why | 22:27 |
| nacc | diddledan: and i don't konw why in the snap directories, the same does not work | 22:27 |
| diddledan | don't use --check | 22:27 |
| nacc | diddledan: i would still be curious if just patch would work, if it's a weird thing with git (corner case) | 22:28 |
| nacc | diddledan: i wasn't | 22:28 |
| nacc | diddledan: if you really can't get it to work, just fork it on github and patch your source? | 22:28 |
| diddledan | oh frak me. I've just had a lightbulb and it's too damned bright it hurts | 22:29 |
| nacc | diddledan: what's that? | 22:29 |
| diddledan | my snapcraft is in a git repo. git recurses to all your subdirectories. previous uses of git apply had been in their own git repo checked out by snapcraft which overrode the snapcraft repo. you're right in that it's because it's not a git repo, but not just that, it's because it's not a git repo and THEREFORE INSIDE MY SNAPCRAFT git repo | 22:30 |
| nacc | diddledan: ah | 22:31 |
| nacc | diddledan: so it seems like ither use a git repo as the source, or use patch? | 22:31 |
| diddledan | so because it detected the .git dir way back up the chain it decided "I don't care that you were in that subdir, I'm going to apply your patch to the top-level where .git is!" | 22:32 |
| nacc | right | 22:32 |
| nacc | i thikn that's configurable -- i wonder if that should be set by snapcraft when it invokes git | 22:32 |
| nacc | since it can non-git nested inside git | 22:32 |
| nacc | should be relatively easy to make a testcase that shows the issue | 22:33 |
| diddledan | this looks to be the correct incantation for such an occurance: git apply --directory=. --unsafe-paths ../../../stage/unrar.patch | 22:42 |
| diddledan | or as you said, just use patch | 22:43 |
| nacc | diddledan: fun :) | 22:45 |
| diddledan | fudge me, that was confusing | 22:45 |
| nacc | diddledan: we were both right and wrong :) | 22:46 |
| diddledan | and of course it worked in my testcase because I made the testcase in a new dir that wasn't a git repo | 22:46 |
| nacc | right | 22:46 |
| mup | Bug #1732555 opened: Installing bad snap has snapd crashing <Snappy:New> <https://launchpad.net/bugs/1732555> | 22:51 |
| mup | PR snapd#4227 opened: tests: adding test for interface frame buffer <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4227> | 22:56 |
| diddledan | that incantation doesn't work actually. reverting to patch :-) | 22:57 |
| diddledan | wow, I am glad I know what was happening now, but boy what an idiot was I!?! :-p | 22:58 |
| diddledan | anywho, tis sleepytime methinks | 22:58 |
| kyrofa | elopio, do the bot subscriptions actually work for you? It never pings me on failures | 23:17 |
| kyrofa | snappy-m-o, github subscribe 1719 | 23:18 |
| snappy-m-o | kyrofa: I'll send you a message if a test fails in the pull request #1719 (many: account for python shebang args in rewrite). | 23:18 |
| mup | PR #1719: firstboot: add firstboot assertions importing <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1719> | 23:18 |
| kyrofa | I'll try again anyway | 23:18 |
| elopio | kyrofa: it worked last time I tried, but haven't in a long time | 23:20 |
| elopio | kyrofa: please let me know if you don't receive it, and I'll debug. | 23:20 |
| kyrofa | elopio, will do | 23:21 |
| kyrofa | elopio, is it technically possible for it to ping me when it finishes, regardless of success, and TELL me whether it succeeded or not? | 23:22 |
| kyrofa | Or is there no trigger for that? | 23:22 |
| kyrofa | (totally don't know how the bot works) | 23:22 |
| mup | PR snapd#4226 closed: tests: disable interfaces-network-control-tuntap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4226> | 23:26 |
| elopio | kyrofa: the bot doesn't know how many tests are running. It just sees when one finishes. | 23:30 |
| elopio | so to report success, you would have to give it the number of tests you expect. Or something more clever than that. Currenly, we have nothing like that. | 23:30 |
| kyrofa | elopio, you mean like the number of tests in a single adt run? | 23:31 |
| * kyrofa makes a google code-in task to count all our tests | 23:31 | |
| elopio | kyrofa: no, the number of tasks reported to the pr. | 23:31 |
| kyrofa | Haha, oh | 23:31 |
| kyrofa | elopio, so say I trigger both xenial:amd64 and xenial:i386 | 23:32 |
| elopio | currently, what it does is to listen on the updates to the PR. If one is a failure, it will ping you. Or something like that, I don't remember all the details | 23:32 |
| kyrofa | Regardless of success or failure, will it get two reports back from adt? | 23:32 |
| kyrofa | If so, I'd love to have it ping me twice, once with each result | 23:33 |
| elopio | kyrofa: well, you could subscribe also to successful results. Not implemented, but that is easy. | 23:34 |
| elopio | https://github.com/elopio/snappy-m-o/blob/master/plugins/snapcraft_github/snapcraft_github.py#L57 | 23:34 |
| kyrofa | elopio, ah, nice! Now I can make PRs when I want stuff? | 23:34 |
| elopio | kyrofa: do you mean, PRs to the bot? Of course! | 23:35 |
| kyrofa | Definitely | 23:36 |
| kyrofa | And it looks like it's a snap? | 23:36 |
| kyrofa | github_build is an interesting looking function | 23:37 |
| kyrofa | elopio, how do you test this, though? | 23:38 |
| kyrofa | elopio, first PR made | 23:46 |
| mup | PR snapd#4228 opened: interfaces,tests: skip unknown plug/slot interfaces <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4228> | 23:51 |
| mup | PR snapd#4229 opened: interfaces,tests: skip unknown plug/slot interfaces <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4229> | 23:51 |
| * zyga EODs | 23:52 | |
| sergiusens | kyrofa elopio why have the tests restarted? Can you at least add notes to the PR? | 23:53 |
| kyrofa | sergiusens, which ones? I didn't restart any | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!