[09:10] <joelkraehemann> hi all
[09:11] <joelkraehemann> https://packages.ubuntu.com/search?keywords=gsequencer&searchon=names&suite=disco&section=all
[09:11] <joelkraehemann> ^^ I wanted to do a sync request but it tells me it has the current version of debian ...
[09:12] <joelkraehemann> So is the above showed information of packages.ubuntu.com just wrong
[09:13] <Laney> joelkraehemann: not exactly, the package is in disco-proposed but not disco proper: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer (read https://wiki.ubuntu.com/ProposedMigration/ for more information on the process)
[09:17] <joelkraehemann> Laney: the test runner crashed
[09:18] <Laney> sounds like a thing to be fixed
[09:31] <joelkraehemann> Laney: it would be nice to obtain stack-traces and tell upstream
[09:32] <joelkraehemann> I do now a i386 chroot
[09:34] <rbasak> joelkraehemann: unfortunately the volume of test failures is so large that it isn't practical to examine them all, isolate if they are introduced by the distribution or if they are genuine upstream bugs, obtain stack traces and report upstream. It's not practical :-/
[09:34] <rbasak> We do what we can.
[09:36] <joelkraehemann> rbasak: do you know systemd-coredump?
[09:36] <rbasak> No.
[09:39] <joelkraehemann> if a process crashes you can obtain a stack trace using `coredumpctl debug`
[09:41] <rbasak> I do know how to obtain stack traces, thanks.
[09:44] <joelkraehemann> You don't have to run within a gdb session
[09:45] <joelkraehemann> and obviously you didn't
[10:09] <joelkraehemann> I just run `libtool --mode=execute gdb ags_check_system_functional_osc_server_test`
[10:09] <joelkraehemann> it passed in my chroot
[10:10] <joelkraehemann> ... may be because I use bionic
[10:35] <doko> cjwatson: do you remember why we need pbuilder in main? that dates back to 2008 ...
[10:45] <cjwatson> doko: more like 2004; it was from the very first seed commit (the history is just obscured slightly by the platform split)
[10:46] <cjwatson> doko: IMO sbuild is sufficient and we don't need two
[10:47] <doko> ok, will demote
[11:09] <joelkraehemann_> FYI: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919269
[11:34] <ahasenack> sil2100: hi there, bileto still seems to be a bit broken, it times out after SSO redirects back to it, do you know if #is is working on it? Should we file an RT?
[11:36] <xnox> ahasenack, are you logged in, in the autopkgtest.ubuntu.com as well?
[11:37] <xnox> i find that bileto -> autopkgtest -> login flow is borked, but one can work around that by loggin into autopkgtest.u.c directly
[11:37] <ahasenack> tryng
[11:37] <ahasenack> I don't see a login link in autopkgtest.u.c, nor my name indicating I'm already logged in
[11:38] <ahasenack> going to bileto.u.c now, it shows me logged in
[11:38] <ahasenack> but I see a bunch of empty tickets
[11:39] <ahasenack> they look like attempts to create tickets that failed perhaps
[11:39] <Laney> that's not really the case, there are just links from excuses to request.cgi
[11:39] <Laney> no particular login flow, so that sounds like a red herring to me
[11:41] <sil2100> ahasenack: hey, yeah, it's still broken, I don't think IS is looking into it as last time they were not able to figure out what's the reason
[11:42] <sil2100> ahasenack: I was looking into it as well but then got preempted out of it
[11:42] <sil2100> ahasenack: could you fill in an RT for tracking?
[11:42] <ahasenack> sil2100: yeah, last time was kind of fire fighting, we may need a ticket
[11:42] <sil2100> ahasenack: the thing that's broken are mostly redirects, for reasons yet unknown
[11:42] <sil2100> So it's all usable, but one needs to remember about that, and refresh the page for instance after creating a ticket
[11:43] <sil2100> And then modifying the ticket info
[11:43] <sil2100> Same for other operations
[11:43] <sil2100> geh
[11:43] <ahasenack> I see
[11:43] <ahasenack> not just login then
[11:43] <ahasenack> I'll file the rt
[11:43] <sil2100> I'll try to look into it again today as well, will need a moment for that though as those are the parts of code I don't know much about
[11:44] <sil2100> And well, Robert's vision of elegant code doesn't really help with readability
[11:48] <ahasenack> sil2100: filed,  you are cc'ed
[11:48] <ahasenack> 1thx
[11:50] <sil2100> ahasenack: thanks!
[13:18] <juliank> So apparently, merging translations from master is as simple as
[13:19] <juliank> for i in po/*.po; do msgmerge -q --previous <(git show master:$i) $i | sponge $i; done
[13:24] <juliank> hmm
[13:24] <juliank> this made one string fuzzy that was not fuzzy before
[13:30] <juliank> for i in doc/po/*.po po/*.po; do msgcat --use-first <(git show master:$i) $i | sponge $i; done
[13:30] <juliank> this + then running update-po (that is, msgmerge) works better
[17:04] <rbasak> jbicha: looks like libical3 can be synced now. I'll do that in a bit unless I'm missing something.
[17:04] <rbasak> (or you object)
[17:16] <jbicha> rbasak: mismatched tarball so you can fakesync if you want
[17:17] <rbasak> :(
[17:17] <rbasak> I was just driving by. I've never done a fakesync so I might leave it for a time when I can pay more attention.
[17:19] <Laney> rbasak: syncpackage can do those, if you're interested
[17:20] <jbicha> rbasak: it's good practice if you want to try it. You'll just have to use the --fakesync option (it suggests it when necessary) and then manually dput the result
[17:21] <rbasak> Oh OK, thanks. AFAICT I can just run it then for this case?
[17:21] <Laney> You end up with a source package that you can look at
[17:22]  * rbasak tries
[17:23] <rbasak> It's just the lack of supervision here that vexes me a little. I usually take great care in reading all possible docs when doing something new :)
[17:26] <rbasak> OK I've done sufficient debdiffing of the results I think.
[17:26]  * rbasak uploads
[17:27] <rbasak> Thank you for your help. Now I understand the tooling it seems far more straightforward and less error prone than I had expected.
[17:46] <bdmurray> superm1: I'd like to see something on StableReleaseUpdates re fwupd being a special case so other SRU team members also know about it and we have a reference.
[21:30] <joelkraehemann> hi all
[21:37] <joelkraehemann> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
[21:37] <joelkraehemann> ^^ I have tried to reproduce using LXC but without success
[21:38] <joelkraehemann> http://paste.debian.net/1060526/
[21:41] <joelkraehemann> my only idea for is, the tests share a NIC and the OSC server gets a conflict ...
[21:44] <joelkraehemann> or something messes with the address 127.0.0.1
[21:44] <joelkraehemann> it would be interesting to run the integration tests with isolation machine.
[21:49] <superm1> bdmurray, which area should I raise that discussion point?
[21:49] <superm1> because changing a wiki is one thing, but I feel it probably needs to be discussed
[21:50] <bdmurray> superm1: The wiki is the way to go - https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
[21:51] <superm1> perfect thanks, I'll do that
[21:51] <bdmurray> superm1: I'd be happy to review the plan
[21:53] <joelkraehemann> Laney: are you still here?
[21:57] <joelkraehemann> does anyone have the right to rerun the tests?
[21:58] <joelkraehemann> please trigger only one container, e.g. i386
[21:58] <joelkraehemann> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
[22:46] <joelkraehemann> This time, I was running the ags_check_system_functional_osc_server_test in 2 different containers ...
[22:47] <joelkraehemann> As the amd64 container completed, I have got SIGPIPE in i386 container
[22:47] <joelkraehemann> http://paste.debian.net/1060540/
[22:47] <joelkraehemann> as running alone in i386 it passes
[22:49] <superm1> bdmurray, okay: https://wiki.ubuntu.com/firmware-updates
[22:50] <superm1> let me know if I should just email the list instead
[23:11] <bdmurray> superm1: I think it'd be worth mentioning fwupdate-signed. Also could you elaborate on "OEMs ... can place information into the metadata"?
[23:11] <superm1> Sure thing
[23:15] <superm1> bdmurray, ok modified
[23:25] <bdmurray> superm1: Why should the ageing requirement be waived?
[23:26]  * jbicha squints at https://launchpadlibrarian.net/406229560/folks_0.11.4-1ubuntu1_0.11.4-1ubuntv1.diff.gz