[11:33] [13:24:50] LocutusOfBorg: To be honest, I wonder if we really need this check. [11:33] cjwatson, ^^ :) [11:33] what happens if debian drops it? [11:34] The main problem is that we don't have Lintian autorejects in LP [11:34] So it's not easy to just say, OK, we'll rely on those [11:35] We could perhaps weaken it in some way [11:38] is there a way to get an /usr/bin/python when installing python3 packages only? [11:42] cjwatson, right now I uploaded the dh-cargo in Debian and will sync later [11:45] OK [11:45] I don't care about future for now :) [11:45] it will probably take time before Debian drops the check anyway [11:47] LocutusOfBorg: cjwatson: you did see my paste from yesterday right? dak only checks control.tar members timestamps, not data.tar. [11:48] i guess that data.tar checks got moved to lintian autorejects. or never existed. [11:48] (but i somehow remember dak checking data.tar before) [11:50] xnox, I lost it, but you are right [11:50] it has been lost in this commit https://salsa.debian.org/ftp-team/dak/commit/77dc932880d95b604f1e4c7527403804fb7a833c [11:50] https://paste.ubuntu.com/p/XzCGS66ycH/ that check only checks timestamps on the control tar members; not on the data tar members. [11:50] and now restored https://salsa.debian.org/ftp-team/dak/commit/19c6730d8d9421e3021a3a3a5f12717e9e1e3e5d [11:51] xnox, yes, but it was a bug in dak [11:51] ah [11:51] ok [11:51] so better fix [11:51] great! [11:51] instead of carrying a delta forever :) [11:51] it has been lost when python-apt gained the feature [11:51] just a mistake [11:51] awesome! [11:52] I want to get rid of such deltas whenever possible, for example today I submitted upstream one of your delta [11:53] https://github.com/gridcf/gct/issues/95 [11:56] xnox: Right, it was after I EODed but OK. Thanks for getting that restored, LocutusOfBorg [11:57] A long-standing mystery solved [12:02] scooby doby dooo [12:03] :D [12:08] rcj: you good with mvo's latest version? [12:08] * Laney is ready to Pull The Trigger [12:20] TJ-: thanks for the testing and assistance! [12:23] thanks Laney ! === ricab is now known as ricab|lunch [12:55] 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] 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] many thanks [12:58] I havent thought about that [12:58] where could I find it? [12:58] on launchpad? [12:59] I've found this? https://launchpad.net/ubuntu/+source/gnome-shell/3.32.2-2ubuntu1 [13:00] maks_piechota: https://ubuntu.com/download/desktop [13:01] maks_piechota: hang on, when you said "main branch" did you mean for a single package? [13:01] nope, maybe I would better explain what I'm trying to achieve [13:02] 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] not the released one [13:03] alternatively I would appreciate any tips on how to prepare environment where I could make some code changes, build and test [13:04] 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] maks_piechota: I'd recommend you start here: https://wiki.ubuntu.com/UbuntuDevelopment [13:11] tip of the day: lxc exec $container eatymdata bash [13:12] TJ-: so the way is to install the newest Ubuntu 19.04 then build and test particular package? [13:32] xnox: hi [13:32] xnox: https://github.com/apache/httpd/commit/7fa21ea6602b30cc43d4f485777545dd73bb25a6 is enough to fix https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1836329 [13:32] Launchpad bug 1836329 in apache2 (Ubuntu Bionic) "Regression running ssllabs.com/ssltest causes 2 apache process to eat up 100% cpu, easy DoS" [Critical,In progress] [13:32] xnox: but I also found https://github.com/apache/httpd/commit/524608b65ec410e797a7283e6e142f8e5a74be26 which is openssl 1.1.1 related [13:33] rcj: thanks - it's somewhat of a black box to me but it seems fine [13:33] 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] but that last patch also notes there is a behavior change, in the commit message [13:33] xnox: any opinion? [13:33] ahasenack: first one is fine "stop retrying, as we are about to terminate the connection" [13:33] 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] ahasenack: the second one -> i wonder if it affects 1.1.1, or ...a, ....b, ....c [13:35] xnox: don't know, and it mentions http2 failures [13:35] "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] ahasenack: it looks small enough too. (a few reindents) [13:36] ahasenack: i think you should take both patches. [13:36] ok [13:39] " 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] yeah [13:40] SSL_read(3)^ [13:44] ahasenack: it looks sane to me to have both patches [13:44] yep === ricab|lunch is now known as ricab [14:00] wxl: I merged usb-creator and released the new version into eoan [14:01] wxl: thanks! [15:04] oSoMoN: hey, re: nested virt, the doc you linked to suggests this only works on AMD CPUs, do you have that? [15:05] hrm, how could I possibly not read that essential bit that mentions AMD… /me digs a hole and hides very deep underground [15:06] kvm it is, then [15:06] :) [15:06] glad I could help :D [15:06] thanks Saviq [15:07] 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] 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:29] bug 1801629 in OEM Priority Project "duplicate for #1798992 direct dependencies of ubiquity should not be autoremovable" [High,Fix released] https://launchpad.net/bugs/1801629 [15:29] bug 1801629 in OEM Priority Project "direct dependencies of ubiquity should not be autoremovable" [High,Fix released] https://launchpad.net/bugs/1801629 [15:33] tomreyn: are *you* seeing this problem in 19.04? [15:34] 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] 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] vorlon: i'm just testing it with the *k*ubuntu 19.04 installer - is this a suitable test? [15:35] it does use subiquity [15:36] tomreyn: kubuntu does not use subiquity [15:36] and after minimal install reports 136 packages can be upgraded and about as many can be auto removed [15:36] sorry i mean ubiquity [15:38] tomreyn: ok. yes, kubuntu w/ ubiquity on 19.04 is a suitable test [15:38] tomreyn: please send the exact output to the bug wrt packages marked for autoremoval [15:38] what is "minimal" install here? I thought minimal desktop install was only enabled for Ubuntu, not Kubuntu [15:38] vorlon: should i also remove the dupe status then? [15:38] tomreyn: yeah [15:38] minimal installation is an option on the kubuntu installer GUI [15:39] hmm [15:44] tomreyn: it's quite possible this issue is specific to the minimal install profile [15:44] yes, i believe it is. [15:50] vorlon: i posted an update now. thanks for your feedback. [16:01] 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] 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] wxl: just subscribe ubuntu-sponsors, the sponsor should change the status after upload [18:12] ginggs: cool, thx. :) [18:12] wxl: yw! [19:22] New dpkg in proposed for x, bb, dd; please go bug hunting, especially on bb and x [19:23] disco was tiny, but the others are larger, so more chance something went wrong in cherry-picking [19:24] I installed ubuntu-desktop with it in a bionic container, and upgraded to cosmic, and that was fine [19:24] But the more people test it, the better [19:25] juliank: Backports of trigger changes? [19:25] infinity: yes [19:25] Fun, fun. [19:25] infinity: guillem had the list of commits prepared, so I ran git cherry-pick on that list and fixed a few conflicts :) [19:25] juliank: How confident are we that guillem's change there will resolve all our looping woes? [19:26] guillem seems pretty confident [19:26] guillem always seems confident. [19:26] That's his default mode. [19:26] It certainly worked for the ubuntu-mate-desktop cosmic -> disco upgrade [19:27] Okay, cool, if it fixed an actual complex testcase, that's promising. [19:27] 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] juliank: Nonsense, you have 2 days to validate it! [19:28] 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] (and seven days for it to migrate?) [19:29] Both cosmic and bionic are at 1.19.0.5, so I can just up-cherry-pick the patches and upload it [19:29] I'm not at all against that, TBH. [19:29] Even though I've never hit the bug, LP is proof that it hits a lot of people. [19:30] The fewer people we leave stranded with broken upgrades, the better. [19:31] ack [19:31] The automated upgrade testing is having issues due to triggers looping so that might be a useful test. [19:31] nice [19:31] 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] infinity: bdmurray approved them, takes some time to build and release :) [19:32] juliank: I was looking at LP, not rmadison. [19:32] Ahh, he just missed the last publisher is all. [19:32] I see the disco one in LP [19:34] 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] infinity: is this tracked anywhere? [19:35] vorlon: Erm, it's not built with gcc-9 at all. A rebuild test wouldn't change that. [19:35] (we hardcode version, we don't use gcc-defaults) [19:36] infinity: ah [19:36] * vorlon digs further then [19:37] The usual culprit for rebuilds exploding is binutils. Unless it's testsuite regressions, which can often be kernel. [19:37] Also, there's all the kernel header messes. [19:37] binutils hasn't changed between the passing and failing tests; but gcc-8 has [19:47] 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] vorlon: What's the failure (if you still have the log open)? [19:49] If not, I'll go look in a sec. [19:57] infinity: FAIL: conform/POSIX2008/arpa/inet.h/conform et al [19:57] vorlon: I blame the kernel for that. [19:57] Maybe/probably. [20:01] Namespace violation: "SIOCGSTAMPNS_OLD" [20:01] Namespace violation: "SIOCGSTAMP_OLD" [20:01] Namespace violation: "fds_bits" [20:01] Namespace violation: "val" [20:01] Yeah, that's kernel header changes. [20:08] sforshee: I know you looked at that. Was your conclusion that it needed fixes kernel-side, glibc-side, or both? [20:08] right [20:11] infinity, bdmurray: Uploaded to cosmic [20:11] juliank: Ta. [20:13] infinity: looked to me that the fixes were needed on the glibc side [20:13] 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] sforshee: Kay. [20:13] infinity: I have already marked glibc badtest per the above [20:13] Check. [20:14] * infinity runs to find tacos in between meetings. [20:14] CURSE YOU TUESDAY. [20:14] (the only thing it's curretnly blocking is libselinux) [20:15] Oh, linux migrated. I didn't notice that. Okay, things are less dire than I was imagining. [20:15] But also, how did that actually work? [20:15] Triggered with the new linux, glibc passed. That can't possibly be right. [20:15] infinity: the trigger was on linux-meta, not linux, and linux-libc-dev is built from linux :P [20:16] Oh, right. [20:16] Well job. [20:16] corner cases within corner cases [20:16] 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] Need to think about that at some point, somehow. [20:24] infinity: yeah, we're finding all the interesting bugs in p-m triggers this month [20:24] (the gcc vs gcc-defaults one should be resolved now) [21:41] what's the expected lag time for the package importer? [21:45] mwhudson: about an hour [21:45] (worst case) [21:45] rbasak: apparently it crashed [21:45] (i asked somewhere less public files) [21:46] *first [21:46] Looks like it's in the process of restarting [21:46] I have been refactoring to make it more reliable, but that work's not finished yet. [21:47] and in the meantime Launchpad API calls started hanging less so I deferred that work focusing on other things. [21:47] Oooh, fix my bugs! :> [21:47] If it keeps doing this then I can focus on finishing the watchdog stuff [21:47] Though I need to get this MySQL transition done firts === kyrofa_ is now known as kyrofa [22:51] uhh is there no way to have a link in monospace text in the wiki? [23:07] mwhudson: backticks ? [23:29] 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] TJ-: backticks don't work on inside or outside :/ [23:31] no, I tried that :) [23:31] there's a class "backtick" attached to elements but unfortunately that class is not defined in CSS [23:32] the only attributes that can be used: Available attributes: class, title, target, accesskey [23:32] find some xss hack that will let me add a