[01:05] <ryanakca> Could someone please sync opensmtpd from Debian unstable? I just uploaded 6.6.2p1-1 that fixes some major security issues: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950121 (not yet reported in Ubuntu)
[01:06] <cjwatson> ryanakca: It'll auto-sync
[01:06] <cjwatson> Just about as quickly as anyone might be able to do it manually
[01:23] <ryanakca> Thanks! I filed a bug, but I don't remember how to use launchpad well enough to mark that it applies to versions of opensmtpd in current/past ubuntu releases.
[02:01] <vorlon> tdaitx: right, 'blacklist' means that autopkgtest won't attempt to run the tests at all, but it doesn't stop proposed-migration from expecting test results
[07:08] <Tuxist> i have problem with my ppa the won't build the i386 packages of pipewire but i need for test i386 applications
[07:09] <Tuxist> https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster
[08:50] <seb128> bdmurray, hey, can you/someone from foundation fix ubuntu-release-upgrader autopkgtests to stop depending on pep8 which has been removed from the archive?
[10:03] <doko> tkamppeter: https://launchpad.net/ubuntu/+source/hplip/3.19.12+dfsg0-3ubuntu1 untested
[10:12] <cpaelzer> doko: FYI py3.8 fix for crmsh inbount - upstream accepted my fix and I'm prepping something for focal now
[10:13] <cpaelzer> lol, obviously inbount->inbound
[10:25] <amitprakash> How do I package a custom build of kernel for PPA? Speficially, the kernel is built for a single set of hardware and includes firmware blobs
[10:25] <amitprakash> It also has no initrd/initramfs support
[11:19] <cjwatson> Tuxist: We'd need to fix https://bugs.launchpad.net/launchpad/+bug/1855069 first before you can do that
[11:20] <cjwatson> (not completely obvious)
[11:30] <gpiccoli> Tnx vorlon, for the heads-up about xenial and for the releases =)
[11:47] <Tuxist> cjwatson: yes i will recommend to build pipewire also in ubuntu with i386 because in 0.3 are wrapper libs for jack and pulseadio
[11:49] <cjwatson> Tuxist: See https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598
[11:49] <cjwatson> (I can't add things off my own bat)
[12:21] <seb128> Laney, juliank, do you know what needs to be done there,
[12:21] <seb128> cups (2.3.1-1ubuntu1 to 2.3.1-2) in proposed for 2 days
[12:21] <seb128>     Regressions
[12:21] <seb128>         openjdk-13/blacklisted: armhf (log, history)
[12:21] <seb128> unsure what the blacklisted is about?
[12:22] <Laney> tdaitx added it, don't know why I'm afraid
[12:23] <seb128> but should proposed-migration block on blacklisted tests?
[12:24] <Laney> depends why the blacklist was put into place
[12:24] <Laney> the release team can hint them as they can for any other test
[12:24] <seb128> tdaitx, ^ can you help with that one?
[12:24] <tkamppeter> tdaitx, hi
[12:24] <Laney> so if it's appropriate to ignore it, a force-badtest for this package with a version of 'blacklisted' would work
[12:24] <seb128> tkamppeter, read backlog if you are about the ask the same question :)
[12:25] <seb128> Laney, k, I guess I don't understnad what blacklist is about ... is that similar to badtest but not even trying to not waste infra resources?
[12:25] <Laney> it means do not run this test
[12:26] <Laney> like if it misbehaves in some way that breaks things on the test runners
[12:26] <Laney> or hits a bug
[12:26] <tkamppeter> Yes, it was exactly what I wanted to ask about, too.
[12:27] <seb128> Laney, is there any case where we want to not ignore results of a blacklisted test? I mean if it's blacklisted it seems to not be tried so it can't have green results?
[12:27] <tkamppeter> What we need (and what was probably intended) for CUPS is to ignore the openjdk tests and pass independent of them, best not even trigger tem.
[12:27] <Laney> It might be blacklisted only temporarily while the problem is investigated
[12:27] <seb128> I see
[12:28] <seb128> let's wait for tdaitx
[12:28] <tkamppeter> But should CUPS be held up during these investigations?
[12:28] <Laney> Imagine if you upload a new version of something and it breaks in a way that requires the blacklist
[12:28] <Laney> You would not want to let that slide in without actually investigating
[12:29] <tkamppeter> It is 9:28am in Brazil, so tdaitx should appear soon.
[12:30] <Laney> Sure, we can probably stop highlighting him now :-)
[13:21] <tdaitx> tkamppeter: seb128: I'm not entirely sure if openjdk-13 and openjdk-14 should block anything, our supported versions are openjdk-8 and openjdk-lts... doko, any opinion on that?
[13:21] <tdaitx> that said, vorlon reminded me last night that blacklisting the autopkgtests won't deal with britney blocking stuff in proposed, so I will send a merge proposal to hint the armhf failures
[13:21] <amitprakash> How do I package a custom build of kernel for PPA? Speficially, the kernel is built for a single set of hardware and includes firmware blobs? It also has no initrd/initramfs support
[13:21] <seb128> tdaitx, thx
[13:21] <amitprakash> I tried uploading via make deb-pkg but that fails on uploading to ppa w/  " Source/binary (i.e. mixed) uploads are not allowed."
[13:22] <Laney> tdaitx: arm64 too
[13:22] <tdaitx> yeah, that on as well
[13:22] <Laney> your hint could probably just be openjdk-13/blacklisted openjdk-14/blacklisted
[13:24] <tdaitx> interesting, I will take a look at that
[13:25] <Laney> I think - there's one for stress-ng that is like that
[13:25]  * Laney checks the code though
[13:27] <tdaitx> there's a stress-ng/blacklisted
[13:27] <tdaitx> good to learn it exists =)
[13:29] <Laney> yeah should work, there's even a testcase in proposed-migration for this one
[13:38] <tdaitx> Laney: many thanks for the pointer on this =)
[14:10] <tjaalton> running a s390x qemu instance on eoan seems to fail, how to debug that?
[14:10] <tjaalton> virt-manager says it's crashing, doing the same on a shell does nothing
[14:13] <xnox> tjaalton:  is your host s390x? did you enable kvm?
[14:14] <tjaalton> no
[14:14] <rbasak> List moderation for ubuntu-devel-announce@ please
[14:14] <tjaalton> amd64 laptop, I have kvm enabled for other machines
[14:14] <rbasak> (in the next day is fine)
[14:16] <cjwatson> rbasak: done
[14:16] <rbasak> Thank you!
[14:20] <tdaitx> vorlon: does the following hinting seems sane to you: https://code.launchpad.net/~tdaitx/britney/openjdk-update-badtest/+merge/378261 ?
[14:24] <cpaelzer> tjaalton: s390x emulation isn't complete
[14:24] <cpaelzer> tjaalton: we almost made it to be complete but then we bumped the ALS for 20.04
[14:24] <cpaelzer> so again we can't run it in emulation
[14:25] <cpaelzer> TL;DR you need a s390x host and --enable-kvm to run Ubuntu
[14:25] <cpaelzer> or a rather old guest that doesn't use any new instructions
[14:28] <cpaelzer> rbasak: what have I done to uvtool ? https://paste.ubuntu.com/p/ZNvBnB8jhn/
[14:29] <cpaelzer> I get this when calling it to sync an image
[14:29] <seb128> hum, does anyone know about netplan here? where does it write nm configs when you doa  "netplan apply" and a config in /etc/netplan with renderer: NetworkManager?
[14:30] <seb128> does it write a .conf for nm on disk or just apply config 'on the fly'?
[14:30] <seb128> --debug doesn't print any debug :/
[14:30] <tjaalton> cpaelzer: ah ok
[14:30] <tjaalton> pity
[14:30] <xnox> tjaalton:  or just launch s390x kvm in canonistack bos02
[14:30] <xnox> tjaalton:  you should have access to that, to simply launch an s390x VM
[14:31] <cpaelzer> yep, for debugging that is the best way I guess
[14:31] <tjaalton> ok, I'll check out
[14:33] <tjaalton> though I can only find bos01 on the wiki
[14:33] <tjaalton> I've never used either
[14:37] <cpaelzer> rbasak: just running "uvt-simplestreams-libvirt query" triggers the same
[14:37] <ahasenack> seb128: I think with NetworkManager it does nothing, and leaves it up to NM itself?
[14:37] <cpaelzer> rbasak: so I guess I have corrupted the pool or something ?!
[14:38] <cpaelzer> ahasenack: there is NM support for netplan coming, I just don't know in which state it is right now in general and even less on the particular system seb128 has
[14:38] <ahasenack> seb128: https://netplan.io/examples#using-network-manager-as-a-renderer
[14:39] <ahasenack> it's not clear if you *can* configure some aspects and leave the rest to NetworkManager, of, if using NM, *all* is left up to NM
[14:39] <rbasak> cpaelzer: check /var/lib/uvtool/libvirt/metadata/
[14:39] <seb128> ahasenack, thanks, poking a bit around that generates a .nmconnection in  /run/NetworkManager/system-connections
[14:39] <rbasak> That should contain json files with base64 encoded names
[14:40] <rbasak> One of them presumably isn't parsing
[14:40] <cpaelzer> rbasak: three files, one is zero size
[14:40] <seb128> ahasenack, I think I've enough to poke a bit more now (trying to figure out the netplan autopkgtest failure in focal)
[14:40] <cpaelzer> out of space maybe?
[14:40] <ahasenack> I think it supports a mix
[14:40] <cpaelzer> rbasak: not out of space
[14:40] <rbasak> I'm not sure what bug might cause that
[14:40] <cpaelzer> rbasak: can I just remove the zero byte file there?
[14:40] <ahasenack> I'm going over https://netplan.io/reference and every now and then it says something like "With NM rendered, this option is ignored", or "With NM, this options does foo"
[14:40] <rbasak> But if you remove the file it should be safe
[14:41] <rbasak> uvtool will just consider the corresponding image to not be synced
[14:41] <rbasak> I'm not sure what might happen if it tries to resync the same image though if it exists in the volume storage pool
[14:41] <rbasak> But we can deal with that if it happens
[14:41] <cpaelzer> rbasak: virsh vol-list uvtool lists 6 entries
[14:41] <cpaelzer> rbasak: but I have 3 on disk and as I said one of them empty
[14:42] <cpaelzer> maybe I should purge ...
[14:42] <rbasak> purge will clean up, sure
[14:42] <rbasak> It is however normal to have more images in the pool than json metadata entries
[14:42] <cpaelzer> rbasak: purge worked
[14:42] <rbasak> If for example an image is expired or replaced but there are still VMs that use it as a backing store
[14:42] <amitprakash> How do I push a custom kernel to launchpad (no modules, firmware blobs added, no initramfs)
[14:42] <cpaelzer> things are good again
[14:42] <cpaelzer> rbasak: and I can re-sync I guess
[14:42] <rbasak> Yep
[14:42] <cpaelzer> if it happens again I need to trace it down more in depth
[14:43] <cpaelzer> thanks rbasak
[14:43] <amitprakash> Currently, I get a rejection w/ "Source/binary (i.e. mixed) uploads are not allowed."
[14:46] <seb128> ahasenack, right, I'm not going to manage a system, just to debug the tests which worked with the previous n-m version, I think I figured out enough of how the config is generated now so I can look into what's wrong, thanks for the pointers/replies!
[14:49] <cjwatson> amitprakash: Launchpad will only ever accept source-only uploads, so you must ensure that your upload is a *_source.changes file that only contains a source package, no .debs etc.  However I can't help with the specific details of how to do that for a custom kernel.  Perhaps #ubuntu-kernel can.
[15:28] <amitprakash> ty cjwatson
[15:44] <doko> jamespage: can we remove octopussy? uploaded by you in 2012 ... only rdep for syslog-ng which I would like to remove too, or at least demote to proposed
[15:55] <doko> cpaelzer, mwhudson: fyi, https://bugs.debian.org/950141
[16:07] <cpaelzer> ahasenack: FYI ^^ rdkit
[16:08] <ahasenack> lovely
[16:11] <doko> ahasenack: my merge attempt is in ppa:doko/toolchain
[16:11] <ahasenack> ok
[16:12] <cpaelzer> ahasenack: got the sssd MP done
[16:12] <cpaelzer> ahasenack: in case you want to upload before you leave
[16:23] <tkamppeter> tdaitx, Laney, seb128, thanks. Currently CUPS still shows blocked on the blacklisted JDKs. Or does it still take time to take effect?
[16:24] <Laney> You need to wait for proposed-migration to run
[16:27] <tdaitx> tkamppeter: top of update excuses says "Generated: 2020.01.29 15:26:02 +0000" and the hinting was merged less than 30 minutes ago
[16:30] <tkamppeter> tdaitx, OK, obrigado.
[16:46] <rbasak> bryce: it looks like git-ubuntu 0.7.4 never got released to the stable channel
[16:46] <rbasak> So I'll push 0.9.1 to all channels now.
[16:53] <Tuxist> i have new jack package that solves problems with pipewire https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster/+packages
[17:01] <Eickmeyer[m]> Laney: You around? We have some systemd questions in #ubuntustudio-devel. (anyone else who might know some systemd stuff can join too)
[17:06] <Laney> Eickmeyer[m]: ok, don't eat me though
[17:06] <Eickmeyer[m]> Laney: We won't eat you. We're just having trouble with some user-level autostart stuff.
[17:39] <bryce> rbasak, sounds good
[17:47] <vorlon> tdaitx: fyi when we have a new version of a package in -proposed that needs a badtest hint, we add both versions rather than replacing the release version w/ the proposed version, so that packages that already ran their tests against the release version don't become newly blocked (openjdk-lts)
[18:01] <dannf> seb128: alsa-utils is uninstallable in focal due to a versioned Breaks in libasound2 - are you working on an alsa-utils merge? if not, i can take a look
[18:01] <joelkraehemann> hi all
[18:05] <ahasenack> cpaelzer: thanks (sssd)
[18:08] <tdaitx> vorlon: ack, sorry for that, should have realized it was best to leave it there for a while
[18:44] <bdmurray> seb128: I'm out today but will get someone to look at it
[18:48] <teward> does anyone know if the PPA builders still build for Trusty or if that was disabled when it EOL'd?  Related to a question/discussion in -packaging
[18:48] <tumbleweed> they'll still build for trusty
[18:58] <dannf> bdmurray: looks like juliank brought back the pep8 transition package - and meanwhile juliank and i had transitioned a few packages over anyway
[19:39] <seb128> bdmurray, hey, it got resolved since I pinged you, so you can forget about it :)
[19:40] <seb128> dannf, doko did that alsa-lib update so I guess he's working on updating the things that need to be updated with it, maybe check with him?
[19:42] <dannf> seb128: ack. doko ^. fyi, i've got a complete merge prepared, just about to test it
[19:57] <juliank> dannf: yeah, it's a bit too annoying for the python3.8 transition at the same time
[19:58] <juliank> dannf: Because now you fix a package, than its rdeps start failing, and it's becoming a mess
[19:58] <juliank> dannf: So doko suggested it'd be easier to just bring it back, we can fix things once the archive calms down
[19:59] <dannf> juliank: well, and we probably should keep the transition till after focal for upgrades anyway
[19:59] <juliank> Well, bionic's shipping pycodestyle, so it does not affect bionic -> focal upgrades
[19:59] <dannf> oh - ok
[20:00]  * dannf just learned about the rename yesterday, didn't realize it was that long ago :)
[20:02] <dannf> juliank: btw - we did our changes subtly different - i also renamed the test_pep8 to test_pycodestyle & search/replaced the files. do you want me to do the same for update-notifier for consistency?
[20:04] <juliank> heh, I made the change the same way I did it in python-apt
[20:04] <juliank> But yeah, you can do that if you like
[20:04] <juliank> I probably should rename the file in python-apt too, but I'm not sure I can be bothered
[20:04] <dannf> ack
[20:27] <techalchemy> juliank, I have a branch atm that changes to pybuild + setuptools + flake8 and already included the mentioned search&replace (though it likely does belong in it's own merge equest)
[20:28] <techalchemy> I think i have everything going to the right places now, but tbh i am by no means an expert at pybuild so it might be a very wrong approach
[22:32] <seb128> dannf, thx for the alsa-utils merge, do you plan to do alsa-plugins as well?
[22:35] <dannf> seb128: i hadn't planned to, but i can change that :)
[22:36] <seb128> dannf, I wouldn't say no if you want to do, usually the alsa set should be updated together
[22:36] <seb128> unsure why doko synced the new -lib only :/