[05:23] morning [07:02] mvo: hi, looks like we might have a bug in time schedule, with some specific days of the month, i'm looking into it [07:03] mborzecki: ok, thank you [07:18] according to go hmm 2017-08-01 00:00:00 +0200 CEST is Tuesday [07:18] mvo, hey, I had to make this small change in MM and other interfaces: https://github.com/snapcore/snapd/pull/5572 [07:18] mvo, would appreciate if this can be incorporated to the nex release [07:20] abeato: checking [07:20] thx [07:21] abeato: we will need jdstrand for this - at least for a second review. but yeah, happy to merge into one of the release PRs once it got that review [07:21] mvo, sure, we indeed need him [07:22] abeato: slightly unfortunate timing :/ we did 2.34.3 on Friday so there will be a bit of time before the next regular release. how urgent is this for you? [07:23] mvo, well, urgent, but can wait a bit in principle. When is the next release planned? [07:25] abeato: the next regular release would be 2.35 which is ~4-6 weeks away. we can do a point release if its critical which will take ~2 weeks (because the 2.34.3 needs to be released first which is ~1 week) [07:27] mvo, ok, I see. I need to check these dates with the client, thanks for the info - will let you know [07:27] abeato: if does do not match we need talk and think about options [07:28] sure :) [07:30] mborzecki: woah, the amazon linux packaging is pretty neat, looks like someone (looking at Neal most likely) did a great job on the fedora packaging to make it pretty universal [07:30] mvo: yes, a couple of %if and it built just fine [07:31] mborzecki: why do we need "storage: preserve-isze" for there? [07:31] mborzecki: yeah, neat! [07:31] mvo: the default image is 25gb, and iirc if we resize it to 10gb it does not boot anymore [07:31] mborzecki: aha, right [07:32] mborzecki: and there is a spread bug that prevents setting this more fine grained(?) [07:32] mvo: cachio knows the details, he's proposed the intial pr to spread [07:32] mborzecki: ok [07:42] abeato: 5469 got two +1 but has some conflicts. do you think you have some cycles to look at those conflicts? [07:42] hm weird, so in the tests 2017-08-01 00:00:00 +0200 CEST .Weekday() is Tuesday, when I run a similar sample in play it's wednesday https://play.golang.org/p/i1-tcO-OzBx same sample ran locally is wednesday too :( [07:43] mvo, sure, let me take a look [07:43] cjwatson: quick question about building snaps on LP. I tried to build the openstreetmap editor josm directly from their svn in LP but get an error: svn: E170013: Unable to connect to a repository at URL 'https://josm.openstreetmap.de/svn/trunk' [07:43] cjwatson: is this just not possible or anything I can do to fix it? [07:45] mborzecki: a second review for 5563 would be great, hopefully straightforward [07:45] mvo: looking [07:47] and 5450 needs a second review as well but its less important (just a small optimization) [07:53] mvo: It's in principle possible but needs some work in launchpad-buildd - see https://bugs.launchpad.net/launchpad-buildd/+bug/1668358 [07:57] cjwatson: thank you [07:59] cjwatson: would it be https://code.launchpad.net/~cjwatson/launchpad-buildd/snap-git-proxy/+merge/323691 for svn? or is there more to it? [08:01] cjwatson: hm, probably not because this is using plain http for the checkout(?) [08:02] note to self, double check the year before swearing at go time parser [08:02] mborzecki: haha [08:03] i clearly need more coffee [08:05] mvo: I think it would involve writing out ~/.subversion/servers with proxy info [08:06] Probably not super-hard but needs testing ... [08:56] mvo: #5573 fixes the timers [08:57] mborzecki: thank you [09:00] moin moin [09:00] * Chipaca started a bit late [09:00] mvo: i'll label it 2.34 in case we do another .34 release [09:00] Chipaca: hi there, there's always a timezone in which it's early :) [09:01] clearly i'm on UTC and just on time [09:02] mborzecki: +1 [09:02] Chipaca: hey, good morning! [09:02] mvo: how're you doing? [09:03] Chipaca: I'm doing well, thank you! how are you? [09:03] mvo: not bad! anything on fire? [09:05] Chipaca: no new fire afaict, git deb package builds are unhappy to a varying degree, s390x in particular is unhappy since some time. but thats not yet too much of a problem (it will be once we need to do a new release) [09:05] boo [09:08] Chipaca: also some review would be great but otherwise things are calm right now. we need to aim for a beta of snapd that supports booting core18 this week [09:08] Chipaca: so not entirely calm :) [09:08] heh [09:13] mvo: other than 5557 is there anything for core18 that needs a review? [09:17] Chipaca: only 5549 which will be needed as part of the failover code for snapd but its not super urgent as on its own its not super useful [09:17] Chipaca: 5570 is an easy win [09:19] Chipaca: and 4.15 does not boot today again, *maybe* the entropy bug again in a different form, I'm just looking into this [09:19] there's been a bunch of people on 18.04 that found all their snaps stopped working, btw [09:20] not sure if that's already been sorted [09:20] #1757284 [09:31] #5572 probably needs a look from jdstrand [09:37] Chipaca: is this similar to the forum thread from last week? [09:37] Chipaca: I think we got a report that after an update there was suddenly havoc [09:37] mvo: ah, probably, i might've merged the two in my head [09:37] yeah sounds like it [09:38] https://forum.snapcraft.io/t/bug-broken-snaps-after-each-update/6536 [09:55] mvo: Chipaca: have you seen this https://forum.snapcraft.io/t/all-snap-app-crashed-on-ubuntu-18-04/6596/2 ? [09:56] mborzecki: isn't that #1757284? [10:01] mborzecki: and given mvo replied to that thread, my magic ball says he's seen it [10:03] Chipaca: the forum topic feels like a mix of 2 different issues [10:04] could well be two similar issues, I have not tried to reproduce myself, no time :/ but I think we need to look at this [10:04] nice how firefox has connection refusded on display, chromium gets sigtrap, ohmyfiraffe just segfaults [10:07] hm, is mup actually back? [10:08] apparently not, pretty trivial PR https://github.com/snapcore/core18/pull/52 [10:09] (this is the reason why core18 was hanging in my local spread run, testing this right now) [10:45] mborzecki, Chipaca did you figure anything out about the bugreport(s) above? sorry, was a bit distracted with looking into kernel hang (tricky to debug, easy once understood :/ [10:54] mvo: left a note in the forum, my bet is on apparmor for now [10:56] ta [11:05] 5560 needs a second review (trivial I hope) [11:13] mvo: isn't it superseded? [11:16] Chipaca: I just updated it [11:17] ohhhh [11:17] mvo: lgtm, then :-) [11:21] Chipaca: ta [11:37] mvo: want to know something hilarious: the _internal_ copy of runtime has a BigEndian boolean [11:38] ah, no, internal/sys (so syscall) [11:43] Chipaca: oh, *fun* [11:44] Chipaca: I remember reading a long discussion why you shouldn't care about endianess in one of the bug bugs and I have given up on anything like official support for this [11:45] mvo: yeah [11:45] mvo: it's entirely possible they're right, and either our test is doing more work than it should, or udev is bonkers, or both [11:45] mvo: ¯\_(ツ)_/¯ [11:46] it's also not outside of the realm of the possible that this particular bit is the exception [11:46] yeah [11:47] mvo: should I add IsBigEndian to osutil? [11:48] Chipaca: hm, that sounds like a nice idea [11:48] Chipaca: fwiw, for practical purposes the check for s390x is fine, we don't support mips and our ppc64 is little endian (I will double check that though) [11:49] Chipaca: yep - endian-little [11:50] mvo: yep, ppc64 vs ppc64el [11:50] * mvo nods [11:50] Let's write a cpu that _only_ works in bigendian bcd [11:52] mvo: anyway, just lunchtime rambling, not blocking or anything [11:55] Chipaca: ta [11:55] Chipaca: yeah, probably a good idea to make it pretty [11:55] (prettier than it currently is) [11:55] mvo: also, did you inhale lunch, or are you IRCing while eating, and in either case, dude [11:55] mvo: mborzecki: Chipaca: anything I can still do for you today before calling it a week? (after the standup I have a bunch of meetings) [11:56] Chipaca: was a bit optimist about it, its not quite ready, should be any minute hopefully :) [11:56] mvo: ah :-) [11:57] pedronis: I've got half a mind to drop the horizontal snapshot approach, close snapshotstate, and instead do verticals [11:57] pedronis: i'm finishin up with with some changes to 5561, would be great it you could date a look before you leave, i understand it's a bit mind numbing though so no worries if you cannot make it :) [11:58] pedronis: like, "this pr implements 'snap snapshots'", etc [11:58] and maybe then slice _those_ into horizontals [11:58] and maybe, maybe, i can get reviews [11:58] Chipaca: that doesn't sound something like I can help today, unless you propose it this second [11:58] pedronis: no, it's a week's work imo [11:59] OTOH I could also do the arch-indep work [11:59] that's also a week + in my estimate [11:59] dunno [12:00] pedronis: to answer your question: I doubt I'll have anything for you to do for me today before the standup, thank you [12:00] ok [12:01] pedronis: all good from my side [12:02] mborzecki: I'll see what I can do, we should chat a bit in the standup about what is not there and the state overall of parallel installs [12:03] error: open /var/lib/snapd/hostfs/home/ubuntu/snap/lxd/common/snapcraft7l7sklw8/core_4917.assert: no such file or directory [12:04] Known issue? Sounds familiar but my Googling is failing me. [12:04] subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/ubuntu/snap/lxd/common/snapcraft7l7sklw8/core_4917.assert', 'local:snapcraft-nondiffidently-overfastidious-luetta/run/core_4917.assert']' returned non-zero exit status 1 [12:05] Ah, bug 1746612. [12:06] Except that I am using the lxd cnap. [12:06] snap [12:06] Oh no, I'm not. I thought I was. [12:06] Never mind :-/ [12:14] pedronis: regarding https://github.com/snapcore/snapd/pull/5561#discussion_r205805753 do you think it makes sense to verify this again in checkSnap() ? [12:17] mborzecki: sorry I don't understand which PR are you referring to? it doesn't seem to check that the name matches [12:18] if you mean #5567 [12:25] pedronis: what i meant that it's probably more applicable to snap.Validate(), as it feels like a part of sanity check, and snapstate checks seem more like functional checks [12:26] pedronis: pff nvm, was thinking about something else entirely :) [12:26] mborzecki: maybe, but but something has to give, Validate takes an info, either that info already has a full intance name split into it [12:26] but then it's late or something needs tweaking in that interface [12:35] mborzecki: I removed my -1, don't think I can manage to review it again fully, we can discuss a bit about state in the standup as I said [12:36] pedronis: ack, who do you tnink is equally well familiar with those internals that might take a look too? [12:36] mborzecki: mvo, also John, what you are likely to be blocked on is alias stuff [12:37] yeah, i remember pulling my hair on this not long ago [12:38] otoh you might be able to attack some of the interface bits [12:56] pedronis: heh, i dug up the changes for that TODO in SetupSnap in some other branch i have, guess I'll refactor this to be in checkSnap instead [12:59] no link in the calendar for the standup? [13:00] mborzecki: strange [13:00] it's not in my calendar either [13:01] mvo: I pinged Gustavo about this last week, it's probably related to hangout vs meet [13:01] mvo, https://github.com/snapcore/snapd/pull/5469 passed now the spread tests [13:01] abeato: cool, thank you [13:01] abeato: I have a look after the meeting [13:01] mvo, great, thanks [13:06] jdrab: in tty[a-zA-Z]*[0-9]*, doesn't that still match 'tty' (and 'ttyprintk') [13:06] ? [13:06] er [13:06] jdstrand: ^ [13:11] Chipaca: it is shell glob matching, not regex, so, 'no' [13:12] Chipaca: eg: ls /dev/tty[a-zA-Z]*[0-9]* [13:12] jdstrand: ah! i thought it was regexps because of the alternation [13:12] it looks like a regex to be sure [13:12] but it isn't [13:12] :-) ok [13:12] jdstrand: i'll dig out my udev dunce hat in a moment [13:13] Chipaca: well, that is quite the subtlety for that hat! [13:13] I just assume you keep it in the drawer [13:14] jdstrand: under my pillow [13:16] heheh === chihchun_afk is now known as chihchun [13:50] mborzecki, that error on amazon PR is not a problem now [13:50] I took a look and everything is ready to be landed [13:50] I'll create the PR today on spread to setup the preserve at system level [13:50] cachio: great [13:51] cachio: could you do another review of #5552 too? [13:51] mvo, we got the +1 to go to candidate [13:51] mborzecki, sure [13:51] cachio: thank you [13:52] cachio: cool, lets do it [14:03] mvo, 2.34.3 in candidate now [14:06] mvo: could you upload a release tarball for snapd later on? [14:07] mborzecki: sure, let me do this now [14:07] mvo: thank you! [14:09] mborzecki: should be there now [14:09] mvo: it is, thanks a lot! [14:17] mvo, snapd will break on cosmic with usrmerge =) or possibly not, not sure.... https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1784394 [14:18] there is a small patch there.... =) [14:20] xnox: thanks, looking [14:21] xnox: thanks, will do, it probably won't break as this should just be a symlink but its more correct this way [14:22] yeah [14:22] xnox: will do a PR shortly! [14:25] arch package updated to 2.34.3 [14:25] ta [14:27] 5573 is green, if anyone wants to do a 2nd review we could land it soon :) [14:38] mborzecki, #5552 merged [14:42] cachio: thanks! [14:59] * pedronis eows [15:29] EOWing on a monday ... nice :) [15:43] * genii slides ogra a mug of their favourite beverage [15:54] * ogra slurps [16:10] * cachio lunch} [16:10] Chipaca: this core18 snapd unit writing is a bit of a pita - but thanks a lot for your PR (and thanks to mborzecki as well). I'm slowly moving forward here, the restarting is still a bit fiddly [16:11] mvo: when you say my PR, you mean my review of your PR? [16:12] Chipaca: yes! the heat make me take mental shortcuts [16:13] mvo: HLQP! :-) [16:29] mvo: why the // FIXME instead of changing the Start to a Restart? [16:32] Chipaca: because it does not work yet [16:32] Chipaca: I got errors with exitcode: -1 [16:33] Chipaca: which is strange [16:33] mvo: boooo 👻👎 [16:33] Chipaca: looking into this now but wanted to get a spread run with improved tests [16:33] Chipaca: yeah :) or rather: :( [16:33] mvo: ok :-) [16:33] Chipaca: the fact that we get -1 is a bug in itself [16:33] mvo: yeah [16:33] Chipaca: oh well [16:43] just add a +2 at the top ! [17:47] Chipaca: you mention ReplaceAllString in pr#5557, content is byte, do you think this is still preferable? or am I misreading your comment? [17:53] mvo, I have seen the lxd issue [17:54] let me see the images because lxd should not be pre-installed [18:00] cachio: thanks, I'm not sure what is going on, the PR is mostly a stab at the problem, I have not run it locally [18:03] mvo, I'll fix the image [18:05] cachio: ok, in this case feel free to close my PR once the image is fixed [18:15] mvo, great, thanks [18:17] mvo, updating the image for xenial 32 bits, if tests pass I'll close the PR [19:27] Chipaca: the issue was RequiredBy vs WantedBy - oh well :) hopefully with that the restart is fine! [19:34] mvo, lxd issue fixed [19:36] I cloosed the PR and pasted the logs with the test results [19:37] cachio: great, thank you [19:45] mvo, np [21:15] tyhicks: fyi, https://github.com/snapcore/snapd/pull/5578 and https://github.com/snapcore/snapd/pull/5579 [21:17] jdstrand: cool, thanks [21:18] tyhicks: hopefully it'll make it into a new 2.34 (the latest stable), but it might not and be only in 2.35. up to mvo [21:22] okay, I'm ready to build firefox 52.9.0esr into a snap, how do I do that? [21:39] `man snapcraft` `No manual entry for snapcraft` [21:42] `autoreconf -i`: `autoreconf: 'configure.ac' or 'configure.in' is required` `Failed to run 'autoreconf -i' for 'firefox': Exited with code 1.` `Verify that the part is using the correct parameters and try again.` [21:52] jesus christ, snaps are awful [21:52] I just took a look at what is inside skype snap [21:52] piles of shite [21:58] Hey cachio, you still around today? [22:03] FreeBDSM: I think that would be an indication that particular snap isn't to your taste. not all snaps are created equal [22:11] kyrofa, yes [22:11] kyrofa, what do you need? [22:11] jdstrand: true [22:12] I think it'll be easier to do `snap install firefox` and just replace firefox files with the ones from ESR 52.9.0 [22:12] and just never update [22:12] however, that's not much portable [22:16] cachio, I'm trying to learn how snapd does spread testing in autopkgtests [22:17] cachio, I see the `autopkgtest` group in spread.yaml [22:18] Is that all there is to it? [22:20] Basically, just point the test to happen on localhost? [22:21] I don't understand why there are so many systems if that's all that happens, though [22:55] kyrofa, the systems which you see are the targat systems for autopkgtests [22:58] kyrofa, first you need to generate the machine with that systems [22:58] then you run the tests against that one