Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Hi,

Ritesh Raj Sarraf  (2021-04-28):
> Please review the attached patch. I build tested locally and the
> results are below. If this looks good to you, then I'll prepare an
> upload and ask the release team for an unblock.

OK, it's slighty different from the haveged package I mentioned that you
could have taken as an example… but I think it should serve our purpose
in a suitable fashion, so feel free to go ahead, thanks!

Regarding this comment:

# We do this to keep the udeb in the installer happy

it's more about your executables being able to find the shared objects
they need, the installer is neither happy nor unhappy. :D

I would expect the following to be a little more descriptive, but of
course you keep whatever you find best. :)

# Ship shared libraries along with the executable in a single udeb


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: retitle 987742 to bind9: CVE-2021-25215

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 987742 bind9: CVE-2021-25215
Bug #987742 [src:bind9] bind9: CVE-2021-25215clearclear
Changed Bug title to 'bind9: CVE-2021-25215' from 'bind9: 
CVE-2021-25215clearclear'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
987742: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987742
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

[Cyril Brulebois]

Control: block -1 by 987587

Hi,

Holger Wansing  (2021-04-24):
> While trying to debug another problem yesterday, I found that the RC1 
> graphical
> installer fails to go forward, when selecting one of these languages:
>  - Kannada
>  - Marathi
>  - Persian
>  - Sinhala
> 
> (tested with rc1-netinst and -netboot image, on an amd64 qemu machine
> with 1G RAM)
> 
> Installer hangs, with only displaying a headline and nothing more,
> eating up all CPU time.

Alright, finally, I'm able to reproduce the issue with locally built
netboot-gtk mini.iso but also a repacked RC 1 netinst with just the
cdrom/gtk/initrd.img file updated! (I decided to give up spending time
trying to get debian-cd to build an image really similar to the released
one, that's a nice to have for me but not needed to debug this issue,
and followed .)

I've been stuck for a while but diffoscope delivered the truth!

> Interestingly, yesterday's daily does not have this problem, while RC1
> has!!! And sadly it has not been discovered, that alpha3 is also
> affected, while alpha2 is fine!

Most of my testing (no pun intended) usually comes after one of those:

make -C build/ build_netboot-gtk USE_UDEBS_FROM=testing
make -C build/ build_netboot-gtk USE_UDEBS_FROM=unstable

For a netinst, one would need to use the build_cdrom_gtk target instead,
and deploy build/dest/cdrom/gtk under install.amd64/ in the ISO.

