[00:09] joelkraehemann: thank you, i'll look again tmrw === led2 is now known as led1 [08:44] rbasak, tjaalton, what happened to the upload from bug #1750947? it looks like it is in the rejected queue but the bug doesn't state why/what's the issue [08:44] bug 1750947 in pulseaudio (Ubuntu Xenial) "pulseaudio print lots of error when selecting unavailable profile" [Undecided,Confirmed] https://launchpad.net/bugs/1750947 [08:57] doko: how do you feel about http://paste.ubuntu.com/p/hK9xtcCrM9/ ? [09:11] mvo: yes, that looks much better [09:13] seb128: Rejected by Robie Basak: Missing SRU information. See bug for details. [09:13] tjaalton, since when missing info is a reason for reject? usually they ask to fix the bug and keep unaccepted meanwhile... [09:14] doko: for this to fully work we need the trivial python upload with the cnf- hints, I will do the change in c-n-f now to actually have a special case for python when python3 is already installed [09:14] tjaalton, thx [09:14] rbasak, ^ [09:14] seb128: yeah my thoughts exactly.. [09:26] anyone can tell me how do i figure out why a package was removed from ubuntu bionic? (python3-motor) [09:26] it's in artful, and it's in debian testing [09:27] LtWorf, https://launchpad.net/ubuntu/+source/python-motor/+publishinghistory [09:27] Laney: we see failures in autopkgtest on bionic-i386 currently with snapd. the error is a bit puzzling, the autopkgtest system seems to hang for more than 15min in "journalctl --sync": https://paste.ubuntu.com/p/r4nJxhXMQg/ (it starts to warn at 07:37 and gets eventually killed at 07:52. is there anything unusual about the i386 autopkgtest systems or the configuration that might explain this? [09:29] mvo: hi, not really and nothing that would be different from amd64, is it OOMing or running out of disk space or something? [09:29] i don't know much about the package, i just use it :D [09:29] did you try running it locally to see if it happens for you? [09:29] i use debian testing, works fine for me [09:30] it did have a bug because it had a broken dependency on pymongo, while in truth it required a newer one [09:30] for a bit, but that was fixed when they upgraded pymongo as well [09:31] Laney: it seems to be fine on amd64 (and the other arches) and never got this behaviour on linode or GCE where we run dozens of the same run each day. sadly our logs do not include disk-free data, but let me dig a bit if I can find something [09:32] Laney: its not OOMing (we do have the dmesg output in our debug log) [09:32] so on debian, i opened and closed the RC bug (and still think the maintainer is a bit clueless) [09:33] LtWorf, talk to doko he's the one who deleted it [09:33] well we use it for some internal thing at work, guess we just switch the vm to debian [09:33] Laney: and funny enough all the other tests that use exactly the same code path work. and the previous failures are also happening in different tests but it is also hanging in journalctl --sync. [09:34] i'm a user of the package, not the dm [09:34] Laney: I assume all the autopkgtest images use the same systemd version in bionic? [09:35] mvo: Yeah, and you can probably see that if you download the artifacts and look at testbed-packages [09:35] Laney: cool, let me try that [09:37] doko: i was kinda using python3-motor :P [09:40] mvo, there are some fixes to journalctl wrt. syncing / flushing / keeping track of FDs. I do not know if you are hitting those bugs. I did not see such bugs yet, but I'm thinking to cherrypick those fixes anyway, because they look sane. [09:40] LtWorf: is there a fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894683 ? [09:40] Debian bug 894683 in src:python-motor "python-motor's autopkg test fail" [Important,Open] [09:41] that would be a ftbfs no? [09:42] it keeps the package out of the release pocket [09:43] i see. Would you be able to do a nmu if i were to make a patch? [09:44] i am under the impression that the maintainer is basically MIA [09:44] but it's team maintained so it's fine [09:50] mvo: I'll run it on the server and then we can look at the console-log and stuff [09:53] seb128: I don't remember if I rejected because of it, but comment 14 is a reason for rejection. It even says so in the SRU docs. [09:53] LtWorf: at this point, I would consider doing a Ubuntu upload, if the bug in Debian has a patch [09:54] okay [09:54] seb128, tjaalton: leaving it in the queue means that every day an SRU team member wastes time looking again. [09:55] seb128, tjaalton: you should not be uploading or sponsoring until the SRU information is complete. [09:55] fine [09:57] rbasak, it seems a bit harsh to require another upload dance when the source doesn't need any change [09:59] seb128: it gets ridiculous when there are four or five uploads languishing in the queue in a row that cannot be accepted because the SRU procedure has been ignored. [10:01] rbasak, right, I can understand that being frustrating ... well in that case the bug has been updated now, can the upload be rescued from the rejection queue or does it need reuploading? [10:02] Rescuing from the rejection queue _is_ reuploading. [10:03] k [10:03] seb128: if it's just an odd one that needs fixing up then I usually leave it in the queue, FWIW. [10:03] tjaalton, well, I guess you need to reupload then [10:03] I don't have the source anymore [10:03] And I also try to be more patient with newbies [10:04] tjaalton, https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=pulseaudio has it [10:04] But when there's a wall of queue items that objectively can't be accepted, then I think it's OK to reject because I'm saving the next SRU person (and possibly myself next week) wasting time reviewing the same wall. [10:05] done [10:05] ricotz: we are currently running an archive test rebuild. please could you stop your mozillateam builds for a week or so, or move to one or two builds per week? [10:05] LtWorf, I can upload in Debian if you have a patch [10:05] rbasak, fair enough, it's just the first time I see that, but usually I do have my SRU bugs SRU compliant before upload, I just had cases where some tweaks/extra info was requested for [10:05] oSoMoN: ^^^ same for LO test builds [10:05] tjaalton, rbasak, thanks [10:06] LocutusOfBorg: i don't have a patch, was evaluating if it was a good idea to work on one :D [10:07] (If i had done it, i would have just attached it) [10:08] doko, ack, I don't have any test builds running, and I'll refrain from doing them [10:10] doko, hi, there are two firefox beta releases per week which are mandatory to be done [10:12] it looks like debian testing has the latest version of python3-motor from pypi (1.2.1) whereas bionic was still on 1.1 https://launchpad.net/ubuntu/bionic/+package/python3-motor [10:12] doko, regarding a recent libreoffice packaging change there is a need for a new build of its backports later this week [10:14] ricotz: mandatory? [10:15] doko, yes [10:18] dok [10:18] *typo [10:18] doko, what happens if the reason for the test failures are a "merge mongodb" issue? [10:22] LocutusOfBorg: mongodb? Context please? [10:22] Because I'm working on bug 1761807 [10:22] bug 1761807 in mongodb (Ubuntu) "[FFe] Bump mongodb to 3.6.X" [High,Triaged] https://launchpad.net/bugs/1761807 [10:24] doko, btw is this archive rebuild done regarding retpoline? [10:25] rbasak, can't we just sync mongodb from debian? [10:25] this should fix python-motor [10:26] I see the bug, so please try to make python-motor back in the archive after uploading mongodb [10:27] LocutusOfBorg: we may be able to sync 2.4 from Debian. I'd just want to check that the Breaks/Replaces remain correct for Ubuntu. [10:27] the changes from Debian can be taken as-is, except for the Breaks+Replaces that needs a lower version [10:27] rbasak, we wrote the same, yes they need to probably have a lower version until bionic is out [10:27] Yeah :) [10:27] the new server package is bionic only [10:27] But I hope to supersede with 2.6 anyway. [10:28] just please make sure that python-motor runs the testsuite again and upload in case [10:28] do you have an ETA? [10:28] maybe in the meanwhile we can sync/merge 2.4 and then leave the jump [10:28] to you :) [10:28] I'm hoping this week. I'm still examining other reverse depends against 2.6 to minimise regression risk. [10:29] (and considering upgrade paths etc) [10:29] what about merging mongodb right now? [10:29] if that doesn't break your workflow, it should make even easier to upgrade after :) [10:30] ricotz: we are doing archive test rebuilds twice per release, that shouldn't be news. I'm a bit sad that these mozilla "requirements" monopolize the buildds [10:30] I have no objection to that, though I'd prefer to focus on 3.6. [10:30] LocutusOfBorg: if you'd like to merge 2.4 this week, please go ahead. [10:30] Uh, 3.4. [10:31] LocutusOfBorg: please make sure the breaks/replaces is correct for Ubuntu. [10:31] LocutusOfBorg: I'm happy for the ppc64el altivec code to be re-enabled the way Debian did it now that IBM have confirmed for us that the upstream workaround is correct. [10:31] LocutusOfBorg: and we need to keep the mongodb-server-core package please. [10:31] LocutusOfBorg: that's all I can think of in relation to the merge. [10:32] If it gets stuck in proposed, well my 3.6 will need to migrate anyway, so it won't affect me. [10:33] rbasak, agree wrt ppc64el [10:33] and the server-core is now in Debian [10:33] and we already talked about the breaks+replaces, we are aligned then! doing [10:34] Yeah it all sounds good. I just wanted to make sure you knew about my "things I care about" list :) [10:34] hmm. I just tried running nvidia-detector in bionic. it tracebacks. who should I be talking to? :-) [10:34] we should *all* have the same list :) [10:35] doko, I see -- this is a bit unfair, those usually take like 1,5-2,5h on x86 which is nothing compared to e.g. chromium and other ppa-copy-happy people [10:35] oh got the merge failure, fixing and uploading [10:36] ricotz: I ping those people as well. but it takes much more on armhf and arm64 [10:36] tseliot: hi :-) [10:43] rbasak, just take the deb packaging from proposed in case it doesn't migrate [10:49] is this applicable in debian? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894683 for version 1.2.1? [10:49] Debian bug 894683 in src:python-motor "python-motor's autopkg test fail" [Important,Open] [10:50] Nafallo: hi [10:51] tseliot: bug 1054458, fixed in 2013 popped up again in bionic for me :-) [10:51] bug 1054458 in ubuntu-drivers-common (Ubuntu Quantal) "nvidia-detector crashed with ValueError in __get_value_from_name(): invalid literal for int() with base 10: 'experimental-304'" [High,Fix released] https://launchpad.net/bugs/1054458 [10:52] LtWorf, I don't know... [10:52] I'm uploading a new mongodb to see if failures still happen [10:52] thanks [10:53] tseliot: are you able to verify? [10:53] Nafallo: I sure didn't expect that. I'll have a look at it [10:54] cheers :-) [11:30] mvo: would you believe that my test run passed 🙄 [12:32] Laney: meh, so sad. I hate heisenbugs. all failures in http://autopkgtest.ubuntu.com//packages/s/snapd/bionic/i386 since the last success happend on --sync. I also looked at the journalctl source, there is some interessting stuff going on there. it sends a signal and then waits for an inotify change on a watch file. makes me wonder if there is a bug there somewhere in bionic [12:50] mvo: would you know how geoip.ubuntu.com works? is the source code available at all? [12:55] Riddell: hey! unfortunately I don't know much about it, I think the source is available but I'm not sure where [12:56] mvo: any idea who would know about it? [12:57] Riddell: maybe ev knows about geoip.u.c but I'm not sure if it was added for ubiquity or was there before and just used by it [13:00] thanks i'll ask him [13:13] Riddell: I *think* it's libapache2-mod-geoip [13:17] thanks TJ- [13:17] I believe that's wrong [13:18] I have an old copy of the internal puppet tree which has (shortish) custom Python handlers which I think implement geoip.ubuntu.com [13:18] But that puppet has been decommissioned so I don't know where their canonical source is now [13:18] I recall seeing some discussion about it many years ago and playing about with something similar, so I may be wrong [13:18] Best bet is probably to ask rt@ubuntu.com for it to be released [13:19] thanks also cjwatson [13:20] I can probably answer questions based on what I have but don't have authorisation to just paste it or whatever :) [13:30] LtWorf, tests passes now, python-motor is back to 18.04, thanks for your contribution to Ubuntu! [13:31] LocutusOfBorg: ah well thanks to you for doing the work, I just complained :P [13:31] Saya: ↑ [13:31] you complaintributed ;) [13:32] Nice :) thanks a bunch [13:32] that was fast [13:34] by the way, i guess the debian bug can be closed too? [13:44] :) [13:44] already closed! [14:16] ah good [14:41] mvo: I got it to happen, and there was stuff about OOM in the logs including journald! [14:42] maybe you need a bigger system? or do you want to be able to run in this kind of system (1536M ram)? [14:42] Laney: ohhh, are you in the system currently? [14:42] also, after I ran journalctl --sync myself out of band the test continued and dmesg was cleared :( [14:43] mvo: yeah, I can paste you dmesg but now it's carrying on [14:44] Laney: so first this amount of ram should be fine. however we had seen (in the past) issues with lowmem which are i386 specific, something that looked like a kernel memory leak that we trigger. let me search for the relevant link [14:44] https://paste.ubuntu.com/p/TRMqVK7vJQ/ [14:44] Laney: I can add code to our tests that errors when we oom [14:44] Laney: so that at least the error is clear [14:45] Laney: s/we/the system/ [14:47] Laney: I suspect this is a variation of https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101 - I will add checks in our code for OOM and make the tests fail in a clean way in such a situation [14:47] Laney: thank you so much! this was super helpful [14:48] Laney: I wonder if the adt artifacts should include a dmesg dump - but this information would have been drowned in the sea of DENIALs probably anyway [14:48] mvo: We had thought about including the console-log, maybe dmesg too [14:48] but in this case dmesg has been truncated by something :( [14:49] Laney: *cough* it is our code doing nasty things. sorry for that [14:49] ah but kern.log has it all [14:49] in your face snapd! [14:50] Laney: heh :) [14:50] * mvo hugs Laney [14:50] *hugs* [14:54] slangasek: hi there, considering I am +1 for removal of LP: #1762334 is there anything else I need to do (like take care of the removal? But I'd need to know how) [14:54] Launchpad bug 1762334 in golang-udm (Ubuntu) "golang-udm build-depends on golang-gocheck-dev, removed from Debian" [High,Triaged] https://launchpad.net/bugs/1762334 [15:08] jamespage, coreycb: any openstack implications in landing bug 1761807? [15:08] bug 1761807 in mongodb (Ubuntu) "[FFe] Bump mongodb to 3.6.X" [High,Triaged] https://launchpad.net/bugs/1761807 [15:16] rbasak: not from an openstack perspective - ceilometer no longer uses mongodb [15:17] OK thanks [15:22] sergiusens: removal needs to be done by an archive admin - done now, thanks :) [15:23] slangasek: please could you also extend the mongodb FFe approval to cover mongo-tools? I think it makes sense to keep the version of mongo-tools in line with the mongodb package. Bug 1761807 - I've added the task. [15:23] bug 1761807 in mongodb (Ubuntu) "[FFe] Bump mongodb to 3.6.X" [High,Triaged] https://launchpad.net/bugs/1761807 [15:26] rbasak: done [15:30] joelkraehemann: in the future, you can put all the debdiffs in one bug [15:30] joelkraehemann: so there are three patches total? [18:48] jbicha: Is this something you could quickly ninja for me? [18:48] https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1762807 [18:48] Launchpad bug 1762807 in software-properties (Ubuntu) "gnome-session-bin installed on Ubuntu MATE" [Undecided,New] [18:50] Wimpress: why the urgency? (I'm asking because I was planning to do a software-properties upload sometime this week to add AppStream metadata) [18:50] jbicha: If you can add that change when you do that, it would be great. [18:51] ok [18:51] I asked because I'm happy to go through biletto. [18:51] it doesn't use bileto just regular bzr merge requests [18:51] But wasn't sure what other changes might be pedning. [18:52] I'll make a merge proposal and sub you. [18:52] ok [18:52] bileto gets you those long version numbers :) === mhcerri_ is now known as mhcerri [18:58] ;25 [19:00] kees, stgraber, mdeslaur, infinity: TB meeting? [19:00] ack [19:01] infinity: ^^ [19:01] jbicha: merge proposal submitted and linked to the bug. Thanks. [20:21] infinity: Can you take another look at this please? [20:21] https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-release-upgrader/ubuntu-mate-bionic-update/+merge/342372 [22:59] LocutusOfBorg: is that you? ~costamagnagianfranco [23:02] yes, it is you. please could you stop these long rebuilds like firefox while the archive rebuild is running? [23:14] stop hogging the builders while I'm hogging the builders! [23:15] (it doesn't look like it's actually a firefox build, it's just a ppa named firefox) [23:18] Right, it was boinc, 33 minutes on armhf. Probably not worth getting too cross about.