[01:05] 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:05] Debian bug 950121 in opensmtpd "opensmtpd: Major vulnerabilities in opensmtpd resulting in RCE and DOS" [Critical,Fixed] [01:06] ryanakca: It'll auto-sync [01:06] Just about as quickly as anyone might be able to do it manually [01:23] 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] 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 === bpsecret- is now known as bpsecret [07:08] i have problem with my ppa the won't build the i386 packages of pipewire but i need for test i386 applications [07:09] https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster [08:50] 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] tkamppeter: https://launchpad.net/ubuntu/+source/hplip/3.19.12+dfsg0-3ubuntu1 untested [10:12] doko: FYI py3.8 fix for crmsh inbount - upstream accepted my fix and I'm prepping something for focal now [10:13] lol, obviously inbount->inbound [10:25] 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] It also has no initrd/initramfs support [11:19] Tuxist: We'd need to fix https://bugs.launchpad.net/launchpad/+bug/1855069 first before you can do that [11:19] Launchpad bug 1855069 in Launchpad itself "PPAs should be able to toggle using PRIMARY's arch-{white,black}lists" [Undecided,New] [11:20] (not completely obvious) [11:30] Tnx vorlon, for the heads-up about xenial and for the releases =) [11:47] 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] Tuxist: See https://discourse.ubuntu.com/t/community-process-for-32-bit-compatibility/12598 [11:49] (I can't add things off my own bat) [12:21] Laney, juliank, do you know what needs to be done there, [12:21] cups (2.3.1-1ubuntu1 to 2.3.1-2) in proposed for 2 days [12:21] Regressions [12:21] openjdk-13/blacklisted: armhf (log, history) [12:21] unsure what the blacklisted is about? [12:22] tdaitx added it, don't know why I'm afraid [12:23] but should proposed-migration block on blacklisted tests? [12:24] depends why the blacklist was put into place [12:24] the release team can hint them as they can for any other test [12:24] tdaitx, ^ can you help with that one? [12:24] tdaitx, hi [12:24] so if it's appropriate to ignore it, a force-badtest for this package with a version of 'blacklisted' would work [12:24] tkamppeter, read backlog if you are about the ask the same question :) [12:25] 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] it means do not run this test [12:26] like if it misbehaves in some way that breaks things on the test runners [12:26] or hits a bug [12:26] Yes, it was exactly what I wanted to ask about, too. [12:27] 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] 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] It might be blacklisted only temporarily while the problem is investigated [12:27] I see [12:28] let's wait for tdaitx [12:28] But should CUPS be held up during these investigations? [12:28] Imagine if you upload a new version of something and it breaks in a way that requires the blacklist [12:28] You would not want to let that slide in without actually investigating [12:29] It is 9:28am in Brazil, so tdaitx should appear soon. [12:30] Sure, we can probably stop highlighting him now :-) [13:21] 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] 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] 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] tdaitx, thx [13:21] 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] tdaitx: arm64 too [13:22] yeah, that on as well [13:22] your hint could probably just be openjdk-13/blacklisted openjdk-14/blacklisted [13:24] interesting, I will take a look at that [13:25] I think - there's one for stress-ng that is like that [13:25] * Laney checks the code though [13:27] there's a stress-ng/blacklisted [13:27] good to learn it exists =) [13:29] yeah should work, there's even a testcase in proposed-migration for this one [13:38] Laney: many thanks for the pointer on this =) === ricab is now known as ricab|lunch [14:10] running a s390x qemu instance on eoan seems to fail, how to debug that? [14:10] virt-manager says it's crashing, doing the same on a shell does nothing [14:13] tjaalton: is your host s390x? did you enable kvm? [14:14] no [14:14] List moderation for ubuntu-devel-announce@ please [14:14] amd64 laptop, I have kvm enabled for other machines [14:14] (in the next day is fine) [14:16] rbasak: done [14:16] Thank you! [14:20] vorlon: does the following hinting seems sane to you: https://code.launchpad.net/~tdaitx/britney/openjdk-update-badtest/+merge/378261 ? [14:24] tjaalton: s390x emulation isn't complete [14:24] tjaalton: we almost made it to be complete but then we bumped the ALS for 20.04 [14:24] so again we can't run it in emulation [14:25] TL;DR you need a s390x host and --enable-kvm to run Ubuntu [14:25] or a rather old guest that doesn't use any new instructions [14:28] rbasak: what have I done to uvtool ? https://paste.ubuntu.com/p/ZNvBnB8jhn/ [14:29] I get this when calling it to sync an image [14:29] 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] does it write a .conf for nm on disk or just apply config 'on the fly'? [14:30] --debug doesn't print any debug :/ [14:30] cpaelzer: ah ok [14:30] pity [14:30] tjaalton: or just launch s390x kvm in canonistack bos02 [14:30] tjaalton: you should have access to that, to simply launch an s390x VM [14:31] yep, for debugging that is the best way I guess [14:31] ok, I'll check out [14:33] though I can only find bos01 on the wiki [14:33] I've never used either [14:37] rbasak: just running "uvt-simplestreams-libvirt query" triggers the same [14:37] seb128: I think with NetworkManager it does nothing, and leaves it up to NM itself? [14:37] rbasak: so I guess I have corrupted the pool or something ?! [14:38] 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] seb128: https://netplan.io/examples#using-network-manager-as-a-renderer [14:39] 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] cpaelzer: check /var/lib/uvtool/libvirt/metadata/ [14:39] ahasenack, thanks, poking a bit around that generates a .nmconnection in /run/NetworkManager/system-connections [14:39] That should contain json files with base64 encoded names [14:40] One of them presumably isn't parsing [14:40] rbasak: three files, one is zero size [14:40] ahasenack, I think I've enough to poke a bit more now (trying to figure out the netplan autopkgtest failure in focal) [14:40] out of space maybe? [14:40] I think it supports a mix [14:40] rbasak: not out of space [14:40] I'm not sure what bug might cause that [14:40] rbasak: can I just remove the zero byte file there? [14:40] 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] But if you remove the file it should be safe [14:41] uvtool will just consider the corresponding image to not be synced [14:41] 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] But we can deal with that if it happens [14:41] rbasak: virsh vol-list uvtool lists 6 entries [14:41] rbasak: but I have 3 on disk and as I said one of them empty [14:42] maybe I should purge ... [14:42] purge will clean up, sure [14:42] It is however normal to have more images in the pool than json metadata entries [14:42] rbasak: purge worked [14:42] If for example an image is expired or replaced but there are still VMs that use it as a backing store [14:42] How do I push a custom kernel to launchpad (no modules, firmware blobs added, no initramfs) [14:42] things are good again [14:42] rbasak: and I can re-sync I guess [14:42] Yep [14:42] if it happens again I need to trace it down more in depth [14:43] thanks rbasak [14:43] Currently, I get a rejection w/ "Source/binary (i.e. mixed) uploads are not allowed." [14:46] 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] 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. === ricab|lunch is now known as ricab [15:28] ty cjwatson [15:44] 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] cpaelzer, mwhudson: fyi, https://bugs.debian.org/950141 [15:55] Debian bug 950141 in src:rdkit "rdkit downloads additional files during the build" [Serious,Open] [16:07] ahasenack: FYI ^^ rdkit [16:08] lovely [16:11] ahasenack: my merge attempt is in ppa:doko/toolchain [16:11] ok [16:12] ahasenack: got the sssd MP done [16:12] ahasenack: in case you want to upload before you leave [16:23] tdaitx, Laney, seb128, thanks. Currently CUPS still shows blocked on the blacklisted JDKs. Or does it still take time to take effect? [16:24] You need to wait for proposed-migration to run [16:27] 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] tdaitx, OK, obrigado. [16:46] bryce: it looks like git-ubuntu 0.7.4 never got released to the stable channel [16:46] So I'll push 0.9.1 to all channels now. [16:53] i have new jack package that solves problems with pipewire https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster/+packages [17:01] Laney: You around? We have some systemd questions in #ubuntustudio-devel. (anyone else who might know some systemd stuff can join too) [17:06] Eickmeyer[m]: ok, don't eat me though [17:06] Laney: We won't eat you. We're just having trouble with some user-level autostart stuff. [17:39] rbasak, sounds good [17:47] 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] 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] hi all [18:05] cpaelzer: thanks (sssd) [18:08] vorlon: ack, sorry for that, should have realized it was best to leave it there for a while [18:44] seb128: I'm out today but will get someone to look at it [18:48] 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] they'll still build for trusty [18:58] bdmurray: looks like juliank brought back the pep8 transition package - and meanwhile juliank and i had transitioned a few packages over anyway [19:39] bdmurray, hey, it got resolved since I pinged you, so you can forget about it :) [19:40] 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] seb128: ack. doko ^. fyi, i've got a complete merge prepared, just about to test it [19:57] dannf: yeah, it's a bit too annoying for the python3.8 transition at the same time [19:58] dannf: Because now you fix a package, than its rdeps start failing, and it's becoming a mess [19:58] dannf: So doko suggested it'd be easier to just bring it back, we can fix things once the archive calms down [19:59] juliank: well, and we probably should keep the transition till after focal for upgrades anyway [19:59] Well, bionic's shipping pycodestyle, so it does not affect bionic -> focal upgrades [19:59] oh - ok [20:00] * dannf just learned about the rename yesterday, didn't realize it was that long ago :) [20:02] 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] heh, I made the change the same way I did it in python-apt [20:04] But yeah, you can do that if you like [20:04] I probably should rename the file in python-apt too, but I'm not sure I can be bothered [20:04] ack [20:27] 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] 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] dannf, thx for the alsa-utils merge, do you plan to do alsa-plugins as well? [22:35] seb128: i hadn't planned to, but i can change that :) [22:36] dannf, I wouldn't say no if you want to do, usually the alsa set should be updated together [22:36] unsure why doko synced the new -lib only :/ === JanC is now known as Guest16482 === JanC_ is now known as JanC