[00:52] <jbicha> vorlon: https://ubuntu-archive-team.ubuntu.com/madison.cgi is displaying code instead of the webpage
[02:00] <vorlon> jbicha: well that's fun, I didn't know we had any cgi scripts under there. :|
[02:00] <vorlon> jbicha: does that break rmadison?
[02:01] <jbicha> yes, that's how I noticed
[02:01] <vorlon> that's annoying.  I'll file an RT about it shortly but first I'm looking at the fact that I broke all image builds by having archive-team.internal DNS changed to a machine that's not running apache
[02:07] <vorlon> ok filing an RT but also trying to figure out if I can magic up an .htaccess in the meantime that redirects everything NOT madison.cgi
[02:20] <vorlon> so the answer to the latter is that I definitely can and it's just a question of how magic
[02:27] <vorlon> jbicha: hacky hacky
[02:27] <vorlon> (it's working)
[02:28] <arraybolt3> Hacky is how it's done :)
[02:32] <jbicha> the rmadison output seems a little out of date. gnome-pkg-tools is a test case
[02:34] <vorlon> yes it will be
[02:34] <vorlon> I need to turn a cron job back on on snakefruit to make it work
[02:35] <vorlon> but first I need to figure out which one
[02:35] <vorlon> (probably the big one which means I need to neuter it)
[02:41] <vorlon> yep
[02:44] <vorlon> jbicha: fixed
[02:45] <jbicha> 👍
=== chris14_ is now known as chris14
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-banagher-meta to canonical-oem-metapackages in bionic
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-cappy-meta to canonical-oem-metapackages in bionic
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-caressa-meta to canonical-oem-metapackages in bionic
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-banagher-meta to canonical-oem-metapackages in focal
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-cappy-meta to canonical-oem-metapackages in focal
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-caressa-meta to canonical-oem-metapackages in focal
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-banagher-meta to canonical-oem-metapackages in jammy
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-cappy-meta to canonical-oem-metapackages in jammy
[04:24] -queuebot:#ubuntu-release- Packageset: Added oem-sutton-caressa-meta to canonical-oem-metapackages in jammy
[06:39] -queuebot:#ubuntu-release- New sync: oem-sutton-banagher-meta (jammy-proposed/primary) [22.04~ubuntu1]
[06:40] -queuebot:#ubuntu-release- New sync: oem-sutton-cappy-meta (jammy-proposed/primary) [22.04~ubuntu1]
[06:42] -queuebot:#ubuntu-release- New sync: oem-sutton-caressa-meta (jammy-proposed/primary) [22.04~ubuntu1]
[06:48] <LocutusOfBorg> sergiodj, I uploaded emacs to Ubuntu with gcc-13 on riscv64, lets cross fingers (and also merged from Debian)
[06:49] <LocutusOfBorg> we had security fixes there
[09:55] <schopin> vorlon: ack on the FFe status field. I'm honestly annoyed at the context-sensitive nature of the status field in LP, though.
[10:53] -queuebot:#ubuntu-release- Unapproved: linux-firmware (jammy-proposed/main) [20220329.git681281e4-0ubuntu3.10 => 20220329.git681281e4-0ubuntu3.11] (core, kernel)
[11:04] -queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187.36 => 1.187.37] (core, kernel)
[11:57] <juliank> Who can rescore-ppa-builds ubuntu-uefi-team ppa for me?
[11:58] <juliank> There's a riscv64 build in there that's queuing a bit long
[11:59]  * juliank is waiting on that to continue with the gnu-efi reverse depends rebuilds for kinetic to ensure SRU doesn't regress (or we at least know what regresses)
[12:00] -queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.2.14-0~18.04.2 => 1.2.14-0~18.04.3] (desktop-core)
[12:36] <cjwatson> juliank: Done, but I think I'd probably better do some builder repair which will be more useful
[12:36] <kanashiro[m]> slyon: hi, not sure if you saw my comment from yesterday, but could you update the status of the mosh MIR bug? (LP: #1997106) It is already in the component mismatches page
[12:36] -ubottu:#ubuntu-release- Launchpad bug 1997106 in mosh (Ubuntu) "[MIR] mosh" [Undecided, In Progress] https://launchpad.net/bugs/1997106
[12:37] <cjwatson> riscv64 has a hard enough time keeping up as it is without half the builders disabled
[12:38] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.6] has been marked as ready
[12:39] <juliank> cjwatson: thanks. basically I just need to ensure it's built before the other PPA starts its 4 test rebuilds
[12:40] <juliank> I don't think we have riscv64 docker containers or I could test that with qemu-user-static emulation locally
[12:42] <juliank> oh we do
[12:42] <cjwatson> It's building now, anyway
[12:42] <juliank> yeah but this means I can run the test rebuilds locally
[12:42] <juliank> of the reverse deps
[12:43] <juliank> :)
[12:43] <juliank> The PPA build is needed anyhow as it's binary copied to the main archive
[12:43] <juliank> (because this is building against -security only)
[12:53] <cjwatson> Right, riscv64 builders all healthy again now
[12:54] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (jammy-proposed) [20220329.git681281e4-0ubuntu3.11]
[12:57] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.37]
[13:00] <slyon> kanashiro[m]: thanks for the reminder, I missed it yesterday. let me have a look
[13:05] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.45 => 2.664.46] (desktop-core, i386-whitelist)
[13:05] <slyon> kanashiro[m]: it seems the mandadory MIR requirement #3 and #4 are not yet addressed. Is there anything planned to fix this?
[13:07] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.46]
[13:07] <slyon> can we at least run the build-time unittests against the installed package during autopkgtests for example?
[13:10] <sil2100> Hello everyone! We'll have to respin 20.04.6 images sadly! But the changeset should be small, so I wouldn't require retesting everything
[13:30] <ricotz> sil2100, hello :), would you be so kind to take a look at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2009354
[13:30] -ubottu:#ubuntu-release- Launchpad bug 2009354 in libreoffice (Ubuntu Kinetic) "[SRU] libreoffice 7.4.6 for kinetic" [High, Incomplete]
[14:07] <ahasenack> sil2100: ginggs: hi, about the focal soft freeze, is that still ongoing? I have a rabbitmq sru for f, j, k, and was wondering if I should hold the focal release
[14:07] <sil2100> ahasenack: please hold for now
[14:07] <ahasenack> sil2100: ack
[14:07] <sil2100> ahasenack: we'll be respinning soon...
[14:15] <tillkamppeter> Hi, I need an exception for a failing autopkg test. It is the test of the foo2zjs package which is triggered by several printing-related packages, especially cups-filters: https://ubuntu-archive-team.ubuntu.com/proposed-migration/lunar/update_excuses.html#cups-filters
[14:16] <tillkamppeter> The test is triggered because foo2zjs depends on cups-filters.
[14:16] <kanashiro[m]> slyon: let me take a look and I will get back to you, thanks for checking!
[14:19] <tillkamppeter> The relevance of the failure is very low for the distro, as it foo2zjs is a driver package for ~100, usually older, printer models, rather cheap printers. Once, the package is not maintained upstream any more, second, it will be removed in Ubuntu 23.10, as printer drivers will get replaced by Printer Application Snaps. and third, it is not very probable that someone connects such a printer to a ppc64el system (server?).
[14:21] <tillkamppeter> So having the build of the whole distro be held by a bug in foo2zjs does not make sense. Also there are drivers for other printers, ~10000 models where the autopkg tests pass with the current cups-filters (2.0b3).
[14:22] <tillkamppeter> Do I want to ask you to let failures of the autopkgtests of foo2zjs not be treated as regression. Could this be done?
[14:51] <zhsj> tillkamppeter: the regression looks strange, it only fails on ppc64el. it makes me think if it's related to -O3 option. and if it's broken on ppc64el, is it better to drop this arch?
[14:53] <sergiodj> LocutusOfBorg: ah, thanks.  I'm working with doko to determine what's going on, but I see that your upload's riscv64 build already passed the stage where it was failing before
[14:53] <sergiodj> so I think it'll work
[14:58] <LocutusOfBorg> sergiodj, I wanted to unblock some emacs stuff stuck on riscv64
[14:58] <LocutusOfBorg> feel free to override my upload once you get the gcc fix :D
[14:59] <tillkamppeter> zhsj, you mean to not build it for that arch at all any more? We could do so. What do I have to add to the package so that its build on ppc64el gets excluded? Or will you in the release team make it getting not built for ppc64el any more?
[14:59] <sergiodj> LocutusOfBorg: thanks a lot!  :)
[14:59] <zhsj> tillkamppeter: i'm not the release team, lol. just my 2 cent :P
[15:01] -queuebot:#ubuntu-release- Unapproved: linux-firmware (kinetic-proposed/main) [20220923.gitf09bebf3-0ubuntu1.4 => 20220923.gitf09bebf3-0ubuntu1.5] (core, kernel)
[15:04] <icey[m]> hey vorlon : the fixes for our Ceph 17.2.5 SRU in Kinetic and Jammy are in the unapproved queues again, and I've run our distro-regression testing on that upload now
[15:19] <kanashiro[m]> slyon: as Robie was working on the mosh MIR and I got assigned just to finish the promotion (surprisingly it is not ready), I will not address your comments right now (it will require some package changes) and wait for Christian to get back from PTO.  I have another unfinished roadmap item requiring my attention (release is coming :)
[15:19] <kanashiro[m]> again, thanks for checking!
[15:25] <doko> LocutusOfBorg: it's probably better to disable the jit in that case, same like for s390x (although I don't know the reasons for that=
[15:26] <RikMills> seed change I made has not propagated to https://ubuntu-archive-team.ubuntu.com/seeds/kubuntu.lunar/desktop
[15:29] <slyon> kanashiro[m]: OK wfm. Thanks.
[15:35] <LocutusOfBorg> doko, what is the problem of using gcc-13 on riscv64?
[15:35] <LocutusOfBorg> it works...
[15:40] <vorlon> RikMills: how long ago?
[15:41] <vorlon> icey[m]: I won't look at the SRU queue until tomorrow; ahasenack and sil2100 are on for today
[15:41] <icey[m]> tomorrow's ok too, I'm just hoping for a less-than-two-week acceptance :-)
[15:50] <RikMills> vorlon: 2hrs for me. I also not that a change push to the ubuntu-mate seed at 10pm UTC yesterday has also not been updated there
[15:50] <RikMills> *also note
[15:51] <vorlon> RikMills: thanks, digging
[15:54] <vorlon> RikMills: we run update-seeds every 5 minutes, but it will fall over at the first entry that has failures updating and then the rest silently don't get processed
[15:55] <bdrung> can we build pycurl for i386 as well (to get rid of the devscripts diff)? Especially since we have now unit tests for the code that uses pycurl.
[15:55] <RikMills> yeah, I recall this from a while back
[15:56] <vorlon> bdrung: do you know why devscripts isn't Arch: all?
[15:57] <vorlon> /usr/bin/debpkg:             ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b2c596013974032c717e71cf9d6c1d0f33b1254d, for GNU/Linux 3.2.0, stripped
[15:57] <vorlon> blah
[15:57] <vorlon> a command I've never heard of before
[15:57] <vorlon> and looks like an all-around bad idea
[15:57] <bdrung> time to rewrite some scripts in rust to complete the language mix :D
[15:58] <vorlon> kill that upstream and then we don't have to worry about an i386 build ;)
[15:59] <schopin> The question is why do we have an i386 build in the first place? Otherwise you're just moving the issue.
[15:59] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop (Legacy) amd64 [Focal 20.04.6] has been updated (20230316)
[16:00] <schopin> unless pycurl is *only* used for the unit tests?
[16:00] <vorlon> bdrung: pycurl build-depends on vsftpd.  I'm not going down that road
[16:00] <vorlon> schopin: gem2deb build-depends on devscripts
[16:04] <vorlon> RikMills: running update-seeds manually has succeeded
[16:05] <vorlon> RikMills: rerunning with the proxy variables from cron set to see what's up
[16:05] <RikMills> vorlon: thanks!
[16:06] <bdrung> gem2deb uses at least dch and wrap-and-sort
[16:09] <vorlon> RikMills: ok, 'bzr pull' on kubuntu-active.trusty is failing with the proxy variables set
[16:09] <vorlon> I'll dig in
[16:09] <vorlon> (the git pulls work fine)
[16:09] <tillkamppeter> Anyone of the release team could have a look at my problem with foo2zjs and ppc64el?
[16:10] <tillkamppeter> @vorlon? ^^
[16:10] <zhsj> bdrung: i want to learn the history of debpkg, why it exists in the first place. but salsa downs...
[16:11] <vorlon> tillkamppeter: I agree with zhsj; test failures like this are a hint that there are broken binaries, and it's better for us to stop making those binaries available on archs where they are not useful and we're not going to support them, than to hint away failures.  I'm going to take a look on ppc64el at what's actually broken
[16:12] <vorlon> RikMills: oh this is the crash of bzr I've already seen elsewhere, that focal bzr + urllib are incompatible with http_proxy env var
[16:12] <vorlon> if we just got everyone off of bzr, we'd be golden
[16:13] <vorlon> as it is, I'll shove in a fix to unset http_proxy
[16:14] <bdrung> zhsj, having a local checkout is useful for this case.
[16:14] <tillkamppeter> Thanks, @vorlon. if you have some solution, please also ping me on Mattermost, as I am not always on IRC.
[16:15] <bdrung> zhsj, https://manpages.debian.org/testing/devscripts/debpkg.1.en.html gives some explanation, but it is not clear to me what having debpkg benefits over making dpkg setuid.
[16:15] <vorlon> RikMills: deployed. seed updates should work fine now
[16:16] <ItzSwirlz> Hi release-team, I just booted the Cinnamon image in a VM, and the.. I guess, Ubiquity stage? (The try or install ubuntu) - the background is still showing a debian logo, and I don't think it's using the Yaru theme. Where should I look? I'm willing to attempt a PR
[16:16] <zhsj> bdrung: that's why i want to check the git commits, the manpage really hurts my head.
[16:18] <jbicha> ItzSwirlz: is it possible for you to not have desktop-base pre-installed since that shouldn't be needed on an Ubuntu system?
[16:18] <ItzSwirlz> jbicha: can you send a link of what desktop-base installs?
[16:19] <jbicha> ItzSwirlz: you can find the file list at the bottom of https://launchpadlibrarian.net/647812491/buildlog_ubuntu-lunar-amd64.desktop-base_12.0.2ubuntu1_BUILDING.txt.gz
[16:20] <jbicha> ItzSwirlz: or run dpkg -L desktop-base  or my favorite is  apt-file list
[16:20] <ItzSwirlz> Yeah, that would explain why there's so much debian lying around.
[16:20] <jbicha> I don't think that would solve your problem but it would get rid of the Debian wallpaper
[16:22] <ItzSwirlz> It's possible desktop-base overrides what is placed
[16:24] <ItzSwirlz> I also need to check GRUB, I didn't but I don't think the oem-config-gtk task is added either
[16:28] <vorlon> tillkamppeter: cups-filters isn't moving anyway, the MIRs aren't finished
[16:28] <tillkamppeter> @vorlon, @zhsj by the way, -O3 cannot be the problem, as the package uses only O2 for building.
[16:28] <vorlon> tillkamppeter: incorrect. dpkg overrides the default compiler flags for all builds on ppc64el
[16:28] <vorlon> you can see it in the build log
[16:29] <jbicha> ItzSwirlz: does Ubuntu Cinnamon use the correct wallpaper by default if you complete the Lunar install?
[16:29] <tillkamppeter> @vorlon, I know, but @seb128 reminded me that the foo2zjs test on ppc64el was still hanging, and for migration both have be solved. That was also a reason why I had prioritized other tasks before looking into the foo2zjs problem again.
[16:30] <ItzSwirlz> jbicha: move to dms
[16:30] <vorlon> tillkamppeter: ok
[16:31] <jbicha> ItzSwirlz: other people here or in #ubuntu-devel may have helpful advice too 🤷
[16:32] <tillkamppeter> @vorlon, OK, so it is O2 anyway, what I have seen now that even on amd64 it only uses O2, but this is probably due to the upstream build system. So we know it is not the O2/O3 problem here, so best is to take it away from ppc64el.
[16:33] <vorlon> tillkamppeter: it is NOT -O2, look at the build log
[16:35] <vorlon> anyway I'm having an annoying time reproducing the failure because ppc64el uses too much memory so I use chroots instead of containers for my ppc64el debugging and the test case assumes cupsd is running. :|
[16:36] <vorlon> right manually starting it works around that
[16:36] <vorlon> but the foo2zjs autopkgtest is buggy to not declare the isolation it needs
[16:38] <tillkamppeter> @vorlon, this I did not know, I have created and applied the test years ago to practically all printer drivers and it worked, up to now. So declaring isolation on it could perhaps help?
[16:40] <vorlon> yes
[16:40] <vorlon> it could be made compatible with chroots by stopping the service and manually starting cupsd but that's not really all that interesting
[16:40] <vorlon> (nobody runs tests in chroot in production)
[16:41] <vorlon> yeah now I'm getting completely different test failures
[16:57] <tillkamppeter> @vorlon, I only want to know now whether simply uploading foo2zjs with isolation declared for the test could already make the test passing and everything is OK, or whether we should now right away remove this package from ppc64el?
[17:03] <vorlon> tillkamppeter: no, that has no bearing on the way autopkgtests are run on our infrastructure
[17:05] <tillkamppeter> @vorlon, OK, thanks, then it seems we should remove it from ppc64el. How to proceed for that? Do I need to mark it somehow in the package and upload or does the release team mark something internally?
[17:06] <vorlon> no
[17:06] <vorlon> foo2zjs isn't what regressed
[17:06] <vorlon> this binary is unchanged and its tests now fail
[17:06] <vorlon> so what changed that is making foo2zjs not work?  that's the broken binary
[17:08] <vorlon> I'm working on getting a sane reproducer environment now (deploying a new larger ppc64el VM so I can launch containers)
[17:10] <tillkamppeter> @vorlon, OK, assuming a change in cups-filters (or the new dependencies libcupsfilters and libppd) would cause it, is that all the other printer drivers are no affected.
[18:12] <sil2100> FYI: 20.04.6 images respinning, confirmed with the desktop image that the workaround helped
[18:33] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.6] has been updated (20230316)
[18:36] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.6] has been updated (20230316)
[18:37] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.6] has been updated (20230316)
[18:38] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.6] has been updated (20230316)
[18:38] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.6] has been updated (20230316)
[18:46] <Eickmeyer> vorlon: ubuntustudio seeds not getting picked-up by update-seeds? I replaced the gnome-3-38-2004 snap with the gnome-42-2204 snap as required and latest build attempt doesn't reflect it happened.
[18:47] <Eickmeyer> I made the change hours ago, fwiw.
[19:01] <vorlon> Eickmeyer: siggggghhhh let me check again what's going on
[19:01] <vorlon> I did do a complete update-seeds run that succeeded when RikMills asked
[19:02] <Eickmeyer> vorlon: I saw, but the last cron job build for Studio failed.
[19:02] <Eickmeyer> (merely 1/2 hour ago-ish)
[19:02] <vorlon> oh I know what it is
[19:02] <vorlon> dammit
[19:02] <vorlon> I forgot to fix this last night
[19:03] <vorlon> I fixed the update of seeds on the new host, but livecd-rootfs hits archive-team.internal for the seeds; and that points to snakefruit still because ubuntu-archive-toolbox isn't running apache; and I turned off all the cronjobs on snakefruit
[19:03] <Eickmeyer> Oh nooooo....
[19:04] <vorlon> sorry.  I totally knew about this issue and then it slipped my mind
[19:04] <vorlon> refreshing the seeds now
[19:04] <Eickmeyer> It's alright. I'm not unbelievably as stressed about this as I am other things.
[19:05] <vorlon> I can kick off another ubuntustudio build after this
[19:05] <Eickmeyer> That would be really helpful.
[19:06] <vorlon> I'll do kubuntu, ubuntu-mate, ubuntustudio which are the ones that have been mentioned here
[19:06] <Eickmeyer> FWIW, edubuntu is looking sunshine and rainbows.
[19:21] <vorlon> ah ubuntu-mate still failing with pipewire vs pulse
[19:23] <Eickmeyer> I've been trying to guide them through that mess, but it seems there's a lot of desktop deps on pulse they need to navigate through.
[19:24]  * vorlon nods
[19:24] -queuebot:#ubuntu-release- Unapproved: openldap (kinetic-proposed/main) [2.5.14+dfsg-0ubuntu0.22.10.1 => 2.5.14+dfsg-0ubuntu0.22.10.2] (i386-whitelist, ubuntu-server)
[19:47] <seb128> vorlon, could you trigger an ubuntu lunar rebuild as well? the iso tracker seems to think it's already rebuilding when it's not
[19:47] <vorlon> seb128: looking
[19:48] <seb128> thx
[19:48] <vorlon> seb128: to be clear, you're looking for a rebuild in addition to the daily that ran at 7:41?
[19:49] <vorlon> (the cowboy is still in place for 20.04.6)
[19:49] <seb128> vorlon, yes, firefox is broken on the current ISO and we want to verify that the store assertion update just issue fixes the issue
[19:49] <vorlon> ack
[19:49] <vorlon> building
[19:49] <seb128> thanks!
[19:50] <arraybolt3> Out of curiosity, how long does it take for seed changes to propagate? I'm impatiently waiting for something I changed just a few minutes ago to go through so I can rebuild Lubuntu, and would like to know when I should check next.
[19:50] <arraybolt3> (I guess that's only partially out of curiosity, more out of wanting to not keep re-checking needlessly :P)
[19:53] <vorlon> arraybolt3: update-seeds is run on a 5-minute schedule.  The actual implementation of the command is has to walk through all the source repositories one-by-one which is annoyingly slow
[19:53] <vorlon> I haven't timed it but should still be sub-20 minutes for the whole thing
[19:55] -queuebot:#ubuntu-release- New: accepted gcr4 [source] (lunar-proposed) [4.1.0-0ubuntu1]
[19:59] -queuebot:#ubuntu-release- New binary: gcr4 [amd64] (lunar-proposed/none) [4.1.0-0ubuntu1] (no packageset)
[20:00] -queuebot:#ubuntu-release- New binary: gcr4 [s390x] (lunar-proposed/none) [4.1.0-0ubuntu1] (no packageset)
[20:00] <RikMills> vorlon: thank you for the image respins. kubuntu livefs succeeded \o/
[20:01] <RikMills> ubuntu-mate did not /o\
[20:04] -queuebot:#ubuntu-release- New binary: gcr4 [arm64] (lunar-proposed/none) [4.1.0-0ubuntu1] (no packageset)
[20:16] <vorlon> tillkamppeter: I can reproduce the ppc64el failure.  How can I manually invoke the filters *without* going through cupsd, to have a minimal test case?
[20:20] <vorlon> tillkamppeter: I've tried rebuilding all of libcupsfilters, libppd, and cups-filters with -O2 instead of -O3 and these still fail.  and it happens sooner for me on my test VM (with an earlier driver and test file in the loop) than on the autopkgtest infra.  So I am left doubtful about the reliability of the whole cups-filters stack on ppc64el as a whole
[20:29] -queuebot:#ubuntu-release- New binary: gcr4 [riscv64] (lunar-proposed/universe) [4.1.0-0ubuntu1] (no packageset)
[20:33] <vorlon> xnox: if these linux-* packages in -proposed are never going to migrate should I just remove them?
[20:36] <tillkamppeter> @vorlon CUPS has a tool named "cupsfilter" (binary package "cups") which allows to run filter chains without using cupsd. It has also a man page. You supply the PPD file, input and output MIME types, options, an input file ... Then the same methods are applied to find the needed filter chain.
[20:43] -queuebot:#ubuntu-release- New binary: gcr4 [armhf] (lunar-proposed/universe) [4.1.0-0ubuntu1] (no packageset)
[20:44] -queuebot:#ubuntu-release- New binary: gcr4 [ppc64el] (lunar-proposed/universe) [4.1.0-0ubuntu1] (no packageset)
[20:48] <teward> notes for anyone watching GNOME and archive: Studio is having an issue with Germinate and requested (with agreement from Wimpy and others) to swap the ordering of dependencies in libcanberra-pulse and asked me with my coredev to upload.  Apparently, GNOME packaging uses an annoying d/control.in to populate d/control which i missed in -10ubuntu3 so I reuploaded WITH the fix as -10ubuntu4.  In case someone wonders why i did two
[20:48] <teward> uploads...
[20:49] <teward> ... nearly at the same time give or take a few
[20:49] <teward> POC for the request came from arraybolt3 and Eickmeyer but Wimpy and RikMills both requested as well
[20:50] <arraybolt3> teward: MATE, not Studio.
[20:50] <Eickmeyer> teward: Nope MATE, not Studio.
[20:50] <teward> oops already put in chagnelog from Studio team but oops
[20:50] <teward> doesn't matter as long as it's fixed
[20:50] <teward> either way, MATE team requested ^^
[20:50] <teward> fixed
[20:50] <teward> not vgoing ot reup -10ubuntu5 for the changelog
[20:50] <teward> but either way, was requested, was uploaded
[20:50] <teward> i'm going to find more coffee
[20:50] <teward> arraybolt3: you owe me $20
[20:51] <arraybolt3> I just sent you more coffee!
[20:54] <arraybolt3> vorlon: Hate to bother you about seeds again, but Lubuntu's seed still hasn't updated on ubuntu-archive-team.ubuntu.com and it's been way more than 20 minutes since I pushed things.
[21:02] <vorlon> arraybolt3: I have to step out for a half hour, but I'll look at it when I get back.  I'm now realizing that even hitting archive-team.internal gets redirected to ubuntu-archive-team.ubuntu.com, which has a different, rsync delay
[21:06] -queuebot:#ubuntu-release- New: accepted gcr4 [amd64] (lunar-proposed) [4.1.0-0ubuntu1]
[21:06] -queuebot:#ubuntu-release- New: accepted gcr4 [armhf] (lunar-proposed) [4.1.0-0ubuntu1]
[21:06] -queuebot:#ubuntu-release- New: accepted gcr4 [riscv64] (lunar-proposed) [4.1.0-0ubuntu1]
[21:06] -queuebot:#ubuntu-release- New: accepted gcr4 [arm64] (lunar-proposed) [4.1.0-0ubuntu1]
[21:06] -queuebot:#ubuntu-release- New: accepted gcr4 [s390x] (lunar-proposed) [4.1.0-0ubuntu1]
[21:06] -queuebot:#ubuntu-release- New: accepted gcr4 [ppc64el] (lunar-proposed) [4.1.0-0ubuntu1]
[21:40] <utkarsh2102> vorlon: hi! I have few questions - mostly just to make sure I understand everything clearly :)
[21:41] <vorlon> utkarsh2102: hi
[21:41] <vorlon> arraybolt3: https://ubuntu-archive-team.ubuntu.com/seeds/lubuntu.lunar/desktop is up-to-date right now; did it fix itself?
[21:41] <utkarsh2102> first, every seed in ubuntu-seeds is germniated via the ./update script in ubuntu-meta, no? and then the output is uploaded to https://ubuntu-archive-team.ubuntu.com/germinate-output/ubuntu.lunar/
[21:41] <utkarsh2102> is that correct?
[21:42] <vorlon> utkarsh2102: ubuntu-archive-team.ubuntu.com is a front-end that pulls from ubuntu-archive-toolbox, which runs germinate.  This is not done using the update script, which is specific to metapackages
[21:43] <utkarsh2102> aaaaaaah, got it! noting it down
[21:43] <arraybolt3> vorlon: Looks like it, thanks you!
[21:46]  * utkarsh2102 is looking for what and where is ubuntu-archive-toolbox :)
[21:46] <vorlon> arraybolt3: ok.  Seems like it took longer than it ought to, but the cycle there is that we run update-seeds every 5 minutes on ubuntu-archive-toolbox, but ubuntu-archive-team.ubuntu.com currently only pulls from that machine to the web frontend hourly.  (There's an open RT to make that a push trigger instead.)
[21:46] <vorlon> utkarsh2102: the replacement for snakefruit.  Privileged machine, you don't have access
[21:47] <utkarsh2102> now that makes sense; I remember your RT around that
[21:47] <utkarsh2102> thanks
[21:47] <vorlon> we run a bunch of stuff on there that *isn't* privileged, should be split out, and should be wrapped in juju+mojo.  But it isn't yet.
[21:48]  * utkarsh2102 nods
[21:48] <utkarsh2102> if only I was given some spare cycles :)
[21:49] <utkarsh2102> out of curiosity, is germinate on ububtu-archive-toolbox different from the germinate call (germinate-update-metapackage) in ubuntu-meta?
[21:49] <utkarsh2102> and how so?
[21:50] <vorlon> arraybolt3: so anyway, in the worst case it might take around ~2h5m before a change is reflected on the frontend
[21:50] <vorlon> if everything's working as expected right now
[21:50] <vorlon> wait that's not right. 1h5m
[21:51] <arraybolt3> Makes sense.
[21:52] <vorlon> utkarsh2102: lp:ubuntu-archive-scripts, update-germinate. $HOME/germinate in turn is a checkout of lp:germinate
[21:55] <utkarsh2102> I see, so it's pure germinate
[21:55] <utkarsh2102> and the ubuntu-meta one works only for metapackages
[22:00] <utkarsh2102> vorlon: second, not every seed in ubuntu-seeds in turned into a metapackage. Even though the ./update script (germinate-update-metapackage) is called and they're germinated, but only the ones mentioned in d/control gets created, no?
[22:01] <utkarsh2102> that is, the usual packaging process :)
[22:03] <utkarsh2102> so the ./update script in ubuntu-meta only germinates the seeds that we want the meta-packages for (that is, by mentioning it somewhere? d/control? idk :/)
[22:03] <vorlon> utkarsh2102: debian/control is itself generated
[22:04] <vorlon> the seed pods contain the information about which seeds should be turned into metapackages
[22:05] <utkarsh2102> oh wow! TIL!
[22:05] <utkarsh2102> where's this "seed pod"?
[22:05] <vorlon> utkarsh2102: that's the branch that contains the seeds
[22:05] <vorlon> (not a frequently used name but we have no other name for it)
[22:07] <utkarsh2102> hah!
[22:07] <utkarsh2102> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/?h=lunar I suppose?
[22:07] <utkarsh2102> where exactly do we store that information (to turn seeds to metapackages)
[22:08] <vorlon> cjwatson: huh do you remember why you changed run-proposed-migration (...10 years ago) to checkout lp:auto-package-testing? I don't find anything using this checkout
[22:09] <vorlon> cjwatson: includes references to jenkins :)
[22:12] <vorlon> utkarsh2102: maybe I'm a liar about debian/control being autogenerated hmm
[22:12] <utkarsh2102> yes, I was reallllyyyyy surprised about that!
[22:12] -queuebot:#ubuntu-release- New binary: ubuntustudio-look [amd64] (lunar-proposed/universe) [23.04.1] (ubuntustudio)
[22:13] <Eickmeyer> Hey look! Wallpapers! ^ :)
[22:13] <Eickmeyer> (pun slightly intended)
[22:14] <vorlon> utkarsh2102: yeah looks like we have to manually update debian/control and update.cfg
[22:14] <utkarsh2102> yep
[22:15] <utkarsh2102> so we update the two things there, run the update script and there, we have the new meta-package, correct?
[22:16] <vorlon> yes
[22:16] <utkarsh2102> sweet
[22:17] <utkarsh2102> is there a git repository for ubuntu-meta where you push to?
[22:17] <utkarsh2102> or is it just something you have locally?
[22:17] <utkarsh2102> because https://git.launchpad.net/ubuntu/+source/ubuntu-meta/log/?h=ubuntu/lunar is just imports of the uploads
[22:17] <utkarsh2102> I'd like to see git log if that's available somewhere
[22:19] <vorlon> it's not pushed. the uploads are the history
[22:20] <vorlon> there's not going to be any complicated history there.  upload-level granularity is pretty complete
[22:21] <utkarsh2102> noted, thanks! \o/
[22:24] <utkarsh2102> vorlon: third, I see a lot of seeds referencing the meta-packages themselves. How does that really work? I mean, I am super curious to understand what's happening behind the scenes?
[22:25] <utkarsh2102> how can the seed depend on the metapackage when there isn't one yet :)
[22:25] <utkarsh2102> for eg: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/desktop-minimal#n176
[22:25] <utkarsh2102>  * ubuntu-desktop-minimal # metapackage for everything here
[22:26] <vorlon> utkarsh2102: everything that uses germinate ignores missing packages
[22:27] <utkarsh2102> then why do we even mention it there? what's the purpose of that? for the subsequent runs?
[22:27] <vorlon> you'll find plenty of packages in the seeds that no longer exist; nothing enforces their presence at build time and we have no process for auditing the seeds to remove them
[22:27] <vorlon> utkarsh2102: it's used to set the task header on the metapackage itself
[22:27] <cjwatson> vorlon: I very much do not, sorry!
[22:28] <vorlon> it would be silly if livecd-rootfs used task_install to install the ubuntu-desktop task and this failed to include the metapackage
[22:28] <vorlon> cjwatson: ok then I'll try deleting it!
[22:29] <vorlon> cjwatson: last commit was by pitti in 2015
[22:29] <vorlon> utkarsh2102: (otoh there's growing consensus that it's silly to use the task field at all for installing packages in livecd-rootfs and we are angling to stop doing that next cycle)
[22:30] <cjwatson> vorlon: I think that was probably the first attempt to integrate autopkgtest into p-m
[22:31] <cjwatson> And I'm not sure I properly understood it at the time either
[22:32] <utkarsh2102> vorlon: so IOW, having meta-packages mentioned in the seeds themselves is going to be moot from next cycle onward?
[22:32] <vorlon> utkarsh2102: that's my expectation yes
[22:33] <utkarsh2102> okeydoke, thank you!
[22:33] <utkarsh2102> vorlon: next, are you OK with calling the common seed as server-cloud-minimal-common? :)
[22:33] <vorlon> oh god
[22:33] <utkarsh2102> (you know the history behind that request :))
[22:34] <utkarsh2102> or I'll let it be, when you review the spec, please add a comment around that :)
[22:36] <vorlon> utkarsh2102: my understanding is that the 'common' there refers to the fact that it's common to both baremetal server and cloud images.  Let it be either server-minimal-common or server-cloud-minimal, not server-cloud-hyphen-minimal-common-ampersand
[22:38] <utkarsh2102> noted, I'll bring this up within CPC. Hopefully we can agree on server-cloud-minimal.
[22:47] <utkarsh2102> vorlon: lastly, and also very stupid, some people suggested adding comments in the Task-* fields; for eg: `Task-Seeds: server-cloud-minimal  # this is a comment`. Do you know, at the top of your head, if those comments are allowed like that in the Tasks-* fields?
[22:51] <vorlon> utkarsh2102: not a clue
[22:51] <utkarsh2102> hehe, danke
[23:04] <utkarsh2102> vorlon: this is the last, for now :P
[23:04] <utkarsh2102> if my seed has
[23:04] <utkarsh2102>  Task-Seeds: server-cloud-minimal
[23:04] <utkarsh2102> and   * feature: no-follow-recommends
[23:05] <utkarsh2102> will it at least have the Recommends which are explicitly mentioned in the Task-Seeds seed?
[23:05] <vorlon> I do not know
[23:05] <utkarsh2102> a hunch?
[23:06] <vorlon> utkarsh2102: useless for me to guess in this context
[23:06] <vorlon> run it and see
[23:07] <utkarsh2102> okeydoke, noted. Thank youuuu!
[23:07] <utkarsh2102> for answering all the questions :)
[23:12] <vorlon> bdmurray: so why do we have a checkout of lp:ubuntu-bugpatterns under public_html https://ubuntu-archive-team.ubuntu.com/bugpatterns
[23:12] <vorlon> make that https://ubuntu-archive-team.ubuntu.com/bugpatterns/
[23:28] <vorlon> bdmurray: I guess the answer on this is bugpatterns.xml?
[23:37] <tillkamppeter> @vorlon, I have uploaded a cups-browsed package (cups-browsed SOURCE package should be still in Universe) and get this rejection: https://paste.ubuntu.com/p/kjb9q5dfFF/ The version before I could upload without problem. MIR is bug 2003259
[23:38] <tillkamppeter> It says "Signer is not permitted to upload to the component 'main'.".
[23:38] <vorlon> tillkamppeter: do you have motu rights or PPU rights?
[23:39] <tillkamppeter> I have MOTU rights, so I can upload arbitrary packages into Universe and I have PPU rights to upload printing/scanning-related packages into Main.
[23:40] <vorlon> tillkamppeter: then perhaps this is a package that's not in your PPU set?
[23:41] <vorlon> tillkamppeter: confirmed that it doesn't show up for you in https://ubuntu-archive-team.ubuntu.com/archive-permissions/individuals
[23:41] <tillkamppeter> @vorlon, the cups-browsed SOURCE package should still be in Universe (MIR is not yet "Fix Released"), so I should have upload rights via MOTU, I could upload the earlier versions of the very same source package (2.0~b2-0ubuntu4).
[23:42] <vorlon> tillkamppeter: I see cups-browsed having been promoted to main in -proposed
[23:43] <tillkamppeter> @vorlon, source package or binary package?
[23:43] <vorlon> tillkamppeter: possibly because it was a source split and therefore a source-only promotion so I promoted it without worrying about an MIR
[23:43] <vorlon> it quite clearly should be added to your ppu set but I have to remember how to do that
[23:44] <tillkamppeter> OK, Meaning that cups-browsed is fully in Main now. Who can update my PPU list to reflect this source split (add libcupsfilters, libppd, and cups-browsed)?
[23:44] <vorlon> I *can* update it but I'm not sure if the DMB cares about being consulted before I d
[23:44] <vorlon> o
[23:45] <tillkamppeter> @vorlon and once on it, pappl, pappl-retrofit, cpdb-libs, cpdb-backend-cups, and cpdb-backend-file need to get added to my list, too.
[23:46] <vorlon> utkarsh2102, kanashiro[m], rbasak, teward, bdmurray ^^ do you need any sort of process before I add packages to tillkamppeter's PPU acl that have been split out of source packages he already had PPU on?
[23:46] <vorlon> tillkamppeter: I'm definitely not adding packages to the PPU list that *aren't* a result of a source split, without DMB approval
[23:47] <utkarsh2102> vorlon: I don’t think so. A mail to devel-permissions would be good I think.
[23:47] <tillkamppeter> OK, so for the pappl* and cpdb* we wait for the answer of DMB then ...
[23:47] <utkarsh2102> tillkamppeter: you have that :)
[23:47] <utkarsh2102> but feel free to just do that and send an fyi on the list.
[23:48] <tillkamppeter> @utkarsh2102, what do you mean now?
[23:49] <utkarsh2102> I meant, vorlon can add those packages to your PPU ACL and then send an FYI on the devel-permissions mailing list.
[23:49] <utkarsh2102> or you could request it there and someone can do it and reply. Either works.
[23:49] <tillkamppeter> OK, @vorlon tell me when you have done it.
[23:49] <vorlon> tillkamppeter: AIUI libppd was not split out of an existing source package you had ppu on but is a replacement for the old libppd source.  I think that one needs to go through the DMB process
[23:49] <utkarsh2102> But I think the former is faster.
[23:50] <utkarsh2102> yep.
[23:50] <vorlon> I will add cups-browsed and libcupsfilters to your ACL and email the DMB
[23:50] <tillkamppeter> @vorlon, libppd is split off from CUPS. It contains all PPD support functionality of CUPS.
[23:52] <vorlon> tillkamppeter: libppd> how am I to know this?
[23:52] <vorlon> tillkamppeter: cups-browsed, libcupsfilters are added to your acl
[23:52] <vorlon> tillkamppeter: for the others, please email the DMB and I can add when they've signed off
[23:53] <tillkamppeter> @vorlon I have written about this in the MIR, bug 2003259
[23:55] <tillkamppeter> @vorlon,.cups-browsed got accepted now.
[23:56] <tillkamppeter> @vorlon, so I have to mail to devel-permissions@ubuntu.com for asking for the PPU permissions?
[23:57] <teward> *appears with DMB hat on*
[23:57] <teward> i have no issue with Vorlon assigning rights to source packages broken out of source packages you *already* had PPU access on
[23:57] <teward> but if there's things that are now split that you *didn't* have upload rights to previously, then no, you have to go through the PPU application process again for the new stuff
[23:58] <teward> (case in point for me if I didn't have my coredev rights, nginx now has a dozen libnginxmod source packages incoming from Debian, they were part of src:nginx, but my PPU in theory could be extended to all the things that were now split out of it)
[23:58] <teward> (i had nginx PPU before I had coredev)
[23:58] <teward> this is my current understanding of our policies
[23:59] <teward> so reading scrollback: