[03:12] <mwhudson> http://autopkgtest.ubuntu.com/packages/d/docker.io/focal/amd64 <- the failure triggered by containerd/1.3.1-0ubuntu1 doesn't happen locally
[03:12] <mwhudson> any ideas as to what might be different in the prod infra?
[07:15] <Tuxist> hi i have problem the python package have been removed from focal so i can't build jackd2 i need to to rebuild to avoid conflicts with pipewire 0.3
[07:20] <doko> oSoMoN: lo ftbfs in focal with out-of-disk-space
[07:24] <oSoMoN> uh oh
[07:27] <oSoMoN> marcustomlinson, you might want to take a look at that one: https://launchpad.net/ubuntu/+source/libreoffice/1:6.3.4-0ubuntu2/+build/18611391
[09:05] <tumbleweed> 41
[09:42] <eoli3n_> Hi, what's the status of 20.04 dayli builds ? I mean could i start working on migration with it without fear about major changes ?
[09:44] <eoli3n_> i manage a huge pedagogic config, which require few weeks work to migrate, so, i need to be able to start working as soon as possible
[09:45] <seb128> eoli3n_, it's a serie being actively being worked  on so new versions/changes are still landing but with proposed-staging the focal archive itself shouldn't see major disruptions hopefully
[09:47] <eoli3n_> is there a list of these landing modifications?
[09:59] <juliank> doko: So what do I have to do to get python-apt tests installing deps again? It does not want to install python3-dbg apparently, and then fails
[09:59] <juliank> Broken python3-apt-dbg:arm64 Depends on python3-dbg:arm64 < 3.7.5-1ubuntu1 -> 3.8.0-3 @ii umU > (< 3.8)
[09:59] <juliank> Broken python3-dbg:arm64 Depends on libpython3-dbg:arm64 < 3.7.5-1ubuntu1 | 3.8.0-3 @ii umH > (= 3.8.0-3)
[09:59] <juliank> Investigating (0) python3-dbg:arm64 < 3.7.5-1ubuntu1 -> 3.8.0-3 @ii umU Ib >
[10:00] <juliank> Oh, it needs a rebuild
[10:00] <juliank> It Depends python3-dbg (<< 3.8)
[10:01] <juliank> but why is it picking python3-dbg from proposed anyway?
[10:02] <juliank> This only happens on arm64, ppc64el, and s390x
[10:19] <doko> juliank: no idea why it's arch specific
[10:20] <juliank> doko: the amd64 one does not even pull in python3-{apt-,}-dbg
[10:20] <juliank> very odd
[10:21] <juliank> ah no wrong link
[10:22] <juliank> Get:27 http://ftpmaster.internal/ubuntu focal/main amd64 python3-dbg amd64 3.7.5-1ubuntu1 [1352 B]
[10:22] <juliank> amd64 correctly pulled from release pocket
[10:22] <juliank> For some reason, python3-dbg is pulled from proposed on arm64/ppc64el/s390x
[10:23] <juliank> ah no, on ppc64el it fails because pep8 went away
[10:24] <juliank> Let's sync python-apt 1.9.5 seems
[10:24] <juliank> I never synced that
[10:24] <juliank> Odd
[10:35] <doko> tkamppeter: please could you have a look at hplib ftbfs with python3.8?
[10:38] <AsciiWolf> tsimonq2, hi, would it be possible to upgrade the steam package in Focal, as I wrote in email I sent you, or drop the package completely (and add to sync blacklist)?
[10:40] <AsciiWolf> the outdated two years old version that is still in latest Ubuntu Focal is will be a disaster for users when Ubuntu 20.04 is released... it has many issues (as I wrote in the email), bad udev rules, conflicts with the Valve provided package etc.
[10:44] <AsciiWolf> tsimonq2, all these issues are fixed in the latest Debian version of steam/steam-devices, but it is not possible to auto sync the package because of changes you made two years ago
[10:47] <tkamppeter> doko, I will have a look at the HPLIP.
[10:49] <tkamppeter> Anyone here expert in JDK? JDK blocks CUPS in focal-proposed and it looks like not caused by CUPS. CUPS got a small change and in JDK 100s of tests are failing.
[10:49] <tkamppeter> Only on ARM processors.
[10:56] <doko> tkamppeter: please ask tdaitx
[10:57] <tkamppeter> tdaitx, are you here?
[11:12] <juliank> AsciiWolf: Just because he merged that two years ago should not be taken as a comittment to the package.
[11:15] <juliank> You're basically telling anyone who'd be willing to merge it to not do it because you'll be bothering them with it for years to come
[11:21] <rbasak> paride: could I have a couple of quick reviews please? https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/378155 and https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/378156. They're trivial but maybe just not quite at self-approve level.
[11:22] <paride> rbasak, sure
[11:25] <rbasak> I am assuming these will fix CI - I thought it easier to wait for CI than to jump through the necessary hoops to test locally
[11:28] <rbasak> Thank you!
[11:28] <paride> rbasak, added approve comments; I don't have permissions to change the MP status
[11:28] <paride> yw :)
[11:28] <rbasak> I'll wait for expected CI results before merging
[11:29] <rbasak> lazr.restfulclient's release timing perfectly aligned with my attempt to release git-ubuntu: CI went red right in the middle :-/
[11:30] <rbasak> Ideally I would be able to release using the state of things the day before yesterday, but apparently the pin wasn't completely successful anyway
[11:44] <cjwatson> rbasak: How did the lazr.restfulclient change break you?  Just the bare fact of a new release existing?
[11:44] <cjwatson> I'm surprised the actual change would have affected anything other than Launchpad itself
[11:45] <rbasak> cjwatson: just the bare fact of a new release existing
[11:45] <rbasak> We have pins in setup.py, which was possibly a bad idea. We're generally dropping those pins where possible.
[11:46] <tkamppeter> tdaitx, I have a JDK problem.
[11:46] <rbasak> However if a new release exists and we're pinning an older version, something is bad in our snap build and creates a conflict - so the pin doesn't fully work
[11:46] <cjwatson> Ah.  Odd that a pin wouldn't have carried on working though.
[11:46] <rbasak> More recently we actually test such a mismatch, which causes CI to fail
[11:46] <rbasak> Yeah - the pinning we're doing is broken
[11:49] <enyc> paride: i wish to be nosey and ask if you are named after parallel-port-ide driver =)
[11:51] <paride> enyc, 'paride' this is my real name and I was born before Linux, so I can exclude it :P this is the second time in my life I get asked
[11:58] <enyc> ok =)
[11:58] <enyc> paride: people ask me how to pronounce 'enyc' and I tell them my official answer is you are supposed to store the pattern of letters in your visual-memory and its' not supposed to be pronounced ;p
[12:29] <tkamppeter> doko, I cannot reproduce the FTBFS of HPLIP on my focal. Evsn if I install python3.8-dev there, I cannot uninstall python-3,7-dev and HPLIP always uses python3.7-dev.
[12:32] <tribaal> ahasenack: coming back to the kitty discussion, it seems kitty comes with a bit of a workaround for that problem in the form of the "ssh kitten": from a kitty terminal, "kitty +kitten ssh <whatever SSH options you need>" will solve the problem by copying the appropriate terminfo on the remote host for you (in ~/.terminfo/)
[12:32] <ahasenack> yuck, why is its terminfo so special?
[12:32] <tribaal> I have no idea.
[12:33] <ahasenack> 2020 and backspace still frustrating users :)
[12:34] <tribaal> I know right :)
[12:37] <eoli3n_> any chance to have netinst in daylibuilds for 20.04 ?
[12:38] <eoli3n_> to be able to automate my install/tests with "kickstart"
[12:40] <tribaal> ahasenack: a secondary question would be "why is kitty's terminfo not upstreamed". Assuming it needs to be different for some reason.
[13:06] <doko> seb128: the pango1.0 sync from experimental breaks https://launchpadlibrarian.net/462042991/buildlog_ubuntu-focal-amd64.pyferret_7.5.0-2build1_BUILDING.txt.gz
[13:10] <seb128> doko, I guess pyferret needs to be fixed then
[13:15] <tkamppeter> doko, I cannot reproduce the FTBFS of HPLIP on my focal. Evsn if I install python3.8-dev there, I cannot uninstall python-3,7-dev and HPLIP always uses python3.7-dev.
[13:16] <doko> tkamppeter: do you have -proposed enabled?
[13:17] <tkamppeter> doko, no, perhaps I should do so.
[13:17] <seb128> doko, you might give a try to https://github.com/NOAA-PMEL/PyFerret/commit/104eecc6 ?
[13:18] <seb128> doko, though that commit is for mac but maybe something similar is needed on linux now
[13:19] <tkamppeter> doko, I will try with my other VM later.
[13:22] <tkamppeter> doko, currently there is no desktop for me in Focal, also on the clean VM, so I need to find out how to add proposed by command line.
[13:42] <AsciiWolf> juliank, sorry, I overlooked your reply to my comment regarding the outdated steam package
[13:43] <doko> seb128: same build error
[13:43] <seb128> doko, k, I don't know then, sorry
[13:44] <AsciiWolf> juliank, what is the right approach to do then? I was told on this channel that this should be addressed by tsimonq2 since he is the one who blocked auto sync of the steam package because of the changes he made
[13:46] <AsciiWolf> are there any exact steps that I should do in order to help with the steam package update?
[13:46] <juliank> AsciiWolf: That's not really true, the changes were made earlier
[13:46] <AsciiWolf> juliank, ah, I did not know this
[13:48] <AsciiWolf> anyway, should I create a Launchpad ticket for this or are there any other steps?
[14:04] <AsciiWolf> juliank, I have created a Launchpad ticket: https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1861112
[14:05] <doko> seb128: beancount has a sourceful upload with a buildN number. are you working on that?
[14:05] <AsciiWolf> feel free to let me know if there is anything I can do from my side, my intention was to help users, not to bother Ubuntu devs/package maintainers, sorry for that :)
[14:05] <juliank> AsciiWolf: And I marked it as a duplicate of bug 1796464
[14:05] <AsciiWolf> juliank, oops! I did not notice that one
[14:07] <juliank> My understanding is that steam would have to be remade into an amd64 package depending on the i386 libraries, but I might be wrong
[14:07] <seb128> doko, no, what work is needed? the build version was because the fix is in the packaging vcs in debian so the next upload can be autosynced
[14:08] <doko> well, it ftbfs
[14:08] <seb128> right, that's another issue than the version :p
[14:08] <seb128> but no, I'm not actively working on that one
[14:08] <seb128> had to move back to do other work so I don't have much time for proposed issue atm
[14:22] <ahasenack> rbasak: when/if you have a moment, if you could give me a hint as to what is blocking pacemaker in excuses
[14:22] <ahasenack> A search for "Trying easy from autohinter.*pacemaker" doens't show anything
[14:22] <ahasenack> and its "trying: pacemaker" seems to only list its own packages
[14:24] <ahasenack> rbasak: I mean in terms of running your script
[14:27] <ahasenack> ah, I may have gotten something
[14:30] <rbasak> Let me know if you'd like me to look
[14:31] <ahasenack> ok
[14:32] <ahasenack> need to get rid of the br mirror for these checks
[14:34] <ahasenack> it's deep
[14:35] <ahasenack> hmm, libffi6 vs libffi7
[14:43] <ahasenack> it's entangled with the python 3.8 migration
[14:44] <ahasenack> something like pacemaker -> pacemaker-resource-agents -> resource-agents -> cluster-glue -> python3.8 -> libpython3.8-stdlib
[14:44] <ahasenack> where the new libpython3.8-stdlib is linked with libffi7, and the one in the release pocket is linked with libffi6
[15:20] <tkamppeter> tdaitx, around?
[15:23] <eoli3n_> 133709    eoli3n_ | any chance to have netinst in daylibuilds for 20.04 ?
[15:25] <tumbleweed> eoli3n_: http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/images/netboot/mini.iso
[15:29] <eoli3n_> thx tumbleweed
[15:36] <cpaelzer> doko: the ruby guy to talk to is => kanashiro
[15:56] <tdaitx> tkamppeter: I will submit a request to ignore openjdk autopkgtest failures
[16:05] <tkamppeter> tdaitx, muito obrigado.
[17:14] <tdaitx> vorlon: doko: please review https://code.launchpad.net/~tdaitx/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/378183 to blacklist openjdk-13 and openjdk-14 on armhf/arm64 as well as add them to the big package list (they pass most of the time, but barely)
[17:15] <tdaitx> tkamppeter: ^ this should also fix openjdk-13 and openjdk-14 blocking your updates
[17:17] <tkamppeter> tdaitx, muito obrigado
[17:18] <tkamppeter> tdaitx, vorlon, doko, I had already done a retry on all the four and one passed the retry, the other 3 failed again.
[18:36] <gpiccoli> Hi vorlon, may I ask you to review/merge a britney MR regarding makedumpfile? We have consistent failures in ppc64el, which are being investigated by cascardo (the maintainer) and I; also, this time we had an i386 failure in eoan - mismatch arch from kexec-tools (i386) with kernel (amd64)
[18:36] <gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-eoan/+merge/378195
[18:36] <gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-bionic/+merge/378193
[18:36] <gpiccoli> Those are the MRs - tnx in advance
[18:36] <gpiccoli> This time the fixes are somewhat critical, if we could speed the release to -updates, I'd double-appreciate =)
[18:37] <gpiccoli> mfo, for reference, those are the MRs ^
[18:37]  * gpiccoli thinks the right term is merge proposal (MP) instead of merge request (MR), but anyway...
[18:38] <mfo> gpiccoli, thx!
[18:43] <vorlon> tdaitx: the package should be added to either the blacklist or the big_packages list, not both
[18:44] <vorlon> tdaitx: (since 'blacklist' means it will not be run at all)
[19:01] <gpiccoli> sorry vorlon, forgot Xenial hehe - here it is: https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-xenial/+merge/378197
[19:04]  * gpiccoli leaving, back tmrw o/
[19:13] <ahasenack> doko: if you are still around, I'm troubleshooting sssd's ftbfs with py3.8. I see python3.8-config --ldflags returning these -L components:
[19:13] <ahasenack> -L/usr/lib/python3.8/config-3.8-x86_64-linux-gnu -L/usr/lib
[19:14] <ahasenack> that doesn't look like the usual /usr/lib/x86-64/ I was expecting
[19:14] <ahasenack> is this correct?
[19:14] <ahasenack> furthermore, we don't usually have devel libraries in just /usr/lib
[19:15] <ahasenack> I see the same with python3.7-config, though
[19:37] <tdaitx> vorlon: well, I expect we will be removing it from the blacklist in the future, but I will ammend the merge to remove them from the big package list for armhf and arm64 then
[19:44] <tdaitx> vorlon: btw, when you said "the package should be added to either the blacklist or the big_packages list, not both", do you mean my particular case with openjdk-13 and openjdk-14 or in general?
[19:46] <tdaitx> because big package does not care for release, while the blacklist does, so I understand them to be ortogonal (and while one can blacklist a package for all releases, after a new devel series is opened the big package setting would take effect)
[19:46] <tdaitx> I am not complaining, just trying to understand the logic behind it =)
[19:51] <vorlon> gpiccoli: the xenial one appears to be unnecessary, any failures there are not being shown as regressions
[19:51] <tdaitx> vorlon: btw, while I am at it, should I remove the blacklisted distro entries for openjdk-lts as well?
[19:56] <vorlon> tdaitx: do you mean the disco ones?
[19:56] <tdaitx> indeed
[19:59] <vorlon> tdaitx: yes please
[19:59] <vorlon> tdaitx: and I mean in general, if we're saying that a package is going in the blacklist for an arch, there's no reason to add it to the big_packages list at the same time
[20:18] <tdaitx> vorlon: thanks for the pointers, the merge has been updated: https://code.launchpad.net/~tdaitx/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/378183
[20:25] <ahasenack> are build(ers) somewhat stuck?
[20:25] <cjwatson> Yes, waiting for a sysadmin to show up
[20:25] <ahasenack> https://launchpad.net/ubuntu/+source/shadowsocks-libev/3.3.4+ds-1ubuntu1 uploaded 1h ago, and hasn't started yet
[20:25] <cjwatson> See #launchpad-ops internal
[20:25] <ahasenack> ah
[20:32] <cjwatson> ahasenack: recovering now
[20:32] <ahasenack> yay
[20:32] <ahasenack> thanks
[21:28] <tdaitx> vorlon: thanks for helping with the review =)
[22:13] <murthy> I have build a deb for a pulseaudio module, but I need to change the rpath/runpath for it should I change it in cmake or in debian/ ?
[22:13] <murthy> I am a noob
[22:52] <seb128> tdaitx, vorlon, is there anything needed to make the openjdk blacklisted autopkgtest ignored for proposed migration?
[22:52] <seb128> cups (2.3.1-1ubuntu1 to 2.3.1-2) in proposed for 1 day
[22:52] <seb128>     Regressions
[22:52] <seb128>         openjdk-13/blacklisted: armhf (log, history)
[22:52] <seb128> like that one