=== JanC_ is now known as JanC [03:37] hrm, i've been seeing some ProxyError's from the lp snap builders (worker earlier today and stopped for the last three): https://launchpadlibrarian.net/328378888/buildlog_snap_ubuntu_xenial_i386_git-ubuntu_BUILDING.txt.gz [03:37] cjwatson: --^ [03:37] it seems to be a perm error when trying to get the core snap? [03:54] PR snapd#3581 opened: Add polkit authorization support to /v2/login === chihchun_afk is now known as chihchun [06:13] !tryme [06:13] It works ! [06:25] PR snapd#3579 closed: snap-seccomp: link libseccomp statically to snap-seccomp [06:35] !tryme [06:35] It works ! [08:02] good morning [08:06] morning! [08:56] PR snapd#3582 opened: Merge release 2.26.9 back into master [08:57] * zyga hugs mvo [08:57] PR snapd#3583 opened: tests: fix econnreset test in 2.26 (store urls changed) [08:58] * mvo hugs zyga [09:06] er all my classic snap builds failed [09:06] downloading the core snap failed with [09:06] HTTPSConnectionPool(host='api.snapcraft.io', port=443): Max retries exceeded with url: /api/v1/snaps/download/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_2314.snap (Caused by ProxyError('Cannot connect to proxy.', OSError('Tunnel connection failed: 403 Forbidden',))) [09:13] * zyga fixes a typo in fedora build [09:14] (space exploding typo) [09:26] Pharaoh_Atem: can you please allow me to push to https://github.com/snapcore/snapd/pull/3577 [09:26] PR snapd#3577: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora [09:27] * zyga -> quick breakfast [09:27] mvo: I have a fixed fedora branch, if Pharaoh_Atem doesn't respond soon (it's early for US so I don't expect him to) we can just push that to a separate branch and close his PR [09:27] mvo: together with your fix for econreset it should fix master [09:27] zyga: sounds good [09:29] /home/gopath/src/github.com/snapcore/snapd/tests/lib/boot.sh: line 14: fw_printenv: command not found [09:29] hmm [09:30] nacc: Yes, see RT#104230 [09:30] mwhudson: ^- you too [09:33] mvo: since I "care" more about it now, I will improve proxy support for qemu testing [09:46] nacc,mwhudson,stokachu: classic snap builds should be fixed now; try again [09:48] PR snapd#3577 closed: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora [09:48] PR snapd#3584 opened: packaging: fix Fedora support [09:55] zyga, you could have just asked for me to turn your ability to push on [09:55] Son_Goku: I did :) [09:55] Son_Goku: (earlier above) [09:55] you asked the wrong me :) [09:55] but anyway, it's on [09:55] Son_Goku: I poked Pharaoh_Atem though, sorry about not realizing both of your accounts were on [09:56] thanks! [09:56] did you turn it off before? [09:56] I wonder why it wasn't on in the first place [09:56] zyga: I turn it off by default because sometimes people rewrite commits without telling me [09:56] Son_Goku: aha, good [09:56] Son_Goku: I was just curious if some github default changed [09:56] and I really hate it when I'm attributed to things I didn't do :) [09:56] Son_Goku: I will have one more fedora improvement for testing in a moment [09:56] okay [09:57] well, you can reopen my PR and push there [09:57] this one is already in progress (testing) so it would not be any diferent [09:57] all of your commits are there alreday :) [09:57] (unchanged) [09:58] * Son_Goku shrugs [09:58] okay then [10:12] PR snapd#3582 closed: Merge release 2.26.9 back into master [10:16] PR snapcraft#1403 opened: lxd: Only remove container if one exists [10:26] curious [10:27] mvo: so... [10:27] mvo: I bet that fedora doesn't provide libseccomp.a [10:27] mvo: ... :-( [10:27] * zyga wants to start entertaining alcoholic addition [10:28] zyga: right, we can link it dynamically there [10:28] zyga: we really only need the static build on the core snap [10:29] mvo: which is why I asked about it yesterday :) [10:29] technically... libseccomp.a *does* exist, though [10:30] Son_Goku: it does? (my fedora box is not unpacked yet) [10:30] Son_Goku: which package is it in? [10:30] all static link libraries are separated out into -static subpackages [10:30] ah [10:30] perfect [10:30] I'll make it happen then [10:30] ugh [10:30] Son_Goku: for today that's the best way [10:30] * Son_Goku groans [10:30] fine [10:30] Son_Goku: we can expore build tags and dynamic linking but mvo needs to get this out [10:31] wait, are we going to have 2.27 today or something? [10:31] Son_Goku: I personally would love to drop libseccomp and just genrate bpf from go (because I'm a compiler addict) [10:31] Son_Goku: that's a question for mvo [10:31] please don't make me cry [10:31] golang makes me sad [10:31] the ecosystem is nuts [10:31] great, aint it ? so you only need blots for functional apps ;) [10:32] *bolts [10:32] I've even heard from ex-Googlers that most Googlers hate golang [10:32] Son_Goku: why? [10:33] the development experience is really bad [10:33] Son_Goku: (I really really like writing precise bpf programs from snapd directly) [10:33] and maintaining golang packages is obnoxious [10:33] Son_Goku: anyway, not arguing about golang being nice or not [10:33] like, as in with the way vendoring works and whatnot [10:33] at least one person told me there are more people who like D than there are who like golang [10:34] it's pretty much the domain of the borg group [10:34] (which makes kubernetes) [10:34] Hello! I have a question related to the snapcraft.yaml 'install:' bit that can be defined for a given part [10:34] I can't find any documentation [10:35] When is that run? At which step? [10:35] * zyga doesn't get the vendoring argument (vendoring is a fact, how does golang make it different from python, ruby, C and others?) [10:35] the problem is that golang vendoring works based exclusively off of git commits [10:35] which makes things way more brittle than you think [10:37] zyga, also, not having a debugger unless you use gccgo sucks ass [10:37] Son_Goku: debugger yeah, but then again golang behaves differently from other languages, I rarely use debugger in python (and when I did it was because C exploded) [10:38] but python provides tracebacks and repl capabilities [10:38] Son_Goku: golang has tracebacks as well [10:38] golang compiler failures are inscrutable, too [10:38] as we found out a couple of weeks ago [10:38] Son_Goku: ??! [10:38] well [10:38] those were very much not golang but gccgo and on unsupported arch, right? [10:39] zyga: we weren't using gccgo [10:39] Son_Goku: all I'm saying is that daily hacking on golang code is anything but bad [10:39] * Son_Goku shrugs [10:39] Son_Goku: on ppc64 we were, I tink [10:40] I've had to figure out failures on armv7hl before [10:40] hl? [10:41] offtopic [10:41] armv7l with hfp (hard-float) [10:41] ah [10:41] debian calls it armhf [10:41] hf in debian land [10:41] right [10:41] but the internal architecture name is armv7hl [10:41] offtopic: I found my warcraft 2 CD [10:41] ooh nice [10:41] and it's slightly scratched :-( [10:41] Nooo :( [10:41] I'm playing the soundtrack [10:41] but some tracks (my fav) are not working [10:42] ah, the days where games abused CDAudio for music :) [10:43] yeah [10:43] tack 2 and track 3 are very nice [10:43] * zyga looks at fedora VM prep [10:45] zyga, Son_Goku: you could simply sed aways the #cgo LDFLAGS: -Wl,-Bstatic via the spec file if you want to get rid of the static linking [10:45] that seems like the simplest option for now [10:46] PR snapd#3585 opened: many: configure store from state, reconfigure store at runtime [10:46] welp, that's up to zyga now, I can't do anything anymore [10:46] he closed my PR :) [10:47] mvo: but at least, my spec compiled as of yesterday [10:47] zyga, Son_Goku: re 2.27 - I want to discuss this today, my idea is to have a 2.27~rc1 today and see if it behaves well everywhere (it got more churn than usual). and if that looks ok a real 2.27 EOW maybe [10:47] okay [10:47] Son_Goku: \o/ for the spec work [10:47] Son_Goku: or maybe early next week, but definitely soon as its overdue [10:47] mvo: sounds like a plan [10:48] yeah, it's a couple months overdue :P [10:48] I was hoping for 2.27 to be in Fedora 26 [10:51] *cough* [10:52] sil2100: check out https://snapcraft.io/docs/build-snaps/scriptlets [10:52] davidcalle: oh! Thanks! I see it there [10:54] ugh [10:54] why does my fedora VM use de keymap? [10:54] why doesn't localectl change it :/ [10:54] because you're nuts and you have too much stuff [10:54] *V-M* [10:54] you need to use set-keymap [10:54] with localctl [10:55] I did [10:55] but I was foolish [10:55] to assume "en" is sane [10:55] I wanted "us" [10:55] en is just the same as "de", just worse [10:55] :/ [10:55] keys are all over [10:55] us works, I can do what I wanted [10:56] eh, my wired network caps at 0.5MB/s [10:56] because yeah, that's why [10:57] mvo: well, I'll just ship it as an update [10:57] it's no biggie [10:57] it's not like it's a pain to ship updates :P [10:57] yeah, that's true :-) [10:58] later today I'll try to put my fedora box up so I can have real hardware to work on [11:20] Son_Goku: so, where is libseccomp-devel-static? [11:20] it's just libseccomp-static [11:20] (took my a while but now I have a shell) [11:20] ah [11:21] thanks! [11:21] "dnf repoquery *-static" will give you a list of them all [11:40] ok, pushed to 3584 [11:40] tests fine locally [11:43] :/ [11:43] what's wrong? [11:45] do you know how to use "git rebase" with arbitrary remotes? [11:45] Son_Goku: yes [11:45] Son_Goku: first add the remote [11:45] Son_Goku: then fetch [11:45] Son_Goku: then just reabse against remote/branch [11:45] yep [11:46] I'm a bit weirded out by the merge commit in PR#3584 then [11:46] Son_Goku: I didn't rebase, I merged master [11:46] Son_Goku: note that snap-seccomp is a part of snapd, not snap-confine [11:47] I'm aware [11:47] Son_Goku: and the distinction is more less arbitrary now [11:47] yes, it's for my own sanity [11:47] meh, I don't care [11:47] I'll resync everything later from Dist-Git [11:47] not sure I understand [11:47] ok [11:47] I can move it around [11:47] I want to land this to unbreak fedora and then we can polish the layout [11:47] yeah, go ahead [11:48] so what is the layout you want? [11:48] I prefer keeping security stuff together, and the C stuff typically lives in snap-confine [11:49] because snapd is already insane enough as it is, I try to keep things separate in such a way I know which parts to touch every time something breaks [12:05] mvo: a test just failed on db http://paste.ubuntu.com/25074862/, other than that things are looking very good [12:13] oh [12:13] how did that happen? [12:15] fgimenez: what is the output of /usr/lib/snapd/snap-seccomp there? and that is the revision of the core? [12:16] mvo: this was executed on testflinger, i don't have access to the testbed, the scenario is the basic beta image, core should be from beta without refreshes [12:16] fgimenez: found it [12:16] fgimenez: please re-run [12:17] mvo: sure on it [12:17] geez, tests are sure slow today [12:17] fgimenez: there was an error on snapcraft release for the arm64 revision, now its good [12:17] mvo: great thanks! [12:21] re [12:22] PR snapd#3583 closed: tests: fix econnreset test in 2.26 (store urls changed) [12:26] thanks! [12:35] a small observation, I patched spread to spawn 4 core VMs and this cut a good 3 minutes out of 15 minute run of fedora tests/main/help [12:35] s/15/18/ [12:35] so down from 18 minutes before to 15 minutes after === mpontillo_ is now known as mpontillo === icey_ is now known as icey === nottrobin_ is now known as nottrobin === mariogrip_ is now known as mariogrip === tai271828__ is now known as tai271828_ === mjl_ is now known as mjl === mup_ is now known as mup === cwayne_ is now known as cwayne [12:41] mvo: bummer [12:41] mvo: time exceeded [12:42] another hour wasted [12:42] on 3584 [12:43] mvo: please advise, do you want to merge it anyway or re-run [12:44] zyga-suse: can we increase the workers or something? I would really like to not override this [12:45] cjwatson: thanks building now [12:45] mvo: let me check [12:45] pushed update with more workers [12:46] ta [12:46] though what has failed seems to be ubuntu-16.04-64 [12:46] I think that one could use x10 workers (up from 4) [12:46] I can try and see what we get [12:46] (say up to 6) [12:47] 24 VMs for each git push [12:47] that's $$$ [12:51] zyga-suse, did you get a timeout for fedora? [12:52] no [12:52] travis 49 minute timeout [12:53] ok, because it is not needed to increase the number of workers for suse and fedora if they they running one test [12:54] zyga-suse, do you have a link to see the timeout ? [12:55] yes but I cannot paste it ... one sec [12:55] https://travis-ci.org/snapcore/snapd/builds/252773594?utm_source=github_status&utm_medium=notification === didrocks1 is now known as didrocks [12:59] zyga-suse, there was a problem with linode that caused the several machines were discarded [13:00] zyga-suse, that caused the delay on the execution [13:00] zyga-suse, I'll monitor that to see if it happen again [13:21] mvo: it passed! [13:22] mvo: can you please review 3584 [13:22] cachio, fgimenez: can you please review it from the POV of incresed worker count [13:23] zyga-suse: you dropped the increased capacity for fedora/opensuse :( [13:24] Son_Goku: because cachio will increase it in his branch that unlocks +100 tests [13:24] ah [13:24] Son_Goku: he's already done this for Fedora, going through suse [13:24] Son_Goku: this branch doesn't need the extra workers here (yet) [13:29] fgimenez, cachio, mvo: shall I decrement the workers back to 4? [13:30] cachio, I think so [13:30] zyga-suse, [13:31] zyga-suse, I'll try to see what is happening with those machines that are discarded [13:32] zyga-suse, but it seem to be a problem in linode [13:33] zyga-suse: sure on it [13:33] * Son_Goku sighs [13:34] it works now, can't we just merge it? [13:36] zyga-suse: I'm wondering where 'suse' fits in https://en.wikipedia.org/wiki/Japanese_honorifics [13:37] oh :) ? [13:37] heh :) [13:37] Chipaca, niemeyer: after you discuss the services API I'd like to know if the evolution of that idea has any impact on the interfaces api [13:40] Son_Goku: I'd like to [13:40] then hit the green button [13:40] mvo: can you make a call? [13:41] * Son_Goku hypnotizes mvo to say 'yes' [13:41] Son_Goku: I need more reviews [13:41] Son_Goku: offtopic, in my language we often use "no" to indicate "yes" and "nie" to indicate "no" [13:41] Son_Goku: we also have "tak" which is just "yes" but "no" is used very often [13:48] * zyga-suse fetches tea [13:49] zyga-suse, just move the workers to 4 and push, you will have a green in 40 minutes [13:51] zyga-suse, otherwise we will be wasting resources for all the pushes [13:52] done [13:52] let's see [13:55] zyga-suse: lets wait for another run, 2.27 is still in ~rc so things are not super urgent just yet [13:57] mvo: yep, sounds good [13:57] if you can review the change it would accelerate the time to landing (once green) [14:09] zyga-san, I don't think it impacts the interfaces api, at least in the short term [14:10] zyga-san, there'll still be a /v2/apps/ endpoint with nice juicy appy stuff [14:10] zyga-san, and a /v2/logs/ for all your woodworking needs [14:11] Chipaca: aha, I see, thank you [14:12] Chipaca: I see you are feeling honorific today :) [14:12] zyga, you started :-p [14:12] me? [14:13] “zyga-suse” :-) [14:13] Chipaca: LOL :D [14:17] * Pharaoh_Atem sighs [14:17] back to the grind [14:21] fgimenez, the dragonboard-kernel in edge is quite a bit behind the other channels, any objections to bumping it to the same version the others have ? [14:24] ogra_: any at all , in fact we currently start using it at beta, hopefully will be watching edge changes for db soon, thanks! [14:24] great, thanks ! [14:26] mvo: fedora fix merged [14:27] PR snapd#3584 closed: packaging: fix Fedora support [14:34] cjwatson, hey, does LP reuse/cache instances it builds snaps on? alan_g's seeing weird behaviour after fixing snapcraft.yaml - it failed on 50% of arches... https://launchpad.net/~alan-griffiths/+snap/mircade-snap [14:38] Saviq: there's no reuse, no [14:39] why would we ever see "Skipping pull... (already ran)" then¿? [14:39] Saviq: because LP runs snapcraft more than once [14:40] Saviq: because launchpad builders run each command [14:40] ah separately, ok [14:40] they first run `snapcraft pull` and then the others [14:40] this is from the time of only having network during pull [14:40] yeah, it's slightly historical now, but meh [14:40] then there's a race of some kind... [14:41] yeah, you're doing a parallel build so my money is on a bug in that build system [14:41] try it in cleanbuild a few times maybe [14:41] well, "that build system" being snapcraft, as far I can tell... [14:42] since it tries to operate on a part directory it's not created yet [14:44] Saviq: install should be created. What is not is the leaf directory of `usr` [14:45] zyga: are you (or is somebody) working on getting spread running on opensuse again? [14:45] Saviq: may I be so bold so ask you to look in your cmake given the `-j4` (you can disable parallel builds in the yaml) [14:46] sergiusens, it fails on the games part, which uses the nil plugin [14:46] and is just a dump stage-packages dump [14:46] dumb, even [14:46] Saviq: oh, I am looking at https://launchpadlibrarian.net/328470482/buildlog_snap_ubuntu_xenial_i386_mircade-snap_BUILDING.txt.gz [14:46] what should I be looking at? [14:46] sergiusens, yeah, that's it, [Errno 2] No such file or directory: '/build/mircade-snap/parts/games/install/usr' [14:48] zyga, we are doing "dnf -y -q upgrade" when we prepare the project on fedora and it could be skipped [14:48] zyga, is it right? [14:48] no need to refresh metadata if using dnf [14:48] cachio: not sure if, I think it might have been there for a reason [14:48] sergiusens, oh and btw, cleanbuild --debug does not give me a shell after this failure :/ [14:48] cachio: we do a similar "apt-get update" [14:49] Saviq: unfortunate :-/ [14:49] Saviq: that failure however is from running the miral part (`games`) === chihchun is now known as chihchun_afk [14:50] sergiusens, why would the miral part try and look in the "games" part's folder¿? [14:50] zyga-suse, the problem is that the dnf upgrade is not the than apt update [14:50] it is upgrading the system [14:51] Pharaoh_Atem: ^ should we skip that? [14:51] cachio: let's try, once it starts failing we can make spread-cron do the updates [14:53] mvo: just got this error in the from-archive scenario on xenial http://paste.ubuntu.com/25075603/, in this case snapd is not built from branch, the deb package is installed from proposed and core is installed from beta (and not modified) [14:54] the same scenario passed ok on trusty [14:55] Saviq: retrying armhf worked, i386 didn't (retrying that now). So "racy build" seems plausible. [14:55] sergiusens, ↑ [14:56] Saviq: still, this is not the `games` part running, it is from the miral part [14:57] sergiusens, even so, that would mean snapcraft's telling cmake the wrong install prefix/chroot/something? [14:57] I see no "Building games" message in those logs [14:58] sergiusens, sure, just means the parts' env is leaking between parts? [15:00] Saviq: yes. Maybe. That could be it. This is there since the days of mvo and mterry caring for the code base. But I can check [15:00] sergiusens, it reproduces here in cleanbuild on zesty [15:01] Saviq: on and off? [15:01] or always? [15:01] sergiusens, I'd say more than 50% [15:03] zyga-suse: dnf makecache is equivalent to apt update [15:05] Pharaoh_Atem: intereting, thanks (I never ran that command myself) [15:06] on a normal system, you don't need to [15:06] there's a systemd timer that takes care of it for you [15:06] cjwatson: thanks! yes, my snap built fine overnight, it appears [15:07] jdstrand: hey, replied to the "using snap-update-ns from snap-confine" thread [15:07] zyga-suse: if you need to force a metadata update independent of the actual action, that's how you do it [15:08] normally, you only care in the context of a system upgrade, so "--refresh" can be used as an option to force it [15:08] Pharaoh_Atem: the goal is to accelerate test cycles, if we can not run "dnf update" that's all good [15:08] don't you run system upgrades before every test? [15:08] for ubuntu [15:08] Pharaoh_Atem: I worry though that we'll hit stale cache issues sooner or later unless we do base image updates separately like every 12 hours [15:08] Pharaoh_Atem: we don't [15:09] well, if the metadata is expired, dnf will fetch anyway [15:09] you don't need makecache normally [15:09] Pharaoh_Atem: it was way to slow and it'd be better to just have fresh images updated out-of-band [15:09] then take it out entirely from suse and fedora spread runs [15:10] both of them do metadata refresh and system upgrade [15:10] well, zypper requires metadata refresh manually [15:10] yep [15:11] hi, shouldn't I need root to install a (classic even) snap? http://pastebin.ubuntu.com/25075675/ [15:11] ahasenack: no if you "sudo snap login"ed before [15:12] I see [15:12] nacc: ^ [15:12] ahasenack: thanks [15:13] zyga-suse: the result of that login is what is stored in ~/.snap/auth.json? [15:13] yes [15:13] fgimenez: the error is "expected", we could SRU 2.26.9 - then it will go away. maybe thats cleaner [15:13] hm [15:13] thx [15:15] uh, oh [15:15] thunderstorm [15:16] mvo: np, thank you, btw all the ongoing dragonboard test executions on testflinger have suddenly stopped with "Timeout while trying to communicate with the server.", i'll try to retrigger them but this is going to make the validation longer, pi2 and pi3 finished successfully [15:16] * zyga-suse shuts the desktop down :/ [15:16] but hey, laptops [15:17] sergiusens, alan_g, bug #1703878 [15:17] Bug #1703878: Race/environment leak between parts [15:18] fgimenez: thanks - strange, any idea what happend there? [15:19]