[01:02] <tsimonq2> Nice, for perl to migrate, only its own autopkgtests need to pass, which are probably going to require a patch, that triggers all of the tests again. :P
[01:03]  * tsimonq2 tries to repro the failure on porterboxes first.
[01:06] <tsimonq2> "opening NDBM file failed: No such file or directory at -e line 1." I wonder why it was blindly retried three times. :P
[01:30] <tsimonq2> ahhhh
[01:30] <tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925179
[01:30] <ubot5`> Debian bug 925179 in perl "perl: autopkgtest failures on arm64, ppc64el and s390x: NDBM backwards binary compatibility" [Important,Open]
[01:39] <vorlon> coreycb: fyi, 'lintian masakari-monitors*changes' detects that the autopkgtests are broken because the test name in debian/tests/control doesn't match the name of the script in the directory
[01:41] <vorlon> coreycb: init scripts, huh
[01:42] <vorlon> coreycb: except not really init scripts, because they do nothing except define some variables...
[01:46] <vorlon> coreycb: and debian/masakarimonitors_sudoers looks very wrong, there is no /usr/bin/privsep-helper in Ubuntu AFAICS
[01:57] <tsimonq2> vorlon: https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/ubuntu-release#L194 kick the can on python-scipy? It's the last thing blocking python-numpy and the failure is unrelated, in addition to there already being a hint for the version currently in devel-release. (The astropy-healpix pass hasn't showed up yet.)
[03:16] <vorlon> tsimonq2: I haven't compared the failures for the old vs new versions of python-scipy, do they look the same? can we be confident that python-numpy isn't introducing any regressions?
[03:39] <tsimonq2> vorlon: The failures on the python-scipy in proposed with and without python-numpy look to be the the same.
[05:39] <Eickmeyer> vorlon: I know it's late, but I'm hoping you got my last message about having pushed the changes to carla you requested.
[07:12] <vorlon> Eickmeyer: so, how did you determine that all of hylia is copyright falktx and not ableton?  Because the issue I pointed out was source/modules/hylia/link/AudioEngine.* and source/modules/hylia/link/ableton/* being BSL-1 vs. GPL-2+, and your change now lists all of source/modules/hylia/link/* as GPL-2+, including many files that licensecheck identified as BSL-1 licensed
[07:53] <acheronuk> daily iso builds are not syncing again. i.e. building, but empty: http://cdimage.ubuntu.com/kubuntu/daily-live/20190324/
[08:42] <acheronuk> oh. mcopy: File "::EFI/BOOT/mmx64.efi" not found
[09:03] <acheronuk> hmm. livefs builds complete, but look borked
[09:23] <acheronuk> actually not that
[15:00] <Eickmeyer> vorlon: it was based on https://github.com/falktx/hylia. I’ll do some more investigation ASAP.
=== paride is now known as paride__
[15:23] <Eickmeyer> vorlon: Fixed, tagged, pushed. Basically, I just now went into each file and verified the copyright line in the files. Hopefully this works better. I guess your previous message confused me.
[15:26] <Eickmeyer> I realize you sent that last message at midnight, I was sound asleep. I hope it's not too late.
[15:26] <Eickmeyer> I hope my fixes, rather, are not too late.
[17:10] <acheronuk> cyphermox: on failing iso builds for all flavours: "mcopy: File "::EFI/BOOT/mmx64.efi" not found"
[17:10] <acheronuk> I guess a result of your debian-installer upload a few days back?
[20:08] <infinity> acheronuk: Fixing.
[21:07] <mitya57> Has something happened to proposed migration? The last update_output.txt was generated 2019-03-24 03:35 +0000 which is 17 hours ago. And the packages are not migrating.
[21:18] <mwhudson> mitya57: it doesn't seem like proposed migration itself is stuck but you're right it hasn't run in a while
[21:18] <mwhudson> infinity: if you're still here can you poke? ^
[22:00] <cjwatson> mitya57,mwhudson: There was an unscheduled LP frontend reboot around that time that apparently caused a few client programs to hang.  I've hit it with a suitable stick.
[22:00] <mwhudson> cjwatson: thanks