[00:01] <xnox> doko:  thanks!
[05:40] <doko> gcc-9 builds still running ...
[05:40] <doko> RikMills, xnox: ^^^
[07:31] <jibel> doko, okay, I'll have a look at autopilot to remove the dep on qt4
[08:09] <seb128> hum, a recent file-roller update fails to build on arm64/s390x with that error
[08:09] <seb128>  /usr/bin/ld: cannot find -lgcc_s
[08:09] <seb128> does anyone has an idea what than is about (https://launchpadlibrarian.net/463253875/buildlog_ubuntu-focal-arm64.file-roller_3.35.90-1_BUILDING.txt.gz)
[08:10] <seb128> https://launchpad.net/ubuntu/+source/neon27/0.30.2-4 has the same problem
[08:10] <seb128> I guess toolchain problem in focal-proposed?
[08:10] <seb128> doko, ^ do you know about that?
[08:10] <ricotz> https://launchpad.net/ubuntu/+source/gcc-9/9.2.1-26ubuntu3
[08:11] <seb128> hey ricotz
[08:11] <ricotz> seb128, hi
[08:11] <seb128> ricotz, is that the version that breaks it or fix it? :)
[08:11] <seb128> well it failed to build on those archs as well
[08:13] <ricotz> seb128, I am sure he is aware, seems -26 is borked
[08:14] <seb128> we should maybe just delete that version from proposed meanwhile?
[08:14] <seb128> well, let's wait to see if doko is around and he prefer to try to fix it
[08:14] <ricotz> not my call, but that would be reasonable
[08:14] <ricotz> seb128, could you retry https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#vala
[08:15] <seb128> ricotz, retry isn't really working, see http://autopkgtest.ubuntu.com/packages/a/automake-1.16/focal/armhf
[08:16] <seb128> but the issue is not due to vala, it failed its own trigger, so I think we should just ask to ubuntu-release to skip the automake-1.16/arhmf result to let vala be a candidate
[08:17] <ricotz> seb128, I see, that would be nice
[08:53] <RikMills> seb128: dok0 said last night he was building a fixed gcc, which I suspect is here: https://launchpad.net/~doko/+archive/ubuntu/bootstrap/+packages
[08:58] <seb128> RikMills, ah, good to know, thx
[10:04] <xnox> seb128:  read the overnight backlog
[10:39] <doko> xnox, RikMills: fixed gcc-9 published. I would appreciate it if you could give back failed builds on arm64/s390x in proposed. currently at a workshop
[10:40] <xnox> doko:  i did give back mine. they look ok now! thank you =)
[10:41] <doko> that was not my question
[10:45] <gpiccoli> o/ sil2100 - guess what I'm gonna talk? mdadm, of course ! heheh
[10:46] <gpiccoli> The pkg is on -proposed for 2 weeks almost, and was tested/verified by me
[10:46] <gpiccoli> Any chance we get that promoted to -updates? Tnx in advance
[11:13] <sil2100> gpiccoli: hey! hm, I'm worried that comment #11 from LP: #1850540 is still valid? .4 is still in the works
[11:13] <ubottu> Launchpad bug 1850540 in linux (Ubuntu Focal) "multi-zone raid0 corruption" [Undecided,Confirmed] https://launchpad.net/bugs/1850540
[11:25] <gpiccoli> sil2100, this was dropped! heheh
[11:25] <gpiccoli> We discussed with dannf, no work from his LP is in -proposed now
[11:25] <cjwatson> xnox: One finishes the u-a-t porting work instead of asking passive-aggressive questions? ;-)
[11:26] <cjwatson> It shouldn't be miles away
[11:26] <gpiccoli> That was a factor of delaying in fact - because of regressions in that layout patches, it got my LP delayed hehe
[11:26] <gpiccoli> So, dannf agreed we get mine released and then he'd re-add his work on mdadm, on top of mine =)
[11:27] <xnox> cjwatson:  u-a-t? =)
[11:27] <xnox> ah
[11:27] <xnox> nice =)
[11:27] <xnox> true
[11:28] <xnox> i think the one script that I needed "just worked" wich a change of a shebang ;-)
[11:28] <cjwatson> Some years back I did a bunch of anticipatory porting work but deliberately held off from changing the #! because at the time a lot of its users were on Ubuntu releases that didn't have a sufficiently py3-capable launchpadlib
[11:47] <sil2100> gpiccoli: crap, so it's this darn bug again
[11:47] <sil2100> gpiccoli: you are right, but the pending-sru page still displays the bug as being part of the upload - that's a bug that's happening from time to time there
[11:47] <sil2100> And confusing everyone, eh
[11:48] <gpiccoli> haha ok sil2100, no problem! Tnx for your attention
[11:48] <sil2100> gpiccoli: ok, let me take a look then now!
[11:48] <gpiccoli> Awesome =]
[11:48] <gpiccoli> And I think the kernel part was reworked in the last cycle, so dannf likely will have the mdadm part soon to be merged, and finally get that LP resolved too
[12:18] <ahasenack> hi, any idea why this package from debian isn't in ubuntu yet? https://launchpad.net/debian/+source/vmem
[12:20] <Laney> ahasenack: https://people.canonical.com/~ubuntu-archive/auto-sync/current.log
[12:21] <Laney> vmem_1.8-1 is trying to override modified binary libvmem1_1.7-1ubuntu1.  OK (y/N)?  n
[12:21] <ahasenack> ah
[12:21] <ahasenack> ok, I'm about to update pmdk (where that libvmem 1.7 comes from)
[12:21] <ahasenack> then autosync will work I guess?
[12:21] <ahasenack> pmdk 1.8 doesn't have vmem anymore
[12:22] <Laney> looks like it indeed
[12:22] <ahasenack> ok, thanks
[12:39] <gpiccoli> Thanks a lot sil2100 =)
=== ricab is now known as ricab|lunch
[13:15] <sil2100> gpiccoli: yw! Sorry it took longer than expected, I blame the tooling for that!
[13:16] <gpiccoli> hahaha no need to be sorry, you were quite helpful sil2100, appreciate a lot!
[13:16] <gpiccoli> Tnx dannf also for letting me release my stuff before the layout work!
=== ricab|lunch is now known as ricab
[14:42] <jamespage> Laney: afternoon
[14:42] <jamespage> Laney: I have a new upload of vaultlocker in bionic-backports/unapproved to fixup an SRU related issue
[14:43] <jamespage> any chance that could be accepted? i got the bug reporter to validate the package backport via PPA as well
[14:45] <Laney> jamespage: yup
[14:47] <jamespage> Laney: ta
[14:47] <sahid> coreycb: o/ python-ironic-lib needs a version bump of python3-zeroconf, could you clone the repo?
[14:48] <jamespage> sahid: yep
[14:48] <jamespage> although I'm not coreycb maybe he's already doing it :)
[14:48] <sahid> :)
[14:54] <sahid> jamespage, coreycb: it's python-zeroconf
[15:03] <coreycb> sahid: that's pushed now
[15:03] <sahid> thank you
[17:29] <ahasenack> if I use sudo in a dep8 script, do I need to set the requirement root-required? I didn't want to run the test as root, though, it's just one setup command that has to
[17:36] <joelkraehemann> hi all
[17:36] <joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer
[17:36] <joelkraehemann> ^^ do I need to fill a sync-request?
[17:40] <cjwatson> joelkraehemann: Not as far as I can see.  Why do you think you might need to file one?
[17:43] <cjwatson> (Maybe explain what problem you're trying to solve)
[17:45] <joelkraehemann> version 3.0.3 is still proposed after 3 weeks
[17:46] <joelkraehemann> ... version 3.0.0 introduced additional packages providing GObject-Introspection
[17:46] <joelkraehemann> cjwatson: do you think it is going to focal?
[17:47] <cjwatson> joelkraehemann: It's blocked due to test regressions.  See https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer
[17:47] <cjwatson> (I know nothing more than that)
[17:47] <joelkraehemann> But I do ...
[17:47] <cjwatson> Sync requests are for copying source packages from Debian to focal-proposed; they would achieve nothing here
[17:48] <joelkraehemann> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/g/gsequencer/20200118_155728_62a6c@/log.gz
[17:48] <joelkraehemann> ^^ the test-bed provided wrong configure flags, I think
[17:49] <joelkraehemann> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/g/gsequencer/20200116_193425_57c30@/log.gz
[17:49] <joelkraehemann> ^^ the same here
[17:49] <cjwatson> Configure flags are up to the package, not the testbed, I'm pretty sure
[17:49] <cjwatson> The testbed doesn't concern itself with that sort of detail
[17:49] <joelkraehemann> https://ci.debian.net/packages/g/gsequencer/
[17:51] <joelkraehemann> cjwatson: I am thinking debhelper flags passed to autopkgtest
[17:51] <joelkraehemann> ^^ of
[17:51] <cjwatson> That's not very plausible
[17:51] <cjwatson> I'm pretty certain that's not a thing
[17:52] <cjwatson> I'd suggest diffing test logs to try to narrow things down, perhaps
[17:52] <joelkraehemann> configure: WARNING: unrecognized options: --disable-maintainer-mode
[17:52] <joelkraehemann> xvfb-run: error: Xvfb failed to start
[17:52] <joelkraehemann> you are right, xvfb-run failed ...
[17:52] <joelkraehemann> can you trigger autopkgtest to run again?
[17:53] <cjwatson> xvfb-run is implicated in the ags-integration-functional-test failure (which is labelled "FLAKY"), but that doesn't explain the ags-integration-unit-test failure
[17:53] <cjwatson> Have you investigated that part of the log at all?
[17:54] <joelkraehemann> ags-integration-unit-test FAIL timed out
[17:54] <joelkraehemann> ^^ this is not flaky
[17:54] <joelkraehemann> there are 2 different tests
[17:55] <cjwatson> I didn't say it was flaky :)
[17:55] <cjwatson> I said that ags-integration-functional-test is the one that's flaky and is the one where xvfb-run failed.  Do you have an explanation for the ags-integration-unit-test failure?
[17:55] <joelkraehemann> booth tests relay on xvfb-run
[17:57] <joelkraehemann> ags-integration-unit-test FAIL timed out
[17:57] <joelkraehemann> ^^ the build host didn't have enough computing power ...
[17:57] <joelkraehemann> you are right we should update to latest version
[17:58] <cjwatson> http://autopkgtest.ubuntu.com/packages/g/gsequencer/focal/arm64 shows a failure only 20 minutes ago
[17:58] <cjwatson> So I'm reluctant to just bang retry on it
[17:58] <joelkraehemann> ok
[17:58] <joelkraehemann> it is fixed as of latest upstream
[17:58] <joelkraehemann> ... it is really a unit-test problem
[17:59] <cjwatson> But honestly I'm just giving pointers here, this is mostly not a thing I work with very much
[18:00] <joelkraehemann> I have investigated the issue, the unit-tests timeout because the build host doesn't provide enough CPU power while doing realtime threads ...
[18:42] <Darkchaos> doko: I'd love to fix two issues for openjdk-lts. One seems to be rather complicated but the other one is just a symlink to src.zip, which seems to be important, because IDEs rely on that to have javadoc for system classes.
[18:43] <Darkchaos> Could you guide me through the process/have a look at these? (There also is 1826455) which can be marked as solved by now
[18:56] <Darkchaos> okay, judging by https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/commit/?h=openjdk-11&id=3c36564cf4e6f17e1418332d4b977c8bad69cfa0 the symlink issues are already resolved, so we'd just need to close those two bugs
=== ben_r_ is now known as ben_r