**BUT** (and that's a big but and I cannot lie ♫)

This minimal `make` call is lacking a variable that makes a huge
difference for the languages above. Their translations are incomplete
and trigger a warning after language selection, but that can only happen
if there's a translation-status file!

Quoting `debian/rules` selectively:

# Daily builds vs. uploads to unstable:
ifeq (${SUITE},UNRELEASED)
TRANSSTATUS=
else
TRANSSTATUS=translation-status
endif

Once I figured that out, reproducing the issue is just a matter of
adding this on the `make` line:

make -C build/ build_netboot-gtk USE_UDEBS_FROM=testing 
TRANSSTATUS=translation-status

> Yet another problem which started to appear with alpha3, just like 
> "Bug#987377: rescue-mode: when in graphical mode, locks up one prompt before 
> the shell"
> !!! 

Yes, that looks like the very same issue, as reverting to the old
libpango udeb means we no longer get stuck with those languages. For
more details about the revert, see this message:
  https://bugs.debian.org/987377#91

In case things change in the archive in the meanwhile (we should get at
least a new linux upload soon-ish, one can still stick to archive
contents from when debian-installer 20210415 (for RC 1) was built:

make -C build/ build_netboot-gtk USE_UDEBS_FROM=testing 
TRANSSTATUS=translation-status SNAPSHOT_TS=20210415T151642Z

> The commit 
> https://salsa.debian.org/installer-team/debian-installer/-/commit/95fdc73ca8cde8d7a360fd3d742fc947a045ec0f
> "Drop fontconfig tweaks introduced in version 20170828 (See: #873462)" 
> comes to my mind, also included in alpha3 ... ???

Irrelevant in the end.

> The text installer seems to be not affected (well, only Persian from
> the langs above is available in text installer, and Persian works
> there).

Not surprising in hindsight since that's libpango. :)

> We already have 
> "Bug#983897: installation-reports: Installation in Uyghur hangs"
> where the installer hangs at some later steps - noticed for Uyghur and
> Kannada so far...

Yes, this is likely the kind of “bad luck somewhen” similar to what
happens with rescue mode for some languages (e.g. English) but not all
(e.g. neither French nor German).

> Uyghur is however not affected by this language chooser fail bug.

This part is likely explained by the fact it's at `2 M` while affected
languages are at `2 P` in `build/translation-status`. Note that all
languages at `2 P` don't trigger this bug though (e.g. Telugu doesn't).
Full list at `2 P`:
  am bn bo bs dz ka km ku lo mk ne nn si tl


Back to the “bad luck somewhen” aspect for Uyghur, it would be nice to
check with an unpatched and with a patched image. I might try and do
that at some point, but since both #987377 and this bug are being
confirmed as originating from the same issue (#987587), it looks to me
like I should move on to trying to find a solution (sticking to an old
version of the udeb isn't really a suitable one…).

> As already mentioned by Samuel, this may be another resurgence - in a
> tightened form - of
> "#929877: installation-reports: Buster installer hangs at hard disk step with 
> arabic language"
> from 2019, where the real reason has not been found...

From a quick read, I would think that's a rather different issue, due to
difficulties with some specific glyphs or glyph combinations.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: Re: Bug#987449: [rc-1 graphical d-i] graphical installer hangs at language chooser step for several languages

[Debian Bug Tracking System]

Processing control commands:

> block -1 by 987587
Bug #987449 [debian-installer] [rc-1 graphical d-i] graphical installer hangs 
at language chooser step for several languages
987449 was not blocked by any bugs.
987449 was blocking: 987441
Added blocking bug(s) of 987449: 987587

-- 
987449: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987449
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#987742: bind9: CVE-2021-25215clearclear

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.16.13-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for bind9.

CVE-2021-25215[0]:
| An assertion check can fail while answering queries for DNAME records
| that require the DNAME to be processed to resolve itself

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-25215
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25215
[1] https://kb.isc.org/docs/cve-2021-25215

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987743: bind9: CVE-2021-25216

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.16.13-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for bind9.

CVE-2021-25216[0]:
| A second vulnerability in BIND's GSSAPI security policy negotiation
| can be targeted by a buffer overflow attack

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-25216
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25216
[1] https://kb.isc.org/docs/cve-2021-25216

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987741: bind9: CVE-2021-25214

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.16.13-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for bind9.

CVE-2021-25214[0]:
| A broken inbound incremental zone update (IXFR) can cause named to
| terminate unexpectedly

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-25214
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25214
[1] https://kb.isc.org/docs/cve-2021-25214

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#987608: marked as done (shibboleth-sp: CVE-2021-31826: Session recovery feature contains a null pointer deference)

[Debian Bug Tracking System]

Your message dated Wed, 28 Apr 2021 20:19:04 +
with message-id 
and subject line Bug#987608: fixed in shibboleth-sp 3.2.2+dfsg1-1
has caused the Debian Bug report #987608,
regarding shibboleth-sp: CVE-2021-31826: Session recovery feature contains a 
null pointer deference
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
987608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987608
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: shibboleth-sp
Version: 3.0.2+dfsg1-1
Severity: important
Tags: upstream patch security
Forwarded: https://issues.shibboleth.net/jira/browse/SSPCPP-927

Shibboleth Service Provider Security Advisory [26 April 2021]

An updated version of the Service Provider software is now
available which corrects a denial of service vulnerability.

Session recovery feature contains a null pointer deference
==
The cookie-based session recovery feature added in V3.0 contains a
flaw that is exploitable on systems *not* using the feature if a
specially crafted cookie is supplied.

This manifests as a crash in the shibd daemon/service process.

Because it is very simple to trigger this condition remotely, it
results in a potential denial of service condition exploitable by
a remote, unauthenticated attacker.

Versions without this feature (prior to V3.0) are not vulnerable
to this particular issue.

Recommendations
===
Update to V3.2.2 or later of the Service Provider software, which
is now available.

In cases where this is not immediately possible, configuring a
DataSealer component in shibboleth2.xml (even if used for nothing)
will work around the vulnerability.

For example:



This workaround is only possible after having updated the
core configuration to the V3 XML namespace.

Other Notes
===
The cpp-sp git commit containing the fix for this issue is
5a47c3b9378f4c49392dd4d15189b70956f9f2ec


URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20210426.txt
--- End Message ---
--- Begin Message ---
Source: shibboleth-sp
Source-Version: 3.2.2+dfsg1-1
Done: Ferenc Wágner 

We believe that the bug you reported is fixed in the latest version of
shibboleth-sp, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 987...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ferenc Wágner  (supplier of updated shibboleth-sp package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 27 Apr 2021 12:11:06 +0200
Source: shibboleth-sp
Architecture: source
Version: 3.2.2+dfsg1-1
Distribution: unstable
Urgency: high
Maintainer: Debian Shib Team 
Changed-By: Ferenc Wágner 
Closes: 987608
Changes:
 shibboleth-sp (3.2.2+dfsg1-1) unstable; urgency=high
 .
   * [e44283d] New upstream release: 3.2.2
 High urgency because it fixes CVE-2021-31826:
 Session recovery feature contains a null pointer dereference
 The cookie-based session recovery feature added in V3.0 contains a
 flaw that is exploitable on systems *not* using the feature if a
 specially crafted cookie is supplied.
 This manifests as a crash in the shibd daemon.
 Because it is very simple to trigger this condition remotely, it
 results in a potential denial of service condition exploitable by
 a remote, unauthenticated attacker.
 Thanks to Scott Cantor (Closes: #987608)
   * [3a6ac33] Refresh our patches
Checksums-Sha1:
 51abae0103692c6eb756a0684f956236c766bab3 2891 shibboleth-sp_3.2.2+dfsg1-1.dsc
 15d60364156cd8fd2c60db273cba85f5c28bc075 640648 
shibboleth-sp_3.2.2+dfsg1.orig.tar.xz
 f185a257f713b667f861b0cbc83f9270618a84c9 42116 
shibboleth-sp_3.2.2+dfsg1-1.debian.tar.xz
 cb8f6304381f00faa35b8480e962b646d25065cb 13102 
shibboleth-sp_3.2.2+dfsg1-1_amd64.buildinfo
Checksums-Sha256:
 b855713cb278c5d8051cfb248ad7245f58d7182470e8b6c9dec2552697a85fdf 2891 
shibboleth-sp_3.2.2+dfsg1-1.dsc
 14d0d2ca03adf44c77ed5e8738d537dbe6e9abe5a3d6f15d403f9b00964c9f00 640648 
shibboleth-sp_3.2.2+dfsg1.orig.tar.xz
 6a4d64544ff5f1bf8028b7ba87519ad50237f52ee157aa4d0138dcab542aef0d 42116 
shibboleth-sp_3.2.2+dfsg1-

Bug#987684: php-horde-crypt: flaky autopkgtest: Could not obtain public key from the keyserver

[Mike Gabriel]

Hi Paul,

On  Di 27 Apr 2021 20:00:13 CEST, Paul Gevers wrote:


Source: php-horde-crypt
Version: 2.7.12-5
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed it fails regularly
lately.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

By the way, if your test needs internet access, please mark that in the
restrictions with `needs-internet`.

Paul

[1] https://ci.debian.net/packages/p/php-horde-crypt/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-horde-crypt/11893421/log.gz

autopkgtest [14:12:26]: test phpunit: [---
PHPUnit 9.5.2 by Sebastian Bergmann and contributors.

Runtime:   PHP 7.4.15
Configuration:
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/phpunit.xml

Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/Pgp/BinaryTest.php
   Class name was 'Horde_Crypt_Pgp_BinaryTest', expected
'BinaryTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php
   Class name was 'Horde_Crypt_PgpKeyserverTest', expected
'PgpKeyserverTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpParseTest.php
   Class name was 'Horde_Crypt_PgpParseTest', expected
'PgpParseTest'
Warning:   Test case class not matching filename is deprecated
   in
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/SmimeTest.php
   Class name was 'Horde_Crypt_SmimeTest', expected 'SmimeTest'

...SSE26 /
26 (100%)

Time: 00:30.896, Memory: 6.00 MB

There was 1 error:

1) Horde_Crypt_PgpKeyserverTest::testBrokenKeyserver
Horde_Crypt_Exception: Could not obtain public key from the keyserver.

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/lib/Horde/Crypt/Pgp/Keyserver.php:110
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/lib/Horde/Crypt/Pgp/Keyserver.php:230
/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:80

--

There were 2 skipped tests:

1) Horde_Crypt_PgpKeyserverTest::testKeyserverRetrieve
Problem with
http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x4DE5B969:  
fopen(http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0x4DE5B969):

failed to open stream: HTTP request failed!

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:46

2) Horde_Crypt_PgpKeyserverTest::testKeyserverRetrieveByEmail
Problem with
http://pool.sks-keyservers.net:11371/pks/lookup?op=index&options=mr&search=jan%40horde.org:
fopen(http://pool.sks-keyservers.net:11371/pks/lookup?op=index&options=mr&search=jan%40horde.org):
failed to open stream: HTTP request failed!

/tmp/autopkgtest-lxc.pfr0ho3m/downtmp/build.LRx/src/Horde_Crypt-2.7.12/test/Horde/Crypt/PgpKeyserverTest.php:62

ERRORS!
Tests: 26, Assertions: 62, Errors: 1, Skipped: 2.
autopkgtest [14:12:58]: test phpunit: ---]


Oh well... That flakiness comes from the external keyserver being  
available and not available. I will patch the test to ignore a  
non-reachable keyserver.


Thanks for spotting this.

Mike (who currently is slightly over-worked and fails to get his work  
for Debian 11 done properly, grmpfwqerq...)




--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpdGJtE_1ziz.pgp
Description: Digitale PGP-Signatur

Bug#987201: marked as done (openbgpd: missing Breaks+Replaces: frr (<< 7))

[Debian Bug Tracking System]

Your message dated Wed, 28 Apr 2021 18:19:05 +
with message-id 
and subject line Bug#987201: fixed in openbgpd 6.8p1-3
has caused the Debian Bug report #987201,
regarding openbgpd: missing Breaks+Replaces: frr (<< 7)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
987201: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987201
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: openbgpd
Version: 6.8p1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../openbgpd_6.8p1-2_amd64.deb ...
  Unpacking openbgpd (6.8p1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/openbgpd_6.8p1-2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/man8/bgpd.8.gz', which is also in 
package frr 6.0.2-2+deb10u1
  Errors were encountered while processing:
   /var/cache/apt/archives/openbgpd_6.8p1-2_amd64.deb

There is only the conflict with the manpage, but no conflict with
any executable. There are no conflicts with frr 7.x in bullseye.


cheers,

Andreas


frr=6.0.2-2+deb10u1_openbgpd=6.8p1-2.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: openbgpd
Source-Version: 6.8p1-3
Done: Job Snijders 

We believe that the bug you reported is fixed in the latest version of
openbgpd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 987...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Job Snijders  (supplier of updated openbgpd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 22 Apr 2021 11:55:03 +0200
Source: openbgpd
Binary: openbgpd openbgpd-dbgsym
Architecture: source amd64
Version: 6.8p1-3
Distribution: unstable
Urgency: medium
Maintainer: Job Snijders 
Changed-By: Job Snijders 
Description:
 openbgpd   - OpenBSD BGP daemon
Closes: 987201
Changes:
 openbgpd (6.8p1-3) unstable; urgency=medium
 .
   * Mark conflict with frr (Closes: #987201)
Checksums-Sha1:
 d147e80ef2eb4607a152402d45c283cf4b762935 1852 openbgpd_6.8p1-3.dsc
 c1386b0116a365ade98569875020c40c116fc2a2 3392 openbgpd_6.8p1-3.debian.tar.xz
 7fe23c8f01fd61d1634a518ea64539892237e1fa 539348 
openbgpd-dbgsym_6.8p1-3_amd64.deb
 2a793b52f9be46f35ccc8f56340298213ff6df58 5813 openbgpd_6.8p1-3_amd64.buildinfo
 964f8cf1929532f91d942f362ce7262182f9003e 203348 openbgpd_6.8p1-3_amd64.deb
Checksums-Sha256:
 3aaf647bbd6fa44ef668ce8a9490c35b324ce1221341638ec15ee6948b3ea5b4 1852 
openbgpd_6.8p1-3.dsc
 7df6878f4086cf938259fd51d1e2a1fa42a67fd6e8b1e683702f98beb6b6409b 3392 
openbgpd_6.8p1-3.debian.tar.xz
 d7a93c789043e3b9e671eb53ebdd730baff9c6f0b44ed04e6d3ed7136ee18612 539348 
openbgpd-dbgsym_6.8p1-3_amd64.deb
 7a32d58d401b934ece5cd2d279a07ff036d393b5f00f6db7c6808b0639881a7b 5813 
openbgpd_6.8p1-3_amd64.buildinfo
 9a97dc3e30a41522106f22b4321b7bce53fecc0289bfa32b4a16112064a5a0f8 203348 
openbgpd_6.8p1-3_amd64.deb
Files:
 8ac585abb21974aa1406d87063480e95 1852 net optional openbgpd_6.8p1-3.dsc
 31b83d3788f4ff6f3b094df881c282a0 3392 net optional 
openbgpd_6.8p1-3.debian.tar.xz
 0f5d7d91b44acf3888c6339d00d2b6f9 539348 debug optional 
openbgpd-dbgsym_6.8p1-3_amd64.deb
 6dddf9ed0895ab8c3c3d519adb136725 5813 net optional 
openbgpd_6.8p1-3_amd64.buildinfo
 37c84cbe1676bc17315dc39db7a8647e 203348 net optional openbgpd_6.8p1-3_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEJ217d7abdWx8toZp3Sn4hEKDntMFAmCCzOsACgkQ3Sn4hEKD
ntPznQ/6A8ZYlMcnpBhzp7nVQp4ZEyRHoyZS28Bl5JlKKQO/2G3B6QKdI9BhduQw
Y4TV3zJTExyFuaaUlbBiCsBx61HlVCL7Wa/P2ysdSLvUjJeaTWygyViwYOggRmwd
JQVpo1tZLp/f+HxJ1d/8a6acNZTTGUmF0yWYCo7FbwUOEeSHl97dfapgTnK5ra

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,

On Wed, 2021-04-28 at 17:51 +0200, Cyril Brulebois wrote:
> > 
> > Why not just drop the dependency on udev and libopeniscsiusr
> entirely,
> > for the open-iscsi-udeb package ?
> 
> This is not sufficient:

Please review the attached patch. I build tested locally and the
results are below. If this looks good to you, then I'll prepare an
upload and ask the release team for an unblock.

I also opted to drop the explicit udev dependency.

rrs@priyasi:.../Result$ dpkg -I open-iscsi-udeb_2.1.3-2_amd64.udeb 
 new Debian package, version 2.0.
 size 248668 bytes: control archive=572 bytes.
 592 bytes,14 lines  control  
 Package: open-iscsi-udeb
 Source: open-iscsi
 Version: 2.1.3-2
 Architecture: amd64
 Maintainer: Debian iSCSI Maintainers 
 Installed-Size: 1341
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), libisns-
udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libsystemd0 (>=
247.3), scsi-modules
 Section: debian-installer
 Priority: optional
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
  multi-platform implementation of RFC3720 iSCSI.
  .
  This is the minimal package (udeb) used by debian-installer.


Thanks,
Ritesh
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
From b98d26b860ef7c989438d2641eaa5d2c514d2b51 Mon Sep 17 00:00:00 2001
From: Ritesh Raj Sarraf 
Date: Wed, 28 Apr 2021 22:13:39 +0530
Subject: [PATCH] Make open-iscsi-udeb compatible with d-i

In this change, we add libopeniscsiusr shared object explicitly to the udeb package to
avoid any reference to the libopeniscsiusr .deb package

We also add an override in shlibs generation

This oddity, that of open-iscsi-udeb shipping a library but open-iscsi
not shipping the library, is purely in the context of debian-installer

So, let's override and instruct mkshlibs to do the requested thing

And finally,
Drop explicit dependency on libopeniscsiusr and udev
---
 debian/control | 2 --
 debian/rules   | 6 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 0a4627f..a69ce2c 100644
--- a/debian/control
+++ b/debian/control
@@ -144,8 +144,6 @@ Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libopeniscsiusr,
- udev,
  scsi-modules
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,
diff --git a/debian/rules b/debian/rules
index 10584dd..1152be3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -69,6 +69,9 @@ override_dh_auto_install:
 	dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start sbin/iscsi-start
 	dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.finish-install usr/lib/finish-install.d/10open-iscsi
 
+	# We do this to keep the udeb in the installer happy
+	dh_install -p open-iscsi-udeb libopeniscsiusr/libopeniscsiusr*.so.* usr/lib/${DEB_HOST_MULTIARCH}
+
 override_dh_installinit:
 	dh_installinit -p open-iscsi --name=iscsid
 	dh_installinit -p open-iscsi
@@ -96,3 +99,6 @@ override_dh_installdocs:
 
 override_dh_missing:
 	dh_missing --fail-missing
+
+override_dh_makeshlibs:
+	dh_makeshlibs --add-udeb=open-iscsi-udeb
-- 
2.31.1



signature.asc
Description: This is a digitally signed message part

Bug#976704: po4a: Missing dependency on libpod-parser-perl

[Niko Tyni]

On Sun, Apr 25, 2021 at 09:40:02PM +0300, Adrian Bunk wrote:
> Control: reassign -1 perl 5.32.0-6
> Control: retitle -1 perl needs Breaks on more perl-modules-* packages
> Control: severity -1 serious
> Control: affects -1 po4a
> 
> On Mon, Dec 07, 2020 at 09:24:57AM +0100, Helge Kreutzmann wrote:
> >...
> > Versions of packages po4a depends on:
> >...
> > ii  perl5.32.0-5
> > ii  perl-modules-5.22 [libpod-parser-perl]  5.22.2-5
> >...
> 
> 5.32 != 5.22
> 
> #97 already fixed the same problem for perl-modules-5.24.

Indeed. As discussed there, certain versions of perl-modules-* in the
past Provided virtual packages such as libpod-parser-perl, without making
sure that those bundled modules were usable with the current /usr/bin/perl
on the system. This property broke later when perl was upgraded.

Versions earlier than 5.22 were not affected, and the issue was fixed
in perl-modules-5.26 5.26.2-5 with #899110. 5.24 (which was in stretch)
is already handled but I missed the other versions.

So this only happens with packages that were never in a stable
release. Not sure if that affects the severity. It should be easy to
fix by adding

 Breaks: perl-modules-5.22, perl-modules-5.26 (<< 5.26.2-5)

Any regressions seem improbable given these are leftovers from a time
before the current stable release.

Ubuntu has released with both 5.22 and an affected version of 5.26.
Haven't heard of similar issues there but a fix would possibly help
their users too (at least eventually.)

In general the coinstallability of older libperl5.xx and perl-modules-5.xx
packages with current ones is desirable to ease upgrades of packages
linking against libperl, such as postgresql.
-- 
Niko Tyni   nt...@debian.org

Bug#949767: arrayfire update fails in configure step

[Gard Spreemann]

Gard Spreemann  writes:

> Gard Spreemann  writes:
>
>> Andreas Tille  writes:
>>
>>> Hi Aaron,
>>>
>>> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote:
 Please try adding a build dependency on libclfft-dev and replacing
 src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
 to
 
   find_package(clFFT)
 
 > Thanks a lot for your initial hint
>>>
>>> Thanks again.  I now tried to learn from this and added a similar patch
>>> for CLBLast[1] but as you can see in the new log[2] it is not that
>>> simple.  I tried to compare the content of
>>> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb
>>> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking
>>> like and I need to admit I have no idea why this fails.
>>
>> This seems to be just a typo on my part. The logs have
>>
>> ***
>> CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package):
>>   By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has
>>   asked CMake to find a package configuration file provided by "CLBLast", but
>>   CMake did not find one.
>>   Could not find a package configuration file provided by "CLBLast" with any
>>   of the following names:
>> CLBLastConfig.cmake
>> clblast-config.cmake
>>   Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set
>>   "CLBLast_DIR" to a directory containing one of the above files.  If
>>   "CLBLast" provides a separate development package or SDK, be sure it has
>>   been installed.
>> ***
>>
>> libclblast-dev ships
>>
>>  /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake
>>
>> Notice that there's both "CLBLast" and "CLBlast" in there! I'll
>> investigate.
>
> Looks like an upstream bug; consider the inconsistent capitalization of
> the second l in "clblast" online 363 in
>
>  
> https://salsa.debian.org/gspr/clblast/-/blob/54e86eec37593623a5f692a39d78355043a402ad/CMakeLists.txt#L363
>
> I'll report it upstream and patch src:clblast.

Could you try with the patch from the debian/gspr/typo branch of [1]?
Alternatively, I put a built version of the patched clblast up at [2].


[1] https://salsa.debian.org/gspr/clblast.git

[2] https://nonempty.org/~gspr/clblast-typo/


 Best,
 Gard
 


signature.asc
Description: PGP signature

Bug#987728: wims-modules: depends on unavailable tinymce

[Andreas Beckmann]

Package: wims-modules
Version: 1:4.21f~dfsg1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   wims-modules : Depends: tinymce but it is not installable

tinymce has been removed recently: https://bugs.debian.org/977149


Cheers,

Andreas

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Cyril Brulebois]

Hi Ritesh,

Ritesh Raj Sarraf  (2021-04-28):
> That's an explicit dependency that got added in the merge I reviewed
> for 2.1.2.
> 
> Why not just drop the dependency on udev and libopeniscsiusr entirely,
> for the open-iscsi-udeb package ?

This is not sufficient:

--- a/debian/control
+++ b/debian/control
@@ -144,8 +144,6 @@ Section: debian-installer
 Package-Type: udeb
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libopeniscsiusr,
- udev,
  scsi-modules
 Description: Configure iSCSI
  The Open-iSCSI project is a high-performance, transport independent,

After a build:

(sid-amd64-devel)kibi@tokyo:~/hack/open-iscsi.git$ dpkg --info 
../open-iscsi-udeb_2.1.3-2_amd64.udeb|grep Depends
 Depends: libc6-udeb (>= 2.31), libcrypto1.1-udeb (>= 1.1.1k), 
libisns-udeb, libkmod2-udeb (>= 28), libmount1-udeb (>= 2.33), libopeniscsiusr, 
libsystemd0 (>= 247.3), scsi-modules

Notice that libopeniscsiusr is still there, which isn't surprising at
all. Executables shipped in the udeb refer to shared objects that are
referenced in its shlibs file!

(sid-amd64-devel)kibi@tokyo:~/hack/open-iscsi.git$ cat 
debian/libopeniscsiusr/DEBIAN/shlibs 
libopeniscsiusr 0.2.0 libopeniscsiusr

Random example:

(sid-amd64-devel)kibi@tokyo:~/hack/open-iscsi.git$ objdump -x 
debian/open-iscsi-udeb/sbin/iscsiadm | grep NEEDED
  NEEDED   libisns.so.0
  NEEDED   libcrypto.so.1.1
  NEEDED   libmount.so.1
  NEEDED   libkmod.so.2
  NEEDED   libopeniscsiusr.so.0.2.0
  NEEDED   libc.so.6

Hence my suggestion: shipped shared object(s) in the udeb directly, so
that there's no reference towards external packages.

A similar package is haveged, using debian/shlibs.local to ensure that
the “library resolution” (dh_shlibdeps) doesn't pull the deb library, by
making it explicit for the udeb that it contains the required shared
object(s).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987568: open-iscsi-udeb: uninstallable udeb: non-udeb dependencies

[Ritesh Raj Sarraf]

Hi Cyril,

On Sun, 2021-04-25 at 22:02 +0200, Cyril Brulebois wrote:
> but it seems the experimental uploads weren't fetched for some reason
> (I only glanced at git, didn't check what happened on the archive
> side).
> 
> Since the problem is about the dependency between the udeb and one of
> the library from the same package, a possibly easy fix could be to
> just
> ship the contents of the said library inside the udeb, along with the
> current contents.
> 
> That'd probably be about adjusting a .install file as opposed to
> adding
> a dedicated library udeb that would need some care for SONAME bumps,
> etc. (plus NEW of course).


That's an explicit dependency that got added in the merge I reviewed
for 2.1.2.

Why not just drop the dependency on udev and libopeniscsiusr entirely,
for the open-iscsi-udeb package ?

If you agree, then I can prepare an upload just dropping these.

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


signature.asc
Description: This is a digitally signed message part

Bug#949767: arrayfire update fails in configure step

[Gard Spreemann]

Gard Spreemann  writes:

> Andreas Tille  writes:
>
>> Hi Aaron,
>>
>> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote:
>>> Please try adding a build dependency on libclfft-dev and replacing
>>> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
>>> to
>>> 
>>>   find_package(clFFT)
>>> 
>>> > Thanks a lot for your initial hint
>>
>> Thanks again.  I now tried to learn from this and added a similar patch
>> for CLBLast[1] but as you can see in the new log[2] it is not that
>> simple.  I tried to compare the content of
>> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb
>> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking
>> like and I need to admit I have no idea why this fails.
>
> This seems to be just a typo on my part. The logs have
>
> ***
> CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package):
>   By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has
>   asked CMake to find a package configuration file provided by "CLBLast", but
>   CMake did not find one.
>   Could not find a package configuration file provided by "CLBLast" with any
>   of the following names:
> CLBLastConfig.cmake
> clblast-config.cmake
>   Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set
>   "CLBLast_DIR" to a directory containing one of the above files.  If
>   "CLBLast" provides a separate development package or SDK, be sure it has
>   been installed.
> ***
>
> libclblast-dev ships
>
>  /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake
>
> Notice that there's both "CLBLast" and "CLBlast" in there! I'll
> investigate.

Looks like an upstream bug; consider the inconsistent capitalization of
the second l in "clblast" online 363 in

 
https://salsa.debian.org/gspr/clblast/-/blob/54e86eec37593623a5f692a39d78355043a402ad/CMakeLists.txt#L363

I'll report it upstream and patch src:clblast.


 Best,
 Gard

Bug#949767: arrayfire update fails in configure step

[Gard Spreemann]

Andreas Tille  writes:

> Hi Aaron,
>
> On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote:
>> Please try adding a build dependency on libclfft-dev and replacing
>> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
>> to
>> 
>>   find_package(clFFT)
>> 
>> > Thanks a lot for your initial hint
>
> Thanks again.  I now tried to learn from this and added a similar patch
> for CLBLast[1] but as you can see in the new log[2] it is not that
> simple.  I tried to compare the content of
> libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb
> how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking
> like and I need to admit I have no idea why this fails.

This seems to be just a typo on my part. The logs have

***
CMake Warning at CMakeModules/build_CLBlast.cmake:8 (find_package):
  By not providing "FindCLBLast.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "CLBLast", but
  CMake did not find one.
  Could not find a package configuration file provided by "CLBLast" with any
  of the following names:
CLBLastConfig.cmake
clblast-config.cmake
  Add the installation prefix of "CLBLast" to CMAKE_PREFIX_PATH or set
  "CLBLast_DIR" to a directory containing one of the above files.  If
  "CLBLast" provides a separate development package or SDK, be sure it has
  been installed.
***

libclblast-dev ships

 /usr/lib/x86_64-linux-gnu/cmake/CLBLast/CLBlastConfig.cmake

Notice that there's both "CLBLast" and "CLBlast" in there! I'll
investigate.

 Best,
 Gard

Bug#949767: arrayfire update fails in configure step

[Andreas Tille]

Hi Aaron,

On Tue, Apr 27, 2021 at 08:14:10PM -0400, Aaron M. Ucko wrote:
> Please try adding a build dependency on libclfft-dev and replacing
> src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
> to
> 
>   find_package(clFFT)
> 
> > Thanks a lot for your initial hint

Thanks again.  I now tried to learn from this and added a similar patch
for CLBLast[1] but as you can see in the new log[2] it is not that
simple.  I tried to compare the content of
libclfft-dev_2.12.2-3.1_amd64.deb and libclblast-dev_1.5.2-1_amd64.deb
how the cmake files under /usr/lib/x86_64-linux-gnu/cmake/ are looking
like and I need to admit I have no idea why this fails.

Kind regards

Andreas.


[1] 
https://salsa.debian.org/science-team/arrayfire/-/blob/master/debian/patches/use_debian_packaged_libs.patch#L64
[2] https://salsa.debian.org/science-team/arrayfire/-/jobs/1611074#L1602

-- 
http://fam-tille.de

Processed: severity of 944867 is serious

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 944867 serious
Bug #944867 {Done: Roger Shimizu } [adjtimex] adjtimex cannot 
understand ntpdate output
Severity set to 'serious' from 'important'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
944867: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944867
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 986215

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 986215 + fixed-upstream
Bug #986215 [src:scrollz] scrollz: CVE-2021-29376
Added tag(s) fixed-upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
986215: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986215
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#986215: scrollz: CVE-2021-29376

[Tobias Frost]

Source: scrollz
Followup-For: Bug #986215
Control: tags -1 patch

Fixed upstream with commit: 
https://github.com/ScrollZ/ScrollZ/pull/26/commits/1155969d24e063b6d0b7e08b9b0c4ea8623f92ce

Processed: Re: scrollz: CVE-2021-29376

[Debian Bug Tracking System]

Processing control commands:

> tags -1 patch
Bug #986215 [src:scrollz] scrollz: CVE-2021-29376
Added tag(s) patch.

-- 
986215: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986215
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Debian Bug Tracking System]

Processing control commands:

> severity -1 normal
Bug #987683 [elpa-esup] crashes with "Wrong type argument: (or eieio-object 
class), nil, obj"
Severity set to 'normal' from 'grave'

