| vicamo | hi, need sponsor for https://launchpad.net/~vicamo/+archive/ubuntu/ppa-upload, which contains new upstream release for backport-iwlwifi-dkms package for Focal :) | 06:42 |
|---|---|---|
| vicamo | also https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1859389 for SRU for bug 1859389 | 06:43 |
| ubottu | bug 1859389 in backport-iwlwifi-dkms (Ubuntu Eoan) "[SRU] should disable DKMS build against kernel v5.0.0 or above" [Undecided,In progress] https://launchpad.net/bugs/1859389 | 06:43 |
| === pieq_ is now known as pie | ||
| === pie is now known as pieq | ||
| doko | locutus_: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/l/llvm-toolchain-8/20200115_224438_f9da4@/log.gz not good enough | 08:28 |
| Laney | doko: bustle has reverse-testsuite-triggers so probably not | 09:01 |
| xnox | doko: https://launchpad.net/ubuntu/+source/python3.8/3.8.1-2ubuntu2/+build/18570574 something got done to armhf toolchain? | 10:58 |
| xnox | doko: cause the upload just before that one, did build fine. And I only touched tests =/ | 10:59 |
| Skuggen | cpaelzer: Regarding #1858354, how can I tell exactly which version the stack trace listed in the error tracker is from? | 11:26 |
| Skuggen | Nevermind, looks like it's just the version of the latest report | 11:51 |
| juliank | apt in focal-proposed might have issues with realizing that automake Provides: automake-1.16 | 11:51 |
| juliank | so if there happen to be issues with that, that's the reason | 11:52 |
| juliank | a fixed apt will appear later in the day | 11:52 |
| juliank | That's bug 1859952 | 11:52 |
| ubottu | bug 1859952 in apt (Ubuntu) "apt 1.9.6 regression" [Critical,Fix committed] https://launchpad.net/bugs/1859952 | 11:52 |
| juliank | this also affects one other package, but I can't tell you which one | 11:53 |
| juliank | because I don't know | 11:53 |
| juliank | I only saw the number of virtual package names change by 2 :) | 11:53 |
| doko | xnox: I'll have a look | 11:54 |
| cpaelzer | Skuggen: when you go on the link it lists it in a table | 12:15 |
| cpaelzer | at the bottom of the error.subuntu.com page | 12:16 |
| cpaelzer | well, a table at the top and a list at the botto | 12:16 |
| cpaelzer | but you need to let it load completely to see it | 12:16 |
| Skuggen | cpaelzer: Right, but it listed a lot of different versions of MySQL, and the stack trace only matches the version in the last report (which isn't the latest version of MySQL) | 12:20 |
| Skuggen | I didn't think to check that when I first got a stack trace to give to the dev, so they had some trouble matching it with the code :) | 12:21 |
| Skuggen | One oddity: If I open an incident, it lists the various config files, but not the actual server config file. Do you know if that is intentional, or could it be significant for the issue? | 12:23 |
| ahasenack | xnox: hi, are you working on the openssl migration? | 12:36 |
| xnox | ahasenack: yes.... | 12:37 |
| ahasenack | I have an incentive to help, since my bind9 upload is stuck because of that :) | 12:37 |
| xnox | ahasenack: it's all done. i.e. everything is in proposed now. However the are a couple of things that are external to me | 12:37 |
| xnox | i.e. linux => is being fixed by kernel team (python2 fallout) | 12:37 |
| ahasenack | the test failures on th other packages | 12:37 |
| xnox | i.e. and i did not touch dpdk | 12:37 |
| xnox | ahasenack: all of them are fixed now | 12:38 |
| xnox | in proposed. | 12:38 |
| xnox | ahasenack: what is the status with dpdk on ppc64el? | 12:38 |
| ahasenack | nodejs, one openssl failure, both pythons , ruby2.5, are all sorted? | 12:38 |
| ahasenack | xnox: I don't know, cpaelzer, do you know? ^ | 12:38 |
| xnox | 19.11-2ubuntu1 is green? | 12:39 |
| xnox | let me try that. | 12:39 |
| ahasenack | yeah, it's green | 12:39 |
| xnox | ahasenack: all of those are fixed in proposed, the openssl regressions are against versions in release pocket. I did schedule retries with proposed versions, but britney is very slow at the moment. | 12:39 |
| ahasenack | ok | 12:39 |
| xnox | i will need to reupload openssl to fix the :i386 dep, that is true. I am told perl:native will fix it all, but did not try it yet. | 12:40 |
| xnox | ahasenack: i think we will be waiting on linux anyway atm. It is in progress being fixed, as per emails i got this morning. | 12:40 |
| ahasenack | ok | 12:41 |
| ahasenack | that could take a while then | 12:41 |
| xnox | ahasenack: ruby2.7 is not fixed yet, but i think is low priority as it is brand new. | 12:41 |
| ahasenack | xnox: about ruby2.7, I know someone :) | 12:42 |
| ahasenack | kanashiro: ^ | 12:42 |
| xnox | ahasenack: also bind9 is stuck only because d-i udebs do not know how to generate dependencies based on symbols versions, rather than "same as i was built against". udebs suck | 12:42 |
| ahasenack | xnox: hm, last time I did a bind9 soname change, all I had to do was upload d-i again, which I did | 12:43 |
| xnox | ahasenack: yes, but at that time, there was no different openssl in -proposed pocket when bind9 was built. | 12:43 |
| ahasenack | oh | 12:43 |
| xnox | ahasenack: hence the udebs got the dep >= libssl (version in -release) | 12:43 |
| xnox | and migrated | 12:44 |
| xnox | ahasenack: i think we can rebuild bind in the release pocket only, in bileto ppa, and migrate it. | 12:44 |
| ahasenack | Get:64 http://ftpmaster.internal/ubuntu focal-proposed/main/debian-installer amd64 libssl1.1-udeb amd64 1.1.1d-2ubuntu2 [190 kB] | 12:44 |
| ahasenack | it used that one | 12:44 |
| xnox | cause then all the udebs will be >= focal-release and not hold up the migration | 12:44 |
| ahasenack | d-i, that is | 12:44 |
| xnox | i.e. | 12:46 |
| xnox | Package: libdns-export1107-udeb | 12:46 |
| xnox | Depends: libc6-udeb (>= 2.30), libcrypto1.1-udeb (>= 1.1.1d), libisc-export1104-udeb | 12:46 |
| xnox | Package: libdns-export1107 | 12:46 |
| xnox | Depends: libc6 (>= 2.14), libisc-export1104, libssl1.1 (>= 1.1.1) | 12:46 |
| xnox | note how "-udeb" one rquires >= 1.1.1d; whisht proper per-symbol shlibdeps for the main package needs just any 1.1.1 | 12:47 |
| xnox | i can't wait for udebs to die | 12:47 |
| xnox | ahasenack: if bind9 is urgent to migrate => we can rebuild it against focal-release pocket only; otherwise just need to wait a bit for a few things to be resolved (python*/armhf ftbfs; linux testing) | 12:50 |
| ahasenack | xnox: it's not urgent | 12:50 |
| ahasenack | just a normal merge | 12:51 |
| ahasenack | I will want 9.16 when it comes out later this month, though, it's their ESV ("lts") version, that's the one we want for 20.04 | 12:51 |
| ahasenack | I'll keep an eye on excuses | 12:52 |
| xnox | ack | 12:56 |
| === ricab is now known as ricab|lunch | ||
| seb128 | vorlon, hey, i386 problem of the day. ubuntu-drivers-common is on the i386 whitelist and build-depends on python3-aptdaemon.test which depends on python3-aptdaemon which depends on gir1.2-packagekitglib-1.0 which is missing...should be bring back packagekit/i386? or skip tests on that arch rather? | 12:58 |
| seb128 | tseliot, ^ | 12:58 |
| ddstreet | Laney re: autopkgtest-cloud MP, should i rebase onto the revert, or do you want me to wait until that's sorted out before rebasing? | 13:13 |
| cpaelzer | xnox: ahasenack: I did the restart of dpdk as now pytohn is back | 13:34 |
| cpaelzer | it is good now no more blocking ssl | 13:34 |
| ahasenack | cpaelzer: /usr/bin/python is back? | 13:34 |
| cpaelzer | and I did an MP against salsa to make the test truly python3 | 13:34 |
| cpaelzer | ahasenack: the package "python" is back and that was all it needed | 13:34 |
| ahasenack | so we don't have to python -> python2 | python3 anymore? | 13:35 |
| cpaelzer | for this special case, TBH - it could have been empty | 13:35 |
| cpaelzer | ahasenack: this really was a special case | 13:36 |
| cpaelzer | ahasenack: doko might outline how the next steps around py2/3 are to be done - don't take the special case of dpdk above as an indicator what generally works | 13:37 |
| ahasenack | ok | 13:37 |
| cpaelzer | ahasenack: the "python" that is back in focal is in universe btw | 13:37 |
| xnox | cpaelzer: i do not see python back. it is removed in focal-proposed, and has not been reintroduced. | 13:39 |
| ricotz | hello :), I am running into "dh_builddeb: Sorry, but 10 is the highest compatibility level supported by this debhelper." building dh-autoreconf with debhelper 12 (backported to xenial) -- https://launchpad.net/~ricotz/+archive/ubuntu/toolchain/+build/18562470 -- could anyone point me to the cause of this? | 13:39 |
| xnox | cpaelzer: it is still available in focal-release, but we are working on migrating python-default to remove python in focal-release too. | 13:39 |
| cpaelzer | that is good to know xnox | 13:40 |
| cpaelzer | once that is happening I assume we are back to python2 | python3 dependencies and adapting the shebangs I guess | 13:40 |
| xnox | ricotz: well you are requiring 11 | 13:40 |
| xnox | --- dh-autoreconf-12~ubuntu16.04.1/debian/compat2016-04-02 21:44:18.000000000 +0000 | 13:41 |
| xnox | +++ dh-autoreconf-19~ubuntu16.04.1/debian/compat2018-05-19 19:33:40.000000000 +0000 | 13:41 |
| xnox | @@ -1 +1 @@ | 13:41 |
| udevbot | Error: "@" is not a valid command. | 13:41 |
| xnox | -9 | 13:41 |
| xnox | +11 | 13:41 |
| xnox | ricotz: and installing 12 | 13:41 |
| ricotz | xnox, correct, but the build is using debhelper 12.1.1 | 13:41 |
| cjwatson | I would assume that something is buggy in your debhelper backport then | 13:41 |
| xnox | ricotz: weird | 13:41 |
| ricotz | xnox, https://launchpad.net/%7Ericotz/+archive/ubuntu/toolchain/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 13:41 |
| xnox | cpaelzer: one must use /usr/bin/python2 shebangs and those will work like trusty and up. | 13:42 |
| cpaelzer | xnox: python 2.7.17-1 is in focal/universe right now, so the removal you mention is in 2.7.17-2ubuntu2 then I guess? | 13:42 |
| xnox | cpaelzer: ubuntu1 already had removal, but yes, ubuntu2 is currently in proposed and doesn't ship "python" package which provides "/usr/bin/python" | 13:43 |
| cpaelzer | ahasenack: ^^ so "python -> python2 | python3" and shebang'ing still applies | 13:46 |
| doko | or bang your head | 13:46 |
| cpaelzer | doko: I'm sure you are doing that a lot for this transition | 13:47 |
| * cpaelzer hugs doko | 13:47 | |
| ricotz | cjwatson, there is no-change compared to debhelper in bionic-backports (other than loosening the dh-autoreconf dep) | 13:52 |
| ricotz | does debhelper adjust its features at buildtime somehow? | 13:52 |
| cjwatson | I don't remember. Take your backported .deb apart and look | 13:55 |
| ricotz | maybe caused by the older perl :\ | 13:58 |
| tseliot | seb128, vorlon does anything need ubuntu-drivers-common on i386? | 14:01 |
| seb128 | tseliot, I don't know, Steve added it to the whitelist so I guess there a reason but let's wait on it to be around to comment on that | 14:06 |
| tseliot | ok | 14:08 |
| seb128 | sil2100, hey, if you do your SRU shift could you review glib2.0/eoan? it's a follow up to fix a test regression from the SRU which is curently in proposed, it has been waiting for 1 month in the queue now :/ | 14:12 |
| sil2100 | seb128: sure thing! Sorry I didn't get to it yet, I blame it on .4! | 14:16 |
| ahasenack | cpaelzer: do you know why https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1847157 isn't showing up in https://people.canonical.com/~ubuntu-archive/pending-sru.html ? | 14:16 |
| ubottu | Launchpad bug 1847157 in open-vm-tools (Ubuntu Disco) "memory leaks in open-vm-tools" [Medium,Fix committed] | 14:16 |
| ahasenack | it's fix committed | 14:16 |
| ahasenack | was it released perhaps? | 14:16 |
| seb128 | sil2100, no worry, I'm not going to bother you with the rest of the queue but since that one unblocks (hopefully) a SRU which is already in proposed it would be nice to see it moving | 14:16 |
| seb128 | sil2100, thx! | 14:16 |
| cpaelzer | ahasenack: it got superseded by bug 1844834 and maybe due to that the tracking on the other oen got lost | 14:21 |
| ubottu | bug 1844834 in open-vm-tools (Ubuntu) "open-vm-tools 11.0.0 released" [Medium,Fix released] https://launchpad.net/bugs/1844834 | 14:21 |
| cpaelzer | ahasenack: I'll update the old bug to be clear - it is fix released | 14:21 |
| ahasenack | I just posted a comment asking for info | 14:22 |
| ahasenack | thx | 14:22 |
| cpaelzer | done | 14:22 |
| cpaelzer | did that come up as 60/180 day idle case? | 14:23 |
| === ricab|lunch is now known as ricab | ||
| ahasenack | no, normal triage | 14:26 |
| ahasenack | let me see why | 14:26 |
| ahasenack | cpaelzer: ah, ok | 14:26 |
| ahasenack | cpaelzer: I'm doing my backlog of triages, from the holidays | 14:26 |
| Laney | ddstreet: you'll want to do the same thing that commit is trying to fix, so you might as well wait | 14:57 |
| Laney | or help Seth fix it :D | 14:57 |
| Laney | ddstreet: oh maybe I'm wrong, it might have been fine all along | 14:59 |
| * Laney likes a good old "Revert "Revert "... | 15:02 | |
| vorlon | seb128, tseliot: we only need dh-modaliases (which is Arch: all) from ubuntu-drivers-common on i386 as a build-dep of nvidia; this is a case we currently get wrong with germinate; I'll drop ubuntu-drivers-common from the whitelist | 15:29 |
| ddstreet | Laney seems like it works for me, at least using python3 subprocess call from the cmdline, but i'll defer to sforshee | 15:29 |
| tseliot | vorlon, ok, thanks | 15:30 |
| Laney | ddstreet: I pushed, pls rebase and adjust to match what got changed there | 15:34 |
| Laney | and then yeah, a review from a kernel person | 15:34 |
| sforshee | Laney: yeah I should have explained the testing better in the first place, sorry about that | 15:40 |
| Laney | np | 15:40 |
| seb128 | vorlon, thx | 15:47 |
| seb128 | vorlon, re the build-essential question/reply from yesterday, I'm unsure to understand why librsvg/i386 is failing, but maybe the build-essential part is a red herring and I looked at the wrong part of the log? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/libr/librsvg/20200116_093748_5be90@/log.gz | 15:52 |
| seb128 | 'The following packages have unmet dependencies: | 15:53 |
| seb128 | builddeps:/tmp/autopkgtest.rC32CC/1-autopkgtest-satdep.dsc:i386 : Depends: build-essential:amd64 | 15:53 |
| seb128 | builddeps:essentials : Depends: build-essential but it is not going to be installed' | 15:53 |
| vorlon | seb128: the libxml2-triggered failure I can explain, it's because libxml2:amd64 is in the base system so you have to trigger with all-proposed (due to the bug in the pinning) to get both libxml2:amd64 and libxml2:i386 installed from proposed | 16:00 |
| vorlon | I'll look at the gobject-introspection-triggered one, but I have a meeting now | 16:00 |
| seb128 | vorlon, thx | 16:03 |
| ahasenack | is there precedence in a package for not restarting services during a do-release-upgrade, in the case it's best to see the service restart later, in the new system, instead of during the upgrade, which aborts it? | 16:31 |
| ahasenack | aborts the do-release-upgrade, I mean | 16:31 |
| ahasenack | in other words, I was wondering if adding such a check to a postinst script would make sense: if we are in the middle of a do-release-upgrade, don't restart, or just ignore restart errors | 16:31 |
| vorlon | seb128: can't reproduce the librsvg failure locally. I suggest giving back all of the affected i386 failures with all-proposed and see if that takes care of it | 16:33 |
| seb128 | vorlon, will do, thx | 16:33 |
| vorlon | ahasenack: I think you'd find some special-casing of the do-release-upgrade environment variables in the libpam code for restarting services, but I think it only controls whether we /prompt/ about restarting, not about whether we restart or not | 16:34 |
| ahasenack | ok | 16:34 |
| rbasak | xnox: your upload mysql-8.0 (8.0.18-0ubuntu5) is missing dep8 headers with an upstream bug link, etc. rafaeldtinoco's concurrent patch that was awaiting code review when you uploaded has all of that. How do you want me to resolve this? | 17:18 |
| vorlon | seb128, xnox: big wtfs on these gobject-introspection-related autopkgtest failures; I've resorted to spinning up an autopkgtest vm and trying to install the deps, still can't reproduce it | 18:21 |
| === blackboxsw_ is now known as blackboxsw | ||
| rafaeldtinoco | ahasenack: here ? | 20:42 |
| ahasenack | rafaeldtinoco: here | 20:42 |
| rafaeldtinoco | ahasenack: so.. STREAMS have been removed from glibc.. looks like linux doesn't support it for long time ago | 20:42 |
| ahasenack | is that in the release notes too? | 20:43 |
| rafaeldtinoco | in Changelog | 20:43 |
| sarnold | TIL STREAMS was still in glibc :) | 20:43 |
| rafaeldtinoco | and in NEWS | 20:43 |
| rafaeldtinoco | sarnold: =) | 20:43 |
| rafaeldtinoco | so this "windowmaker" applet | 20:44 |
| rafaeldtinoco | is using the ioctl interface using streams | 20:44 |
| rafaeldtinoco | and wont compile anymore | 20:44 |
| rafaeldtinoco | i guess we should get rid of this package | 20:44 |
| sarnold | holy moly, I haven't actually seen STREAMS in use in the wild before; which package? :) | 20:45 |
| rafaeldtinoco | Dockapp monitoring network interfaces | 20:45 |
| rafaeldtinoco | sarnold: wmnd | 20:45 |
| sarnold | thanks | 20:45 |
| rafaeldtinoco | it had to be a really really old thing =) | 20:45 |
| rafaeldtinoco | src/drivers.c | 20:45 |
| rafaeldtinoco | they have a "solaris/linux" driver | 20:45 |
| rafaeldtinoco | to get consumption for pppd | 20:45 |
| rafaeldtinoco | using ioctl | 20:46 |
| ahasenack | man | 20:47 |
| rafaeldtinoco | problem is that they're sharing code with solaris (since this is 2008) | 20:48 |
| rafaeldtinoco | so they kept the solaris driver enabled to get information from a network device using streams (aka ioctl with streams structure as user pointer) | 20:48 |
| ahasenack | hm | 20:49 |
| sarnold | I wonder if you could just pop solaris_fpppd out of the debian/rules | 20:49 |
| rafaeldtinoco | yep | 20:49 |
| rafaeldtinoco | that was going to be my next move | 20:49 |
| rafaeldtinoco | unsure if it will lose functionality | 20:49 |
| rafaeldtinoco | but thats the way | 20:49 |
| rafaeldtinoco | #ifdef USE_LINUX_PROC | 20:49 |
| rafaeldtinoco | {USE_LINUX_PROC, linux_proc_list, NULL, | 20:49 |
| rafaeldtinoco | linux_proc_get, NULL, NULL, 0}, | 20:49 |
| rafaeldtinoco | #endif | 20:49 |
| rafaeldtinoco | hopefully this is enough | 20:49 |
| ahasenack | yeah, we really don't want to spend too much time on this | 20:53 |
| ahasenack | the threshold of fixing it vs dropping it isn't high | 20:53 |
| rafaeldtinoco | ahasenack: came on! what about all those windowmaker uses | 20:53 |
| rafaeldtinoco | users... | 20:53 |
| rafaeldtinoco | or the afterstep ones | 20:53 |
| ahasenack | NeXT | 20:53 |
| rafaeldtinoco | lol | 20:53 |
| * ahasenack used windowmaker on a 64Mb RAM K6 desktop | 20:54 | |
| rafaeldtinoco | i used windowmaker until .. ~2012 | 20:54 |
| rafaeldtinoco | kind of | 20:54 |
| rafaeldtinoco | cant complain | 20:54 |
| rafaeldtinoco | when they added freetype to it | 20:54 |
| rafaeldtinoco | gave an extra life | 20:54 |
| rafaeldtinoco | ahasenack: sarnold: yep | 20:56 |
| rafaeldtinoco | that did the trick | 20:56 |
| sarnold | yay | 20:56 |
| rafaeldtinoco | just disabled the solaris plugin | 20:56 |
| rafaeldtinoco | nice, let me patch this #) | 20:57 |
| rafaeldtinoco | ahasenack: https://launchpadlibrarian.net/460915148/wmnd_0.4.17-3ubuntu1.debdiff | 21:06 |
| rafaeldtinoco | quick +1 | 21:06 |
| rafaeldtinoco | so I can upload, pls | 21:06 |
| * ahasenack checks | 21:06 | |
| ahasenack | rafaeldtinoco: just the changelog message, I don't understand the phrasing at all :) | 21:07 |
| rafaeldtinoco | solaris_fpppd driver made it FTBFS as glibc disabled stropts | 21:07 |
| rafaeldtinoco | better ? | 21:07 |
| rafaeldtinoco | made wmnd FTBFS because recent glibc disabled streams ? | 21:08 |
| ahasenack | "remove solaris_fpppd driver since it uses stropts.h which is gone with glibc 2.30 (#....)" | 21:08 |
| rafaeldtinoco | :* | 21:08 |
| rafaeldtinoco | perfect | 21:08 |
| ahasenack | +1 | 21:08 |
| rafaeldtinoco | ill fix the ) | 21:08 |
| rafaeldtinoco | to align with \ | 21:08 |
| rafaeldtinoco | just saw that also | 21:08 |
| rafaeldtinoco | thx! | 21:08 |
| ahasenack | was just looking at that stray ) :) | 21:09 |
| ahasenack | not a stray | 21:09 |
| ahasenack | did you test this build? No changes needed in d/*.install files? | 21:09 |
| rafaeldtinoco | yep | 21:09 |
| ahasenack | ok | 21:09 |
| ahasenack | go for it | 21:09 |
| rafaeldtinoco | ill re-test now | 21:09 |
| ahasenack | I'm gonna eod | 21:09 |
| rafaeldtinoco | alright | 21:09 |
| rafaeldtinoco | have a good one o/ | 21:10 |
| ahasenack | have to drive home still | 21:10 |
| ahasenack | cya | 21:10 |
| rafaeldtinoco | cya | 21:10 |
| xnox | vorlon: we have uncovered arm related issues in binutils/ffi and respun those between bug reported and today. So all of them should be simply retried with latest greatest toolchain in proposed. | 22:35 |
| xnox | rbasak: my code was simply written by me. And imho is better, as it pushes the deadline until 2037, rather than 2025. It will be resolved with new upstream release, when my patch will be dropped. And i don't think i actually care about fixing it in eoan. | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!