[11:33] <LocutusOfBorg> [13:24:50] <ansgar> LocutusOfBorg: To be honest, I wonder if we really need this check.
[11:33] <LocutusOfBorg> cjwatson, ^^ :)
[11:33] <LocutusOfBorg> what happens if debian drops it?
[11:34] <cjwatson> The main problem is that we don't have Lintian autorejects in LP
[11:34] <cjwatson> So it's not easy to just say, OK, we'll rely on those
[11:35] <cjwatson> We could perhaps weaken it in some way
[11:38] <seb128> is there a way to get an /usr/bin/python when installing python3 packages only?
[11:42] <LocutusOfBorg> cjwatson, right now I uploaded the dh-cargo in Debian and will sync later
[11:45] <cjwatson> OK
[11:45] <LocutusOfBorg> I don't care about future for now :)
[11:45] <LocutusOfBorg> it will probably take time before Debian drops the check anyway
[11:47] <xnox> LocutusOfBorg:  cjwatson: you did see my paste from yesterday right? dak only checks control.tar members timestamps, not data.tar.
[11:48] <xnox> i guess that data.tar checks got moved to lintian autorejects. or never existed.
[11:48] <xnox> (but i somehow remember dak checking data.tar before)
[11:50] <LocutusOfBorg> xnox, I lost it, but you are right
[11:50] <LocutusOfBorg> it has been lost in this commit https://salsa.debian.org/ftp-team/dak/commit/77dc932880d95b604f1e4c7527403804fb7a833c
[11:50] <xnox> https://paste.ubuntu.com/p/XzCGS66ycH/ that check only checks timestamps on the control tar members; not on the data tar members.
[11:50] <LocutusOfBorg> and now restored https://salsa.debian.org/ftp-team/dak/commit/19c6730d8d9421e3021a3a3a5f12717e9e1e3e5d
[11:51] <LocutusOfBorg> xnox, yes, but it was a bug in dak
[11:51] <xnox> ah
[11:51] <xnox> ok
[11:51] <LocutusOfBorg> so better fix
[11:51] <xnox> great!
[11:51] <LocutusOfBorg> instead of carrying a delta forever :)
[11:51] <LocutusOfBorg> it has been lost when python-apt gained the feature
[11:51] <LocutusOfBorg> just a mistake
[11:51] <xnox> awesome!
[11:52] <LocutusOfBorg> I want to get rid of such deltas whenever possible, for example today I submitted upstream one of your delta
[11:53] <LocutusOfBorg> https://github.com/gridcf/gct/issues/95
[11:56] <cjwatson> xnox: Right, it was after I EODed but OK.  Thanks for getting that restored, LocutusOfBorg
[11:57] <cjwatson> A long-standing mystery solved
[12:02] <xnox> scooby doby dooo
[12:03] <LocutusOfBorg> :D
[12:08] <Laney> rcj: you good with mvo's latest version?
[12:08]  * Laney is ready to Pull The Trigger
[12:20] <ahasenack> TJ-: thanks for the testing and assistance!
[12:23] <mvo> thanks Laney !
[12:55] <maks_piechota> Hi there! I'm new in Ubuntu development and as a first step I would like to build and install current main branch on my computer. Is there any tutorial how to do it?
[12:57] <TJ-> maks_piechota: have you got several weeks? building the main archive will take a looooong time! Alternatively, just install from a prebuilt ISO like everyone else
[12:57] <maks_piechota> many thanks
[12:58] <maks_piechota> I havent thought about that
[12:58] <maks_piechota> where could I find it?
[12:58] <maks_piechota> on launchpad?
[12:59] <maks_piechota> I've found this? https://launchpad.net/ubuntu/+source/gnome-shell/3.32.2-2ubuntu1
[13:00] <TJ-> maks_piechota: https://ubuntu.com/download/desktop
[13:01] <TJ-> maks_piechota: hang on, when you said "main branch" did you mean for a single package?
[13:01] <maks_piechota> nope, maybe I would better explain what I'm trying to achieve
[13:02] <maks_piechota> I'm looking for opportunities for active contribution in Ubuntu project as a developer, and I think the first thing to do is to install Ubuntu version that is developed currently
[13:02] <maks_piechota> not the released one
[13:03] <maks_piechota> alternatively I would appreciate any tips on how to prepare environment where I could make some code changes, build and test
[13:04] <rcj> Laney: just gave it a +1 for my testing with the ubuntu-cpc project.  Not sure if the code solves the problem for your project.
[13:05] <TJ-> maks_piechota: I'd recommend you start here: https://wiki.ubuntu.com/UbuntuDevelopment
[13:11] <juliank> tip of the day: lxc exec $container eatymdata bash
[13:12] <maks_piechota> TJ-: so the way is to install the newest Ubuntu 19.04 then build and test particular package?
[13:32] <ahasenack> xnox: hi
[13:32] <ahasenack> xnox: https://github.com/apache/httpd/commit/7fa21ea6602b30cc43d4f485777545dd73bb25a6 is enough to fix https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1836329
[13:32] <ahasenack> xnox: but I also found https://github.com/apache/httpd/commit/524608b65ec410e797a7283e6e142f8e5a74be26 which is openssl 1.1.1 related
[13:33] <Laney> rcj: thanks - it's somewhat of a black box to me but it seems fine
[13:33] <ahasenack> and I'm wondering if I should include both, or just the one that fixes that explicit problem. I fear we could be chasing openssl 1.1.1 regressions for some time still, one by one
[13:33] <ahasenack> but that last patch also notes there is a behavior change, in the commit message
[13:33] <ahasenack> xnox: any opinion?
[13:33] <xnox> ahasenack:  first one is fine "stop retrying, as we are about to terminate the connection"
[13:33] <rcj> Laney: you could always revert tobikoch's patch to fix bases and rebuild the desktop image to see if it catches the failure.
[13:34] <xnox> ahasenack:  the second one -> i wonder if it affects 1.1.1, or ...a, ....b, ....c
[13:35] <ahasenack> xnox: don't know, and it mentions http2 failures
[13:35] <ahasenack> "When no data could be read, our code returned EAGAIN up until OpenSSL 1.1.0, but APR_EOF for OpenSSL 1.1.1."
[13:36] <xnox> ahasenack:  it looks small enough too. (a few reindents)
[13:36] <xnox> ahasenack:  i think you should take both patches.
[13:36] <ahasenack> ok
[13:39] <ahasenack> " Old documentation indicated a difference between 0 and -1, and that -1 was retryable.  You should instead call SSL_get_error() to find out if it's retryable."
[13:39] <ahasenack> yeah
[13:40] <ahasenack> SSL_read(3)^
[13:44] <TJ-> ahasenack: it looks sane to me to have both patches
[13:44] <ahasenack> yep
[14:00] <mdeslaur> wxl: I merged usb-creator and released the new version into eoan
[14:01] <mdeslaur> wxl: thanks!
[15:04] <Saviq> oSoMoN: hey, re: nested virt, the doc you linked to suggests this only works on AMD CPUs, do you have that?
[15:05] <oSoMoN> hrm, how could I possibly not read that essential bit that mentions AMD… /me digs a hole and hides very deep underground
[15:06] <oSoMoN> kvm it is, then
[15:06] <Saviq> :)
[15:06] <Saviq> glad I could help :D
[15:06] <oSoMoN> thanks Saviq
[15:07] <oSoMoN> https://docs.oracle.com/cd/E97728_01/F12470/html/nested-virt-support.html is even more explicit, I wish I had landed on that page first
[15:29] <tomreyn> vorlon: when you have a minute, could you double check whether bug 1798992 should have been a dupe of bug 1801629? it is my impression that they discuss different issues.
[15:33] <vorlon> tomreyn: are *you* seeing this problem in 19.04?
[15:34] <vorlon> someone else followed up and said they saw it in 19.04 but not enough detail to be sure their issue is the same as yours
[15:34] <vorlon> the installer was fixed such that there should not be packages left pending autoremoval due to ubiquity's (normal) removal at the end of the install
[15:35] <tomreyn> vorlon: i'm just testing it with the *k*ubuntu 19.04 installer - is this a suitable test?
[15:35] <tomreyn> it does use subiquity
[15:36] <vorlon> tomreyn: kubuntu does not use subiquity
[15:36] <tomreyn> and after minimal install reports 136 packages can be upgraded and about as many can be auto removed
[15:36] <tomreyn> sorry i mean ubiquity
[15:38] <vorlon> tomreyn: ok.  yes, kubuntu w/ ubiquity on 19.04 is a suitable test
[15:38] <vorlon> tomreyn: please send the exact output to the bug wrt packages marked for autoremoval
[15:38] <vorlon> what is "minimal" install here?  I thought minimal desktop install was only enabled for Ubuntu, not Kubuntu
[15:38] <tomreyn> vorlon: should i also remove the dupe status then?
[15:38] <vorlon> tomreyn: yeah
[15:38] <tomreyn> minimal installation is an option on the kubuntu installer GUI
[15:39] <vorlon> hmm
[15:44] <vorlon> tomreyn: it's quite possible this issue is specific to the minimal install profile
[15:44] <tomreyn> yes, i believe it is.
[15:50] <tomreyn> vorlon: i posted an update now. thanks for your feedback.
[16:01] <tomreyn> fginther: you had added tag id-5c69703c382c5e410989f269 to this 1798992 bug back in february - i assume this means you somehow assigned this to yourself - could you check the state of this assignment (and update it as needed, if needed)? thank you!
[18:09] <wxl> i can't upload to usb-creator, so i've attached debdiffs for an SRU. the status would be changed to in progress when a sponsor uploads or is it something i should do now?
[18:12] <ginggs> wxl: just subscribe ubuntu-sponsors, the sponsor should change the status after upload
[18:12] <wxl> ginggs: cool, thx. :)
[18:12] <ginggs> wxl: yw!
[19:22] <juliank> New dpkg in proposed for x, bb, dd; please go bug hunting, especially on bb and x
[19:23] <juliank> disco was tiny, but the others are larger, so more chance something went wrong in cherry-picking
[19:24] <juliank> I installed ubuntu-desktop with it in a bionic container, and upgraded to cosmic, and that was fine
[19:24] <juliank> But the more people test it, the better
[19:25] <infinity> juliank: Backports of trigger changes?
[19:25] <juliank> infinity: yes
[19:25] <infinity> Fun, fun.
[19:25] <juliank> infinity: guillem had the list of commits prepared, so I ran git cherry-pick on that list and fixed a few conflicts :)
[19:25] <infinity> juliank: How confident are we that guillem's change there will resolve all our looping woes?
[19:26] <juliank> guillem seems pretty confident
[19:26] <infinity> guillem always seems confident.
[19:26] <infinity> That's his default mode.
[19:26] <juliank> It certainly worked for the ubuntu-mate-desktop cosmic -> disco upgrade
[19:27] <infinity> Okay, cool, if it fixed an actual complex testcase, that's promising.
[19:27] <juliank> infinity: The problem I guess for testing is that I did not upload a fixed version to cosmic, because no time to release anyway
[19:28] <infinity> juliank: Nonsense, you have 2 days to validate it!
[19:28] <infinity> juliank: (But more seriously, if having a fixed version in cosmic is likely to make fewer cosmic->disco upgrades explode, I'm fine with it landing past EOL and leaving the archive open for that)
[19:28] <sarnold> (and seven days for it to migrate?)
[19:29] <juliank> Both cosmic and bionic are at 1.19.0.5, so I can just up-cherry-pick the patches and upload it
[19:29] <infinity> I'm not at all against that, TBH.
[19:29] <infinity> Even though I've never hit the bug, LP is proof that it hits a lot of people.
[19:30] <infinity> The fewer people we leave stranded with broken upgrades, the better.
[19:31] <juliank> ack
[19:31] <bdmurray> The automated upgrade testing is having issues due to triggers looping so that might be a useful test.
[19:31] <juliank> nice
[19:31] <infinity> juliank: Also, when you said "in proposed", did you mean "in the queue"?  I don't see BB and XX in the archive.  Maybe you have an SRU lackey working on those. :)
[19:32] <juliank> infinity: bdmurray approved them, takes some time to build and release :)
[19:32] <infinity> juliank: I was looking at LP, not rmadison.
[19:32] <infinity> Ahh, he just missed the last publisher is all.
[19:32] <juliank> I see the disco one in LP
[19:34] <vorlon> infinity: I had assumed glibc 2.29-0ubuntu3 had been built with gcc-9 (and thus, was gcc-9-ok) but I see that it's not - and the glibc 2.29-0ubuntu3 rebuild autopkgtest now fails
[19:34] <vorlon> infinity: is this tracked anywhere?
[19:35] <infinity> vorlon: Erm, it's not built with gcc-9 at all.  A rebuild test wouldn't change that.
[19:35] <infinity> (we hardcode version, we don't use gcc-defaults)
[19:36] <vorlon> infinity: ah
[19:36]  * vorlon digs further then
[19:37] <infinity> The usual culprit for rebuilds exploding is binutils.  Unless it's testsuite regressions, which can often be kernel.
[19:37] <infinity> Also, there's all the kernel header messes.
[19:37] <vorlon> binutils hasn't changed between the passing and failing tests; but gcc-8 has
[19:47] <vorlon> infinity: gcc-8 8.3.0-16ubuntu3 used to build glibc 2.29-0ubuntu3, also used on the last passing glibc autopkgtest.  gcc-8 8.3.0-19ubuntu1 used in the now-failing test
[19:49] <infinity> vorlon: What's the failure (if you still have the log open)?
[19:49] <infinity> If not, I'll go look in a sec.
[19:57] <vorlon> infinity: FAIL: conform/POSIX2008/arpa/inet.h/conform et al
[19:57] <infinity> vorlon: I blame the kernel for that.
[19:57] <infinity> Maybe/probably.
[20:01] <infinity>     Namespace violation: "SIOCGSTAMPNS_OLD"
[20:01] <infinity>     Namespace violation: "SIOCGSTAMP_OLD"
[20:01] <infinity>     Namespace violation: "fds_bits"
[20:01] <infinity>     Namespace violation: "val"
[20:01] <infinity> Yeah, that's kernel header changes.
[20:08] <infinity> sforshee: I know you looked at that.  Was your conclusion that it needed fixes kernel-side, glibc-side, or both?
[20:08] <vorlon> right
[20:11] <juliank> infinity, bdmurray: Uploaded to cosmic
[20:11] <infinity> juliank: Ta.
[20:13] <sforshee> infinity: looked to me that the fixes were needed on the glibc side
[20:13] <infinity> vorlon: Anyhow, if those are the only failures, I think we can also do some badtest or skiptest jiggery to get the compiler/kernel/glibc in before uploading a glibc that retriggers the world.  Assuming glibc is where the fix goes.  Cause holding everything up on another week-plus test cycle sounds less fun.
[20:13] <infinity> sforshee: Kay.
[20:13] <vorlon> infinity: I have already marked glibc badtest per the above
[20:13] <infinity> Check.
[20:14]  * infinity runs to find tacos in between meetings.
[20:14] <infinity> CURSE YOU TUESDAY.
[20:14] <vorlon> (the only thing it's curretnly blocking is libselinux)
[20:15] <infinity> Oh, linux migrated.  I didn't notice that.  Okay, things are less dire than I was imagining.
[20:15] <infinity> But also, how did that actually work?
[20:15] <infinity> Triggered with the new linux, glibc passed.  That can't possibly be right.
[20:15] <vorlon> infinity: the trigger was on linux-meta, not linux, and linux-libc-dev is built from linux :P
[20:16] <infinity> Oh, right.
[20:16] <infinity> Well job.
[20:16] <vorlon> corner cases within corner cases
[20:16] <infinity> This is definitely something broken about moving all linux tests to linux-meta triggers, since I'm specifically a reverse trigger for linux-libc-dev.
[20:17] <infinity> Need to think about that at some point, somehow.
[20:24] <vorlon> infinity: yeah, we're finding all the interesting bugs in p-m triggers this month
[20:24] <vorlon> (the gcc vs gcc-defaults one should be resolved now)
[21:41] <mwhudson> what's the expected lag time for the package importer?
[21:45] <rbasak> mwhudson: about an hour
[21:45] <rbasak> (worst case)
[21:45] <mwhudson> rbasak: apparently it crashed
[21:45] <mwhudson> (i asked somewhere less public files)
[21:46] <mwhudson> *first
[21:46] <rbasak> Looks like it's in the process of restarting
[21:46] <rbasak> I have been refactoring to make it more reliable, but that work's not finished yet.
[21:47] <rbasak> and in the meantime Launchpad API calls started hanging less so I deferred that work focusing on other things.
[21:47] <Unit193> Oooh, fix my bugs! :>
[21:47] <rbasak> If it keeps doing this then I can focus on finishing the watchdog stuff
[21:47] <rbasak> Though I need to get this MySQL transition done firts
[22:51] <mwhudson> uhh is there no way to have a link in monospace text in the wiki?
[23:07] <TJ-> mwhudson: backticks ?
[23:29] <TJ-> mwhudson: the only way I can see it /could/ be done is adding an option to the link, as in [[target|alt-text|class="some-class-that-sets_font-family:monospace"]] but I don't see any such class in the CSS
[23:30] <mwhudson> TJ-: backticks don't work on inside or outside :/
[23:31] <TJ-> no, I tried that :)
[23:31] <TJ-> there's a class "backtick" attached to <tt> elements but unfortunately that class is not defined in CSS
[23:32] <TJ-> the only attributes that can be used: Available attributes: class, title, target, accesskey
[23:32] <mwhudson> find some xss hack that will let me add a <style> element to the page? :)
[23:56] <mwhudson> TJ-: i made it work sorta kinda https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls
[23:58] <mwhudson> rbasak: has it crashed again or is it just taking a long time to catch up? src:casper still doesn't seem to have my upload from yesterday