[08:38] <seb128> rbalint, hey, https://launchpad.net/ubuntu/+source/vim/2:8.2.0716-3ubuntu2 ... why is it a good idea disabling test? would be nice to have some description stating if that's a forever delta or wjat's the reason, also do you plan to try to get that change to Debian?
[09:08] <rbasak> vorlon: sergiodj asked me to review https://code.launchpad.net/~sergiodj/britney/hints-ubuntu-xenial/+merge/388495 but I've never really understood what you want wrt. these cases. SRU to fix the autopkgtest? badtest the version only? badtest all versions?
[09:08] <rbasak> AIUI a fix to the test case in Xenial is available.
[09:08] <rbasak> And this failure "blocks" the rpcbind SRU from being released
[09:09] <rbasak> Any chance of some documentation for when a badtest is acceptable to you please?
[09:13] <xnox> seb128:  it builds fine in debian, maybe with the next merge it will "just work"
[09:14]  * xnox ponders when matrix channel will finally send a message, or maybe that would be never.
[09:15] <seb128> xnox, hey, what are you talking about?
[09:18] <seb128> xnox, was it my comment about vim?
[09:19] <seb128> xnox, basically I was saying that adding undocumented and unforwarded delta just creates debt and increase our workload for futur cycles
[09:38] <xnox> seb128:  please see discussion about vim on riscv64 across all the previous weeks here, on #ubuntu-meeting and ~RISCV =)
[09:38] <xnox> seb128:  this change was not done lightly.
[09:40] <xnox> rbalint:  i did say, you should also open a bug report documenting that tests were disabled for riscv64 and need to be investigated.... and expected for that bug to be referenced in the changelog. such that there are breadcrumbs for others to follow ^
[09:40] <Laney> the changelog could be more verbose, I think that's a fair comment to make
[09:40] <xnox> Laney:  yeap.
[09:45] <cpaelzer> slyon: all dpkg tests are green now
[09:46] <cpaelzer> should migrate on the next run
[09:48] <seb128> xnox, I didn't say that it was done lightly, just that the rational was undocumented in the changelog and that there was no bug reference or forwarding ... but seems you agree so no reason to keep that discussion going :-)
[09:56] <slyon> cpaelzer: great!
[10:12] <rbasak> TIL: lddtree
[10:12] <rbasak> Thanks Christian :)
[10:12] <cpaelzer> yw rbasak
[10:12] <cpaelzer> you sometimes want -a on it
[10:12] <cpaelzer> Hi https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4192/+build/19813392 is hanging and it will soon timeout-die
[10:13] <cpaelzer> This is due to bug 1891158
[10:13] <ubottu> bug 1891158 in dee (Ubuntu) "riscv64 build - hang at the end of the build (groovy)" [Medium,Confirmed] https://launchpad.net/bugs/1891158
[10:13] <cpaelzer> I've added some debug to this build, but even hitting an exit 1 in override_dh_auto_test  will suffer from the hanging process keeping the chroot up
[10:13] <cpaelzer> I'm afraid once it died I won't be able to get the full log
[10:14] <cpaelzer> can anyone "log into" that builder and get the build log as generated so far?
[10:14] <cpaelzer> cjwatson: ^^ since you gave me the initial traces to follow when debugging this - maybe you can do that?
[10:24] <cjwatson> cpaelzer: I'm pretty sure if you cancel it you'll get the full log.
[10:24] <cjwatson> cpaelzer: And even if you don't, this is a devirt builder so I can always log in after the fact and get the full log.
[10:25] <cjwatson> cpaelzer: So please try an ordinary cancel first.
[10:25] <cpaelzer> thanks cjwatson - I wanted to make sure I ask before I throw away the chance to get to the log - aborting now ...
[10:30] <cpaelzer> cjwatson: cancel complete, no buildlog there
[10:30] <cpaelzer> cjwatson: could you log in and throw me the full log somewhere?
[10:32] <Laney> cpaelzer: what are you seeing - stray dbus-daemon or something?
[10:38] <cpaelzer> Laney: yes seems like that
[10:39] <Laney> mmm
[10:39] <cpaelzer> I see some timeouts on the test and then it never dies until 24h timeout
[10:39] <Laney> so https://bazaar.launchpad.net/~indicator-applet-developers/dbus-test-runner/trunk.16.10/view/head:/libdbustest/service.c#L181 failed I guess
[10:39] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1891158 is what I know about it so far
[10:39] <ubottu> Launchpad bug 1891158 in dee (Ubuntu) "riscv64 build - hang at the end of the build (groovy)" [Medium,Confirmed]
[10:39] <Laney> because you see that g_print() but then the daemon is still there
[10:39] <Laney> so that kill must have not worked?
[10:39] <cpaelzer> yes I see the g_print
[10:39] <cpaelzer> but the builder still isn't returning
[10:40] <cpaelzer> I was adding some debug in the build to look for active processes and open cwds
[10:40] <cpaelzer> that is the build I'd like the log from
[10:40] <cpaelzer> just in case it helps to understand the case
[10:40] <Laney> It's probably waiting for all of the build's processes to exit, namely that dbus-daemon
[10:40] <Laney> I'm just pointing you at dbus-test-runner because it might be a good place to add some more verbosity
[10:40] <cpaelzer> I'd have a mitigation skipping the tests on riscv64, but only would go that route after giving up on understanding what goes on
[10:41] <Laney> like -> here's the PID of the dbus-daemon I spawned, here's the PID of the thing I tried to kill
[10:41] <Laney> then you can match those up an dsee if that's the stray one
[10:41] <cpaelzer> for now getting that full build log of https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4192/+build/19813392 woud be a good next step
[10:42] <cpaelzer> but thanks on the hint for dbus-test-runner - I could throw one wit hmore debug into the PPA as well
[10:42] <cpaelzer> just that I have to ask for full logs is a bit inhibiting :-)
[10:42] <cpaelzer> as "alone" I can only see the snippet the build shows while running
[10:42]  * cpaelzer off a bit for lunch
[10:43] <Laney> I wonder if you lowered the timeout on your local system if it would happen to
[10:43] <Laney> too*
[10:43] <Laney> like, make it 1 second or 0.1 seconds or something, might trigger the same bug
[11:03] <cjwatson> cpaelzer: will do after meeting
[11:17] <cpaelzer> back again, and thanks in advance
[11:24] <cpaelzer> Laney: it can't be a fraction but -m 1 is already building
[11:25] <cpaelzer> and vice versa "just" bumping the timeout could be a fix for riscv builds for now
[11:31] <Laney> right, even if you manage to fix the test runner to fail properly it's still an FTBFS :-)
[11:34] <cpaelzer> Laney: ha - timeout = 1 on x86 triggers the same warnings/erorrs, but NOT the hang of the builder
[11:34] <cpaelzer> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4200/+build/19818311 is an example
[11:34] <Laney> interesting
[11:35] <Laney> perhaps riscv64 does process reaping differently
[11:37] <wgrant> Laney, cpaelzer: dbus-test-runner is what generally gets stuck, I haven't worked out why.
[11:37] <wgrant> But there are a couple of packages that were consistently hanging because it didn't die for a while. But they seemed to eventually fix themselves by around maybe September.
[11:38] <cpaelzer> wgrant: https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1891158 seems to be a new occasion for this then
[11:38] <ubottu> Launchpad bug 1891158 in dee (Ubuntu) "riscv64 build - hang at the end of the build (groovy)" [Medium,Confirmed]
[11:38] <seb128> wooot, sbuild migrated :)
[11:39] <cpaelzer> Right now I'm testing if for riscv I need to bump the timeout or skip the test entirely
[11:39] <cpaelzer> seb128: yes I did some trigger magic
[11:39] <seb128> thanks slyon and cpaelzer for the work unblocking it!
[11:39] <cpaelzer> together with dpkg
[11:39] <cpaelzer> wgrant: was there a bug for dbus-test-runner back then?
[11:40] <cpaelzer> wgrant: or should I add a task that we keep open to my bug (for documentation purposes) ?
[11:40] <wgrant> cpaelzer: Has anyone tried to reproduce it?
[11:41] <cpaelzer> I tried to trigger the same on other arches with no luck
[11:41] <wgrant> For something like dee I'd probably just skip the test suite, since it tends to bitrot fairly aggressively.
[11:41] <cpaelzer> I can make it happen more likely on riscv64 thou, by reducing the timeout
[11:41] <wgrant> But someone probably should dig into dbus-test-runner at some point.
[11:41] <wgrant> Yep
[11:41] <cpaelzer> I'll add a dbus-test-runner task to my bug then
[11:42] <cpaelzer> and try in a riscv64 qemu a bit
[11:43] <cpaelzer> wgrant: since I have you here - ever seen https://github.com/dartsim/dart/issues/1482 before?
[12:04] <ahasenack> teward: hi, around? Would you like us to merge nginx from debian again, or were you planning on doing that?
[12:09] <rbasak> rbalint: o/ I'm reviewing this glibc SRU. In bug 1889190, what's the user story that's broken please? And shouldn't it be fixed in Groovy first?
[12:09] <ubottu> bug 1889190 in glibc (Ubuntu Focal) "ldconfig is still deferred in libc6.preinst " [Undecided,New] https://launchpad.net/bugs/1889190
[12:54] <rbasak> rafaeldtinoco: o/ couple of quick queries on your bcache-tools SRU for Xenial please
[12:55] <rafaeldtinoco> xenial ?
[12:55] <rbasak> Oh Bionic sorry
[12:55] <rbasak> I have Xenial in my head
[12:55] <rafaeldtinoco> ah =)
[12:55] <rafaeldtinoco> sure
[12:55] <rbasak> Because the version number in your upload would clash with a Xenial SRU should that be required
[12:55] <rbasak> Can you see if you agree please?
[12:55] <rbasak> Second question - I note this was already accepted into Focal, but I'm puzzled by the dependency on gawk
[12:55] <rafaeldtinoco> oh
[12:56] <rafaeldtinoco> rbasak: I missed that, yes
[12:56] <rafaeldtinoco> just saw it
[12:56] <rbasak> The code being added calls "awk" by name, which would be subject to update-alternatives
[12:56] <rbasak> If gawk is specifically required, then I'd expect gawk to be called by name explicitly, as well as the depependency
[12:56] <rafaeldtinoco> rbasak: so I had an issue with awk (mawk vs gawk recently)
[12:56] <rafaeldtinoco> you prefer us to call a specific one ?
[12:56] <rbasak> If you need a specific one, then I'd expect that
[12:56] <rbasak> If you don't need a specific one, then I'm not sure you need the dependency?
[12:56] <rafaeldtinoco> I dont think for this case a specific one is needed
[12:57] <rafaeldtinoco> rbasak: I thought I had a dep for it
[12:57] <rafaeldtinoco> it was part of paelzers review
[12:57] <rafaeldtinoco> one of his requests iirc
[12:57] <rafaeldtinoco> unless Im confusing with other revirew
[12:57] <rafaeldtinoco> let me check
[12:58] <rbasak> It's not marked Essential so maybe you do need a dependency
[12:58] <rafaeldtinoco> rbasak: im thinking because of groovy & focal
[12:58] <rafaeldtinoco> -Depends: ${misc:Depends}, ${shlibs:Depends}
[12:58] <rafaeldtinoco> +Depends: ${misc:Depends}, ${shlibs:Depends}, gawk
[12:58] <rafaeldtinoco> for groovy
[12:59] <rafaeldtinoco> focal also has it
[12:59] <rafaeldtinoco> rbasak: ok all 3 have the same change
[12:59] <rafaeldtinoco> to debian/control (Depends)
[12:59] <rafaeldtinoco> isn't that enough ?
[12:59] <rbasak> I would have used "mawk | awk" or something
[13:00] <rafaeldtinoco> oh
[13:00] <rbasak> What you have isn't incorrect, but it would cause gawk to get pulled in to an SRU if the user doesn't have it installed I think
[13:00] <rafaeldtinoco> I see what you mean
[13:00] <rbasak> Although
[13:00] <rafaeldtinoco> makes sense
[13:00] <rbasak> lsb-core depends on it
[13:00] <rbasak> As does byobu
[13:00] <cpaelzer> we have alinged to some common packages already depending on it that way, but we didn't check which ones
[13:01] <rbasak> mawk is in the minimal seed
[13:01] <rbasak> So we can always expect that
[13:01] <cpaelzer> rbasak: is there a single bug for "please get mysql5.7 into debian (testing)" ?
[13:01] <rbasak> cpaelzer: you mean 8.0?
[13:01] <cpaelzer> yeah
[13:02] <rbasak> There isn't, but also it would only be unstable, not testing
[13:04] <rafaeldtinoco> rbasak: with those dependencies and an already done SRU for focal with gawk, should we stick to gawk for bionic just so things are the same ? And I recently had a regression in +1maint because of mawk vs gawk syntax (autopkgtest dependencies though).. I thought the same about alternatives / mawk being the default fort minimum
[13:07] <rbasak> rafaeldtinoco: I accepted that Focal is done that way. But if it introduces something undesirable, then we have an opportunity to not do that to users for Bionic here.
[13:07] <rbasak> OK
[13:07] <rbasak> Leave it as it is.
[13:08] <rafaeldtinoco> rbasak: I can change, no complains
[13:08] <rafaeldtinoco> I thought about uniformity vs fixing it =)
[13:08] <rbasak> I'll leave it to you then. I'll accept either way.
[13:08] <rafaeldtinoco> rbasak: just to confirm
[13:08] <rbasak> It does mean more work for you if one of them turns out to be wrong.
[13:08] <rafaeldtinoco> having mawk would be better
[13:08] <rafaeldtinoco> right ?
[13:08] <rafaeldtinoco> because its already part of min installation
[13:09] <rbasak> IMHO, using mawk would be better since that's guaranteed to be present on Ubuntu, and wouldn't pull in a dependency - especially in adding that in an SRU.
[13:09] <rbasak> Right
[13:09] <rbasak> It's fine to know about a shortcoming and depend on gawk, but in that case gawk needs to be used explicitly rather than assuming which way the update-alternative points
[13:09] <rafaeldtinoco> yep
[13:09] <rafaeldtinoco> one thing Im afraid now Robie
[13:10] <rafaeldtinoco> Im pretty sure I have tested everything with gawk
[13:10] <rbasak> Right
[13:10] <rbasak> That's why I'll accept gawk for Bionic :)
[13:10] <rafaeldtinoco> but I can call it directly
[13:11] <rafaeldtinoco> rbasak: should I change a direct call s/awk/gawk and repush ?
[13:11] <rafaeldtinoco> to be 100% ?
[13:11] <rbasak> Sure if you want to do that
[13:11] <rbasak> Remember to fix the version string please
[13:11] <rafaeldtinoco> alright, ill fix both and ping u back
[13:11] <rafaeldtinoco> thanks!
[13:20] <rafaeldtinoco> rbasak: should I use 1.0.8-2ubuntu1 or 1.0.8-2ubuntu1.0 ?
[13:21] <rafaeldtinoco> xenial could have a 1.0.8-2ubuntu0.1
[13:22] <rbasak> 1.0.8-2ubuntu0.18.04.1?
[13:22] <rbasak> That would leave 1.0.8-2ubuntu0.16.04.1 for Xenial, etc
[13:22] <rafaeldtinoco> perfect
[13:24] <cjwatson> cpaelzer: https://paste.ubuntu.com/p/RhFWhJHW2Z/
[13:25] <rafaeldtinoco> rbasak: as I had uploaded 1.0.8-2ubuntu0.1
[13:25] <rafaeldtinoco> this will also solve that correct ?
[13:25] <rafaeldtinoco> just checking
[13:25] <rafaeldtinoco> (I assume I have to overseed the previous upload to -proposed)
[13:28] <rafaeldtinoco> (and should I force push to git-ubuntu pkg also ? the new upload tag ?)
[13:31] <rbasak> rafaeldtinoco: yes I will reject the old upload so it will be as if that didn't happen. You can push the new upload tag and delete the old one
[13:31] <rafaeldtinoco> perfect. thanks
[13:33] <cpaelzer> thanks cjwatson
[13:43] <rafaeldtinoco> rbasak: taking a few to test it against the test case again
[13:43] <rafaeldtinoco> just to make sure =)
[13:44] <rbasak> Sure
[14:16] <cpaelzer> seb128: Laney: in proposed are all kind of things around *compiz* 2:0.8.18 most of them blocked on missing build dep (one epoch away).  I come from a +1 POV, is Desktop handling these and I can go on without looking into it?
[14:17]  * cpaelzer reads old +1 report mails if something was mentioned
[14:18] <cpaelzer> "all kind" may be too much
[14:18] <cpaelzer> looking a bit deeper it is down to two things
[14:18] <cpaelzer> https://launchpad.net/ubuntu/+source/compiz-plugins-experimental/2:0.8.18-1
[14:18] <cpaelzer> https://launchpad.net/ubuntu/+source/compizconfig-python/2:0.8.16-2
[14:18] <seb128> cpaelzer, I don't think anyone in desktop has been working or interested by those
[14:18] <seb128> mitya57 might know better the status
[14:19] <cpaelzer> seb128: I'm clearing out packages like these - if I could get a clear "we don't need and are not interestd in those" that woudl be enough
[14:19] <cpaelzer> mitya57: let me know once you read that
[14:20] <mitya57> cpaelzer: Debian decided to use a fork of Compiz 0.8. We are using 0.9 where all code is in a single source, so all those source packages should be deleted/blacklisted.
[14:20] <cpaelzer> thank you
[14:20] <cpaelzer> will let that happen then
[14:21] <seb128> mitya57, thanks
[14:25] <cpaelzer> essentially is a re-occurance of 1844626 - I'll try to ensure it stays non-synced this time
[14:43] <rbalint> rbasak, thanks for reviewing glibc, yes the fix is planned to land in groovy next weeks with the other fixes in the upload
=== hellswor1 is now known as hellsworth
[14:50] <rbalint> rbasak, with do-release-upgrade the bug did not cause problems in my testing, but it is still reproducible the way listed in the bug
[14:58] <rafaeldtinoco> rbasak: upload/1.0.8-2ubuntu0.18.04.1 (uploaded) sources file pushed
[15:10] <bdmurray> bryyce: node-redis has passed for me multiple times. do you want to add it to long_tests or shall I?
[15:21] <bryyce> bdmurray, that's great to hear.  I haven't marked long tests before but would love to learn how.
[15:23] <bdmurray> bryyce: I tried to write enough down here if its inadequate let me know and I'll give you a hand. https://wiki.ubuntu.com/ProposedMigration#autopkgtests
[15:29] <bryyce> thanks
[15:33] <seb128> rbalint, hey, did you get anywhere with systemd vs plymouth?
[15:48] <cpaelzer> rbalint: I was checking the systemd autopkgtests which were flaky retries and which were real issues
[15:48] <cpaelzer> rbalint: and it seems all were flaky (most resolved now and src:audit in the queue to be tested)
[15:49] <cpaelzer> rbalint: but one remained - plymouth - that seemed to be a genuine issue and I found https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1886886/comments/2
[15:49] <ubottu> Launchpad bug 1886886 in plymouth (Ubuntu) "Plymouth 0.9.5 release" [Wishlist,Fix committed]
[15:49] <cpaelzer> I wanted to ask what became of this and if you could update the bug if something was e.g. added to systemd/245.7-1ubuntu1 for it
[16:02] <seb128> vorlon, hey, could you have a look to the speech-dispatcher-contrib i386 build failure? it seems a fallout from your change you upstreamed to Debian but unsure why it didn't bite us previous cycle?
[16:47] <LocutusOfBorg> niedbalski, debian bug opened, and uploaded in Ubuntu groovy
[16:47] <niedbalski> LocutusOfBorg: great, thank you.
[16:50] <LocutusOfBorg> please send upstream your patch
[16:51] <LocutusOfBorg> <BTS> Opened #968298 in src:bind9-libs 1:9.11.19+dfsg-1 by Gianfranco Costamagna (locutusofborg) «bind9-libs: SEGFAULT on redundant dhcp server configuration». https://bugs.debian.org/968298
[16:51] <ubottu> Debian bug 968298 in src:bind9-libs "bind9-libs: SEGFAULT on redundant dhcp server configuration" [Important,Open]
[16:55] <niedbalski> LocutusOfBorg: iiuc, it would be difficult to land that patch in upstream, only affects stable branches and the code around socket event handling was entirely refactored in most recent releases.
[16:55] <LocutusOfBorg> so, it isn't a problem in the last version?
[17:01] <niedbalski> LocutusOfBorg: it is in the version that ubuntu has 9.11.19+dfsg-1, but we are far behind upstream releases in libisc-export, i'd have to check if it is reproducible with current master, but a quick glance at the code, shows a huge delta of changes / complete refactor in that area.
[17:15] <ahasenack> LocutusOfBorg: niedbalski: keep in mind we have two sources for bind9 in focal+. bind9-libs builds just the libraries for legacy apps like isc-dhcp who don't work with the latest upstream (9.16.x), isc-dhcp being one
[17:16] <ahasenack> then we have bind9, which is 9.16.x (upstream's latest LTS track), which builds the server and the libraries used by that server, but NOT by isc-dhcp
[17:20] <niedbalski> LocutusOfBorg: ahasenack: okay, thanks. the patch is only required for isc-dhcp (afaik) in focal+, therefore the change in bind9-libs shouldn't affect bind9 itself.
[17:20] <ahasenack> correct
[17:21] <ahasenack> we had to keep this legacy bind9 code around because of isc-dhcp, debian installer, and bind-dyndb-ldap iirc
[17:21] <ahasenack> but mostly isc-dhcp
[17:22] <niedbalski> ahasenack: understood
[17:23] <ahasenack> great work fixing that, btw
[17:23] <niedbalski> LocutusOfBorg: the debdiff for focal is also attached to the bug, unsure if you'll use that or merge back from groovy
[17:23] <niedbalski> ahasenack: thank you a lot for the clarification, somebody was suggesting to verify bind9, but giving this, that won't be required
[17:24] <ahasenack> right, it won't affect bind9
[17:35] <rbalint> cpaelzer, seb128 i plan adding a fix to next systemd upload, will update  the bug, too
[18:03] <rafaeldtinoco> waveform: ping (on open-iscsi)
[18:04] <rafaeldtinoco> are you uploading gcc-10 patch anytime ? cause I'm merging it to 2.1.1 today, and I think it already contains the fix.
[18:04] <rafaeldtinoco> just wanted to sync
=== lfaraone_ is now known as lfaraone
=== rafaeldtinoco_ is now known as rafaeldtinoco
[18:23] <seb128> rbalint, thanks
[19:04] <vorlon> rbasak: what I /want/ is baseline retesting so that we don't have to add manual hints ;) but in the meantime, the 'force-reset-test' hint, with a version number, is the most semantically correct
[19:05] <vorlon> rbasak: where would you want this documented?
[19:06] <waveform> rafaeldtinoco, ah - nice - I'll close the bug and wait for the merge, thanks!
[19:06] <rafaeldtinoco> waveform: tku!
[19:19] <vorlon> seb128: hmm I don't see what these build failures related to speech-dispatcher-kali have to do with my patch to omit speech-dispatcher-festival from the i386 build
[20:04] <xnox> mwhudson: hm rustc has been building for 21h now. Yet in Debian it built in 11h. Do you know what is normal amount of time for rust to build on riscv64?
[20:09] <cjwatson> xnox: That doesn't seem like much of an apples-to-apples comparison, since our builders are emulated but that 11h time is from a native build
[20:10] <xnox> cjwatson: oh, they have native builders?! Where? How? What? I want that!
[20:10] <cjwatson> https://people.debian.org/~mafm/posts/2019/20191211_debian-gnulinux-riscv64-port-sponsors-and-build-machines/
[20:11] <cjwatson> A number of Debian's riscv64 buildds are still emulated, but rv-rr44-01 is one of the native ones
[20:12] <cjwatson> The remark about "frequent lock-ups" there doesn't make me enthusiastic about operating them, but maybe that comment is dated ...
[20:15] <xnox> thanks, and yeah it's just the hifive-unleashed boards not quite datacentre hardware / servergrade.
[20:21] <cjwatson> Yeah.  I mean more power to them giving it a go
[20:21] <cjwatson> But I'm not volunteering to be managing those things :)
[20:36] <seb128> vorlon, are we looking at the same thing? https://launchpad.net/ubuntu/+source/speech-dispatcher-contrib/0.10.1-1/+build/19789421
[20:36] <seb128> vorlon, dh_gencontrol: error: Requested unknown package speech-dispatcher-festival via -N/--no-package, expected one of: speech-dispatcher-pico speech-dispatcher-baratinoo speech-dispatcher-kali speech-dispatcher-ibmtts
[20:36] <seb128> is the error from what I see
[20:37] <seb128> vorlon, I think that's because the same source is used to build speech-dsipatch and -contrib
[20:37] <seb128> but the binary doesn't exist so the rule should probably be limited to the first one?
[20:41] <vorlon> seb128: ah I was looking at the dpkg-shlibdeps warnings, sorry.  Uh so the -N option is still there but the package is no longer built from this source?
[20:43] <vorlon> seb128: yeah so the debian/rules special case should just be dropped because speech-dispatcher-festival is commented out in debian/control...
[20:56] <LocutusOfBorg>  niedbalski the diff you provided is already in unapproved queue
[21:05] <seb128> vorlon, ups, my IRC disconnected but I didn't notice ...checking again I think the same content is used to generate speech-dispatcher and speech-dispatcher-contrib sources, there is some debian/rules sed lines to generate one or the other
[21:06] <seb128> vorlon, so your fix works for speech-dispatcher but broke -contrib (which you didn't seem to have update/uploaded at the time)
[21:06] <vorlon> seb128: ah I see, so the problem is my patch is applied to a source package I didn't submit it to ;)
[21:07] <vorlon> so a more complete fix would be to check for the package in the output of dh_listpackages before setting the -N option
[21:07] <seb128> right, sort of
[21:08] <seb128> of have a 'if source' condition in addition of the ubuntu/i386 ones
[21:09] <vorlon> I don't know a sensible interface for checking source package name from within debian/rules; dh_listpackages is easy
[21:09] <tumbleweed> dpkg-parsechangelog, probably
[21:10] <seb128> vorlon, k
[21:11] <vorlon> tumbleweed: yeah - which is a hassle :)
[21:11] <vorlon> not a "sensible interface" :)
[21:11] <tumbleweed> :)
[21:11] <seb128> ifneq (,$(filter speech-dispatcher-festival,$(shell dh_listpackages)))
[21:11] <seb128> ?
[21:12] <seb128> vorlon, do you want to fix/upload or should I try that ^ ?
[21:14] <mwhudson> xnox: hm the one in focal built in 15h https://launchpad.net/ubuntu/+source/rustc/1.41.0+dfsg1+llvm-0ubuntu2/+build/19157331
[21:19] <vorlon> seb128: please go ahead
[21:23] <ddstreet> vorlon i'm stumped on software-properties migration from groovy-proposed, it complains about unsatisfiable deps for i386 and riscv64, but there are no new binary deps, just python3-launchpadlib, so i'm not sure how any previous versions got promoted...?
[21:23] <ddstreet> not sure if i'm missing something in the process, or if it was just manually approved before
[21:26] <seb128> vorlon, k
[21:27] <seb128> ddstreet, where do you see that?
[21:27] <seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has
[21:27] <seb128> Will attempt migration (Any information below is purely informational)
[21:27] <seb128> "software-properties-common/i386 has unsatisfiable dependency, but it is already uninstallable in the target suite so never mind. "
[21:27] <seb128> ddstreet, seems like it's going to migrate on the next publisher?
[21:27] <ddstreet> is that what it means?
[21:28] <ddstreet> ok i misread it then :)
[21:28] <seb128> 'so never mind'
[21:28] <seb128> also 'is purely informational'
[21:28] <ddstreet> lol, well never mind i will do then :)
[21:29] <ddstreet> thanks!
[21:29] <seb128> np!
[21:38] <mwhudson> i kind of love the britney "xx yy zz problem but never mind" messages
[21:38] <mwhudson> although they are a bit confusing
[21:39] <mwhudson> i can totally imagine the coding process that leads to them
=== SudoBash is now known as appxprt
=== Enlik is now known as Guest22584