[00:09] 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] PR snapcraft#1717: catkin plugin: check for pip packages in part only [00:41] * ikey is doing his last clean local builds ready for upload :3 [01:03] so uhm [01:03] Pushing solus-runtime-gaming_0.0.0_amd64.snap [===========================] 100% [01:03] [1] 9686 segmentation fault snapcraft push solus-runtime-gaming_0.0.0_amd64.snap [01:03] idk what happened [01:03] processing went kersplat [01:04] and i believe thats because it never expected to need a manual review [01:04] ikey it is python, I don't expect a segmentation fault but a traceback instead [01:04] python is special [01:04] this is much worse of a thing to track down I fear [01:05] yeah [01:05] I will look into it [01:05] so who manually reviews snaps? :D [01:05] ikey among them is jdstrand [01:05] oh ok [01:06] my assumption is i can't actually upload my lsi snap until the base snap is in as it depends on it [01:10] ikey so the one that failed to push is the one with a base decl? [01:10] yeah [01:10] (NEEDS REVIEW) type 'base' not allowed lint-snap-v2_snap_type_redflag [01:10] 0 Warnings [01:10] 22 Passes [01:11] kyrofa the arm64 test might take for ever and ever [01:11] full error: https://hastebin.com/raw/vayobosulu [01:11] setuid binaries won't be usable inside there anyway [01:11] it also dislikes symlinks :p === JoshStrobl is now known as JoshStrobl|zzz [01:14] * ikey will nuke them for the next build to clean it up [01:23] wtf i cant use bin in my snap [01:29] bin/linux-steam-integration.exec glxgears does not exist lint-snap-v2_command (glxgears) [01:29] ok the review system is dumb. [01:30] like clinically stupid [01:31] command: bin/linux-steam-integration.exec linux-steam-integration.settings [01:31] it won't accept that [01:33] * ikey is unable to upload snaps at all, woo. [01:54] * ikey made a workaround ^^ [01:55] ikey we in snapcraft wrap those in scripts [01:55] the `command` [01:55] yeah i just made it do the same [01:55] https://github.com/solus-project/runtime-snaps/commit/3cdf7f2d9f06187a76e26465551f470561be3de2 [01:55] "tada" [01:55] I don't think that review tool is geared toward reviewing base snaps [01:56] oh that rejection was for LSI itself [01:56] ive now got LSI actually uploaded and accepted [01:56] but yeah it hates base snaps and forbids them [01:56] so the solus-runtime-gaming is still pending [01:57] 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] there, rejected [01:58] * ikey builds the new clean guy [01:58] kyrofa your arm64 adt run started! [01:58] PR snapcraft#1736 closed: recording: pass the build info flag to the container [01:58] sergiusens, yeah you're right... still waiting on that :( [01:58] Oh! Haha [01:58] Well that's good. Another four hours... [01:59] kyrofa I am going to go to bed though or I will be toast tomorrow [01:59] sergiusens, yeah not worth it [01:59] We'll pick it up again in the morning. Almost there [01:59] kyrofa I might wake up super early though [02:00] I forgot I need to prepare my presentation for pyconar this weekend too [02:00] oh, and Monday is a holiday [02:00] so many things to do, so little time [02:00] Yeah I hear you! [02:00] sergiusens, sleep well, talk tomorrow :) [02:00] o wat dashboard has download stats [02:02] 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:03] * ikey creates more work for himself [02:08] ok linux-steam-integration rev3 is on edge now [02:08] devmode [02:13] PR snapcraft#1732 closed: tests: dotnet only works on 16.04 [02:14] 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] PR snapcraft#1717: catkin plugin: check for pip packages in part only === chihchun_afk is now known as chihchun [02:34] i fixed the remaining issues with the solus-runtime-gaming, has 0 warnings now [02:34] just 1 error [02:34] its a base snap [02:34] and it requested review by itself [03:31] kyrofa: sergiusens: found it: https://github.com/snapcore/snapcraft/pull/1717/commits/b1768cc851adc1c94e08a063b2479269805a4580 [03:31] PR snapcraft#1717: catkin plugin: check for pip packages in part only [03:31] snappy-m-o autopkgtest 1717 xenial:armhf xenial:arm64 [03:31] elopio: I've just triggered your test. [04:00] sergiusens, elopio nooooooooooooo [04:01] sergiusens, I didn't scroll back that far, just saw some errors in the middle of catkin tests [04:02] Well, should be done by morning-ish anyway [04:02] elopio, thanks for pushing a fix :) === 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 [05:00] snappy-m-o autopkgtest 1717 xenial:armhf xenial:arm64 [05:00] elopio: I've just triggered your test. [06:41] snappy-m-o autopkgtest 1717 xenial:arm64 [06:41] elopio: I've just triggered your test. [06:46] o/ [07:04] mvo: hey, good morning; I'm just waking up here, any fires related to debian image update? [07:07] zyga: good morning. all quiet on the debian image [07:07] zyga: at least afaict, not many PRs since last night it seems [07:08] zyga: but at least some from jamie that did succeed [07:08] interesting [07:08] I'll boot sid and see if anything was reverted [07:09] last night cachio helped me refresh the image so in theory we should be running apparmor now [07:09] moin moin [07:10] zyga: cool [07:10] zyga: yeah, I have some 2.30 tasks and need to chase why 2.29 is not in stable yet [07:11] mvo: any fires there or just unknown? [07:12] zyga: I'm trying to find this out now [07:16] 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:24] 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] Bug #1732359: installation snap vlc / stable fails with: ERROR open /snap/vlc/7/meta/gui/vlc.desktop: no such file or directory