-- 
987683: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987683
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Antoine Beaupré]

Control: severity -1 normal

On 2021-04-28 09:00:46, Lev Lamberov wrote:
> Hi Antoine,
>
> Вт 27 апр 2021 @ 13:53 Antoine Beaupre :
>
>> Package: elpa-esup
>> Version: 0.7.1-3
>> Severity: grave
>> Tags: upstream
>>
>> This package is unusable in Debian 11 bullseye in its current
>> state. In my Emacs 1:27.1+1-3.1 session, i run M-x esup and I get:
>>
>> error in process sentinel: Wrong type argument: (or eieio-object class), 
>> nil, obj
>>
>> *Messages* has this:
>>
>> Loading /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup-autoloads.el 
>> (source)...done
>> Starting esup...
>> esup process started on port 37851
>> at 1
>> error in process sentinel: slot-value: Wrong type argument: (or eieio-object 
>> class), nil, obj
>> error in process sentinel: Wrong type argument: (or eieio-object class), 
>> nil, obj
>>
>> This is the upstream bug: https://github.com/jschaf/esup/issues/85
>>
>> It looks like it is a packaging issue, since, according to the above
>> bug report, recompiling the .el files fixes the problem (haven't tested).
>
> Thanks for reporting, investigating and forwarding!
>
> Is it a fresh install of elpa-esup?

Yes, installed from the Debian package in Bullseye.

> I have elpa-esup installed for a long time and I cannot reproduce the
> bug on my machine. Running esup starts another GNU Emacs session and
> gives me a proper report on startup like the following excerpt:

Oh interesting! Maybe that's why it works, since the bytecode is older?

> ```
> Total User Startup Time: 0.357sec Total Number of GC Pauses: 3 Total 
> GC Time: 0.065sec
>
> package.elc:16  0.134sec   37%
> (byte-code "\301\302!\210\301\303!\210 [...]
> ```
>
> I wonder how recompiling could fix the problem you face, since
> installing/reinstalling the package or GNU Emacs itself should trigger
> recompilation of it along with all other installed Emacs packages.

Yeah, as I said I haven't tried to recompile myself, that's just what
the upstream bug report says. If anything, maybe it's the opposite and
if *you* recompile you'll trigger the bug? No idea.

[...]

> So, may it be a bug in dh-elpa or GNU Emacs itself?

Maybe! This is way beyond my elisp-fu unfortunately.

One key information I have just discovered is that I can't reproduce
with `emacs -q`. So this is probably an interaction with my .emacs.d
configuration and the package, unfortunately. Downgrading severity.

a.

-- 
While the creative works from the 16th century can still be accessed
and used by others, the data in some software programs from the 1990s
is already inaccessible.
 - Lawrence Lessig

Bug#944431: Salzburg BSP

[Markus Koschany]

Hi Philip,

thank you for the reminder and the debdiff. Indeed I wanted to fix this issue
in Buster too but it seems I forgot to do it. I have requested a buster-pu
(#987719) and already uploaded the package.

Cheers,

Markus


signature.asc
Description: This is a digitally signed message part

Bug#986986: marked as done (libretro-mgba: doesn't work in retro-runner: undefined symbol: glUniform2i)

[Debian Bug Tracking System]

Your message dated Wed, 28 Apr 2021 11:18:29 +
with message-id 
and subject line Bug#986986: fixed in mgba 0.8.4+dfsg-2
has caused the Debian Bug report #986986,
regarding libretro-mgba: doesn't work in retro-runner: undefined symbol: 
glUniform2i
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
986986: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986986
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: libretro-mgba
Version: 0.8.4+dfsg-1
Severity: important
Control: affects -1 gnome-games-app

In bullseye, invoking libretro-gba from GNOME Games doesn't work. Other cores 
such as nestopia and bsnes are working fine.

I debugged into retro-runner and got this:

(gdb) n
100 in ../../../gmodule/gmodule-dl.c
(gdb) p handle
$2 = (gpointer) 0x0
(gdb) p dlerror()
$3 = 0x7fffe8015030 "/usr/lib/x86_64-linux-gnu/libretro/mgba_libretro.so: undefined 
symbol: glUniform2i"

I guess libretro-mgba needs to link -lGL.

It does work in retroarch, but I'm guessing that's probably by coincidence, as 
retroarch already links -lGL itself.

-- System Information:
Debian Release: bullseye/sid
 APT prefers testing
 APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libretro-mgba depends on:
ii  gnome-games-app [libretro-frontend]  3.38.0-1
ii  libc62.31-11
ii  libinih1 53-1+b2
ii  retroarch1.7.3+dfsg1-1.1+b2
ii  zlib1g   1:1.2.11.dfsg-2

libretro-mgba recommends no packages.

libretro-mgba suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: mgba
Source-Version: 0.8.4+dfsg-2
Done: Ryan Tandy 

We believe that the bug you reported is fixed in the latest version of
mgba, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 986...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ryan Tandy  (supplier of updated mgba package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 20 Apr 2021 18:31:14 -0700
Source: mgba
Architecture: source
Version: 0.8.4+dfsg-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team 
Changed-By: Ryan Tandy 
Closes: 986986
Changes:
 mgba (0.8.4+dfsg-2) unstable; urgency=medium
 .
   * Add upstream patches to remove unused OpenGL code from the libretro core
 and fix its undefined references. (Closes: #986986)
 - debian/patches/CMake-Move-gl.c-and-gles2.c-to-FEATURE_SRC.patch
 - debian/patches/CMake-Move-BUILD_GL-flags-to-FEATURE_DEFINES.patch
   * Add upstream patch to fix PC alignment check when loading a save state.
 - debian/patches/GBA-Serialize-Fix-alignment-check-when-loading-state.patch
   * Add upstream patch to fix crash when unloading a Game Boy ROM in a
 libretro frontend that doesn't implement the camera interface.
 - debian/patches/Libretro-Only-set-camera-peripheral-when-it-is-avail.patch
   * Add upstream patches to fix crashes identified by fuzz testing.
 - debian/patches/Core-Fix-destroying-an-mVL-with-an-invalid-channel-c.patch
 - debian/patches/GB-MBC-Remove-unused-SRAM-size.patch
 - debian/patches/GB-MBC-Force-minimum-SRAM-size-on-rare-MBCs-that-alw.patch
 - debian/patches/GB-Video-Don-t-rendering-negative-batches.patch
 - debian/patches/GB-Video-Fix-deserializing-negative-LX-state.patch
 - debian/patches/GB-Video-Discard-SGB-packets-in-non-SGB-mVLs.patch
Checksums-Sha1:
 234f8ea58a795ae83817d0a438d6e9d333eede24 2696 mgba_0.8.4+dfsg-2.dsc
 a6847007e8609cd3103807fb70b5f87659b1fd6d 16700 mgba_0.8.4+dfsg-2.debian.tar.xz
 dd65860057b038d936e03f26a2042a4fdd767f06 21396 
mgba_0.8.4+dfsg-2_amd64.buildinfo
Checksums-Sha256:
 e98d3383491e8c4b1065156dbfea8dda5dfddab40f634194898591fe25596d9a 2696 
mgba_0.8.4+dfsg-2.dsc
 c9a708e91713e219f21bcb9221ef689383112212a91cf9cbb98a2dc109afb760 16700 
mgba_0.8

Bug#987504: imagemagick: attempt to perform an operation not allowed by the security policy `EPS'

[Adrian Bunk]

On Wed, Apr 28, 2021 at 06:43:02AM +0200, Salvatore Bonaccorso wrote:
> Hi Adrian,

Hi Salvatore,

> On Sat, Apr 24, 2021 at 11:20:43PM +0300, Adrian Bunk wrote:
>...
> > Options are either reverting the imagemagick change or fixing
> > the packages that got broken in bullseye and buster.
> > 
> > Security and release teams are Cc'ed.
> 
> No time for a more lenghty reply to this right now, but our point was
> exactly to bring the same patch (already applied in the last DSA) as
> well in bullseye's version as this was missing and discussed back then
> and recently with the maintainer as well.
> 
> If this is not the case yet, are bugs filled against those packages
> you found to be failing to build now due to this change in stable and
> unstable?

my question was exactly how to move forward here.

If everyone (including the release team) agrees that the imagemagick 
change should stay and RC bugs be filed, I can do the bug filing.

> Regards,
> Salvatore

cu
Adrian

Processed: remove pending tag after cloning the ca-certificates issue

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 987602 - pending
Bug #987602 [src:ca-certificates] 
ca-certificates-java,default-jre-headless,openjdk-11-jre-headless: get rid of 
the circular dependency
Removed tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
987602: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987602
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#987566: ghostscript: PDF Interpreter error on armel

[Jonas Smedegaard]

Control: severity -1 normal

Hi Guilhem,

Quoting Guilhem Bonnefille (2021-04-25 20:52:16)
> Package: ghostscript
> Version: 9.27~dfsg-2+deb10u4
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Initialy, I found the bug by updating from Debian stretch to buster 
> (10.9): the printer was working on stretch but no more on buster. The 
> device was running on armel. I did tests on i686 and it works.
> 
> After investigation, I was able to identify the « smallest » error context. 
> The following command:
> 
> gs -dPDFDEBUG -dPARANOIDSAFER -dNOPAUSE -dNOINTERPOLATE -dNOMEDIAATTRS 
> -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=jpeg 
> -sMediaType=Automatic -sOutputType=0 -r600x600 -dMediaPosition=7 
> -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=841 -dcupsMediaType=-1 
> -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=17 -dcupsInteger0=26 
> -scupsPageSizeName=A4 -I/usr/share/cups/fonts -c '< 9.00 9.00 9.00] /Margins[0 0]>>setpagedevice' -f -_ < 
> /tmp/ades.cups-pdf >/dev/null
> 
> Produces error messages on armel but not on i686:
> 
> 8.3 0 0 8.3 0 0 cm
> BT
> Error reading a content stream. The page may be incomplete.
>Output may be incorrect.
> Error: Form stream has unbalanced q/Q operators (too many q's)
>Output may be incorrect.
> Q
> Q
> Error: File did not complete the page properly and may be damaged.
>Output may be incorrect.
> %Resolving: [1 0]
> 
> The input is obtained from hp-setup print test page (PS) converted to 
> cups-pdf with cupsfilter, which certainly means that gs is not able to 
> read a PDF it generates.

Thanks for the bugreport - the details provided is much appreciated!

A key piece is missing, however: Please provide a sample file which - 
like you describe - succeeds to be processed by Ghostscript on i686 and 
armel/stretch but fails on armel/buster.

Would also be helpful if you could check that same file can be 
succesfully parsed by other PostScript parsers - e.g. Evince, xpdf, and 
(if you have access to that) Adobe applications.


I am lowering severity: That field reflects the package as a whole not 
the specific issue reported, and I don't consider this issue so severe 
that Debian would be better off without Ghostscript if it cannot be 
solved.  Don't worry - it is common to mistake the scope of the severity 
field :-)


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Processed: Re: Bug#987566: ghostscript: PDF Interpreter error on armel

[Debian Bug Tracking System]

Processing control commands:

> severity -1 normal
Bug #987566 [ghostscript] ghostscript: PDF Interpreter error on armel
Severity set to 'normal' from 'grave'

-- 
987566: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987566
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems