[00:00] <teward> `libppd` *new* is a replacement for src:libppd.  you did not have upload rights to `src:libppd` initially.  Whether it split from cups or not, since this is still techincally `src:libppd` (even though it's replaced and not, say, libppdng for a 'next gen' version), I'd say you have to apply for libppd with justification as to why *again* to extend your access to that
[00:00] <teward> tillkamppeter: basically, yes, you have to mail and request PPU rights for src:libppd
[00:01] <teward> and put yourself on the DMB agenda for a day that is not already taken by someone who is applying for any kind of rights
[00:02] <teward> *returns to the shadows to poke some things*
[00:10] <jbicha> teward: extending ppu to similar packages might be able to be handled by email without attending a meeting. Is that correct?
[00:14] <tillkamppeter> @jbicha, for me it was all the time the case that I have asked by e-mail and they had granted me the rightts. I did not have to wait for the next meeting slot.
[00:14] <tillkamppeter> @teward ^^
[00:15] <tillkamppeter> I also remeber that I got granted the new packages I asked for by the Technical Board (and there seb128 is member currently ...).
[00:23] <tillkamppeter> Thanks a lot, @vorlon @utkarsh2102 @teward @jbicha I will talk with seb128 tomorrow how I will have to proceed for updating my PPU list.
[00:32] <teward> jbicha: correct, but it requires an email to be sent to the DMB
[00:33] <tumbleweed> which was sent
[00:33] <teward> tumbleweed: i see an email to the dmb from vorlon giving an FYI, if tillkamppeter has sent his own request email then it hasn't arrived here yet
[00:34] <tumbleweed> catching up, your analysis seems reasonable enough
[00:35] <teward> tumbleweed: yeah if tillkamppeter wants ppu for libppd then they ahve to email in still with the request, DMB reserves the right to process the request via email and indirect vote, but if they assert that it be in a meeting, then it'll be in a meeting.  DMB's prerogative in both cases
[00:36] <tumbleweed> yep
[01:23] <jbicha> vorlon: the excuses page is corrupted starting at glibc
[01:34] <jbicha> it's cleared up
[01:38] -queuebot:#ubuntu-release- New binary: ubuntustudio-look [amd64] (lunar-proposed/universe) [23.04.2] (ubuntustudio)
[02:42] <vorlon> doko: cross-toolchain-base{,-ports} still build-depend on linux-source-5.19.0; I've gone ahead and removed that NBS package now
=== chris14_ is now known as chris14
=== arraybolt3_ is now known as arraybolt3
[04:44] <vorlon> xnox, apw: if these kernels in lunar-proposed are being superseded before by newer versions before release, removing them now is also easier than having to chase a bunch of NBS binaries...
[04:48] <vorlon> well, the rsync to the web frontend is clearly getting stuck somewhere; we've had 3 full successful p-m runs since the last one shown on the web from 4 hours ago
[05:20] -queuebot:#ubuntu-release- New: accepted ubuntustudio-look [amd64] (lunar-proposed) [23.04.1]
[05:20] -queuebot:#ubuntu-release- New: accepted ubuntustudio-look [amd64] (lunar-proposed) [23.04.2]
[06:54] <LocutusOfBorg> its sad that we can't see anymore britney logs
[07:05] <LocutusOfBorg> https://people.canonical.com/~ubuntu-archive/proposed-migration/log/lunar/
[07:05] <LocutusOfBorg> this page says: You don't have permission to access this resource.
[08:25] <xypron> I want to reproduce LP#2011744. Where did all the 22.04.1 images in https://cdimage.ubuntu.com/releases/22.04.1/release/ go?
[08:25] -ubottu:#ubuntu-release- Launchpad bug 2011744 in grub (Ubuntu) "grub-efi-riscv64-bin 2.06-2ubuntu7.1 makes D1 unbootable" [Undecided, New] https://launchpad.net/bugs/2011744
[08:59] <apw> vorlon, ack, thanks for the reminder.
[10:23] <cjwatson> utkarsh2102: those Task-* fields are parsed by a script in the tasksel source package - ubuntu-seeds.pl I think
[10:38] <utkarsh2102> cjwatson: oh! so given that we no longer populate tasks in tasksel and it's all history now, does that mean it's no longer relevant? can we drop those Tasks-* fields altogether?
[10:41] <cjwatson> utkarsh2102: It seems possible but I am WAY out of date on this stuff
[10:41] <utkarsh2102> understood!
[10:42] <cjwatson> utkarsh2102: (And also probably something to hold off on until near the start of a release cycle)
[10:42] <utkarsh2102> obviously :)
[10:42] <cjwatson> utkarsh2102: Oh, there's also stuff in lp:ubuntu-archive-publishing that parses those fields ...
[10:42] <utkarsh2102> aha
[10:43] <cjwatson> Maybe that's complexity that can be dropped if we're abandoning tasks, but it would certainly need to be looked at
[10:43] <utkarsh2102> so we can't drop them after all, can we?
[10:43] <cjwatson> IDK
[10:43] <cjwatson> These days I think my job is mostly providing historical information so that other people can make decisions :)
[10:44] <utkarsh2102> I might as well schedule a session in Prague :)
[10:45] <utkarsh2102> I, anyway, have a follow-up question then: if we want to inherit another seed (using something that's common to a couple of seeds), we generally seem to be using Tasks-Seeds: common-seed-name, is that moot?
[10:46] <utkarsh2102> and so all we need is the relationship of inheritance in STRUCTURE instead?
[10:47] <utkarsh2102> can we drop things like https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/desktop-minimal#n6
[10:48] <cjwatson> So Task-Seeds is/was a bit subtle
[10:48] <cjwatson> The idea of that was basically to handle cases where we needed to combine the dependency expansion of multiple seeds into a single task
[10:49] <cjwatson> e.g. we needed desktop-common for seed management reasons but we didn't want to expose it as a task, that sort of thing
[10:50] <cjwatson> If tasks are going away then it shouldn't be needed - but again, Task-Seeds is looked at by lp:ubuntu-archive-publishing, so that would need to be considered as well as tasksel
[10:50] <utkarsh2102> ooooof, hahaha
[10:51] <utkarsh2102> okay, so Tasks-Seeds is still somewhat respected
[10:51] <utkarsh2102> not the other Tasks-* fields
[10:51] <utkarsh2102> is that a correct TL;DR?
[10:52] <cjwatson> utkarsh2102: Not quite, as I say u-a-p considers several of them
[10:52] <cjwatson> utkarsh2102: Might be best to briefly familiarize yourself with its code
[10:52] <utkarsh2102> ah, okay
[11:02] <utkarsh2102> you're right, I can see traces of methods parsing tasks-* fields
[11:38] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.765.19 => 2.765.20] (desktop-core, i386-whitelist)
[11:41] <sil2100> tjaalton: heey!
[11:41] <sil2100> tjaalton: I'm looking for someone to review my livecd-rootfs upload for jammy - would you have a moment?
[11:41] <sil2100> It's basically only image-building stuff
[11:58] -queuebot:#ubuntu-release- New binary: cups-browsed [amd64] (lunar-proposed/main) [2.0~b4-0ubuntu2] (no packageset)
[12:16] <tjaalton> sil2100: sure thing
[12:18] -queuebot:#ubuntu-release- New: accepted cups-browsed [amd64] (lunar-proposed) [2.0~b4-0ubuntu2]
[12:31] <ricotz> tjaalton, hey, I am hoping you can take a look at this too https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2009354
[12:31] -ubottu:#ubuntu-release- Launchpad bug 2009354 in libreoffice (Ubuntu Kinetic) "[SRU] libreoffice 7.4.6 for kinetic" [High, Incomplete]
[12:57] <sil2100> tjaalton: thanks :)
[13:12] <sil2100> tjaalton: if anything, those changes are not really relevant for devel, only jammy, but I do keep ubuntu/master up-to-date with those
[14:48] <tjaalton> yeah I'm trying to recover my desktop after upgrade to lunar.. then I'll have a look :)
[14:54] <sil2100> :D
[14:56] <vorlon> xypron: https://old-releases.ubuntu.com/releases/jammy/
[14:57] <xypron> thx vorlon
[14:59] <vorlon> LocutusOfBorg: https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/lunar/ - it's a strange error, but effectively the problem is that there's a dangling symlink in the path.  The process running apache now rsyncs from the actual backend, and log is a symlink to a directory under proposed-migration's working directory so it doesn't actually come with when we rsync.  I think I should be
[14:59] <vorlon> able to reverse the link there and be ok...
[15:00] <LocutusOfBorg> thanks!
[15:00] <LocutusOfBorg> I find that link really useful
[15:01] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.765.20]
[15:02] <vorlon> LocutusOfBorg: I think I've done the needful fs dance, now it just needs to rsync (which will take longer because it's a LOT of historical data)
[15:03] <LocutusOfBorg> thanks^2
[15:04] <vorlon> (how much historical data? oh, 197G)
[15:05] <vorlon> including hirsute and impish, let's prune those now
[15:06] <vorlon> well this is a treat, why does bionic have 100G of logs when *xenial* only has 32G
[15:07] <vorlon> ahahahaha it's because the kernel matrix exploded
[15:08] <vorlon> so the logs include lots of information about a huge and increasing number of NBS packages
[15:26] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (kinetic-proposed) [2.23.1-0ubuntu3.1]
[15:27] <vorlon> wow what wants to pull libgpm2 up to priority: standard
[15:27] <vorlon> I don't think I've used gpm in 20 years
[15:29] -queuebot:#ubuntu-release- Unapproved: rejected squid [source] (kinetic-proposed) [5.6-1ubuntu3.1]
[15:31] -queuebot:#ubuntu-release- Unapproved: accepted squid [source] (kinetic-proposed) [5.6-1ubuntu3.1]
[15:33] <vorlon> tjaalton: on LP: #2008755 you mention test builds of the llvm-dependent mesa, but there's nothing in the SRU test case about it. What testing is happening / must happen to make sure mesa isn't mis-built?
[15:33] -ubottu:#ubuntu-release- Launchpad bug 2008755 in llvm-toolchain-15 (Ubuntu Kinetic) "[SRU] Upgrade to 15.0.7 on Kinetic and Jammy" [Undecided, In Progress] https://launchpad.net/bugs/2008755
[15:34] <vorlon> tjaalton: somewhere I still have an open bug report about the armhf regression that was caused by a mesa rebuild but only caught on rebuild of a dependent package, right before our release... :)
[15:38] <vorlon> seb128, sil2100: I've reverted the hack for posting Ubuntu focal images to a different product under the ISO tracker, on the assumption that the images with the targeted fix isn't going to need respun again.  http://iso.qa.ubuntu.com/qatracker/milestones/443/builds/274185/testcases doesn't have any test results yet tho
=== arraybolt3_ is now known as arraybolt3
[15:39] <seb128> ack
[15:39] <sil2100> o/
[15:40] <sil2100> Yeah, I sent a call-for-testing reminder in the morning, I might run some tests during the weekend
[15:44] <vorlon> tjaalton: I actually can't find an open bug anymore for the mesa/armhf regression that was only detected by a build-time test suite, so presumably that's been fixed to now work as an autopkgtest.  But that autopkgtest would only be triggered on an upload of mesa, not the upload of llvm-toolchain-15... so there's a risk that an SRU of mesa later will uncover issues with 15.0.7.  But you're the
[15:44] <vorlon> expert on all this so I'm ok with the assumed risk if you are
[15:45] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-15 [source] (kinetic-proposed) [1:15.0.7-0ubuntu0.22.10.1]
[15:46] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-15 [source] (jammy-proposed) [1:15.0.7-0ubuntu0.22.04.1]
[15:49] <orndorffgrant> Hello! We're hoping to get in one more u-a-t release before beta freeze for lunar - I have an FFe bug up at LP: #2011757 if someone has time to take a look. Please let me know if we need anything else
[15:49] -ubottu:#ubuntu-release- Launchpad bug 2011757 in ubuntu-advantage-tools (Ubuntu) "[FFe] ubuntu-advantage-tools 27.14" [Undecided, New] https://launchpad.net/bugs/2011757
[15:52] <tillkamppeter> @vorlon, did you try the cupsfilter utility on ppc64el?
[15:53] <vorlon> tillkamppeter: yes, I sent messages on IRC about it yesterday.  I reproduced errors, and they persisted even when building all of libppd, libcupsfilter, and cups-filters with -O2 instead of -O3
[15:53] <vorlon> tillkamppeter: so I'm looking for guidance here on how to reduce this to a minimal test case.  How can I invoke these filters manually instead of through cupsd?
[15:54] <vorlon> tillkamppeter: my concern is, even though foo2zjs has the only ppds for which this is failing, I don't know how deep the breakage in the printing stack is
[15:55] -queuebot:#ubuntu-release- Unapproved: rejected wireguard [source] (kinetic-proposed) [1.0.20210914-1ubuntu2.22.10.0]
[15:56] <tillkamppeter> @vorlon, I have a meeting now and in 1 hour from now I can give you example command lines with cupsfilter, also tell you how to invoke a single filter manually.
[15:56] <vorlon> tillkamppeter: thanks
[16:11] <tjaalton> vorlon: I've pushed current mesa versions to the ppa for test-building. it was actually zixing who wrote the bug description, so maybe I should've improved it a bit to cover this properly
[16:12] <vorlon> tjaalton: right - a test build of mesa doesn't by itself provide the same level of coverage as the autopkgtests of mesa's reverse-dependencies do
[16:12] <tjaalton> true
[16:13] <tjaalton> I'd say llvm itself is pretty well battle-tested, at least when it comes to point-releases
[16:13] <vorlon> tjaalton: anyway, I've accepted it, on the grounds that the autopkgtests should protect us from regressions on the next mesa upload, and if you want more testing before that, you are more than capable of doing so :)
[16:13] <tjaalton> so 15 at this point at least is stable
[16:16] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (kinetic-proposed) [1:19.0.0-0ubuntu1.1]
[16:17] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (jammy-proposed) [1:18.0.0-0ubuntu1.1]
[16:27] -queuebot:#ubuntu-release- Unapproved: rejected smc-tools [source] (kinetic-proposed) [1.7.0-0ubuntu1.22.10.1]
=== mateus is now known as mateus-morais
[16:31] <vorlon> lvoytek: SRU paperwork on LP: #2003586 mentions a test for a fix for LP: #2006972 but that bug is not mentioned in the changelog
[16:31] -ubottu:#ubuntu-release- Launchpad bug 2003586 in bind9 (Ubuntu Kinetic) "MRE Updates 9.18.12 / 9.16.36" [Undecided, In Progress] https://launchpad.net/bugs/2003586
[16:31] -ubottu:#ubuntu-release- Launchpad bug 2006972 in bind9 (Ubuntu Jammy) "bind9 can't load preinstalled plugins" [Undecided, In Progress] https://launchpad.net/bugs/2006972
[16:32] <vorlon> lvoytek: (for kinetic - I haven't seen jammy yet)
=== mateus is now known as mateus-morais
[16:41] <vorlon> lvoytek: I've dropped the pointers to the other tests from the description of LP: #2003586, this is redundant as we pick up those references directly from debian/changelog.  But that still leaves the question of why LP: #2006972 is referenced here but isn't in the changelog.  I'll cross-check jammy real quick
[16:41] -ubottu:#ubuntu-release- Launchpad bug 2003586 in bind9 (Ubuntu Kinetic) "MRE Updates 9.18.12 / 9.16.36" [Undecided, In Progress] https://launchpad.net/bugs/2003586
[16:41] -ubottu:#ubuntu-release- Launchpad bug 2006972 in bind9 (Ubuntu Jammy) "bind9 can't load preinstalled plugins" [Undecided, In Progress] https://launchpad.net/bugs/2006972
[16:41] <tillkamppeter> @vorlon, I am a back a little bit earlier. Tim, our new Desktop Team director, also told, meetings should not take unnecessarily long ... So I can give you the example command lines now.
[16:41] <vorlon> lvoytek: ok it's there - that explains
[16:42] <vorlon> tillkamppeter: perfect, thank you
[16:44] <tillkamppeter> @vorlon, the printer model/its driver are described by the PPD file, the one you use for creating the CUPS queue. In this PPD there are one or more lines `*cupsFilter: ...` or `*cupsFilter2: ...`.
[16:45] <tillkamppeter> These lines descibe which filter specific to the printer has to be called, this filter is the actual driver, and which input format (a format which CUPS or cups-filters must be able to create, this filter requires.
[16:45] <vorlon> tillkamppeter: I haven't located the actual ppd files however.  'foo2zjs:0/ppd/foo2zjs/Dell-1355.ppd' seems to generate it dynamically?
[16:46] <tillkamppeter> There can be more than one such line, to have alternatives for different input formats.
[16:46] <vorlon> they're present in the foo2zjs source
[16:46] <vorlon> I guess I can pull it from there
[16:47] <vorlon> so I have:
[16:47] <vorlon> *cupsFilter:    "application/vnd.cups-postscript 100 foomatic-rip"
[16:47] <vorlon> *cupsFilter:    "application/vnd.cups-pdf 0 foomatic-rip"
[16:47] <vorlon> and the inputs in the test are pdf
[16:47] <tillkamppeter> Yes, this is a so-called PPD URI or driver URI. With this the PPD gets dynamically generated. I had to do it this way many years ago as we had the distro on a CD and only the PPDs were already more than 700 MB ...
[16:47] <vorlon> do I just feed the pdf to foomatic-rip on stdin?
[16:49] <vorlon> that doesn't seem to work
[16:49] <tillkamppeter> You run `/usr/lib/cups/driver/foo2zjs list` to see all available PPD URIs of foo2zjs and `/usr/lib/cups/driver/foo2zjs cat <PPD URI>` to generate the PPD file on stdout.
[16:49] <vorlon> output: https://paste.ubuntu.com/p/QRSgTJNY7Q/
[16:51] <tillkamppeter> You cannot run a CUPS filter with just an input file on the command line. It needs to know what the printer is.
[16:52] <tillkamppeter> The PPD tells that foomatic-rip is the driver filter, but the driver filter needs the PPD to know which of the many models it supports is actually used.
[16:52] <vorlon> ok
[16:52] <tillkamppeter> Also a CUPS filter has a certain command line syntax (run `man filter`).
[16:52] <vorlon> foomatic-rip -P adt-test-foo2zjs-0 < /usr/share/cups/data/default-testpage.pdf succeeded but gave no output
[16:52] <vorlon> ... because this is the command that reproduces the bug
[16:53] <vorlon> ok perfect, thanks
[16:53] <vorlon> I can work with that now
[16:53] <tillkamppeter> So fo the failure we have two places where it can happen: Once, in the filter chain from the input format to the format the driver needs, and second, in the driver.
[16:54] <tillkamppeter> Do you have a print queue names adt-test-foo2zjs-0 on your system and is it with a foo2zjs PPD?
[16:55] <tillkamppeter> You must know that foomatic-rip has 2 modes, it can be used as CUPS filter or as stand-alone spooler-less printing utility.
[16:56] <tillkamppeter> To run foomatic-rip correctly and to be absolutely sure that it is used as under CUPS, do
[16:56] <vorlon> ok.  I've confirmed good output for the files that are shown to work, and empty output for the known failing input, so I can run with it from here
[16:57] <tillkamppeter> cat <input PDF file> | PPD=<PPD file> /usr/lib/cups/filter/foomatic-rip 1 1 1 1 '' > out
[16:58] <tillkamppeter> @vorlon, for confirming, please try this last command line.
[16:58] <vorlon> tillkamppeter: yep, same thing
[16:58] <tillkamppeter> @vorlon so if you can confirm, this is great, as now we know that it is on the driver level, in foomatic-rip.
[16:59] <vorlon> oh, except that gives a bunch of other output on stderr
[17:00] <vorlon> DEBUG: Calling FindDeviceById(cups-)
[17:00] <vorlon> DEBUG: Failed to send: org.freedesktop.ColorManager.NotFound:device id 'cups-' does not exist
[17:00] <vorlon> I'll stick with my existing reproducer
[17:02] <tillkamppeter> Now it can be foomatic-rip itself, which is part of cups-filters, or any program which foomatic-rip call: Ghostscript, or some part of foo2zjs, or some other CUPS filter which foomati-rip could call.
[17:03] <tillkamppeter> Also each program foomatic-rip call, including the binaries of foo2zjs use libraries, so it can also happen athat the binaries of foo2zjs did not change but some library has a change which breaks it.
[17:03] <tillkamppeter> @vorlon, it is right to stick with the reproducer, please continue with it for now.
[17:04] <tillkamppeter> foomatic-rip is very verbose, in normal use CUPS manages this flood of logging, on manual call you see everything.
[17:04] <vorlon> after capturing the input file that's fed to gs, I've done https://paste.ubuntu.com/p/ntqkp3hpnB/.  Looks like valid output to me?
[17:05] <tillkamppeter> Now you can also see what foomatic-rip is doing. Especially do not worry about any failures of getting color profiles from colord. If there are none, printing still happens normally, using standard sRGB or sGray profiles which come with Ghostscript.
[17:05] <vorlon> (valid but empty, as the input file /usr/share/cups/data/default-testpage.pdf is not empty)
[17:07] <vorlon> hmm hmm
[17:08] <vorlon> possibly that's a wrong gs pipeline
[17:08] <vorlon> and ghostscript isn't what's changed anyway
[17:09] <tillkamppeter> Yes, this is the wrong one, foomatic-rip does also preparative tasks with Ghostscript, like counbting pages, determining page sizes, ... Also scripts of foo2zjs could run Ghostscript more than once.
[17:09] <tillkamppeter> I do not actually know all the magic of foo2zjs as it worked all the time, only now it ceased to work on ppc64el ...
[17:11] <tillkamppeter> Can you tell me which printer the reproducer case for you is?
[17:11] <vorlon> I'm able to get a failure with foo2zjs:0/ppd/foo2zjs/Dell-1355.ppd
[17:11] <vorlon> which didn't show failures on the autopkgtest infra
[17:11] -queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (kinetic-proposed) [1:9.18.12-0ubuntu0.22.10.1]
[17:12] <vorlon> but it's definitely a regression when upgrading cups-filters from -proposed
[17:14] <tillkamppeter> I had observed it with the 2 Epsons and you now with the Dell 1355, all using the sub-driver foo2hbpl2 ...
[17:16] <tillkamppeter> The PPD contains `*FoomaticRIPCommandLine: "foo2hbpl2-wrapper %A"`. This means that the program foo2hbpl2-wrapper is called and PostScript is fed into it, foomatic-rip taking care of converting incoming PDF to PostScript at first.
[17:18] <tillkamppeter> So we have again two places where the content of the input file can get lost, either fopomatic-rip calling something to turn PDF into PostScript (which is mostly done only in foo2zjs, most other foomatic-rip-based drivers use Ghostscript and therefore accept PDF right away).
[17:18] <vorlon> well, capturing the gs output to a file and feeding it to foo2hbpl2-wrapper gives me output which appears to be proper PJL
[17:20] <tillkamppeter> Or it is in the driver itself, the script foo2hbpl2-wrapper combined with the binary compiled from foo2hbpl2.c.
[17:20] -queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (jammy-proposed) [1:9.18.12-0ubuntu0.22.04.1]
[17:21] <tillkamppeter> So if you dissect things and try to call parts separately you see now that the bug does not appear any more.
[17:21] <vorlon> that's currently what I'm finding yes
[17:21] <tillkamppeter> so it seems that somehow we need to keep the foomatic-rip harness.
[17:22] <vorlon> tillkamppeter: oh but also, in an strace I don't see it calling foo2hbpl2-wrapper.  Should I expect it to exec this or should I expect foomatic-rip to be implementing this in-line?
[17:23] <tillkamppeter> Write a mini script which simply saves stdin in a file, something like `cat - > /tmp/printout`. Now edit the PPD and replace foo2hbpl2-wrapper by the name of your mini script. Run the foomatic-rip command line again.
[17:23] <tillkamppeter> Is /tmp/printout empty or a valid PostScript file?
[17:24] <vorlon> tillkamppeter: according to strace, the value of FoomaticRIPCommandLine is never invoked by foomatic-rip.  So I'll investigate there.
[17:24] <tillkamppeter> foomatic-rip always executes the program specified in *FoomaticRIPCommandLine, as long there is no error earlier.
[17:25] <tillkamppeter> Best is you run the command line I have given to you with the PPD and PDF which are the reproducer for me. Than you paste for me the command line itself and all console output it produces.
[17:26] <vorlon> yes the error seems to come from 'gs -q -dBATCH -dSAFER -dQUIET -dNOPAUSE -dNOINTERPOLATE -sPAPERSIZE=letter -g10200x6600 -r1200x600 -sDEVICE=pbmraw -dCOLORSCREEN -dMaxBitmap=500000000 -sOutputFile=|cat 1>&3 -_' which dies with a SIGPIPE
[17:28] <vorlon> sorry, that's the wrong commandline
[17:29] <vorlon> I meant gs -q -dNOPAUSE -dBATCH -sDEVICE=bbox -dDEVICEWIDTHPOINTS=1 -dDEVICEHEIGHTPOINTS=1 -_
[17:29] <tillkamppeter> @vorlon, the problem is the `-sOutputFile=|cat 1>&3` this only works in the script/program where you have ripped this line out from. You do not have file descriptor #3 on the command line.
[17:29] <vorlon> tillkamppeter: yes sorry I cut'n'pasted wrong
[17:30] <tillkamppeter> Replace it by `-sOutputFile=out`...
[17:31] <tillkamppeter> The second you gave me is for counting the pages. It outputs 2 lines for each page in the input file.
[17:32] <tillkamppeter> This one works for me (on amd64) exactly as you pasted it.
[17:33] <vorlon> yes, and standalone it will run fine - it's a sigpipe problem
[17:33] <vorlon> so definitely shouldn't be related to -O3 but certainly can be architecture-dependent
[17:33] <vorlon> on is specific to foomatic-rip but could happen arbitrarily with any driver
[17:35] <tillkamppeter> Now I want to ask you to do the following: Run the command line `cat <input PDF file> | PPD=<PPD file> /usr/lib/cups/filter/foomatic-rip 1 1 1 1 '' > out 2> log` and paste for me your exact command line, with the PPD and PDF you actually used, and make available to me the file `log`. The file `out` must be empty as we deal with your reproducer, please check this.
[17:37] <vorlon> # cat /usr/share/cups/data/default-testpage.pdf | PPD=/root/foo2zjs-20200505dfsg0/PPD/Dell-1355.ppd /usr/lib/cups/filter/foomatic-rip 1 1 1 1 '' > out 2> log
[17:37] <vorlon> yes, 'out' is empty
[17:38] <vorlon> Input is empty, outputting empty file.
[17:38] <vorlon> pdf-to-ps exited with status 1
[17:38] <vorlon> from log
[17:38] <tillkamppeter> Could you paste the whole log for me?
[17:39] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (kinetic-proposed) [1:7.4.6-0ubuntu0.22.10.1]
[17:39] <tillkamppeter> It seems that foomatic-rip's pdf-to-ps conversion fails ...
[17:39] <vorlon> https://paste.ubuntu.com/p/FkB6JXHJJj/
[17:40] <vorlon> I'm afk now for a bit, should have some breakfast
[17:42] <tillkamppeter> OK, @vorlon, I will ask you for further tests for after your breakfast ...
[17:43] <tillkamppeter> @vorlon, please ping me when you are back.
[17:50] <ricotz> vorlon, thank you!
[17:51] <tillkamppeter> @vorlon, could you run: cat /usr/share/cups/data/default-testpage.pdf | PATH="/usr/lib/cups/filter:${PATH}" PPD=/root/foo2zjs-20200505dfsg0/PPD/Dell-1355.ppd /usr/lib/cups/filter/foomatic-rip 1 1 1 1 '' > out 2> log
[17:54] <RikMills> britney logs now seem inaccessible
[17:54] <RikMills> https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/lunar/
[17:54] <RikMills> 404 forbidden
[17:54] <tillkamppeter> @vorlon, is `out` still empty? If `out` is non-empty, try with another printer (PPD file).
[17:54] <RikMills> *403
[18:00] <RikMills> also no new excuses since 9:21am
[18:17] <vorlon> tillkamppeter: I'm going to focus on the SIGPIPE question for a while.  I vaguely remember there being some differences in buffer handling on ppc64el vs other archs but don't remember what.  In any case it's a matter of tracking down the bug now in foomatic-rip's handling of the pipes that's causing this failure. running the scripts from
[18:17] <vorlon> https://unix.stackexchange.com/questions/11946/how-big-is-the-pipe-buffer certainly shows some differences. amd64: https://paste.ubuntu.com/p/x3SBHYVb9m/ ppc64el: https://paste.ubuntu.com/p/RC6tBBwd6x/
[18:18] <vorlon> RikMills: see discussion above with LocutusOfBorg.  I'm waiting on IS to dig into why the rsync is broken; and then once it's not broken there'll be a fair bit of data to transfer before this is fixed
[18:19] <ahasenack> just saw the words "rsync broken", there was a security update that changed its behavior somewhat
[18:19] <ahasenack> https://bugs.launchpad.net/bugs/2011622
[18:19] -ubottu:#ubuntu-release- Launchpad bug 2011622 in rsync (Ubuntu) "rsync 3.1.3-8ubuntu0.5 (CVE-2022-29154 patch) breaks remote brace interpretation" [Undecided, Invalid]
[18:20] <vorlon> ahasenack: well it was working as of 9:21am, so I don't think the timing lines up
[18:20] <ahasenack> ok
[18:20] <vorlon> either way, I need IS to dig into it :)
[18:20] <tillkamppeter> @vorlon, could you run my last suggested command line? I would like to know whether it works for you, as the first command line I gave you had a problem which masked the actual bug. Please run the command line, tell me whether `out` is still empty and paste `log` for me. Thanks.
[18:23] <vorlon> tillkamppeter: not right now, I'm head-down digging into the pipe error which I'm confident is the root cause.  You don't need to hang around on your Friday evening hand-holding me on the other stuff, if this doesn't lead to a solution I can ping you again on Monday
[18:28] <tillkamppeter> @vorlon No problem, you can ping me also today, do not need to wait for Monday if you run into some problem ...
[18:38] -queuebot:#ubuntu-release- Unapproved: accepted glance [source] (kinetic-proposed) [2:25.1.0-0ubuntu1]
[18:39] <vorlon> tillkamppeter: haha, now I've tickled things enough that I get good output when running under strace but it still fails when I don't
[18:45] <vorlon> tillkamppeter: HOWEVER. I have a fix for a definite issue and it looks like the foo2zjs test suite is passing now, so I'll upload if it finishes ok
[18:49] <vorlon> tillkamppeter: in the end, the bug itself doesn't look arch-specific to me, it just happens that the test suite trips it on ppc64el because of different buffer handling on that arch - but that a different-sized input pdf might trip it on other archs too. (Though I could be wrong about that.)
[18:50] <tillkamppeter> @vorlon So it is an upstream bug in foomatic-rip?
[18:51] <vorlon> tillkamppeter: yes - and my fix is looking good
[18:51] <vorlon> definitely gotten farther now in the foo2zjs testsuite
[18:52] <tillkamppeter> @vorlon, could you tell me already what upstream bug in foomatic-rip it is and your patch?
[18:54] <vorlon> tillkamppeter: I will shortly, just writing up the patch description
[18:55] <vorlon> also I think I've got an extraneous change in my patch so I want to re-test without it
[18:58] <tillkamppeter> @vorlon https://github.com/OpenPrinting/cups-filters
[18:59] <vorlon> yes
[18:59] -queuebot:#ubuntu-release- Unapproved: accepted glance [source] (jammy-proposed) [2:24.2.0-0ubuntu1]
[19:02] <tillkamppeter> @seb128 foo2zjs is solved! Thanks to @vorlon! He has investigated it on ppc64el with my instructions! PR on cups-filters coming soon!
[19:06] <vorlon> tillkamppeter: ok lol just realized my fix was incorrect and the test suite was passing because the version of foomatic-rip I was testing had a debug print statement in it that counted as "output". <facepalm> but I am getting closer
[19:34] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (kinetic-proposed) [2:21.1.0-0ubuntu1]
[19:38] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (kinetic-proposed) [17.2.5-0ubuntu0.22.10.2]
[19:41] <vorlon> tillkamppeter: ok, back to where I was: successful output under strace, no output when not under strace.
[19:47] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (jammy-proposed) [17.2.5-0ubuntu0.22.04.2]
[19:50] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.17-0ubuntu0.20.04.2]
[19:52] <vorlon> tillkamppeter: ok, got it!
[19:53] <vorlon> tillkamppeter: I'm going to upload, and file the upstream PR in parallel
[19:58] <tillkamppeter> @vorlon, GREAT!!! I am looking forward ...
[19:58] <vorlon> tillkamppeter: https://github.com/OpenPrinting/cups-filters/pull/517
[19:58] -ubottu:#ubuntu-release- Pull 517 in OpenPrinting/cups-filters "fix a SIGPIPE error when calling gs" [Open]
[20:06] <tillkamppeter> @vorlon I have merged your PR now, thanks a lot.
[20:07] <vorlon> coreycb: fwiw 'adduser nova kvm' is idempotent, you don't have to wrap it in a check you can just call 'adduser nova kvm >/dev/null'
[20:08] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (kinetic-proposed) [3:26.1.0-0ubuntu2]
[20:12] <seb128> tillkamppeter, great!
[20:12] <seb128> vorlon, thanks for sorting it out!
[20:12] <vorlon> sure thing
[20:15] -queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (kinetic-proposed) [2.5.14+dfsg-0ubuntu0.22.10.2]
[20:21] <tillkamppeter> @vorlon, thanks a lot for all the work on this. Probably the occasional failures of foo2zjs autopkgtests on other architectures (which we had simply remedied by repeating the test) were caused by the same issue.. And good to know now that not only Windows users but also ppc64el Linux users have their old printers conserved!
[20:23] -queuebot:#ubuntu-release- Unapproved: accepted libidn [source] (jammy-proposed) [1.38-4ubuntu1]
[20:24] <vorlon> tillkamppeter: and this could affect any printer driver that was using foomatic-rip; not sure what others are out there
[20:29] <seb128> vorlon, hum, any idea about why update_excuses_by_team.html didn't update since 9utc?
[20:30] <vorlon> seb128: well empirically I can say that the rsync job between u-a-t.internal and the frontend box is not working.  But I flagged IS about it when I started my day and have had no action on it yet
[20:30] <seb128> vorlon, alright, thanks, I guess it's a sign I should call it a day!
[20:31] <vorlon> seb128: have a good weekend :)
[20:39] <seb128> thanks, you too!
[20:52] <tillkamppeter> @vorlon, seems that update_excuses is botched in general today?
[20:53] <tillkamppeter> @seb128, have a nice weekend! Now it seems that cups-filters 2.x is all sorted.
[20:57] <vorlon> tillkamppeter: yes, the rsync to the frontend is broken and I'm waiting on IS
[21:49] <LocutusOfBorg> jbicha, I fail to understand how gles is required in armhf, looks now they are building the embedded library statically on armhf
[21:49] <LocutusOfBorg> and upstream removed the binding here https://github.com/WebKit/WebKit/commit/d257ea20c5996ada3c009a6a2f4a639f92c0e2ca#diff-9b1b189b26c7de73601bea48390c0edfb383c0c87ace4e761057ca36fef34fe9
[21:49] -ubottu:#ubuntu-release- Commit d257ea2 in WebKit/WebKit "WebGL has a lot of #if USE(ANGLE) blocks, making it hard to maintain"
[21:49] <LocutusOfBorg> and surf autopkgtest fails because the GLESv2.so.foo is not found
[21:50] <LocutusOfBorg> I'm out of ideas