Bug#894643: cups: autopkgtest fails due to output on stderr since 2.2.7-1
Source: cups Version: 2.2.7-1 Severity: normal Control: user ci-t...@tracker.debian.org Control: usertag -1 regression -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since the upload of 2.2.7-1 the autopkgtest of cups fails¹ with the following output to stderr: lpadmin: Raw queues are deprecated and will stop working in a future version of CUPS. Please either fix the test to not trigger deprecated behavior or allow output to stderr in the test suite by adding "allow-stderr" to the restrictions. ¹ https://ci.debian.net/packages/c/cups/unstable/amd64/ - -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'testing'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlrCjMwACgkQnFyZ6wW9 dQrttgf/dkBIEB21ylUJkYvinfiB068xxL0LQKesi5q/bGwxMZwACzIQdpvDs6D8 dYLn/vS21foLvyEMaOtKA8r/aBYD0935P1G/kaU4nWV4pEERF4sOHL0x49N/LdUO vok2ZLpU2+gpMceSJnCdJpFnG/PxnRN6yOz7stXYGHLk2Ld5/HxSr9uozUxle4iF ZszOVhSbNx9tjDFfw/JZ7U64OqrocHIuMIFMHjF/uTpVW1ovWBhEktVksWKYn2+I 4qN5bug+MkfxDSQ246QGC919TvGFS2i18Qev3dQmz0i9MumbTJ3AEQKEf9lReZEN G9NqJ605xGhVYgPSMZZYC+Rxfmu/0g== =PJ4x -END PGP SIGNATURE-
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Source: ghostscript, cups Version: ghostscript/9.22~dfsg-3 Version: cups/2.2.8-5 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update timeout Dear maintainers, With a recent upload of ghostscript the autopkgtest of cups started to fail in testing and unstable due to the test timing out. It now takes more than 2:47 hours to complete the test, while in the past it ran typically slightly more than 6 minutes. As ghostscript was uploaded with urgency high this regression is NOT delaying of the migration of ghostscript to testing [1] and cups will be hit by this in testing tomorrow. I have assigned the bug to both packages. Could you please investigate the situation and reassign the bug to the right package? If needed, please change the bug's severity as appropriate. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=ghostscript https://ci.debian.net/data/autopkgtest/testing/amd64/c/cups/894494/log.gz signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Control: tags -1 - moreinfo On Wed, 29 Aug 2018 09:41:37 +0200 Jonas Smedegaard wrote: > It would be most helpful if someone could dig out from that convoluted > ci-in-cups test the actual ghostscript command causing cups to hang. Looking here: https://sources.debian.org/src/cups/2.2.8-5/debian/tests/cups/ it runs: /usr/share/cups/test-drivers As the log ends with: * Driver drv:///sample.drv/dymo.ppd - Create test printer: done. - Print test job with /usr/share/cups/data/topsecret.pdf: I guess it successfully runs this command /usr/sbin/lpadmin -p $DUMMY_PRINTER_NAME -E -m $driver -v file:///dev/null and fails with this command: rid=$(/usr/bin/lp -d $DUMMY_PRINTER_NAME $file | sed -e 's/^.*request id is \(.*\) (.*)$/\1/g') where DUMMY_PRINTER_NAME=test-printer0 driver=drv:///sample.drv/dymo.ppd file=/usr/share/cups/data/topsecret.pdf Is that enough for you to continue? Paul signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Control: tags -1 moreinfo Hi, On 29-08-18 20:20, Jonas Smedegaard wrote: > Thanks - that is indeed helpful, but provides only the _cups_ commands. > > Inside those are some Ghostscript command (and some data) which I would > need to check if/what fails with Ghostscript. Both of them are "ELF 64-bit LSB shared object" so it would help if the cups maintainers could help here. Paul signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Dear all, On 31-08-18 15:48, Till Kamppeter wrote: > On 31/08/18 15:36, Didier 'OdyX' Raboud wrote: >> Le vendredi, 31 août 2018, 01.25:24 h CEST Jonas Smedegaard a écrit : >>> Do the freshly released experimental Ghostscript release help anything? >> >> It doesn't seem to, unfortunately. :-( >> >> To reproduce the issue; just run this as root: >> /usr/share/cups/test-drivers I tried this on my fully up-to-date testing/buster system and it fails for a different reason: lpinfo: Bad file descriptor Not sure yet, what that means for any of this. >> Surprisingly; it will fail when testing the _second_ printer, always. >> Also, it >> doesn't seem to get fixed with the ghostscript from testing. >> >> There's something fishy here, but I can't say with certainty that it's >> ghostscript's fault :-( > > Which driver is this second printer using? As mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907493#26 DUMMY_PRINTER_NAME=test-printer0 driver=drv:///sample.drv/dymo.ppd > Which version of cups-filters are you using? 1.21.0 has a bug in > foomatic-rip which is fixed in 1.21.1. Please update to 1.21.1 if you > have 1.21.0 currently. I had none installed. I now try with 1.20.4-1 which is in testing, where the bug was reported from and where cups fails with the ghostscript from unstable. The autopkgtest ran successfully with cups-filters/1.21.0-1 and with cups-filters/1.21.1-1 so I assume they are both fine in this respect. On my laptop, lpinfo still fails. Paul signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Hi Jonas, On 31-08-18 01:25, Jonas Smedegaard wrote: > Do the freshly released experimental Ghostscript release help anything? I'll trigger the test shortly and report back with the results. Paul signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Hi Jonas, On 31-08-18 16:19, Jonas Smedegaard wrote: > Currently¹ I cannot (easily) setup a CUPS testing environment, so would > appreciate if someone else can confirm if the version now in testing > _also_ causes this same failure - and if so then please help ensure that > this issue does not block the security fix now in unstable to enter > testing. The cups test with only packages from testing is successfully running. It has been tried two times over the last two days, visible with the trigger "migration-reference/0" here: https://ci.debian.net/packages/c/cups/testing/amd64/ I have requested the cups test in testing with ghostscript from experimental. I hasn't finished yet, albeit it probably started soon after I requested it at 2018-08-31 19:20:50 UTC, so this isn't looking good. Feel free to check in 2:30 hours or so, it should be visible at the page linked above with the trigger "elbrus ghostscript from experimental". If that ran for 2:47 and failed it probably timed out (which you can confirm by looking at the bottom of the test log). Paul signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript causes multiple autopkgtests to time out
Control: reassign -1 ghostscript 9.22~dfsg-3 Control: retitle -1 ghostscript causes multiple autopkgtests to time out Control: affects -1 src:cups src:gutenprint src:dymo-cups-drivers Control: affects -1 src:epson-inkjet-printer-escpr On 31-08-18 21:49, Paul Gevers wrote: > I have requested the cups test in testing with ghostscript from > experimental. I hasn't finished yet, albeit it probably started soon > after I requested it at 2018-08-31 19:20:50 UTC, so this isn't looking > good. Feel free to check in 2:30 hours or so, it should be visible at > the page linked above with the trigger "elbrus ghostscript from > experimental". If that ran for 2:47 and failed it probably timed out > (which you can confirm by looking at the bottom of the test log). It timed out. Additionally, I spotted multiple packages on the ci.d.n that started to time out [1] that seem to be related to printing. I have triggered tests with ghostscript from unstable for them too. They all time out as well (marked as affected by this bug). Paul [1] https://ci.debian.net/status/slow/ signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript causes multiple autopkgtests to time out
Hi Jonas, all, Does ghostscript and/or cups do anything with ssl? I can't find it in the (build) depends, nor in the build log, but somehow, somewhere the "topsecret.pdf" name and other tests that time out due to it triggered something in my mind. This is not unlikely to be a red haring, but here it goes. Openssl in unstable is updated some time ago to upstream version 1.1.1. See https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1, which contains: ''' TLS 1.3 has lots of changes that might cause issues. See https://wiki.openssl.org/index.php/TLS1.3 for more information. One of those changes may cause time out: SSL_MODE_AUTO_RETRY is enabled by default. Applications that use blocking I/O in combination with something like select() or poll() will hang. This can be turned off again using SSL_CTX_clear_mode(). Many applications do not properly handle non-application data records, and TLS 1.3 sends more of such records. Setting SSL_MODE_AUTO_RETRY works around the problems in those applications, but can also break some. It's recommended to read the manpages about SSL_read(), SSL_write(), SSL_get_error(), SSL_shutdown(), SSL_CTX_set_mode() and SSL_CTX_set_read_ahead() again. ''' If this would be true, than building the package in testing as opposed to unstable should not have the time out issue. I think that is something that could be tested. Paul signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript causes multiple autopkgtests to time out
Control: affects -1 src:brlaser src:c2esp On 02-09-18 13:18, Paul Gevers wrote: > Additionally, I spotted multiple packages on the ci.d.n that started to > time out [1] that seem to be related to printing. I have triggered tests > with ghostscript from unstable for them too. They all time out as well > (marked as affected by this bug). It seems more packages are affected via their autopkgtest. Paul signature.asc Description: OpenPGP digital signature
Bug#907493: [SECURITY] [DSA 4288-1] ghostscript security update
Dear security team, On 09/07/18 23:23, Moritz Muehlenhoff wrote: > Package: ghostscript > CVE ID : CVE-2018-15908 CVE-2018-15910 CVE-2018-15911 > CVE-2018-16511 CVE-2018-16513 CVE-2018-16539 >CVE-2018-16540 CVE-2018-16541 CVE-2018-16542 >CVE-2018-16543 CVE-2018-16585 The latest upload of ghostscript to unstable, which as far as I know only tried to fix some of these CVE's, caused the autopkgtest of multiple packages to start timing out (bug 907493). Were you aware of that and have you done any testing to verify that this isn't an issue for the stable upload? If so, that would be an interesting data point for the bug. If not, you may be facing the same regression in stretch. I have the wild hunch that this is related to the openssl upstream bump in unstable, but nobody has verified that yet. If stretch is no not seeing this regression that would mean there may also be a path to fix testing/buster until we figure out what needs fixing in ghostscript. Paul signature.asc Description: OpenPGP digital signature
Bug#907493: ghostscript breaks cups autopkgtest: test times out
Hi Jonas, On 14-09-18 22:26, Jonas Smedegaard wrote: > Another release of Ghostscript is now in experimental. Can someone > please test if those autopkgtests still fail? 9.25~dfsg-1~exp1 passed the cups test. https://ci.debian.net/data/autopkgtest/testing/amd64/c/cups/994233/log.gz Paul signature.asc Description: OpenPGP digital signature
Bug#908937: ghostscript breaks ocrmypdf autopkgtest
Source: ghostscript, ocrmypdf
Control: found -1 ghostscript/9.25~dfsg-2
Control: found -1 ocrmypdf/6.2.3-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainers,
With a recent upload of ghostscript the autopkgtest of ocrmypdf fails in
testing when that autopkgtest is run with the binary packages of
ghostscript from unstable. It passes when run with only packages from
testing. I copied some of the output at the bottom of this report.
As ghostscript is uploaded with urgency high, this regression is NOT
delaying of the migration of ghostscript to testing [1]. If this
regression requires blockage of ghostscript to testing, fast action is
required (raising the severity of this bug should be enough, albeit I
haven't tested RC blockage when bugs are assigned to multiple packages.
Due to the nature of this issue, I filed this bug report against both
packages. Can you please investigate the situation and reassign the bug
to the right package? As needed, please change the bug's severity.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=ghostscript
https://ci.debian.net/data/autopkgtest/testing/amd64/o/ocrmypdf/1000885/log.gz
=== FAILURES
===
___ test_compression_changed[congress.jpg-lossless]
spoof_tesseract_noop = {'ADTTMP':
'/tmp/autopkgtest-lxc.bj5c8t8i/downtmp/autopkgtest_tmp',
'ADT_ARTIFACTS':
'/tmp/autopkgtest-lxc.bj5c8t8i/do...j5c8t8i/downtmp/test-suite-artifacts',
'AUTOPKGTEST_TMP':
'/tmp/autopkgtest-lxc.bj5c8t8i/downtmp/autopkgtest_tmp', ...}
ocrmypdf_exec = ['/usr/bin/python3', '-m', 'ocrmypdf']
resources =
PosixPath('/tmp/autopkgtest-lxc.bj5c8t8i/downtmp/build.24A/src/tests/resources')
image = 'congress.jpg', compression = 'lossless'
outpdf =
'/tmp/pytest-of-debci/pytest-0/test_compression_changed_congr0/out.pdf'
@pytest.mark.parametrize('image,compression', [
('baiona.png', 'jpeg'),
('baiona_gray.png', 'lossless'),
('congress.jpg', 'lossless')
])
def test_compression_changed(spoof_tesseract_noop, ocrmypdf_exec,
resources, image, compression, outpdf):
from PIL import Image
input_file = str(resources / image)
output_file = str(outpdf)
im = Image.open(input_file)
# Runs: ocrmypdf - output.pdf < testfile
with open(input_file, 'rb') as input_stream:
p_args = ocrmypdf_exec + [
'--image-dpi', '150', '--output-type', 'pdfa',
'--pdfa-image-compression', compression,
'-', output_file]
p = Popen(
p_args, close_fds=True, stdout=PIPE, stderr=PIPE,
stdin=input_stream, env=spoof_tesseract_noop)
out, err = p.communicate()
assert p.returncode == ExitCode.ok, err
pdfinfo = PdfInfo(output_file)
pdfimage = pdfinfo[0].images[0]
if compression == "jpeg":
assert pdfimage.enc == Encoding.jpeg
else:
if ghostscript.jpeg_passthrough_available():
# Ghostscript 9.23 adds JPEG passthrough, which allows a
JPEG to be
# copied without transcoding - so report
if image.endswith('jpg'):
assert pdfimage.enc == Encoding.jpeg
else:
> assert pdfimage.enc not in (Encoding.jpeg,
Encoding.jpeg2000)
E AssertionError: assert not in
(, )
E+ where = .enc
tests/test_main.py:917: AssertionError
_ test_preserve_metadata[pdfa]
_
spoof_tesseract_noop = {'ADTTMP':
'/tmp/autopkgtest-lxc.bj5c8t8i/downtmp/autopkgtest_tmp',
'ADT_ARTIFACTS':
'/tmp/autopkgtest-lxc.bj5c8t8i/do...j5c8t8i/downtmp/test-suite-artifacts',
'AUTOPKGTEST_TMP':
'/tmp/autopkgtest-lxc.bj5c8t8i/downtmp/autopkgtest_tmp', ...}
output_type = 'pdfa'
resources =
PosixPath('/tmp/autopkgtest-lxc.bj5c8t8i/downtmp/build.24A/src/tests/resources')
outpdf =
'/tmp/pytest-of-debci/pytest-0/test_preserve_metadata_pdfa_0/out.pdf'
@pytest.mark.parametrize("output_type", [
'pdfa', 'pdf'
])
def test_preserve_metadata(spoof_tesseract_noop, output_type,
resources, outpdf):
pdf_before = pypdf.PdfFileReader(str(resources / 'graph.pdf'))
output = check_ocrmypdf(
resources / 'graph.pdf', outpdf,
'--output-type', output_type,
env=spoof_tesseract_noop)
pdf_after = pypdf.PdfFileReader(str(output))
for key in ('/Title', '/Author'):
> assert pdf_before.documentInfo[key] ==
pdf_after.documentInfo[key]
tests/test_metadata.py:52:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Bug#908937: ghostscript breaks ocrmypdf autopkgtest
ginggs already noted this: this patch fixes 1 of the 3 failing tests https://github.com/jbarlow83/OCRmyPDF/commit/517b385fe5cb2195023100a807e6f18dc7e6faea#diff-b61a6d542f9036550ba9c401c80f00ef Paul signature.asc Description: OpenPGP digital signature
Bug#908937: ghostscript breaks ocrmypdf autopkgtest
Dear Sean, On 16-09-18 20:30, Sean Whitton wrote: > Paul: does preventing regressions in testing take precedence? Normally, yes temporarily (we are not blocking yet), but ghostscript was uploaded with urgency high. That means that regressions are ignored and without an RC bug, ghostscript will migrate to testing tomorrow (if my counting is correct). > If so, > this bug should be reassigned to ghostscript and raised to RC severity. I don't follow what you mean by this sentence. > But ISTM that ocrmypdf is less important, so ghostscript should be > allowed to migrate and ocrmypdf should be kicked out. ocrmypdf can stay in testing as long as it doesn't have an RC bug itself. So just to make it clear: if this change making ocrmypdf totally unusable and you still want ghostscript to migrate to testing to fix multiple CVE's, than assigning this bug to ocrmypdf and raising it to RC level will start the autoremoval process. If you think it is worth searching for a solution in ghostscript to avoid it breaking ocrmypdf, than reassign this bug to ghostscript and raise the severity to RC level to avoid migration. Paul signature.asc Description: OpenPGP digital signature
Bug#926960: cjet: autopkgtest times out since 2019-04-07
Source: cjet Version: 0.8.9-7 X-Debbugs-CC: debian...@lists.debian.org Severity: important User: debian...@lists.debian.org Usertags: timeout regression Dear maintainers, Since 2019-04-07 the autopkgtest of your package started to fail because it times out (after 2:47h) on ci.debian.net in both unstable and testing. Unfortunately, this most likely isn't caused by any of your direct (test) dependencies, otherwise the integration with our migration software should have caught it. If the content of our log is correct, the following files may hint at the culprit: https://ci.debian.net/data/packages/unstable/amd64/c/cjet/2214069.log https://ci.debian.net/data/packages/testing/amd64/c/cjet/2226265.log Can you please investigate the situation? Don't hesitate to ask for help from the Debian CI team (in X-Debbugs-CC) if you need help solving this issue. If the situation doesn't change in a week or two I may blacklist this package on the ci.debian.net infrastructure. If that happens I will remove the blacklist once this bug is fixed. If needed, please ping me to try any uploads you make that should fix the issue if you are unsure and don't want to close this bug until verified. Paul https://ci.debian.net/data/autopkgtest/testing/amd64/c/cjet/2226265/log.gz autopkgtest [12:38:01]: test printer-driver-cjet: [--- * Driver foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Canon-LBP-4U-cjet.ppd - Create test printer: done. - Print test job with /usr/share/cups/data/standard.pdf:
Bug#939044: ocrmypdf: autopkgtest not compatible with new pikepdf, ghostscript and/or pytest
Source: ocrmypdf
Version: 8.0.1+dfsg-1
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pikepdf
Control: affects -1 src:ghostscript
Control: affects -1 src:pytest
[X-Debbugs-CC: debian...@lists.debian.org, pike...@packages.debian.org,
ghostscr...@packages.debian.org, pyt...@packages.debian.org]
Dear maintainers,
With a recent upload of pikepdf and with a recent upload of ghostscript
and with a recent upload of pytest (althought that pulls in the others)
the autopkgtest of ocrmypdf fails in testing when that autopkgtest is
run with the binary packages of those packages from unstable. It passes
when run with only packages from testing. In tabular form, e.g.:
passfail
pikepdffrom testing1.6.1+dfsg-1
ocrmypdf from testing8.0.1+dfsg-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of pikepdf,
ghostscript and pytest to testing [1]. Because failure is triggered by
two packages separately, I filed the bug against ocrmypdf, please
reassign (and clone) if that wasn't correct.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pikepdf
https://ci.debian.net/data/autopkgtest/testing/amd64/o/ocrmypdf/2854254/log.gz
=== FAILURES
===
___ test_non_square_resolution[hocr]
___
renderer = 'hocr'
spoof_tesseract_cache = {'ADTTMP':
'/tmp/autopkgtest-lxc._q0vjo65/downtmp/autopkgtest_tmp',
'ADT_ARTIFACTS':
'/tmp/autopkgtest-lxc._q0vjo65/do...q0vjo65/downtmp/test-suite-artifacts',
'AUTOPKGTEST_TMP':
'/tmp/autopkgtest-lxc._q0vjo65/downtmp/autopkgtest_tmp', ...}
resources =
PosixPath('/tmp/autopkgtest-lxc._q0vjo65/downtmp/build.Oxe/src/tests/resources')
outpdf =
'/tmp/pytest-of-debci/pytest-0/test_non_square_resolution_hoc0/out.pdf'
@pytest.mark.parametrize('renderer', RENDERERS)
def test_non_square_resolution(renderer, spoof_tesseract_cache,
resources, outpdf):
# Confirm input image is non-square resolution
in_pageinfo = PdfInfo(resources / 'aspect.pdf')
assert in_pageinfo[0].xres != in_pageinfo[0].yres
check_ocrmypdf(
resources / 'aspect.pdf',
outpdf,
'--pdf-renderer',
renderer,
> env=spoof_tesseract_cache,
)
tests/test_main.py:481:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
input_file =
PosixPath('/tmp/autopkgtest-lxc._q0vjo65/downtmp/build.Oxe/src/tests/resources/aspect.pdf')
output_file =
'/tmp/pytest-of-debci/pytest-0/test_non_square_resolution_hoc0/out.pdf'
env = {'ADTTMP':
'/tmp/autopkgtest-lxc._q0vjo65/downtmp/autopkgtest_tmp',
'ADT_ARTIFACTS':
'/tmp/autopkgtest-lxc._q0vjo65/do...q0vjo65/downtmp/test-suite-artifacts',
'AUTOPKGTEST_TMP':
'/tmp/autopkgtest-lxc._q0vjo65/downtmp/autopkgtest_tmp', ...}
args = ('--pdf-renderer', 'hocr')
p = , out = ''
@pytest.helpers.register
def check_ocrmypdf(input_file, output_file, *args, env=None):
"Run ocrmypdf and confirmed that a valid file was created"
p, out, err = run_ocrmypdf(input_file, output_file, *args, env=env)
# ensure py.test collects the output, use -s to view
print(err, file=sys.stderr)
> assert p.returncode == 0
E assert 15 == 0
E+ where 15 = .returncode
tests/conftest.py:155: AssertionError
- Captured stderr call
-
INFO -1: [tesseract] Tesseract cache folder
/tmp/autopkgtest-lxc._q0vjo65/downtmp/build.Oxe/src/tests/cache/aspect/__-l__eng__01.ocr.png__01__hocr__txt
- HIT
ERROR - Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/ruffus/task.py", line 712, in
run_pooled_job_without_exceptions
register_cleanup, touch_files_only)
File "/usr/lib/python3/dist-packages/ruffus/task.py", line 544, in
job_wrapper_io_files
ret_val = user_defined_work_func(*params)
File "/usr/lib/python3/dist-packages/ocrmypdf/_pipeline.py", line 827,
in convert_to_pdfa
pdf_layers_file.save(layers_file)
ValueError: Cannot overwrite input file
_ test_non_square_resolution[sandwich]
_
renderer = 'sandwich'
spoof_tesseract_cache = {'ADTTMP':
'/tmp/autopkgtest-lxc._q0vjo65/downtmp/autopkgtest_tmp',
'ADT_ARTIFACTS':
'/tmp/autopkgtest-lxc._q0vjo65/do...q0vjo65/downtmp/test-suite-artifacts',
'AUTOPKGTEST_TMP':
'/tmp/autopkgtest-lxc._q0vjo65/downtmp/autopkgtest_tmp', ...}
resources =
PosixPath('/tmp/autopkgtest-lxc._q0vjo65/downtmp/build.Oxe/src/tests/resources')
outpdf =
'/tmp/pytest-of-debci/pytest-0/test_non_square_resolution_san0/out.pd
Bug#939794: ghostscript breaks fig2dev autopkgtest: compare arrow tips with template failed unexpectedly
Source: ghostscript, fig2dev Control: found -1 ghostscript/9.28~~rc2~dfsg-1 Control: found -1 fig2dev/1:3.2.7a-7 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainers, With a recent upload of ghostscript the autopkgtest of fig2dev fails in testing when that autopkgtest is run with the binary packages of ghostscript from unstable. It passes when run with only packages from testing. In tabular form: passfail ghostscriptfrom testing9.28~~rc2~dfsg-1 fig2devfrom testing1:3.2.7a-7 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. (The output is rather dense. I would love a more verbose output, so that others like me have something to look at.) Currently this regression is blocking the migration of ghostscript to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from ghostscript/9.28~~rc2~dfsg-1. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=ghostscript https://ci.debian.net/data/autopkgtest/testing/amd64/f/fig2dev/2909339/log.gz Test PostScript output language. 28: compare arrow tips with templateFAILED (output.at:41) signature.asc Description: OpenPGP digital signature
Bug#939794: ghostscript breaks fig2dev autopkgtest: compare arrow tips with template failed unexpectedly
Hi Roland, On 09-09-2019 09:05, Roland Rosenfeld wrote: > Removing the "./" from the input filename the error disappears. > Sadly the testsuite generates a filename with /./ in it... > From my point of view ../.././data/arrows.eps is a valid file name on > Unix systems, so gs should accept it. > > Is there a good reason to reject this file name in gs? Then we have > to change the testsuite, otherwise I'd suggest fixing the behavior of > gs. I'm not sure, but does https://bugs.debian.org/bug=939044#75 help you? Paul signature.asc Description: OpenPGP digital signature
Bug#940127: ghostscript makes c2esp autopkgtest timeout
Source: ghostscript, c2esp Control: found -1 ghostscript/9.28~~rc2~dfsg-1 Control: found -1 c2esp/27-4 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update timeout Dear maintainers, With a recent upload of ghostscript the autopkgtest of c2esp timeouts [1] in testing when that autopkgtest is run with the binary packages of ghostscript from unstable. It passes when run with only packages from testing. In tabular form: passfail ghostscriptfrom testing9.28~~rc2~dfsg-1 c2esp from testing27-4 all others from testingfrom testing The autopkgtest of c2esp also times out in unstable since the upload of ghostscript. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? Paul [1] https://ci.debian.net/data/autopkgtest/testing/amd64/c/c2esp/2944626/log.gz signature.asc Description: OpenPGP digital signature
Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
Source: ghostscript, doc-rfc Control: found -1 ghostscript/9.53.1~dfsg-2 Control: found -1 doc-rfc/20191026-1 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of ghostscript the autopkgtest of doc-rfc fails in testing when that autopkgtest is run with the binary packages of ghostscript from unstable. It passes when run with only packages from testing. In tabular form: passfail ghostscriptfrom testing9.53.1~dfsg-2 doc-rfcfrom testing20191026-1 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of ghostscript to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from ghostscript/9.53.1~dfsg-2. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=ghostscript https://ci.debian.net/data/autopkgtest/testing/amd64/d/doc-rfc/7163820/log.gz autopkgtest [06:12:23]: test pspdf-parsing: [--- Tests that all files are parseable by p*t*xt, in order to suport dhelp integration. - testing rfc1119.ps.gz - testing rfc1124.ps.gz - testing rfc1125.ps.gz - testing rfc1128.ps.gz - testing rfc1129.ps.gz - testing rfc1131.ps.gz - testing rfc1142.ps.gz - testing rfc1144.ps.gz - testing rfc1147.ps.gz - testing rfc1168.ps.gz - testing rfc1195.ps.gz - testing rfc12.ps.gz - testing rfc1237.ps.gz - testing rfc1241.ps.gz - testing rfc1245.ps.gz - testing rfc1246.ps.gz - testing rfc1247.ps.gz Segmentation fault autopkgtest [07:25:45]: test pspdf-parsing: ---] signature.asc Description: OpenPGP digital signature
Bug#974970: src:fonts-urw-base35: fails to migrate to testing for too long: Depends on version of ghostscript that's not migrating
Source: fonts-urw-base35 Version: 20170801.1-3 Severity: important Control: close -1 20200910-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 970878 Control: affects 970878 src:fonts-urw-base35 X-Debbugs-CC: ghostscr...@packages.debian.org Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:fonts-urw-base35 in its current version in unstable has been trying to migrate for 62 days [2]. Hence, I am filing this bug. Because I know that your package can't migrate due to ghostscript (which is a key package) not migrating, I filled this bug as important instead of the normal severity serious. Please coordinate with the ghostscript maintainer to fix the situation. We may raise the severity of this bug to serious later. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=fonts-urw-base35 signature.asc Description: OpenPGP digital signature
Bug#975841: src:ghostscript: fails to migrate to testing for too long: unresolved RC bug: autopkgtest regression
Source: ghostscript Version: 9.52.1~dfsg-1 Severity: serious Control: close -1 9.53.3~dfsg-5 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:ghostscript in unstable has been trying to migrate for >80 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=ghostscript signature.asc Description: OpenPGP digital signature
Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
Hi Jonas, On Fri, 23 Oct 2020 12:07:27 +0200 Jonas Smedegaard wrote: > > Of course, I'm biased since I'm the maintainer of doc-rfc, but I think > > it's a fair assesment. > > For the record it is not a PDF file but a (quite large and allegedly) > PostScript file that causes Ghostscript to segfault. doc-rfc got a new upload and removed the offending file. So, there's no no autopkgtest regression reported anymore. Unless you think this segfault case is severe enough (I could really see that point) I also like ghostscript to just migrate. It's your call. If you want ghostscript to migrate, just lower this bug's severity. > I do agree that Ghostscript shouldn't segfault. Indeed. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers
Dear Didier, On Fri, 16 Oct 2020 14:23:59 +0200 Didier 'OdyX' Raboud wrote: > According to the 3.20.9-3 armhf auutopkgtest run for migration testing; > https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz > > hpcups sometimes crashes with free(): invalid pointer. For instance, it > seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd' > printer will let hpcups crash. Just to have the information for the release process, do you think this is a regression compared to buster, or did you just found out now because of autopkgtest? Is there any progress on this issue? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1000781: ghostscript breaks asymptote autopkgtest: build fails: GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
Source: ghostscript, asymptote Control: found -1 ghostscript/9.55.0~dfsg-1 Control: found -1 asymptote/2.70+ds-2 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of ghostscript the autopkgtest of asymptote fails in testing when that autopkgtest is run with the binary packages of ghostscript from unstable. It passes when run with only packages from testing. In tabular form: passfail ghostscriptfrom testing9.55.0~dfsg-1 asymptote from testing2.70+ds-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of ghostscript to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=ghostscript https://ci.debian.net/data/autopkgtest/testing/amd64/a/asymptote/17088116/log.gz cd png && make all make[4]: Entering directory '/tmp/autopkgtest-lxc.9yct2tpe/downtmp/build.gii/src/doc/png' cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ axis3.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ bezier2.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ bezier.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ beziercurve.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ bigdiagonal.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ binarytreetest.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ Bode.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ brokenaxis.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ CAD1.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ CDlabel.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ colons.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ colors.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ cube.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ cylinderskeleton.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ datagraph.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ diagonal.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ diatom.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ dots.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ eetomumu.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ elliptic.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ errorbars.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ exp.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ filegraph.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ flow.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ flowchartdemo.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ GaussianSurface.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ generalaxis3.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ generalaxis.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ graphmarkers.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ grid3xyz.asy cd .. && ../asy -dir ../base -config "" -render=0 -f png -o png/ hatch.asy Error: /rangecheck in --stroke-- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1990 1 3 %oparray_pop 1989 1 3 %oparray_pop 1988 1 3 %oparray_pop --nostringval-- 1977 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- fill (NULL) (gs_pattern1_instance_t) (pattern accumulator) 0 %pattern_paint_finish --nostringval-- Dictionary stack: --dict:767/1123(ro)(G)-- --dict:0/20(G)-- --dict:83/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 2701 GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1 _shipout(prefix,f,currentpatterns,format,wait,view,t); ^ ../base/plain_shipout.asy: 104.11: runtime: shipout failed make[4]: *** [Makefile:14: hatch.png] Error 1 make[4]: Leaving direct
Bug#1006849: cups breaks python-cups autopkgtest
Source: cups, python-cups Control: found -1 cups/2.4.1op1-1 Control: found -1 python-cups/2.0.1-5 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of cups the autopkgtest of python-cups fails in testing when that autopkgtest is run with the binary packages of cups from unstable. It passes when run with only packages from testing. In tabular form: passfail cups from testing2.4.1op1-1 python-cupsfrom testing2.0.1-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Unfortunately the output is rather dense, I have no clue what goes wrong. Currently this regression is blocking the migration of cups to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=cups https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-cups/19783617/log.gz - Create printer test-printer1 - Interrupted (or finished), delete test printers: done. autopkgtest [14:11:08]: test testscripts OpenPGP_signature Description: OpenPGP digital signature
Bug#1011990: pappl: autopkgtest regression: fails on output to stderr
Source: pappl
Version: 1.2.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of pappl the autopkgtest of pappl fails in testing
when that autopkgtest is run with the binary packages of pappl from
unstable. It passes when run with only packages from testing. In tabular
form:
passfail
pappl from testing1.2.0-1
all others from testingfrom testing
I copied some of the output at the bottom of this report. The test
itself seems to pass, but there's output to stderr. Output to stderr is
by default treated as failure by autopkgtest, unless the allow-stderr
restriction is set.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pappl
https://ci.debian.net/data/autopkgtest/testing/amd64/p/pappl/22174962/log.gz
testsuiteFAIL stderr: Starting tests...
autopkgtest [18:13:16]: test testsuite: - - - - - - - - - - stderr - -
- - - - - - - -
Starting tests...
api: papplSystemFindLoc('de'): PASS
api: papplLocGetString('A printer with that name already exists.'): PASS
(got 'Ein Drucker mit diesem Namen existiert bereits.')
api: papplSystemFindLoc('en'): PASS
api: papplLocGetString('A printer with that name already exists.'): PASS
(got 'A printer with that name already exists.')
api: papplSystemFindLoc('es'): PASS
api: papplLocGetString('A printer with that name already exists.'): PASS
(got 'Una impresora con ese nombre ya existe.')
api: papplSystemFindLoc('fr'): PASS
api: papplLocGetString('A printer with that name already exists.'): PASS
(got 'Une imprimante avec ce nom existe déjà.')
api: papplSystemFindLoc('it'): PASS
api: papplLocGetString('A printer with that name already exists.'): PASS
(got 'Una stampante con quel nome esiste già.')
api: papplSystemFindLoc('ja'): PASS
api: papplLocGetString('A printer with that name already exists.'): PASS
(got '既に存在している名前のプリンター。')
api: papplSystemFindLoc('zz'): PASS (got NULL)
api: papplLocGetString('A printer with that name already exists.'): PASS
(got key string)
api: papplSystemGetAdminGroup: PASS
api: papplSystemGet/SetAdminGroup('admin-0'): PASS
api: papplSystemGet/SetAdminGroup('admin-1'): PASS
api: papplSystemGet/SetAdminGroup('admin-2'): PASS
api: papplSystemGet/SetAdminGroup('admin-3'): PASS
api: papplSystemGet/SetAdminGroup('admin-4'): PASS
api: papplSystemGet/SetAdminGroup('admin-5'): PASS
api: papplSystemGet/SetAdminGroup('admin-6'): PASS
api: papplSystemGet/SetAdminGroup('admin-7'): PASS
api: papplSystemGet/SetAdminGroup('admin-8'): PASS
api: papplSystemGet/SetAdminGroup('admin-9'): PASS
api: papplSystemGet/SetAdminGroup(NULL): PASS
api: papplSystemGetContact: PASS
api: papplSystemGet/SetContact('Admin 0'): PASS
api: papplSystemGet/SetContact('Admin 1'): PASS
api: papplSystemGet/SetContact('Admin 2'): PASS
api: papplSystemGet/SetContact('Admin 3'): PASS
api: papplSystemGet/SetContact('Admin 4'): PASS
api: papplSystemGet/SetContact('Admin 5'): PASS
api: papplSystemGet/SetContact('Admin 6'): PASS
api: papplSystemGet/SetContact('Admin 7'): PASS
api: papplSystemGet/SetContact('Admin 8'): PASS
api: papplSystemGet/SetContact('Admin 9'): PASS
api: papplSystemGetDefaultPrinterID: PASS (1)
api: papplSystemSetDefaultPrinterID(2): PASS
api: papplSystemSetDefaultPrinterID(1): PASS
api: papplSystemGetDefaultPrintGroup: PASS
api: papplSystemGet/SetDefaultPrintGroup('users-0'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-1'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-2'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-3'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-4'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-5'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-6'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-7'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-8'): PASS
api: papplSystemGet/SetDefaultPrintGroup('users-9'): PASS
api: papplSystemGet/SetDefaultPrintGroup(NULL): PASS
api: papplSystemGetDNSSDName: PASS
api: papplSystemGet/SetDNSSDName('System Test A'): PASS
api: papplSystemGet/SetDNSSDName('System Test B'): PASS
api: papplSystemGet/SetDNSSDName('System Test C'): PASS
api: papplSystemGet/SetDNSSDName('System Test D'): PASS
api: papplSystemGet/SetDNSSDName('System Test E'): PASS
api: papplSystemGet/SetDNSSDName('System Test F'): PASS
api: papplSystemGet/SetDNSSDName('System Test G'): PASS
api: papplSystemGet/SetDNSSDName('System Test H'): PASS
api: papplSystemGet/SetDNSSDName('System Test I'): PASS
api: papplSystemGet/SetDNSSDName('System Test J'): PASS
api: papplSystemGet/SetDNSSDName(NULL): PASS
api: papplSystemGetFooterHTML: PASS
api: papplSystemSetFooterH
Bug#1081121: src:cups-pk-helper: fails to migrate to testing for too long
Source: cups-pk-helper Version: 0.2.6-1 Severity: serious Control: close -1 0.2.6-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:cups-pk-helper has been trying to migrate for 31 days [2], hence this bug report. The current output of the migration software for this package is copied to the bottom of this report and should list the reason why the package is blocked. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. This bug submission immediately closes the bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. This bug is also tagged to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. This bug report has been automatically generated and has only been sent manually. If you have any comments with regards to the content or the process, please reach out to me. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=cups-pk-helper Current text from [2]: Migration status for cups-pk-helper (0.2.6-1 to 0.2.6-2): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ Updating cups-pk-helper would introduce bugs in testing: #1079125, #1079293 ∙ ∙ Rejected due to piuparts regression - https://piuparts.debian.org/sid/source/c/cups-pk-helper.html Additional info: ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Reproducible on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ ∙ ∙ 31 days old (needed 5 days) OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079125: cups-pk-helper: diff for NMU version 0.2.6-2.1
Control: tags -1 patch pending Dear maintainer, I've prepared an NMU for cups-pk-helper (versioned as 0.2.6-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. Paul diff -Nru cups-pk-helper-0.2.6/debian/changelog cups-pk-helper-0.2.6/debian/changelog --- cups-pk-helper-0.2.6/debian/changelog 2024-08-08 10:26:27.0 +0200 +++ cups-pk-helper-0.2.6/debian/changelog 2024-10-19 21:49:01.0 +0200 @@ -1,3 +1,15 @@ +cups-pk-helper (0.2.6-2.1) unstable; urgency=medium + + * Non-maintainer upload + + [ Laurent Bigonville ] + * Ensure service is started as cups-pk-helper (Closes: #1079293) + + [ Roland Clobus ] + * Don't fail during purge on lack of deluser (Closes: #1079125) + + -- Paul Gevers Sat, 19 Oct 2024 21:49:01 +0200 + cups-pk-helper (0.2.6-2) unstable; urgency=medium * Team upload. diff -Nru cups-pk-helper-0.2.6/debian/cups-pk-helper.postrm cups-pk-helper-0.2.6/debian/cups-pk-helper.postrm --- cups-pk-helper-0.2.6/debian/cups-pk-helper.postrm 2024-08-08 10:26:27.0 +0200 +++ cups-pk-helper-0.2.6/debian/cups-pk-helper.postrm 2024-10-19 21:49:01.0 +0200 @@ -4,7 +4,7 @@ case "$1" in purge) - deluser cups-pk-helper + deluser cups-pk-helper || true ;; esac diff -Nru cups-pk-helper-0.2.6/debian/rules cups-pk-helper-0.2.6/debian/rules --- cups-pk-helper-0.2.6/debian/rules 2024-08-08 10:26:27.0 +0200 +++ cups-pk-helper-0.2.6/debian/rules 2024-10-19 21:49:01.0 +0200 @@ -9,4 +9,4 @@ dh $@ override_dh_auto_configure: - dh_auto_configure -- --enable-compile-warnings=yes + dh_auto_configure -- --enable-compile-warnings=yes --with-daemon-user=cups-pk-helper OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1099049: src:ghostscript: unsatisfied build dependency in testing: rst2pdf
Source: ghostscript Version: 10.04.0~dfsg-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: edos-uninstallable Dear maintainer(s), Dose [1] is reporting a build issue with your package, it's missing a build dependency. Obviously your build dependencies shouldn't be removed from testing, but unfortunately there are multiple scenarios where that can happen nevertheless. To uphold our social contract, Debian requires that packages can be rebuild from source in the suite we are shipping them, so currently this is a serious issue with your package in testing. Can you please investigate the situation and figure out how to resolve it? Regularly, if the build dependency is available in unstable, helping the maintainer of your Build-Depends to enable migration to testing is a great way to solve the issue. If your build dependency is gone from unstable and testing, you'll have to fix the build process in some other way. Paul Note: this bug report was sent after some quick manual checks using a template. Please reach out to me if you believe I made a mistake in my process. [1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1108870: cpdb-libs: autopkgtest regression: test dependencies can't be installed
Source: cpdb-libs Version: 2.0~b5-1.2 Severity: serious User: debian...@lists.debian.org Usertags: regression Tags: trixie-ignore Dear maintainer(s), Your package has an autopkgtest, great. However, it fails since February 2025 in unstable and testing, but also in stable. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation As I highly suspect this is a test only issue, with my Release Team member hat on I have tagged this as trixie-ignore as it's so late in the freeze and it's not worth removing the package from trixie because of this at this moment. Having said that, if a fix is possible without fully removing the autopkgtest and without making the test superficial, it's still welcome, but it would need to happen soon. Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/data/autopkgtest/testing/amd64/c/cpdb-libs/61507034/log.gz 28s The following packages have unmet dependencies: 29s satisfy:command-line : Depends: cpdb-backend-cups (>= 2.0~b4) but it is not going to be installed 29s Depends: libcupsfilters2-common (>= 2~) but it is not going to be installed 29s Depends: cups-filters (>= 2~) but 1.28.17-6 is to be installed OpenPGP_signature.asc Description: OpenPGP digital signature
