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 that00:00
tewardtillkamppeter: basically, yes, you have to mail and request PPU rights for src:libppd00:00
tewardand put yourself on the DMB agenda for a day that is not already taken by someone who is applying for any kind of rights00:01
teward*returns to the shadows to poke some things*00:02
jbichateward: extending ppu to similar packages might be able to be handled by email without attending a meeting. Is that correct?00:10
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:14
tillkamppeterI also remeber that I got granted the new packages I asked for by the Technical Board (and there seb128 is member currently ...).00:15
tillkamppeterThanks a lot, @vorlon @utkarsh2102 @teward @jbicha I will talk with seb128 tomorrow how I will have to proceed for updating my PPU list.00:23
tewardjbicha: correct, but it requires an email to be sent to the DMB00:32
tumbleweedwhich was sent00:33
tewardtumbleweed: 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 yet00:33
tumbleweedcatching up, your analysis seems reasonable enough00:34
tewardtumbleweed: 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 cases00:35
jbichavorlon: the excuses page is corrupted starting at glibc01:23
jbichait's cleared up01:34
-queuebot:#ubuntu-release- New binary: ubuntustudio-look [amd64] (lunar-proposed/universe) [23.04.2] (ubuntustudio)01:38
vorlondoko: cross-toolchain-base{,-ports} still build-depend on linux-source-5.19.0; I've gone ahead and removed that NBS package now02:42
=== chris14_ is now known as chris14
=== arraybolt3_ is now known as arraybolt3
vorlonxnox, 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:44
vorlonwell, 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 ago04:48
-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]05:20
LocutusOfBorgits sad that we can't see anymore britney logs06:54
LocutusOfBorgthis page says: You don't have permission to access this resource.07:05
xypronI 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/201174408:25
apwvorlon, ack, thanks for the reminder.08:59
cjwatsonutkarsh2102: those Task-* fields are parsed by a script in the tasksel source package - ubuntu-seeds.pl I think10:23
utkarsh2102cjwatson: 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:38
cjwatsonutkarsh2102: It seems possible but I am WAY out of date on this stuff10:41
cjwatsonutkarsh2102: (And also probably something to hold off on until near the start of a release cycle)10:42
utkarsh2102obviously :)10:42
cjwatsonutkarsh2102: Oh, there's also stuff in lp:ubuntu-archive-publishing that parses those fields ...10:42
cjwatsonMaybe that's complexity that can be dropped if we're abandoning tasks, but it would certainly need to be looked at10:43
utkarsh2102so we can't drop them after all, can we?10:43
cjwatsonThese days I think my job is mostly providing historical information so that other people can make decisions :)10:43
utkarsh2102I might as well schedule a session in Prague :)10:44
utkarsh2102I, 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:45
utkarsh2102and so all we need is the relationship of inheritance in STRUCTURE instead?10:46
utkarsh2102can we drop things like https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/desktop-minimal#n610:47
cjwatsonSo Task-Seeds is/was a bit subtle10:48
cjwatsonThe idea of that was basically to handle cases where we needed to combine the dependency expansion of multiple seeds into a single task10:48
cjwatsone.g. we needed desktop-common for seed management reasons but we didn't want to expose it as a task, that sort of thing10:49
cjwatsonIf 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 tasksel10:50
utkarsh2102ooooof, hahaha10:50
utkarsh2102okay, so Tasks-Seeds is still somewhat respected10:51
utkarsh2102not the other Tasks-* fields10:51
utkarsh2102is that a correct TL;DR?10:51
cjwatsonutkarsh2102: Not quite, as I say u-a-p considers several of them10:52
cjwatsonutkarsh2102: Might be best to briefly familiarize yourself with its code10:52
utkarsh2102ah, okay10:52
utkarsh2102you're right, I can see traces of methods parsing tasks-* fields11:02
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.765.19 => 2.765.20] (desktop-core, i386-whitelist)11:38
sil2100tjaalton: heey!11:41
sil2100tjaalton: I'm looking for someone to review my livecd-rootfs upload for jammy - would you have a moment?11:41
sil2100It's basically only image-building stuff11:41
-queuebot:#ubuntu-release- New binary: cups-browsed [amd64] (lunar-proposed/main) [2.0~b4-0ubuntu2] (no packageset)11:58
tjaaltonsil2100: sure thing12:16
-queuebot:#ubuntu-release- New: accepted cups-browsed [amd64] (lunar-proposed) [2.0~b4-0ubuntu2]12:18
ricotztjaalton, hey, I am hoping you can take a look at this too https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/200935412:31
-ubottu:#ubuntu-release- Launchpad bug 2009354 in libreoffice (Ubuntu Kinetic) "[SRU] libreoffice 7.4.6 for kinetic" [High, Incomplete]12:31
sil2100tjaalton: thanks :)12:57
sil2100tjaalton: if anything, those changes are not really relevant for devel, only jammy, but I do keep ubuntu/master up-to-date with those13:12
tjaaltonyeah I'm trying to recover my desktop after upgrade to lunar.. then I'll have a look :)14:48
vorlonxypron: https://old-releases.ubuntu.com/releases/jammy/14:56
xypronthx vorlon14:57
vorlonLocutusOfBorg: 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 be14:59
vorlonable to reverse the link there and be ok...14:59
LocutusOfBorgI find that link really useful15:00
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.765.20]15:01
vorlonLocutusOfBorg: 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:02
vorlon(how much historical data? oh, 197G)15:04
vorlonincluding hirsute and impish, let's prune those now15:05
vorlonwell this is a treat, why does bionic have 100G of logs when *xenial* only has 32G15:06
vorlonahahahaha it's because the kernel matrix exploded15:07
vorlonso the logs include lots of information about a huge and increasing number of NBS packages15:08
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (kinetic-proposed) [2.23.1-0ubuntu3.1]15:26
vorlonwow what wants to pull libgpm2 up to priority: standard15:27
vorlonI don't think I've used gpm in 20 years15:27
-queuebot:#ubuntu-release- Unapproved: rejected squid [source] (kinetic-proposed) [5.6-1ubuntu3.1]15:29
-queuebot:#ubuntu-release- Unapproved: accepted squid [source] (kinetic-proposed) [5.6-1ubuntu3.1]15:31
vorlontjaalton: 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/200875515:33
vorlontjaalton: 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:34
vorlonseb128, 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 tho15:38
=== arraybolt3_ is now known as arraybolt3
sil2100Yeah, I sent a call-for-testing reminder in the morning, I might run some tests during the weekend15:40
vorlontjaalton: 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 the15:44
vorlonexpert on all this so I'm ok with the assumed risk if you are15:44
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-15 [source] (kinetic-proposed) [1:15.0.7-0ubuntu0.22.10.1]15:45
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-15 [source] (jammy-proposed) [1:15.0.7-0ubuntu0.22.04.1]15:46
orndorffgrantHello! 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 else15:49
-ubottu:#ubuntu-release- Launchpad bug 2011757 in ubuntu-advantage-tools (Ubuntu) "[FFe] ubuntu-advantage-tools 27.14" [Undecided, New] https://launchpad.net/bugs/201175715:49
tillkamppeter@vorlon, did you try the cupsfilter utility on ppc64el?15:52
vorlontillkamppeter: 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 -O315:53
vorlontillkamppeter: 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:53
vorlontillkamppeter: 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 is15:54
-queuebot:#ubuntu-release- Unapproved: rejected wireguard [source] (kinetic-proposed) [1.0.20210914-1ubuntu2.22.10.0]15:55
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
vorlontillkamppeter: thanks15:56
tjaaltonvorlon: 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 properly16:11
vorlontjaalton: right - a test build of mesa doesn't by itself provide the same level of coverage as the autopkgtests of mesa's reverse-dependencies do16:12
tjaaltonI'd say llvm itself is pretty well battle-tested, at least when it comes to point-releases16:13
vorlontjaalton: 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
tjaaltonso 15 at this point at least is stable16:13
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (kinetic-proposed) [1:19.0.0-0ubuntu1.1]16:16
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (jammy-proposed) [1:18.0.0-0ubuntu1.1]16:17
-queuebot:#ubuntu-release- Unapproved: rejected smc-tools [source] (kinetic-proposed) [1.7.0-0ubuntu1.22.10.1]16:27
=== mateus is now known as mateus-morais
vorlonlvoytek: SRU paperwork on LP: #2003586 mentions a test for a fix for LP: #2006972 but that bug is not mentioned in the changelog16: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/200358616:31
-ubottu:#ubuntu-release- Launchpad bug 2006972 in bind9 (Ubuntu Jammy) "bind9 can't load preinstalled plugins" [Undecided, In Progress] https://launchpad.net/bugs/200697216:31
vorlonlvoytek: (for kinetic - I haven't seen jammy yet)16:32
=== mateus is now known as mateus-morais
vorlonlvoytek: 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 quick16: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/200358616:41
-ubottu:#ubuntu-release- Launchpad bug 2006972 in bind9 (Ubuntu Jammy) "bind9 can't load preinstalled plugins" [Undecided, In Progress] https://launchpad.net/bugs/200697216: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
vorlonlvoytek: ok it's there - that explains16:41
vorlontillkamppeter: perfect, thank you16:42
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:44
tillkamppeterThese 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
vorlontillkamppeter: I haven't located the actual ppd files however.  'foo2zjs:0/ppd/foo2zjs/Dell-1355.ppd' seems to generate it dynamically?16:45
tillkamppeterThere can be more than one such line, to have alternatives for different input formats.16:46
vorlonthey're present in the foo2zjs source16:46
vorlonI guess I can pull it from there16:46
vorlonso 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
vorlonand the inputs in the test are pdf16:47
tillkamppeterYes, 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
vorlondo I just feed the pdf to foomatic-rip on stdin?16:47
vorlonthat doesn't seem to work16:49
tillkamppeterYou 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
vorlonoutput: https://paste.ubuntu.com/p/QRSgTJNY7Q/16:49
tillkamppeterYou cannot run a CUPS filter with just an input file on the command line. It needs to know what the printer is.16:51
tillkamppeterThe 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
tillkamppeterAlso a CUPS filter has a certain command line syntax (run `man filter`).16:52
vorlonfoomatic-rip -P adt-test-foo2zjs-0 < /usr/share/cups/data/default-testpage.pdf succeeded but gave no output16:52
vorlon... because this is the command that reproduces the bug16:52
vorlonok perfect, thanks16:53
vorlonI can work with that now16:53
tillkamppeterSo 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:53
tillkamppeterDo you have a print queue names adt-test-foo2zjs-0 on your system and is it with a foo2zjs PPD?16:54
tillkamppeterYou must know that foomatic-rip has 2 modes, it can be used as CUPS filter or as stand-alone spooler-less printing utility.16:55
tillkamppeterTo run foomatic-rip correctly and to be absolutely sure that it is used as under CUPS, do16:56
vorlonok.  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 here16:56
tillkamppetercat <input PDF file> | PPD=<PPD file> /usr/lib/cups/filter/foomatic-rip 1 1 1 1 '' > out16:57
tillkamppeter@vorlon, for confirming, please try this last command line.16:58
vorlontillkamppeter: yep, same thing16: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:58
vorlonoh, except that gives a bunch of other output on stderr16:59
vorlonDEBUG: Calling FindDeviceById(cups-)17:00
vorlonDEBUG: Failed to send: org.freedesktop.ColorManager.NotFound:device id 'cups-' does not exist17:00
vorlonI'll stick with my existing reproducer17:00
tillkamppeterNow 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:02
tillkamppeterAlso 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:03
tillkamppeterfoomatic-rip is very verbose, in normal use CUPS manages this flood of logging, on manual call you see everything.17:04
vorlonafter 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:04
tillkamppeterNow 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:05
vorlonhmm hmm17:07
vorlonpossibly that's a wrong gs pipeline17:08
vorlonand ghostscript isn't what's changed anyway17:08
tillkamppeterYes, 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
tillkamppeterI do not actually know all the magic of foo2zjs as it worked all the time, only now it ceased to work on ppc64el ...17:09
tillkamppeterCan you tell me which printer the reproducer case for you is?17:11
vorlonI'm able to get a failure with foo2zjs:0/ppd/foo2zjs/Dell-1355.ppd17:11
vorlonwhich didn't show failures on the autopkgtest infra17:11
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (kinetic-proposed) [1:9.18.12-0ubuntu0.22.10.1]17:11
vorlonbut it's definitely a regression when upgrading cups-filters from -proposed17:12
tillkamppeterI had observed it with the 2 Epsons and you now with the Dell 1355, all using the sub-driver foo2hbpl2 ...17:14
tillkamppeterThe 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:16
tillkamppeterSo 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
vorlonwell, capturing the gs output to a file and feeding it to foo2hbpl2-wrapper gives me output which appears to be proper PJL17:18
tillkamppeterOr 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:20
tillkamppeterSo if you dissect things and try to call parts separately you see now that the bug does not appear any more.17:21
vorlonthat's currently what I'm finding yes17:21
tillkamppeterso it seems that somehow we need to keep the foomatic-rip harness.17:21
vorlontillkamppeter: 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:22
tillkamppeterWrite 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
tillkamppeterIs /tmp/printout empty or a valid PostScript file?17:23
vorlontillkamppeter: according to strace, the value of FoomaticRIPCommandLine is never invoked by foomatic-rip.  So I'll investigate there.17:24
tillkamppeterfoomatic-rip always executes the program specified in *FoomaticRIPCommandLine, as long there is no error earlier.17:24
tillkamppeterBest 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:25
vorlonyes 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 SIGPIPE17:26
vorlonsorry, that's the wrong commandline17:28
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
vorlontillkamppeter: yes sorry I cut'n'pasted wrong17:29
tillkamppeterReplace it by `-sOutputFile=out`...17:30
tillkamppeterThe second you gave me is for counting the pages. It outputs 2 lines for each page in the input file.17:31
tillkamppeterThis one works for me (on amd64) exactly as you pasted it.17:32
vorlonyes, and standalone it will run fine - it's a sigpipe problem17:33
vorlonso definitely shouldn't be related to -O3 but certainly can be architecture-dependent17:33
vorlonon is specific to foomatic-rip but could happen arbitrarily with any driver17:33
tillkamppeterNow 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:35
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> log17:37
vorlonyes, 'out' is empty17:37
vorlonInput is empty, outputting empty file.17:38
vorlonpdf-to-ps exited with status 117:38
vorlonfrom log17:38
tillkamppeterCould you paste the whole log for me?17:38
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (kinetic-proposed) [1:7.4.6-0ubuntu0.22.10.1]17:39
tillkamppeterIt seems that foomatic-rip's pdf-to-ps conversion fails ...17:39
vorlonI'm afk now for a bit, should have some breakfast17:40
tillkamppeterOK, @vorlon, I will ask you for further tests for after your breakfast ...17:42
tillkamppeter@vorlon, please ping me when you are back.17:43
ricotzvorlon, thank you!17:50
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> log17:51
RikMillsbritney logs now seem inaccessible17:54
RikMills404 forbidden17:54
tillkamppeter@vorlon, is `out` still empty? If `out` is non-empty, try with another printer (PPD file).17:54
RikMillsalso no new excuses since 9:21am18:00
vorlontillkamppeter: 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 from18:17
vorlonhttps://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:17
vorlonRikMills: 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 fixed18:18
ahasenackjust saw the words "rsync broken", there was a security update that changed its behavior somewhat18: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:19
vorlonahasenack: well it was working as of 9:21am, so I don't think the timing lines up18:20
vorloneither 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:20
vorlontillkamppeter: 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 Monday18:23
tillkamppeter@vorlon No problem, you can ping me also today, do not need to wait for Monday if you run into some problem ...18:28
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (kinetic-proposed) [2:25.1.0-0ubuntu1]18:38
vorlontillkamppeter: haha, now I've tickled things enough that I get good output when running under strace but it still fails when I don't18:39
vorlontillkamppeter: 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 ok18:45
vorlontillkamppeter: 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:49
tillkamppeter@vorlon So it is an upstream bug in foomatic-rip?18:50
vorlontillkamppeter: yes - and my fix is looking good18:51
vorlondefinitely gotten farther now in the foo2zjs testsuite18:51
tillkamppeter@vorlon, could you tell me already what upstream bug in foomatic-rip it is and your patch?18:52
vorlontillkamppeter: I will shortly, just writing up the patch description18:54
vorlonalso I think I've got an extraneous change in my patch so I want to re-test without it18:55
tillkamppeter@vorlon https://github.com/OpenPrinting/cups-filters18:58
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (jammy-proposed) [2:24.2.0-0ubuntu1]18:59
tillkamppeter@seb128 foo2zjs is solved! Thanks to @vorlon! He has investigated it on ppc64el with my instructions! PR on cups-filters coming soon!19:02
vorlontillkamppeter: 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 closer19:06
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (kinetic-proposed) [2:21.1.0-0ubuntu1]19:34
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (kinetic-proposed) [17.2.5-0ubuntu0.22.10.2]19:38
vorlontillkamppeter: ok, back to where I was: successful output under strace, no output when not under strace.19:41
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (jammy-proposed) [17.2.5-0ubuntu0.22.04.2]19:47
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.17-0ubuntu0.20.04.2]19:50
vorlontillkamppeter: ok, got it!19:52
vorlontillkamppeter: I'm going to upload, and file the upstream PR in parallel19:53
tillkamppeter@vorlon, GREAT!!! I am looking forward ...19:58
vorlontillkamppeter: https://github.com/OpenPrinting/cups-filters/pull/51719:58
-ubottu:#ubuntu-release- Pull 517 in OpenPrinting/cups-filters "fix a SIGPIPE error when calling gs" [Open]19:58
tillkamppeter@vorlon I have merged your PR now, thanks a lot.20:06
vorloncoreycb: 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:07
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (kinetic-proposed) [3:26.1.0-0ubuntu2]20:08
seb128tillkamppeter, great!20:12
seb128vorlon, thanks for sorting it out!20:12
vorlonsure thing20:12
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (kinetic-proposed) [2.5.14+dfsg-0ubuntu0.22.10.2]20:15
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:21
-queuebot:#ubuntu-release- Unapproved: accepted libidn [source] (jammy-proposed) [1.38-4ubuntu1]20:23
vorlontillkamppeter: and this could affect any printer driver that was using foomatic-rip; not sure what others are out there20:24
seb128vorlon, hum, any idea about why update_excuses_by_team.html didn't update since 9utc?20:29
vorlonseb128: 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 yet20:30
seb128vorlon, alright, thanks, I guess it's a sign I should call it a day!20:30
vorlonseb128: have a good weekend :)20:31
seb128thanks, you too!20:39
tillkamppeter@vorlon, seems that update_excuses is botched in general today?20:52
tillkamppeter@seb128, have a nice weekend! Now it seems that cups-filters 2.x is all sorted.20:53
vorlontillkamppeter: yes, the rsync to the frontend is broken and I'm waiting on IS20:57
LocutusOfBorgjbicha, I fail to understand how gles is required in armhf, looks now they are building the embedded library statically on armhf21:49
LocutusOfBorgand upstream removed the binding here https://github.com/WebKit/WebKit/commit/d257ea20c5996ada3c009a6a2f4a639f92c0e2ca#diff-9b1b189b26c7de73601bea48390c0edfb383c0c87ace4e761057ca36fef34fe921: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
LocutusOfBorgand surf autopkgtest fails because the GLESv2.so.foo is not found21:49
LocutusOfBorgI'm out of ideas21:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!