| 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:33 |
| 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:34 |
| cjwatson | We could perhaps weaken it in some way | 11:35 |
| seb128 | is there a way to get an /usr/bin/python when installing python3 packages only? | 11:38 |
| LocutusOfBorg | cjwatson, right now I uploaded the dh-cargo in Debian and will sync later | 11:42 |
| 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:45 |
| xnox | LocutusOfBorg: cjwatson: you did see my paste from yesterday right? dak only checks control.tar members timestamps, not data.tar. | 11:47 |
| 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:48 |
| 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:50 |
| 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:51 |
| LocutusOfBorg | I want to get rid of such deltas whenever possible, for example today I submitted upstream one of your delta | 11:52 |
| LocutusOfBorg | https://github.com/gridcf/gct/issues/95 | 11:53 |
| cjwatson | xnox: Right, it was after I EODed but OK. Thanks for getting that restored, LocutusOfBorg | 11:56 |
| cjwatson | A long-standing mystery solved | 11:57 |
| xnox | scooby doby dooo | 12:02 |
| LocutusOfBorg | :D | 12:03 |
| Laney | rcj: you good with mvo's latest version? | 12:08 |
| * Laney is ready to Pull The Trigger | 12:08 | |
| ahasenack | TJ-: thanks for the testing and assistance! | 12:20 |
| mvo | thanks Laney ! | 12:23 |
| === ricab is now known as ricab|lunch | ||
| 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:55 |
| 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:57 |
| maks_piechota | I havent thought about that | 12:58 |
| maks_piechota | where could I find it? | 12:58 |
| maks_piechota | on launchpad? | 12:58 |
| maks_piechota | I've found this? https://launchpad.net/ubuntu/+source/gnome-shell/3.32.2-2ubuntu1 | 12:59 |
| TJ- | maks_piechota: https://ubuntu.com/download/desktop | 13:00 |
| 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:01 |
| 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:02 |
| maks_piechota | alternatively I would appreciate any tips on how to prepare environment where I could make some code changes, build and test | 13:03 |
| 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:04 |
| TJ- | maks_piechota: I'd recommend you start here: https://wiki.ubuntu.com/UbuntuDevelopment | 13:05 |
| juliank | tip of the day: lxc exec $container eatymdata bash | 13:11 |
| maks_piechota | TJ-: so the way is to install the newest Ubuntu 19.04 then build and test particular package? | 13:12 |
| 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 |
| ubottu | 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 |
| ahasenack | xnox: but I also found https://github.com/apache/httpd/commit/524608b65ec410e797a7283e6e142f8e5a74be26 which is openssl 1.1.1 related | 13:32 |
| 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:33 |
| xnox | ahasenack: the second one -> i wonder if it affects 1.1.1, or ...a, ....b, ....c | 13:34 |
| 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:35 |
| 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:36 |
| 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:39 |
| ahasenack | SSL_read(3)^ | 13:40 |
| TJ- | ahasenack: it looks sane to me to have both patches | 13:44 |
| ahasenack | yep | 13:44 |
| === ricab|lunch is now known as ricab | ||
| mdeslaur | wxl: I merged usb-creator and released the new version into eoan | 14:00 |
| mdeslaur | wxl: thanks! | 14:01 |
| Saviq | oSoMoN: hey, re: nested virt, the doc you linked to suggests this only works on AMD CPUs, do you have that? | 15:04 |
| oSoMoN | hrm, how could I possibly not read that essential bit that mentions AMD… /me digs a hole and hides very deep underground | 15:05 |
| oSoMoN | kvm it is, then | 15:06 |
| Saviq | :) | 15:06 |
| Saviq | glad I could help :D | 15:06 |
| oSoMoN | thanks Saviq | 15:06 |
| 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:07 |
| 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:29 |
| ubottu | 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 |
| ubottu | bug 1801629 in OEM Priority Project "direct dependencies of ubiquity should not be autoremovable" [High,Fix released] https://launchpad.net/bugs/1801629 | 15:29 |
| vorlon | tomreyn: are *you* seeing this problem in 19.04? | 15:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| vorlon | hmm | 15:39 |
| vorlon | tomreyn: it's quite possible this issue is specific to the minimal install profile | 15:44 |
| tomreyn | yes, i believe it is. | 15:44 |
| tomreyn | vorlon: i posted an update now. thanks for your feedback. | 15:50 |
| 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! | 16:01 |
| 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:09 |
| 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! | 18:12 |
| juliank | New dpkg in proposed for x, bb, dd; please go bug hunting, especially on bb and x | 19:22 |
| juliank | disco was tiny, but the others are larger, so more chance something went wrong in cherry-picking | 19:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| infinity | The fewer people we leave stranded with broken upgrades, the better. | 19:30 |
| 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:31 |
| 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:32 |
| 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:34 |
| 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:35 |
| vorlon | infinity: ah | 19:36 |
| * vorlon digs further then | 19:36 | |
| 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:37 |
| 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:47 |
| 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:49 |
| 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. | 19:57 |
| 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:01 |
| 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:08 |
| juliank | infinity, bdmurray: Uploaded to cosmic | 20:11 |
| infinity | juliank: Ta. | 20:11 |
| 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:13 |
| * 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:14 |
| 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:15 |
| 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:16 |
| infinity | Need to think about that at some point, somehow. | 20:17 |
| 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) | 20:24 |
| mwhudson | what's the expected lag time for the package importer? | 21:41 |
| 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:45 |
| 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:46 |
| 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 | 21:47 |
| === kyrofa_ is now known as kyrofa | ||
| mwhudson | uhh is there no way to have a link in monospace text in the wiki? | 22:51 |
| TJ- | mwhudson: backticks ? | 23:07 |
| 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:29 |
| mwhudson | TJ-: backticks don't work on inside or outside :/ | 23:30 |
| 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:31 |
| 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:32 |
| mwhudson | TJ-: i made it work sorta kinda https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls | 23:56 |
| 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 | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!