=== cpaelzer_ is now known as cpaelzer
[06:52] <doko> coreycb: yes, that's what I'm aiming for
[06:53] <doko> coreycb: ehh, wait, 20.04 ...
[07:46] <doko> oSoMoN: how was the lo autopkg test failure resolved (the one which failed with OpenJDK 11)?
[07:48] <oSoMoN> doko, not fully resolved yet, the failing test was apparently ignored to allow the promotion of openjdk 11
[07:48] <oSoMoN> doko, but I have a decent understanding of the problem and I know how to fix it, just trying to get to a consensus with upstream
[07:56] <doko> oSoMoN: ta
=== cpaelzer_ is now known as cpaelzer
=== juergh_ is now known as juergh
[12:28] <coreycb> doko: ok thanks. i'm trying to get 3.7 unit tests enabled upstream and also expressing the need to be more proactive upstream with testing python3.
[15:29] <rbasak> Somebody in #ubuntu-server has: https://www.irccloud.com/pastebin/2uSLUZYU/
[15:30] <rbasak> shim from trusty-updates is being installed with only dpkg in the trusty release pocket, which explodes because dpkg in the release pocket doesn't understand xz.
[15:30] <rbasak> Is there some mechanism that should be making sure that dpkg gets updated first?
[15:30] <rbasak> Maybe juliank knows? ^
[15:31] <juliank> rbasak: Pre-Depends on dpkg
[15:31] <juliank> appropriately versioned of course
[15:32] <juliank> rbasak: But I think hte problem is that we binary copied the shim down
[15:32] <juliank> and built it with xz inthe first place
[15:32] <rbasak> Yeah I need to double check but I don't believe it had a Pre-Depends - I looked for that.
[15:32] <rbasak> So that's a regression-updates bug then?
[15:32] <juliank> dpkg in updates does have support for control.tar.xz though
[15:32] <rbasak> This user is preseeding.
[15:33] <rbasak> So dpkg doesn't get updated before shim does in this case it seems.
[15:33] <juliank> yes, which means shim needs either a Pre-Depends on the right dpkg version or compressed without uniform compression
[15:33] <rbasak> OK I'll ask the user to file a bug.
[15:34] <juliank> (the problem here is xz compressed control files, not xz in general)
[15:34] <rbasak> Yep
[15:35] <juliank> So overrding dh_builddeb to dh_builddeb -- --no-uniform-compression
[15:35] <juliank> should do the trick
[15:36] <rbasak> sil2100: looks like you'd copied shim back? ^
[15:37] <juliank> oh and the other is Pre-Depends: dpkg (>= 1.17.5ubuntu5.8~)
[15:37] <sam_w> rbasak: re: reporting this... https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1792497
[15:37] <ubottu> Launchpad bug 1792497 in shim (Ubuntu) "package shim (not installed) failed to install/upgrade: subprocess dpkg-deb --control returned error exit status 2" [Undecided,Confirmed]
[15:37] <sam_w> us
[15:37] <juliank> see bug 1730627
[15:37] <ubottu> bug 1730627 in dpkg (Ubuntu Trusty) "xz compressed control.tar files not supported" [Medium,Fix released] https://launchpad.net/bugs/1730627
[15:37] <sam_w> *I think this is the same issue?
[15:38] <juliank> sam_w: seems like it, but logs are broken
[15:38] <rbasak> Yeah I was just about getting to that conclusion
[15:38] <rbasak> Seems very likely though
[15:39] <sam_w> as in logs on the bug report? I can probably provide some
[15:40] <rbasak> I pasted yours in a comment.
[15:41] <rbasak> Your pastebin is enough to tell us what's going on.
[15:44] <sam_w> rbasak: cool
[15:46] <rbasak> sam_w: thank you for the report! I think what's needed to fix it is understood, but shim is somewhat complicated to handle so I'll wait for the right people to appear to handle it.
[15:57] <sam_w> rbasak: no worries, will subscribe to updates from that bug...
[19:03] <sarnold> Trevinho: hello, can you take a look at 1797012 ? :) thanks
[19:24] <xnox> tsimonq2, i do not provide any support over PM
[19:24] <xnox> tsimonq2, please always use a public channel
[19:24] <tsimonq2> xnox: ack :)
[20:57] <mwhudson> could some kind soul do a git ubuntu import of cargo?
[23:53] <rbasak> mwhudson: now running
[23:54] <mwhudson> rbasak: thanks
[23:55] <mwhudson> rbasak: i would like to talk to you about getting my splitting up of the rustc delta into the import branch so i can use it again at some point but it must be rather late for you...
[23:55] <rbasak> It's fine, I'm awake.
[23:56] <rbasak> Have you uploaded anything b ased on your splitting up yet? A new package merge perhaps?
[23:56] <mwhudson> yes i followed the wiki instructions on pushing i think
[23:56] <rbasak> To get the importer to adopt rich history it has to be given the rich history before it sees the upload.
[23:56] <mwhudson> i haven't uploaded anything to ubuntu yet
[23:57] <mwhudson> yeah i ran git push mwhudson  merge old/debian new/debian old/ubuntu reconstruct/1.28.0+dfsg1+llvm-0ubuntu2 deconstruct/1.28.0+dfsg1+llvm-0ubuntu2 logical/1.28.0+dfsg1+llvm-0ubuntu2
[23:57] <rbasak> I see
[23:57] <rbasak> And that merge branch is ready for upload?
[23:57] <mwhudson> mwhudson being ssh://mwhudson@git.launchpad.net/~mwhudson/ubuntu/+source/rustc
[23:57] <mwhudson> er, more or less
[23:58] <mwhudson> there are some subsequent changes
[23:58] <mwhudson> hmm i guess i'm not actually going to upload 1.28.0+dfsg1+llvm-0ubuntu2, there is going to be an upstream update
[23:59] <rbasak> The idea is that, eventually, anyone who wants to adopt the workflow will always give (via a wrapper around dput or something) the importer the rich git commits before dput runs.
[23:59] <rbasak> When the importer sees the upload published in Launchpad, it will use the rich history supplied, if it matches.