[07:24] not* installable [07:26] jibel: thanks, looking [07:26] jibel: and good morning :)! [07:27] jibel: I can reproduce, its a broken symlink in the snap [07:30] Good morning mvo [07:30] it's weird it reached stable and no one noticed it is not installable [07:32] jibel: yeah, also it seems like stable->edge all have the same revision of vlc [07:32] jibel: version says "daily" [07:32] jibel: I guess we need to reach out to them and suggest to use "daily" for "edge" and not stable :) [07:32] mvo: note the revision, 7, meaning it's not daily [07:33] mvo: unless they count days at pluto frequency [07:33] zyga: why not? [07:33] zyga: maybe they just started 7 days ago, I have no insight into this [07:33] mvo: it was "daily" and ~5 in heildenberg [07:33] (I honestly don't know when they started to publish it) [07:33] (sorry for spelling that wrong) [07:33] zyga: uhhhh, ok. so daily for a day long ago [07:33] it's just "not actively maintianed" [07:33] :( [07:50] hmm, debian seems to be working [07:50] I'll check if we get the right image for real [08:01] eh :) [08:01] mvo: so cachio or gustavo mixed up the two [08:01] mvo: and "sid" and "stretch" are swapped [08:02] zyga: heh [08:02] zyga: ok, mystery solved [08:02] mvo: hmm, actually, it's the same old image [08:02] mvo: I changed sources.list in both [08:02] we are not on the new images yet [08:02] I guess I'll just talk to cachio later today [08:09] zyga: so I feel slightly proud of myself [08:09] I delved into the world of ELF deps and didn't drown [08:09] I didn't really like messing around with ELF data, though :/ [08:10] top elf tip: alias readelf='readelf --wide' [08:12] mwhudson: oh if only it were that simple [08:12] I was using libelf directly [08:12] ah [08:13] i actually quite like go's debug/elf [08:13] it doesn't support reading all the attributes, but it's a nice API [08:14] Son_Goku: what are you trying to do? [08:14] do you really want to know? [08:14] yes [08:14] I like elf and things like tat [08:14] https://github.com/rpm-software-management/rpm/pull/360 [08:14] PR rpm-software-management/rpm#360: elfdeps: Add full multiarch deps support [08:14] that [08:15] is rpm going multiarch? [08:15] well, rpm is going to support it [08:16] it's up to distributions if they want to do a multiarch scheme of some kind [08:17] elfdeps is actually the only bit of rpm that wasn't multiarch-safe already [08:17] as it predates rpm's own multiarch support [08:19] thank you for pushing that in your spare time :) [08:21] the only thing I'm not sure about is if this handles x32 properly [08:22] Son_Goku: I played with x32 lately, I'm actually very fond of this idea [08:22] Son_Goku: object size is very compact and you have all the instructions and registers [08:22] I don't know what it looks like from ELF [08:22] Son_Goku: for vast majority of my work x32 is sufficient [08:22] Son_Goku: in which sense? [08:23] oh interesting [08:23] it comes up as x86-32 [08:23] that's probably not good [08:23] I think it's called x32 more often [08:24] but naming and off by one and so on :) [08:24] so here's the interesting bit [08:24] it is elfclass32 [08:24] but machine is x86_64 [08:25] right, because that probably defines various pointer sizes and what not [08:25] right [08:25] and I also suspect nobody thought of this when elf was designed [08:25] I think that's a pretty safe assumption [08:25] as people thought it would just grow and grow [08:25] oh god, this means I need to special-case this [08:25] offtopic, meld and gnome look really amazing [08:37] snappy-m-o autopkgtest 1717 xenial:arm64 [08:37] sergiusens: I've just triggered your test. [08:38] zyga: and now I added handling for x32 [08:39] Son_Goku: given that an average consumer PC has 4GB of ram or less, I'd love to see windows use x32 [08:39] not going to happen [08:39] Son_Goku: so that linux folks with their 32GB machines would notice [08:39] Son_Goku: never say never [08:39] I probably should add support for x32 to the regular elfdeps mode [08:39] Son_Goku: microsoft is quite a surprise source lately [08:39] since I am touching that code... [08:40] Son_Goku: and on that sense it would also make sense in arm phone world [08:40] there, absolutely [08:40] Son_Goku: and by extension in iot [08:41] 512MB board with 64bit CPU running in x32-like mode === JanC is now known as Guest41818 [08:42] brb [09:19] PR snapd#4204 closed: store: enable "base" field from the store [09:31] eh all phone cpus just implement aarch32 still don't they? [09:31] it seems noone can quite decide if arm64ilp32 is worth it yet [09:31] mwhudson: I think the trend is clear for aarch64 being used by most now [09:32] zyga: i mean, 64-bit phone cpus implement the old arm 32-bit instruction set as well [09:32] there are server cpus that don't but they also have gobs of ram [09:32] mwhudson: yes, that's true [09:45] :( my base snap is already outdated and needs redoing [09:46] PR snapd#4219 opened: snap/validate: extend socket validation tests [09:48] jdstrand, hi, just saw your messages from yesterday, I pushed ^^ with the changes you requested since the branch was merged already === __chip__ is now known as Chipaca [09:54] 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] so i won't be around until ~midday, assuming they're on time [09:59] Chipaca: good luck! === JoshStrobl|zzz is now known as JoshStrobl [10:51] PR snapd#4210 closed: many: add magic /snap/README file [10:53] snappy-m-o autopkgtest 1717 xenial:arm64 [10:53] sergiusens: I've just triggered your test. [10:53] 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:54] PR snapd#4217 closed: interfaces/browser-support: add shm path for nwjs [10:54] PR snapcraft#1735 closed: unit tests: reset log level after test [10:57] PR snapd#4207 closed: Flesh out NVIDIA support for biarch and multiarch systems [11:03] snappy-m-o autopkgtest 1717 xenial:i386 [11:03] sergiusens: I've just triggered your test. [11:11] hrm, asciicasting is harder than it looks, when you make stupid mistakes like leaving a folder around after the dry run [11:12] mvo: is master broken? I got a couple of emails about it, though recent merges seemed innocent enough [11:20] 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:21] PR snapd#4220 opened: snapd: allow hooks to have slots [11:21] pedronis: it looks like the opensuse repo has a hickup, I will disable opensuse for the moment I think [11:36] 4214 needs a second review - should be easy peasy [11:38] mvo: done [11:41] zyga: \o/ [11:41] PR snapd#4214 closed: fakestore: add go-flags to prepare for `new-snap-declaration` cmd [11:54] 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:55] mvo: for 2.29 that's it, and some improvement bits on that are in 2.30 [11:55] pedronis: thank you [11:56] 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] (or "done", "2.29") [11:56] "upcoming" "2.29" [11:57] 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:58] mvo: in theory we (Gustavo) put stuff in the roadmap topic that we know will come [11:58] but there's often more/smaller stuff too [11:58] also don't know how that process will change [11:58] mvo: I would be ok to have further tags personnaly [11:59] 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] s/fell/feel/ [12:00] pedronis: yes [12:00] Chipaca: silly question, do we have a forum topic describing the new ansimeter? [12:06] sergiusens: I sent you my gist. also note the bug I just found... I'll make a PR for it asap [12:12] 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:13] 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:17] mvo: wonder if it's the syntax or something about perms we don't understand [12:17] 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:18] pedronis: yeah, worth raising during the standup I think, maybe gustavo knows (he knows the software best afaict) [12:20] 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:21] pedronis: As long as we can stick to it, more metadata is good [12:21] pedronis: As long as it's useful as well, obviousy [12:23] ... and on that note, I really need to get driving or we won't get there today [12:23] o/ [12:23] yea, I tend to be ok with process (within reason), but yes unclear we follow already current process [12:24] 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:33] mvo: this is also 2.30 https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774 and needs more work ? [12:40] PR snapcraft#1737 opened: cli: pass remote from container_config to clean method [12:45] hi [12:46] would anyone know how to deal with https://paste.ubuntu.com/25967274/ ? [12:49] axino: hey there [12:49] did you manually tinker with the mount ? [12:49] 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:50] not that I know of [12:50] ogra_: it's a bug in 14.04 and inside containers [12:50] ah, 14.04 ... [12:50] (this is a xenial container yes) [12:50] ogra_: this is a container here actually [12:50] axino: not sure if this will help you, but: [12:50] yes, i noticed the container [12:51] axino: you can unmount those things manually (all the mounts in /snap/*/*) [12:51] axino: then you should be able to: sudo mount --bind /snap /snap; sudo mount --make-rshared /snap; [12:51] FWIW I found I could "snap changes" and "snap abort" but it doesn't help [12:51] axino: then you should be able to sudo systemctl start each of the mount units [12:51] axino: and then it should recover [12:51] axino: that's roughly what my in-progress fix is trying to do [12:52] zyga: should I stop snapd first ? [12:52] axino: you can but it doesn't (should not) matter [12:55] zyga: now the core snap is broken :x [12:55] axino: did you mount everything back? [12:55] axino: ideally paste the steps you took [12:56] axino: look at /etc/systemd/system and start all the mount units back (or mount them manually) [12:56] zyga: https://pastebin.ubuntu.com/25967312/ [12:57] (what I used to start the mounts back) [12:57] who can i beg or bribe for snap store review? :) [12:57] err [12:57] the units I started are gone [12:57] pedronis: yes [12:57] pedronis: thank you [12:57] axino: hmm [12:57] axino: what is actually mounted? [12:57] zyga: it was looking like this https://pastebin.ubuntu.com/25967315/ [12:58] no [12:58] I mean moubted [12:58] not what systemd things [12:58] thinks* [12:58] zyga: https://pastebin.ubuntu.com/25967318/ [12:58] 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] axino: how about /proc/self/mountinfo [12:59] zyga: https://pastebin.ubuntu.com/25967323/ [12:59] mvo: he answered, I think he said ok if we manage to stick to it [12:59] pedronis: aha, cool. sorry missed the reply [13:00] axino: ok this looks good now [13:00] axino: now go to /etc/systemd/system and look at the mount units you see [13:00] niemeyer: thanks about your reply for the tags [13:00] start the core one [13:01] zyga: https://pastebin.ubuntu.com/25967332/ [13:01] OK starting the last core one [13:01] axino: ok, start each one one by one [13:01] axino: then start snapd [13:01] zyga: OK we're back in business [13:01] axino: and that should work [13:01] zyga: thanks o/ [13:01] axino: and my fix is doing essentially that, just working on some details [13:02] ok [13:02] axino: thank you for testing this! :) [13:02] zyga: will that impact every "snap remove" under LXD ? [13:02] axino: no [13:02] axino: well, the bug affects a lot of things [13:02] 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] axino: then it's all good [13:03] ok [13:03] axino: what we did here was the more costly/complex recovery process [13:04] mvo: i did not write about ansimeter [13:07] PR snapcraft#1738 opened: unit tests: make the check for output less strict [13:11] Chipaca: did you see this: https://forum.snapcraft.io/t/do-not-print-the-progress-bar-when-running-snap-commands/2816 ? [13:13] pedronis: i hadn't; commented [13:26] jdstrand: around? [13:31] mvo, PR #4218 [13:31] PR snapcraft#1739 opened: Lxd refresh remote [13:31] PR #4218: tests: adding tests for time*-control interfaces [13:31] this is the new one [13:31] I closed the other one before more people look at it [13:32] mvo, https://travis-ci.org/snapcore/snapd/builds/302294954#L4740 [13:32] this is the error I see in ubuntu core, with timezone = n/a [13:32] mvo: will you create the 2.30 2.31 tags ? [13:43] kalikiana how confident are you in your PRs? [13:44] kalikiana can you add notes on what you tested? [13:44] 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:45] lemme document what I did [13:47] kalikiana please check [13:52] tea [14:07] jdstrand, updated the PR, thanks for the review [14:15] flexiondotorg: around ? [14:34] zyga: hey, yes [14:34] ackk: thanks! [14:40] jdstrand: I updated the secure-file PR [14:41] pstolowski: what snap can i use to play with config? [14:41] was looking for 'test-snapd-conf*' but that's not it [14:43] pedronis: sorry for the slow reply, I am still trying to figure out how to define new tags [14:43] pedronis: where? [14:43] um [14:43] mvo: where? [14:43] :-) [14:44] Chipaca, do you need something for a spread test? [14:44] Chipaca: in the forum [14:44] pstolowski: for playing with snnapshots [14:45] mvo: you need admin [14:45] i think [14:45] Chipaca: I have this (I think) - maybe not enough of it [14:45] mvo: what tag do you want to create? mind if i do it for you? [14:45]