-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (focal-proposed) [2.46+20.04]07:14
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (focal-proposed) [2.46.1+20.04]07:48
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.46+18.04]07:49
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.46.1+18.04]07:50
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.46]07:53
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.46.1]08:16
rbalintLocutusOfBorg, instead of hinting systemd haveged should be fixed to not start in lxc08:29
juliankrbalint: what's the matter?08:51
juliankWe install it by design, not by accident08:51
rbalintjuliank, it is ok, it just should not start in lxc because it can't and fails08:53
Laneyrbalint: this is amd64, not lxc ... or are the tests using that internally?08:55
rbalintjuliank, Laney yes, i just realizes i was wrong, haveged fails outside of lxc08:56
juliankmaybe it fails because I install both rng-tools and haveged since a week or two ago?08:56
juliankmaybe you can only have one08:56
rbalintjuliank, this makes sense08:56
juliank(but not all our clouds support rng-tools)08:57
juliankAh, also we don't install inside container08:57
rbalintjuliank, i've patched glibc to ignore the test failure due to lack of entropy, so i'm ok with reverting adding haveged08:58
juliankrbalint: we've installed haveged for ages08:59
juliankWe're trying to switch to rng-tools08:59
rbalintjuliank, then rng-tools08:59
Laneyno wait08:59
Laneyit used to pass with haveged, the same commit of autopkgtest08:59
Laneythen we started consistently failing on the 5th, so ... what?09:00
juliankLaney: well, maybe rng-tools started working, idk?09:00
juliankWell it should have worked before that I suppose09:00
rbalintLaney, 2020-09-05 , new haveged landed09:01
Laneyand this fails to start in the cloud or something?09:01
juliank haveged.service loaded failed failed Entropy Daemon based on the HAVEGE algorithm'09:02
Laneylet's see09:02
juliankthere's no status or journalctl09:02
Laneyseems bad09:05
rbalintLaney, at least we caught it :-)09:06
Laneynot at the right time, but better than nothing09:07
Laneyhaveged's autopkgtests just build it and run 'make check', that is not good09:08
Laneythinking of reverting this, thoughts?09:09
rbalintLaney, +109:09
rbalintddstreet, haveged ^^^09:10
LaneyI'll file a bug, just a second09:10
Laneytesting in a sid vm09:10
Laneylxc launch --vm ♥ ♥ ♥09:10
Laney"active (running)"09:13
Laneyguess we lose :-)09:13
rbalintLaney, do you have some time today to check the glibc ffe?09:25
Laneyyeah, I started typing a reply, will send it after haveged09:25
rbalintLaney, thanks!09:25
LocutusOfBorgxnox, are you aware that your ghc 8.8.3-1ubuntu1 and 8.8.3-1ubuntu2 can't be published because they will trigger a full transition on armhf? last time I changed  optc--param -optcggc-min-expand=10 on an a single architecture I had to rebuild the world... (and it was a leaf package)09:33
LocutusOfBorgso, please don't hit publish.09:33
LocutusOfBorgif we have to do a 1k transition better use 8.8.4, that is a minor bugfix release09:33
Laneyrbalint: would you keep an eye on 'rmadison systemd' and retry the tests once it's published please?09:46
rbalintLaney, rmadison haveged?09:48
=== seb128_ is now known as seb128
Laneyyeah, you know what I m ean09:50
rbalintLaney, sure09:51
xnoxLocutusOfBorg:  I am aware of that, but also ghc ftbfs on armhf is holding up 145+ package ffi transition.09:59
xnoxLocutusOfBorg:  something is wrong with either the way we build the new compiler, or how the current one in groovy-release was built.09:59
xnoxLocutusOfBorg:  cause in debian/previously it only took 12-15h or so to build. Yet now, it never finishes for us after going for 4d+ on armhf. Despite taking 12-15h on arm64.10:00
xnoxLocutusOfBorg:  is there something broken in our llvm, or ghc, such that we might need to rebootstrap it off debian again?10:01
LaneyTry asking IS to have a look at the builder, see if it's too overcommitted or weirdly IO bound or something10:02
xnoxwell somehow the build is now cancelled.10:04
xnoxnot sure why10:04
Laneydoesn't look like it to me https://launchpad.net/ubuntu/+source/ghc/8.8.3-3build1/+build/1987260310:05
cjwatsonAlso cancelling is only ever manual - it wouldn't happen automatically10:06
xnoxah, sorry, got confused in my tabs10:06
* xnox slurps more coffee10:06
xnoxeven if it completes building, the build-time there is not acceptable. something is broken.10:06
Laneyno more GHCs for groovy after this I'd say ;-)10:07
xnox<<ghc: 45287392 bytes, 19 GCs, 6117865/12278732 avg/max bytes residency (4 samples), 31M in use, 0.003 INIT (0.003 elapsed), 13.981 MUT (14.080 elapsed), 0.371 GC (0.375 elapsed) :ghc>>10:07
xnoxnot sure if this is good, bad or what it is.10:07
cjwatsonOnce it eventually finishes you might find something interesting by diffing build logs10:08
cjwatsonOr what Laney suggested above, though I'd be cautious to avoid accidentally killing something by incautious manual poking10:09
xnoxyeah that =/10:09
LaneyLaunchpad being able to use bos01 would probably help a little, too, if it is a problem with overcommit10:10
Laneyas an instance of a general "get more arm hardware" solution10:10
xnoxLocutusOfBorg:  but 8.8.4 hasn't migrated in debian yet.10:12
cjwatsonMy vague memory of why we don't currently use bos01 is that we haven't ported the base image building machinery to new keystone or similar, but I could be wrong10:19
cjwatsonwgrant would probably remember10:19
LaneyYeah, keystone v3, we had to do some light porting for autopkgtest10:19
Laneyit wasn't too bad, but still, work10:19
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1027.27] (no packageset)10:22
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1027.27]10:30
LocutusOfBorgxnox, 8.8.4 hasn't migrated because of slow new queue, we already have such leaf stuff here :)10:37
rbalintLaney, if we kill all glibc ppa autopkgtests on arm64/armhf that could help with the load10:37
LocutusOfBorgI took haskell-gi-harfbuzz from new queue and uploaded into groovy10:37
rbalintLaney, i would be ok with that, i think the aready ran tests are convincing enough for the ffe10:38
Laneyrbalint: ok, if that's what you want!10:38
rbalintLaney, if you won't complain later for not enough tests ;-)10:39
Laneyall gone10:40
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.3 => 2.04-1ubuntu26.4] (core)10:41
LocutusOfBorgbtw we should according to the build log, be near the end of the armhf build10:45
LocutusOfBorgxnox, we should (once the build is over) diff the log as Colin said, between 8.8.3-1build1 and 8.8.3-1ubuntu210:47
LocutusOfBorgalso, can anybody try to test haskell-hoogle/armhf on big_packages?10:48
LocutusOfBorgits still a libffi blocker10:49
xnoxcompared with arm64, it's like at 89% of the buildlog.10:49
xnoxbut that's like still hours to get there, i guess.10:49
LaneyI'll make sure to use this ghc a lot :-)10:50
LocutusOfBorgnot on armhf, too slow also in compiling stuff...10:50
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.142.5 => 1.142.6] (core)11:04
xnoxbdmurray:  grub2 & grub2-signed in focal-proposed are the ones you want to unblock lts->lts upgrades.11:05
rbalintbdmurray, wsl1 users should also wait for glibc11:18
seb128could someone update the reset hint for spice on ppc?11:41
seb128there was one lucky success and it's back to failing and blocking things11:41
LaneyI did it already11:43
seb128Laney, thanks!12:03
LocutusOfBorgubuntu-archive: cat-bat is NBS-proposed on armhf, can anybody please clean it up? depends on diamond-aligner, NBS there12:07
-queuebot:#ubuntu-release- New: accepted haskell-shake [amd64] (groovy-proposed) [0.19.1-2]12:09
-queuebot:#ubuntu-release- New: accepted haskell-shake [armhf] (groovy-proposed) [0.19.1-2]12:09
-queuebot:#ubuntu-release- New: accepted haskell-shake [riscv64] (groovy-proposed) [0.19.1-2]12:09
-queuebot:#ubuntu-release- New: accepted haskell-shake [arm64] (groovy-proposed) [0.19.1-2]12:09
-queuebot:#ubuntu-release- New: accepted haskell-shake [s390x] (groovy-proposed) [0.19.1-2]12:09
-queuebot:#ubuntu-release- New: accepted haskell-shake [ppc64el] (groovy-proposed) [0.19.1-2]12:09
LocutusOfBorgis it possible ubuntu-archive to remove swt4-gtk on armhf? it is NBS also in Debian...13:02
=== didrocks999 is now known as didrocks
-queuebot:#ubuntu-release- Unapproved: snapcraft (focal-proposed/universe) [3.0ubuntu1 => 3.0ubuntu1.1] (no packageset)14:00
bdmurrayrbalint: the upgrade process doesn't distinguish between wsl1 users or not14:26
ddstreetLaney rbalint latest haveged upstream is 1.9.13, but debian is still at 1.9.8, would you prefer 1) package 1.9.13 and ask debian to accept it and put it into groovy, or 2) just package 1.9.13 and put it into groovy and worry about debian later, or 3) revert groovy back to the really old 1.9.1, or 4) backport the specific fix for the segfault from upstream into 1.9.814:27
rbalintbdmurray, well would better do of glibc should be out before letting them to do release upgrade14:27
Laneyddstreet: I did (3) already; I would do (1) + (2) or (4) next but I don't have a particular opinion on what because I don't know haveged particularly well14:32
Laneyalso beefing up the autopkgtest, as I said14:32
ddstreetLaney right re: #3 what i meant was give up entirely on a newer haveged for groovy, i.e. touch nothing else14:32
ddstreetyeah, unfortunately the previous 'dieharder' test wouldn't have failed either, as it only segfaults with --Foreground14:32
bdmurrayrbalint: Is there a bug regarding the glibc update?14:33
rbalintddstreet, Laney if 1.9.13 is good i'd go with 2), because tests are still failing because broken haveged is in the image as i see14:33
ddstreet1.9.13 works for me, doesn't segfault14:34
rbalintddstreet, Laney and getting .13 in is faster than waiting for new images, i think14:34
Laneyah yeah new images /o\14:34
rbalintLaney, i forgot about those, too :-)14:34
rbalintddstreet, then i think going ahead with .13 is the best, i think14:35
LaneyI don't know the first thing about .13, so I refuse to have an opinion :p14:35
rbalintbdmurray, glibc is pending sru with several bugs14:36
Laneybut if you're going to package it, also proposing it to Debian would be the decent thing to do14:36
ddstreetyep i'll definitely open a salsa MR, but presumably it would take time for debian to merge, if we want it in ubuntu immediately to fix breakage probably shouldn't wait for debian14:37
rbalintLaney, sure14:37
rbalintddstreet, i see bump soname in haveged changelog14:38
rbalintddstreet, but there are no reverse deps14:39
ddstreetyep, seemed nothing but haveged uses libhavege1/214:39
rbalintddstreet, Laney  seems almost only bugfix release, so i think it can be uploaded without an ffe14:43
* rbalint afk a bit14:45
bdmurrayrbalint: when updating hints for a stable release we use ubuntu-sru not ubuntu-release15:06
rbalintbdmurray, thanks, why is that? it is harder to cherry-pick, not that bzr supported that in the past15:11
cjwatsonbzr supports it just as much as git does15:11
cjwatsonbzr merge -c<revision> has basically the same semantics as git cherry-pick <commit>15:12
rbalintcjwatson, thanks15:13
cjwatsonand the branch ownership is different because when a series is released responsibility for managing it is effectively handed over from ~ubuntu-release to ~ubuntu-sru15:13
cjwatsonit shouldn't have any particular effect on cherry-picking; it's a different branch either way15:14
rbalintbdmurray, ok, so the question is even more valid, why using the ubuntu-sru file when the branch is different already and cherry-picking would work using the same file even with brz?15:19
bdmurrayrbalint: I don't recall the reasoning behind it but I think it has to do with separating things pre and post release15:20
rbalintbdmurray, ok, that's not needed after the migration to git, because the release clearly branches off after release15:22
cjwatsonIt's about ownership/permissions, not about branching15:22
rbalintcjwatson, i thought the o/p is per branch15:23
cjwatsonbzr vs. git has very little to do with it15:23
cjwatsonOh, you're talking about the actual file name in the branch and not the URL of the branch, I see15:24
rbalintcjwatson, yes15:24
cjwatsonStill, the bzr/git business isn't relevant15:24
rbalintcjwatson, did bzr have something like git lot --graph master focal showing where the bzr branch forked off?15:25
cjwatsonI'm not your bzr manual :-)15:25
cjwatsonThere are certainly ways to get equivalent information, but I'm not going to go hunting for an exact UI equivalent15:26
rbalintcjwatson, so seemed to be very good at reminding how historical sw worked :-)15:26
cjwatson(Worst case, "bzr help revisionspec")15:26
cjwatsonAFAICS the hint permissions for ubuntu-sru and ubuntu-release are identical, so shouldn't be a problem there15:28
rbalintbdmurray, so how about just updating the ubuntu-release file instead of ubuntu-sru because it will be easier going forward?15:28
rbalintbdmurray, like not maintaining the hits per user which also used to be a practice15:29
rbalintcjwatson, good, i've prepared the switch to git for some time, one less thing to worry about15:30
rbalintbdmurray, also there is a commit to the 'freeze' file which separates pre- and post release15:31
ddstreetrbalint Laney fyi, haveged 1.9.13 failed on arm64 in my test ppa because it didn't like its self-test results...i'm retrying it but best case there is its self-tests are flaky, so i'm gonna look at just backporting the startup segfault fix in 1.9.8 for groovy15:33
-queuebot:#ubuntu-release- Unapproved: squid3 (xenial-proposed/main) [3.5.12-1ubuntu7.13 => 3.5.12-1ubuntu7.14] (ubuntu-server)15:40
rbalintbdmurray, also in bionic hints there were commits to ubuntu-release and to per user files15:40
Laneyrbalint: I rebuilt the images, now the new old haveged should really be there16:28
Laneydowngrading packages, just say no!16:28
Laneyand now I have retried systemd again16:31
Laneythis looks like we're mashing the button, but we're not, honest16:31
rbalintLaney, i was not looking , but good!16:40
vorlonLocutusOfBorg: swt4-gtk seems to have quite a few reverse-build-deps on armhf, what do we do with those?17:31
-queuebot:#ubuntu-release- Unapproved: gdm3 (focal-proposed/main) [3.34.1-1ubuntu1 => 3.36.3-0ubuntu0.20.04.1] (desktop-core)17:34
vorlonLocutusOfBorg: also why are you copying in a new upstream version of swt4-gtk post-FF anyway17:35
bdmurrayCan somebody remove sbuild-launchpad-chroot from bionic-proposed as it FTBFS.17:37
bdmurrayparide: Did something go wrong with your tag editing of bug 1874362? You did verify it correct?17:39
ubot5bug 1874362 in smartmontools (Ubuntu Bionic) "update-smart-drivedb is missing in Xenial and Bionic" [Undecided,Fix committed] https://launchpad.net/bugs/187436217:39
Laneybdmurray: done17:41
-queuebot:#ubuntu-release- Unapproved: corosync-qdevice (focal-proposed/universe) [3.0.0-4ubuntu1 => 3.0.0-4ubuntu1.1] (no packageset)17:45
-queuebot:#ubuntu-release- Unapproved: rejected nvme-cli [source] (focal-proposed) [1.9-1ubuntu0.1]17:58
-queuebot:#ubuntu-release- Unapproved: accepted rhythmbox-plugin-alternative-toolbar [source] (focal-proposed) [0.19.3-1.1]18:02
bdmurrayCould python-pip also be removed from xenial-proposed as it fails its autopkgtests?18:06
-queuebot:#ubuntu-release- Unapproved: rejected libvirt [source] (focal-proposed) [6.0.0-0ubuntu8.4]18:15
tewardwhoever approved the late-sync of xca (unless it's 'soft freeze' right now) thank you.  (that fixes a couple bugs AND lets me say "fixed in Groovy, SRU these fixes to Focal" now.18:25
tewardLaney: remind me, if I try and upload direct to -backports will it prohbit me or go via NEW or something?  Looking to backport `xca` to Focal backports :P18:26
tewardalso planning the same for nginx but never got a reply from you18:26
-queuebot:#ubuntu-release- Unapproved: accepted nvme-cli [source] (focal-proposed) [1.9-1ubuntu0.1]18:44
ddstreetrbasak could you import haveged into git-ubuntu? also i forget if there's a process for asking for pkgs to be git-ubuntu imported...18:45
ahasenackit's fine here, when someone is looking :)18:46
ahasenackI highlight on git-ubuntu18:46
LocutusOfBorg 2020-09-06 14:33:46 CESTPublishedGroovyproposeduniversemisc4.16.0-218:46
LocutusOfBorg 2020-09-06 14:33:54 CESTSupersededGroovyproposeduniversemisc4.16.0-118:46
LocutusOfBorgI copied -2 over -1, hoping to fix something, I didn't copy any new release18:46
LocutusOfBorganyway, Debian removed them I presume?18:46
LocutusOfBorgI did reverse-depends -r sid   src:swt4-gtk, rmadison for all the reverse-dependencies, and they are all source:all architecture18:49
LocutusOfBorgso no reverse-dependencies on armhf?18:50
ahasenackddstreet: importing18:50
-queuebot:#ubuntu-release- Unapproved: php7.4 (focal-proposed/main) [7.4.3-4ubuntu2.2 => 7.4.3-4ubuntu2.3] (i386-whitelist)18:53
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (focal-proposed) [3.0ubuntu1.1]19:01
LocutusOfBorgvorlon, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96291519:13
ubot5Debian bug 962915 in ftp.debian.org "RM: swt4-gtk [armel armhf i386 mipsel] -- ROM; Upstream no longer supports 32 bits architectures" [Normal,Open]19:13
ahasenackddstreet: https://code.launchpad.net/ubuntu/+source/haveged done, and it will be kept up-to-date now19:30
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.3-0ubuntu1]20:30
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.10-0ubuntu1]20:36
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.1.1-0ubuntu1]20:40
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (bionic-proposed) [1:12.0.2-0ubuntu1]20:42
-queuebot:#ubuntu-release- Unapproved: accepted munin [source] (xenial-proposed) [2.0.25-2ubuntu0.16.04.4]20:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!