[07:33] sil2100: hiho, you might know - is bileto down for a reason or juts by accident? [07:33] I get connection timeouts when browsing to it [08:11] cpaelzer: hmmm [08:11] cpaelzer: it works here for me, probably was just some temporary failure? [08:18] sil2100: yeah working now [08:18] odd === JanC is now known as Guest41406 === JanC_ is now known as JanC [09:01] hey, I look for some packaging magic guidance [09:01] Debian did a change that is useful in moving a blob (rom file) generated from an arch sepcific package to a "Architecture: all" package [09:01] so far so good [09:02] but we built two such roms (so far arch specific on s390x), and the second rom can ONLY build on s390x [09:02] it can easily be reused on other architectures [09:02] furthermore debian did it ina hackish way which will miss if any changes/fixes for those roms are done to the makefile upstream [09:03] so I wonder if I could build things on s390x the "upstream intended way" but then still make them part of an "Architecture: all" package (preferably the one I already have containing other roms as well) [09:03] I realized my knowledge on build-indep is lower than it should be so any help is welcome [09:03] Sounds like you want "XB-Build-Indep-Architecture: s390x" in the first stanza of debian/control [09:04] may be LP-specific - there was debate about it and I'm not sure we ever got that into Debian [09:05] cjwatson: interesting, let me read about that flag [09:06] cjwatson: it is possible (not sure yet) that there are also roms that only build on x86 (the current executor of build-indep) [09:07] cjwatson: is there any chance that I can get both or is this an "either this or that" decision? [09:07] also search endinges don't give me useful links for XB-Build-Indep-Architecture is there any reference you could share? [09:10] yeah it has x86 only bits as well [09:10] so the question really is can I have one deb package that has content built on two different builders, and I assume the answer is no [09:11] am I allowed to split an extra (new) package for that being architecture:all but built on s390x [09:11] I could only move the two roms I want there and have all I want right? [09:11] the roms built the upstream intended way ending up in a arch:all package [09:11] I'll try that - let me know if that is in vain :-) [09:17] cpaelzer: I mean ... you can't simultaneously build a package on more than one arch [09:17] cpaelzer: you'll have to split it up or else work out some way to get everything to build on a single arch [09:19] cjwatson: yep, I decided to split the package [09:19] thanks for confirming my assumptions [09:19] are there known limitations on building architecture: all content NOT in build-indep [09:20] can't recall I'm afraid [09:20] as that is what I need to build one on x86 (that will be in build-indep) and one on s390x (that will be in buld-arch) [09:20] ok, I'll give it a try [09:20] thank you already cjwatson [09:21] I'm not totally sure how what you're saying makes sense [09:21] But I need to catch a train [09:23] have a good ride [09:54] Odd_Bloke, hello, if you want to do some hg-git fixup, http://debomatic-amd64.debian.net/distribution#disco/hg-git/0.8.12-0ubuntu1/autopkgtest [09:54] the test requiring ssh should be disabled in my opinion [09:54] :) [09:56] LocutusOfBorg: do you plan to upload hg-git 0.8.12 to debian? [10:00] ginggs, for some reasons the same version fails there... [10:01] http://debomatic-amd64.debian.net/distribution#unstable/hg-git/0.8.12-0.1/buildlog [10:01] I couldn't figure out why... maybe new git version [10:03] i saw some fixes in hg-git gitlab that are not released yet [10:03] but i want to know if you are planning to upload hg-git to debian, so we don't duplicate work [10:04] s/gitlab/bitbucket/ [10:45] ginggs, no please, I plan to do something else, more important :D [10:45] go go go, you can start from my DOM upload :D [11:18] jbicha: hi, what's still missing from lm-sensors migration? [11:29] Skuggen: from juliank: https://paste.ubuntu.com/p/HK3p28KNkz/ [11:30] Skuggen: he said in #ubuntu-release it's fixed upstream in 5.7.26 but has no release yet. [11:30] Do we need to upload this patch or is the upstream release imminent? [11:31] 5.7.26 or 5.7.25? [11:31] I need this patched for lz4 (but it's also blocked by systemd, and ros-ros-comm on some archs) [11:31] Skuggen: https://bugs.mysql.com/bug.php?id=93778 says "Fixed in 5.6.44, 5.7.26, 8.0.15." [11:33] Enough time to fix in Debian and autosync over? [11:34] sure, it's not _super_ urgent [11:34] I think we'll have to fix systemd too, and that'll take longer [11:36] OK I'll knock up a MR for Salsa. [11:36] 5.7.26 is some ways off (5.7.24 is the current release, and 5.7.25 will be out soon) [11:37] juliank: shall I hack your changelog for version/release to leave you attributed? [11:38] I'd just dch -r it so I'd end up in [ ] inside the changelog [11:38] OK [11:38] Skuggen: So, 5.7.25 will be released with a failing test suite? That's fun [11:39] time based tests are fun in any case [11:39] "oh 2018 is a long way off, let's use that" [11:39] "oh no, it's 2019, the test testing 2018 stopped working" [11:39] I suspect it might be fixed "properly" [11:40] hopefully [11:41] * juliank looks at ros-ros-comm, that's scarier [11:53] hi, bileto.ubuntu.com is timing out after authentication with sso (proxy error 502), is that something that is usually addressed with a service restart of some sort? [11:54] or something more serious is going on? [11:54] #is can restart services, but don't really know the layout of that machine [11:56] juliank: Yeah, hopefully. I' [11:56] I've seen some such tests fixed properly, while others are just +10 years :P [11:58] Skuggen: I think the problem is that we are running out of years on 32-bit [11:58] s/the/a/ [12:00] sil2100: around? [12:00] bileto.u.c seems to have lost some launchpad authentication token and it's filling the logs with messages like " Waiting to hear from Launchpad about your decision..." [12:01] apparently waiting for someone to hit that url [12:01] do you know what that is about? #is can restart things, but it looks like this is something else === ricab is now known as ricab|lunch [12:44] hmmm [12:44] ahasenack: let me look at that === shadeslayer is now known as shadeslayer[m] === shadeslayer[m] is now known as shadeslayer [13:35] tjaalton: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says that gkrelmmm is blocked by gnutls28 [13:47] jbicha: gotcha [14:40] doko: by any chance can you rebuild the openstack packages in your test rebuilds? i think most are fixed. [14:40] fyi jamespage ^ [14:41] coreycb: what was the issue? [14:41] jamespage: several were hitting the sqlite issue but i've built a few more that were hitting other issues successfully. [16:09] teward: hi, do you know where nginx stands with lua 5.x support? Does it still only support lua5.1? [16:09] https://github.com/openresty/lua-nginx-module/issues/204 seems to indicate they don't want to go beyond 5.1 [16:10] ...and found the issue you reported :) https://github.com/openresty/lua-nginx-module/issues/343 [17:07] coreycb, jamespage: given back, currently running === simpoir is now known as simpoir|lunch [17:14] doko: thanks [17:53] ahasenack: lua is a real mess [17:56] juliank: looks like it, we have 5.1, 5.2 and 5.3 in disco [18:42] ahasenack: I mean, luajit only supports 5.1 syntax (+ some 5.2), and 5.2 had a huge ABI break, so code is split in luajit vs lua>=5.2 [18:42] and that sucks [18:43] I saw that nginx switched to jit at some point === simpoir|lunch is now known as simpoir === ricab|lunch is now known as ricab [19:41] Laney: network-manager dep8 fix++, based on your changelog message [19:41] Thank you for sorting that