Bug#985604: sweethome3d svg export bug

[Andrius Merkys]

On 2021-03-23 01:16, Markus Koschany wrote:
> Am Montag, den 22.03.2021, 07:55 +0200 schrieb Andrius Merkys:
>> On 2021-03-20 18:05, Антон Скрипка wrote:
>>> When export to SVG:
>>>
>>> Java 3D: implicit antialiasing enabled
>>> java.lang.NoClassDefFoundError:
>>> org/freehep/graphicsbase/util/UserProperties
>>
>> I confirm this bug. Apparently, sweethome3d does not locate JAR of
>> libfreehep-graphicsbase-java. I have fixed this [1], will try to get the
>> fix for bullseye release.
> 
> Thanks for taking care of this Andrius. This must have been changed when
> freehep was updated a while ago.

No problem. Indeed, this bug was caused after updating freehep. I am
working on getting the fix into bullseye.

There is one more issue related to freehep update, #985690. However, I
do not yet see how it manifests, thus it may be a minor one.

Best,
Andrius

Bug#985692: unblock: sweethome3d/6.4.2+dfsg-2

[Andrius Merkys]

Control: tags -1 - moreinfo

On 2021-03-22 21:26, Sebastian Ramacher wrote:
> Control: tags -1 confirmed moreinfo
> 
> On 2021-03-22 12:03:55 +0200, Andrius Merkys wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Dear release-team,
>>
>> I am seeking pre-approval to upload sweethome3d/6.4.2+dfsg-2.
> 
> Please go ahead and removed the moreinfo tag once the version is
> available in unstable.

Thanks! Uploaded sweethome3d/6.4.2+dfsg-2 to unstable.

Best,
Andrius



signature.asc
Description: OpenPGP digital signature

Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2

[Andrius Merkys]

On 2021-03-23 02:08, Mathias Gibbens wrote:
> On Tue, 2021-03-16 at 12:57 +0200, Andrius Merkys wrote:
>> On 2021-03-15 19:28, Mathias Gibbens wrote:
 I have reviewed your packaging, and saw libcurl4-openssl-dev
 among
 the build dependencies. Do you know what does openrct2 need it
 for?
 My concern here is that in-game network access/downloads may
 interfere with Debian policies.
>>>
>>>   Grepping through the code, it appears that openrct2 uses the
>>> libcurl
>>> dependency primarily in two places. The first is to automatically
>>> download missing objects referenced in a scenario or save game.
>>> There's
>>> a vibrant community of openrct2 fans who create custom scenery
>>> objects,
>>> and it looks like this is a helper to fetch missing custom objects.
>>> I've not gotten into this aspect of the game, so I haven't
>>> personally
>>> used it. The second place libcurl is used is in support of
>>> multiplayer
>>> connection making.
>>>
>>>   Both of these only happen when the end-user is running the
>>> program,
>>> so I think that shouldn't run afoul of Policy. (I know network
>>> access
>>> during build is verboten, which is why there's an
>>> override_dh_auto_configure in d/rules and corresponding component
>>> source tars [more below].)
>>
>> Thanks for checking this out. Both use cases are indeed not violating
>> the policy.
>>
>> However, we need to make sure the downloader for missing objects
>> knows
>> the right place to put them. It must not attempt writing outside
>> user's
>> home directory.
> 
>   Yes, by default openrct2 places all config, save games, objects, etc
> in ~/.config/OpenRCT2/. It also respects the XDG_CONFIG_HOME
> environment variable.

Good then. Thanks for confirming.

 I fail to build the package as of
 e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with
 the
 following error log (only the last lines):

 [snip]

 Any ideas what might have gone wrong?
>>>
>>>   This is the first package I've created that contains multiple
>>> upstream tarballs as described in uscan(1). The normal openrct2
>>> build
>>> downloads a handful of pre-generated metadata (the "objects"
>>> component
>>> tarball) and custom scenarios for the opening sequence (the "title-
>>> sequences" component tarball) at build time, but we can't do that
>>> in
>>> Debian. So I added them as additional sources. The error you're
>>> seeing
>>> indicates that for some reason they aren't being properly extracted
>>> into the source directory prior to starting the build.
>>
>> Indeed, this must be the problem on my side, due to incorrectly
>> created
>> upstream tarball. I admit I know very little about multiple upstream
>> tarballs (MUTs).
>>
>> However, in this case it looks like the split of the MUT to
>> individual
>> source packages would make sense. They seem to have version numbers
>> on
>> their own, and I notice no signs in them being released in a
>> lockstep.
>> For example, it might happen that at some point objects or
>> title-sequences are released more often that the main game, and
>> bumping
>> Debian version of the MUT just to update the components will become
>> tedious. What do you think about splitting?
> 
>   It would certainly be easy enough to split the components out into
> three distinct source packages:
> 
> openrct2
> openrct2-objects
> openrct2-title-sequences
> 
>   And then have openrct2 depend on the other two to properly bring in
> all the required bits of the program.

I would suggest exactly the same.

>   I set things up using MUTs to try to reflect upstream's build process
> as closely as possible, but as you point out having three distinct
> packages will allow more flexibility when updating in the future.
> 
>   My only question would be if having three different packages would
> make the RFS process any harder, and if I should then file two more RFS
> bugs for the two new source packages.

I do not think this would make RFS process any harder. As the releases
of these three packages do not happen in a lockstep, you would probably
want to upload the MUT whenever any of them is released anyway. MUT
might save extra RFSes in case of simultaneous release, but I do not
think this is worth optimizing for.

In practice, instead of filing RFSes I used to ping my initial
sponsor(s) with a list of packages I want to get uploaded. RFS is a
formal request, but I see people directly mailing packaging teams with
requests for uploads. And maybe at some point you will become a DD and
will be able to upload packages yourself.

>   Thanks for helping me build a better package(s)!

Thank you for working on openrct!

Best wishes,
Andrius

Bug#985719: praat: Menu bar invisible

[Rafael Laboissière]

Control: tags -1 + moreinfo unreproducible

I cannot reproduce the bug on my system with Gnome/Xorg. Does the problem 
occur only in Praat for you or also in other GTK3 programs?


Best regards,

Rafael Laboissière

* Joonas Kylmälä  [2021-03-22 18:17]:


Package: praat
Version: 6.1.40-1
Severity: important
X-Debbugs-Cc: joonas.kylm...@iki.fi

Dear Maintainer,

The top menu bar that is supposed to be shown on "Praat Objects" 
window is invisible. It happens both on debian testing and the latest 
version from the expiremental repo. I'm using Gnome on Wayland, I am 
unable to confirm whether it would work on Gnome on Xorg because Gnome 
on Xorg seems to be broken on Debian testing (it doesn't start for me 
at all).


I'm able to workaround the problem now by guessing the position of 
each menu item and having the program in full screen. E.g. when "Praat 
Objects" window is in full screen I can click just above "Objects:" 
and I will get the menu that says:


About Praat 
New Praat Script 
...


Thanks for looking into this, 
Joonas


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


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

Versions of packages praat depends on: 
ii  libasound2   1.2.4-1.1 
ii  libc62.31-9 
ii  libcairo21.16.0-5 
ii  libgcc-s110.2.1-6 
ii  libglib2.0-0 2.66.7-2 
ii  libgtk-3-0   3.24.24-3 
ii  libpango-1.0-0   1.46.2-3 
ii  libpangocairo-1.0-0  1.46.2-3 
ii  libpulse014.2-2 
ii  libstdc++6   10.2.1-6 
ii  libx11-6 2:1.7.0-2 
ii  oss-compat   7 
ii  python3  3.9.2-2


praat recommends no packages.

praat suggests no packages.

-- no debconf information

Bug#985766: plocate-updatedb.timer: fires at exactly midnight

[Calum McConnell]

Package: plocate
Version: 1.1.5-1
Severity: minor
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The current timer shipped by plocate simply fires the
service every day at midnight.  That is bad practice,
since if everyone did it, computers would all hang
at midnight as they get swamped with expiring timers.

Instead, use SystemD's RandomizedDelaySec and
AccuracySec to distribute jobs.  Adding 
RandomizedDelaySec=12h and AccuracySec=20min to the
timer unit file would cause SystemD to run the update
job at some point in the morning, and have the freedom
to align it with other jobs as needed.

Thank you!
Calum


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

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 plocate depends on:
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6
ii  liburing1   0.7-3
ii  libzstd11.4.8+dfsg-2.1

plocate recommends no packages.

Versions of packages plocate suggests:
ii  powermgmt-base  1.36
ii  systemd-sysv247.3-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAmBZYOsdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzI2ZA/+LyYskPo/dHnw17Gx
VZXwn3Hl5ZlUQNXVgvz86kgc+ngDauEUtznEZ+enYVtpxUkKNjoWsQ1taqdpq2JT
tsIReZwyeWB/ig3X3/U/VIGxg3OgrNOeMx68AqdHldpUXZav1OVb290yp2XOl4Ep
Yu1/GBmVVLTcTItQQsXg+hYgjgqhl5EfqzlCqxN+EFNvLmrmHoO0vbT0fl0PzobY
GP9Rz8Xddy+Oah8Ovi0FeOVZzkh9o3dTbH6MonTKtMKeGZiweJMiiB13ghZKDUBE
VlWgHavNMt/XiLyBtYPF4ZM1mRLVjx9aZFz9ZqDTDb9FeH+Fhjfe3cxXyINldTui
cSOPTwqhNC8KfS/E8oW+wSWYBKfJjcI003QA3jqTLuWf0a5iSSxZNqNwTguFWz39
7liKfUQPdz9UxwplJ4eYySiO5dgFYZcaXa5WjowlCLhhqNTPuqUyciHA/TxawlQH
5D5x9lS/vy2Zp7iBFFA3mwOvKzlj/kw/GmCGxJrrUxA5c8LMsrnWS/fFKrSYDmvJ
geABRgp67PQjS2aitFStXu0y6Faf48WgvmH1qZ1tecyx9auCAsuWgndrHvfSq2Ue
5sITHHizrATNanK2LXyWGiDdJsR5hSHyBe83PieRdCXFcE+mUBXOF+g8GebdEcnB
qRmu1H2JFeAQg0D1aT4hepnjFFI=
=te/R
-END PGP SIGNATURE-

Bug#985765: openjdk-17: non-free PKCS#11 headers

[Bastian Germann]

Source: openjdk-17
Severity: important
Version: 17~14-1
Control: affects -1 openjdk-11

OpenJDK includes the OASIS PKCS#11 headers in 
src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11*.h. It is 
unclear whether OASIS IPR is DFSG-free (see #952951). Most probably it 
is not: 
https://enterprise.dejacode.com/licenses/public/oasis-ipr-policy-2014/


libnss3-dev contains MPL-2.0 licensed drop-in replacements for the 
headers, which is already a build dependency and might be used instead.

Bug#985755: debian-installer: Bullseye netinst Installer doesn't find RTL8723DE Network Hardware

[Charles Curley]

On Mon, 22 Mar 2021 18:02:25 -0400
Kenneth Parker  wrote:

> Package: debian-installer
> Severity: important
> X-Debbugs-Cc: sea7k...@gmail.com


There is a lengthy discussion of the problem on the Debian User list,
starting at https://lists.debian.org/debian-user/2021/03/msg01089.html

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#981616: 981616 is fixed in 5.10.24-1

[Ryutaroh Matsumoto]

Control: close -1 5.10.24-1

I recheck the situation with Debian kernel 5.10.24 and
Debian firmware-brcm80211 20201218-3.
5GHz WiFi works fine with vc4 and without vc4.

Debian package of firmware-brcm80211 newer than 20201218-3
has a severe issue with 5GHz WiFi as reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984489
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985632
But it is a separate topic.

Best regards, Ryutaroh

Bug#954290: kexec doesn't do reboots on systemd install?

[Jerome Charaoui]

severity important
thanks

Hello,

After some time trying to figure this out, I came to the conclusion that 
/sbin/reboot via kexec, which is supposed to be the default behavior of 
this package, does not work with recent versions of systemd (eg. 
bullseye). Hence, upgrading the severity of this bug report.


The cause appears to be a change in systemd itself and has been 
discussed on the GitHub issue tracker [0] since it appears to affect 
other distributions as well. There also has been some discussion about 
this problem on Debian mailing lists [1].


Currently, the only way to use kexec I could find is to load a kernel 
manually using "kexec -l ..." followed by "systemctl kexec".


In the absence of a forthcoming fix, maybe the maintainer of this 
package should consider the inclusion of an appropriate errata in the 
bullseye release notes.


Thanks.

[0] https://github.com/systemd/systemd/issues/15029
[1] 
https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2020-February/040573.html

Bug#985764: nik4: Stale link in documentation

[Wookey]

Package: nik4
Version: 1.6-7
Severity: normal
Tags: upstream

The file /usr/share/doc/nik4/README.md.gz contains a link to
instructions at 
http://switch2osm.org/loading-osm-data/
which no longer exists.
I'm not sure what it should be replaced with.

Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine

[Ryutaroh Matsumoto]

Control: found -1 20210315-1

> I will re-check 20210315-1.

The system boots with 20210315-1 and the reported symtom remains in
the same way. Ryutaroh

Bug#985755: Steps to Recreate this Bug

[Kenneth Parker]

1.  Have Laptop, with the following WiFi Hardware (as per lspci Command):

 > Network controller: Realtek Semiconductor Co., Ltd. RTL8723DE
802.11b/g/n PCIe Adapter

2. Use Netinst CD to begin an Install.  I tried this with many different
ones, from Buster, Bullseye, Bullseye with Non-Free, Sid.

3. Follow Instructions up to Network Configuration.  Note:  I have used
both Text Installer and Expert Text Installer.

4.  Offending Step is, "Detect Network Hardware".

 It takes about a minute wait, before something, perhaps times out, and
it returns, sure that there is ONLY an Ethernet Port on the Laptop.

The Problem is Recreated.  It's hard to figure out how to describe
something so early in the Install Process.  Hopefully, this helps.

Kenneth Parker

Bug#985763: imx-code-signing-tool: DFSG issues with back_end-hsm

[Bastian Germann]

Source: imx-code-signing-tool
Severity: serious

code/back_end-hsm contains doc/HSM-CST_UG.pdf which has an unclear 
license and is probably not in source format. Also, the OASIS PKCS#11 
headers are contained in the subdirectory src/include. It is unclear 
whether OASIS is DFSG-free (see #952951).


As the package is not built with the hsm backend, an easy solution is 
removing it entirely.

Bug#982250: [Debian-on-mobile-maintainers] Upstream Efforts

[Christopher Talbot]

Hello,

Per this discussion, I created Debian packaging for upstream mmsd:
https://source.puri.sm/kop316/mmsd/-/tree/debian/latest

Commit f4b8b32477a411180be1823fdc460b4f7e1e3c9c (the commit before
adding the Debian Packaging) is in sync with 
https://git.kernel.org/pub/scm/network/ofono/mmsd.git (upstream)

There is only one patch, and it removes a compiler flag (-WError). 
It is required to allow mmsd to compile.

-- 
Respectfully,
Chris Talbot

On Mon, 2021-03-22 at 16:05 +0100, Guido Günther wrote:
> Hi,
> On Mon, Mar 22, 2021 at 10:00:58AM -0400, Chris Talbot wrote:
> > Good Morning,
> > 
> > I agree that this is a reasonable course of action. To make sure I
> > understand: should I change this bug to packaging upstream mmsd, or
> > should I close this bug and open a new bug to package upstream
> > mmsd?
> 
> Reusing this one is fine i think.
> Cheers,
>  -- Guido
> 
> > I am fine doing either one, but I want to make sure I do the
> > correct
> > one.
> > 
> > -- 
> > Respectfully,
> > Chris Talbot
> > 
> > On Mon, 2021-03-22 at 08:40 +0100, Guido Günther wrote:
> > > Hi Chris,
> > > On Tue, Mar 16, 2021 at 10:01:14AM -0400, Chris Talbot wrote:
> > > > Hello,
> > > > 
> > > > I attempted again to contact the upstream developers and did
> > > > not
> > > > recieve a response. Please see my message from Feb 24, 2021:
> > > > 
> > > > https://lists.ofono.org/hyperkitty/list/of...@ofono.org/thread/HFGZCER3I6G52SPSG44OC4KTHDO2ZEC6/
> > > > 
> > > > As such, does it make the most sense to keep this as a fork? As
> > > > far
> > > > as
> > > > I can tell, the original mmsd has been abandoned.
> > > > 
> > > > As another note, I reformatted the repository a bit. "Master"
> > > > has
> > > > the
> > > > most up to date version of mmsd:
> > > > https://source.puri.sm/kop316/mmsd/
> > > > 
> > > > And the Debian packaging is here:
> > > > https://source.puri.sm/kop316/mmsd/-/tree/debian/modemmanager/latest
> > > > 
> > > > I am still keeping the upstream patches seperate, but I am
> > > > wondering
> > > > what the best course of action is at this point.
> > > 
> > > I'd go about it like this:
> > > 
> > > - package 'upstream' mmsd for Debian and make it go into Debian.
> > > This
> > >   usually takes some time due to NEW processing
> > > - Once that passed depending on upstream feedback it would be
> > > either
> > > the
> > >   point in time to take over upsream maintenance of mmsd *or* add
> > > your
> > >   patches in `debian/patches`.
> > > 
> > > Does that make sense?
> > > Cheers,
> > >  -- Guido
> > > 
> > > 
> > > > Thank you!
> > > > 
> > > > -- 
> > > > Respectfully,
> > > > Chris Talbot
> > > > 
> > > > 
> > > > ___
> > > > Debian-on-mobile-maintainers mailing list
> > > > debian-on-mobile-maintain...@alioth-lists.debian.net
> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
> > > > 
> > 
> > 
> > ___
> > Debian-on-mobile-maintainers mailing list
> > debian-on-mobile-maintain...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers

Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine

[Ryutaroh Matsumoto]

Hi Maximilian, thank you again for your response.

> but are you sure that these
> bootflags are still adequate for the latest cypress firmware?

What did you mean by "bootflags"??
Did you mean /proc/cmdline (i.e. cmdline.txt in Raspberry Pi)?

> concerning bluetooth unfortunately this seems missing firmware
> in latest upstream firmware git (see #962038 ) or possible wget info
> https://wiki.debian.org/RaspberryPi4#Bluetooth

I know that bluetooth interferes with 2.4GHz WiFi with pure Debian
packages as reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984844

I do not see any intererence between bluetooth and 5GHz WiFi.
I doubt the intererence as bluetooth frequency does not overlap with 5GHz WiFi 
at all.
With the firmware 20210208-4, 2.4GHz WiFi works fine provided that
bluetooth is turned off by rfkill etc.

I am running a combination of pure Debian packages and
encountered the reported symptom. What is a Debian way to
use 5GHz WiFi? Do you need additional information?

> this should not be reproducible as 20210315-1 and 20210315-1~exp1 are
> unchanged (just uploaded into experimental before unstable).

I will re-check 20210315-1.

Best regards, Ryutaroh

Bug#985758: mozc: tegaki-zinnia-japanese shouldn't be a dependency after handwriting support was removed

[Gunnar Hjalmarsson]

X-Debbugs-Cc: danielzgtg.opensou...@gmail.com

I submitted a merge request, which also drops libzinnia-dev from 
Build-Depends and includes a related change in d/rules.


https://salsa.debian.org/debian/mozc/-/merge_requests/8

--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985334: treeline doesn't start

[Doug Bell]

Jörg Volkmann wrote:
> Package: treeline
> Version: 3.0.1-1.1
> 
> Treeline doesn't start,it shows only the message below

The Debian TreeLine package is broken.  Older versions of TreeLine are
not compatible with Python 3.9.  An upgrade to TreeLine 3.1.4 is
required to work with Python 3.9.

I recommend that users install from source, available on
.  It's not difficult to install.

-Doug

Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2

[Mathias Gibbens]

On Tue, 2021-03-16 at 12:57 +0200, Andrius Merkys wrote:
> Hi Mathias,
> 
> On 2021-03-15 19:28, Mathias Gibbens wrote:
> > > I have reviewed your packaging, and saw libcurl4-openssl-dev
> > > among
> > > the build dependencies. Do you know what does openrct2 need it
> > > for?
> > > My concern here is that in-game network access/downloads may
> > > interfere with Debian policies.
> > 
> >   Grepping through the code, it appears that openrct2 uses the
> > libcurl
> > dependency primarily in two places. The first is to automatically
> > download missing objects referenced in a scenario or save game.
> > There's
> > a vibrant community of openrct2 fans who create custom scenery
> > objects,
> > and it looks like this is a helper to fetch missing custom objects.
> > I've not gotten into this aspect of the game, so I haven't
> > personally
> > used it. The second place libcurl is used is in support of
> > multiplayer
> > connection making.
> > 
> >   Both of these only happen when the end-user is running the
> > program,
> > so I think that shouldn't run afoul of Policy. (I know network
> > access
> > during build is verboten, which is why there's an
> > override_dh_auto_configure in d/rules and corresponding component
> > source tars [more below].)
> 
> Thanks for checking this out. Both use cases are indeed not violating
> the policy.
> 
> However, we need to make sure the downloader for missing objects
> knows
> the right place to put them. It must not attempt writing outside
> user's
> home directory.

  Yes, by default openrct2 places all config, save games, objects, etc
in ~/.config/OpenRCT2/. It also respects the XDG_CONFIG_HOME
environment variable.

> 
> > > I believe uploads to unstable are discouraged only for packages
> > > already in testing, so targeting unstable here should be OK.
> > 
> >   OK, I've switched back to unstable and staged it locally. I'll
> > bundle
> > that with any other changes that come from the package review
> > process
> > before openrct2 gets uploaded to NEW.
> 
> Good, thanks.
> 
> > > I fail to build the package as of
> > > e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with
> > > the
> > > following error log (only the last lines):
> > > 
> > > [snip]
> > > 
> > > Any ideas what might have gone wrong?
> > 
> >   This is the first package I've created that contains multiple
> > upstream tarballs as described in uscan(1). The normal openrct2
> > build
> > downloads a handful of pre-generated metadata (the "objects"
> > component
> > tarball) and custom scenarios for the opening sequence (the "title-
> > sequences" component tarball) at build time, but we can't do that
> > in
> > Debian. So I added them as additional sources. The error you're
> > seeing
> > indicates that for some reason they aren't being properly extracted
> > into the source directory prior to starting the build.
> 
> Indeed, this must be the problem on my side, due to incorrectly
> created
> upstream tarball. I admit I know very little about multiple upstream
> tarballs (MUTs).
> 
> However, in this case it looks like the split of the MUT to
> individual
> source packages would make sense. They seem to have version numbers
> on
> their own, and I notice no signs in them being released in a
> lockstep.
> For example, it might happen that at some point objects or
> title-sequences are released more often that the main game, and
> bumping
> Debian version of the MUT just to update the components will become
> tedious. What do you think about splitting?

  It would certainly be easy enough to split the components out into
three distinct source packages:

openrct2
openrct2-objects
openrct2-title-sequences

  And then have openrct2 depend on the other two to properly bring in
all the required bits of the program.

  I set things up using MUTs to try to reflect upstream's build process
as closely as possible, but as you point out having three distinct
packages will allow more flexibility when updating in the future.

  My only question would be if having three different packages would
make the RFS process any harder, and if I should then file two more RFS
bugs for the two new source packages.

> 
> >   I personally use lxc containers which I can quickly spin up to
> > get a
> > clean minimal build environment, and the following commands build
> > the
> > openrct2 package for me:
> > 
> >dget -x 
> > https://mentors.debian.net/debian/pool/main/o/openrct2/openrct2_0.3.3+dfsg-1.dsc
> > dpkg-source -x openrct2_0.3.3+dfsg-1.dsc
> > cd openrct2-0.3.3+dfsg/
> > debuild
> > 
> >   I know there's several additional tools for building packages
> > (like
> > pbuilder), but I haven't really had a strong need to get those
> > working
> > due to my use of lxc.
> 
> I see. I have no knowledge about lxc builder, but somehow I imagine
> that
> it should have the same build sequence.
> 
> Best,
> Andrius
> 

  Thanks for helping me build a better package(s)!

Mathias


signature.asc
Description: 

Bug#952950: nss: Replace PKCS11 headers provided by OASIS

[Bastian Germann]

On Tue, 23 Mar 2021 00:18:08 +0100 Bastian Germann wrote:> Upstream had
a discussion about the license at
> https://phabricator.services.mozilla.com/D63241 and with OASIS at
> https://markmail.org/thread/4juvugfvj45iyrmp

As far as I can see, the license for NSS's PKCS#11 headers is MPL 2.0
(DFSG-free) and not the OASIS IPR.

Bug#985390: unblock: squid/4.13-7

[Santiago Garcia Mantinan]

Hi again!

I have just pushed:

https://salsa.debian.org/squid-team/squid/-/commit/fe8a10ef8ec40411bb59bec7af2b179796d4f4ef

I think I'm addressing all your concerns there, if you like it I'll run
tests tomorrow and upload the -9 package.

Thanks in advance.
-- 
Manty/BestiaTester -> http://manty.net

Bug#985762: debcargo fails to mark --all-features tests as non-flaky

[Daniel Kahn Gillmor]

Package: debcargo
Version: 2.4.4
Control: affects -1 src:rust-sequoia-openpgp

I'm updating sequoia-openpgp's debcargo.toml to currently contain the
following:

---
# sequoia always needs at least one crypto backend and nettle is
# currently the only crypto-backend available on debian systems.
# Since crypto-nettle is included in the default, and in
# --all-features we should expect those tests to succeed as well.
# See https://bugs.debian.org/985741 for more info.
[packages.lib]
test_is_broken = true
[packages."lib+crypto-nettle"]
test_is_broken = false
[packages."lib+default"]
test_is_broken = false
[packages."lib+@"]
test_is_broken = false
---

I'd expect this to produce a batch of tests where the only tests *not*
marked flakey are those tests that include the crypto-nettle feature
(see also #985741).

However, debcargo 2.4.4 generates a debian/tests/control file that
includes this stanza (note that the "flaky" restriction is included):

---
Test-Command: /usr/share/cargo/bin/cargo-auto-test sequoia-openpgp 1.1.0 
--all-targets --all-features
Features: test-name=rust-sequoia-openpgp:@
Depends: dh-cargo (>= 18), librust-quickcheck-0.9-dev, librust-rand-0.7-dev, 
librust-rpassword-5+default-dev, @
Restrictions: allow-stderr, skip-not-installable, flaky
---

I'll try to override this using the *.debcargo.hint mechanism, but i
don't understand why the [packages."lib+@"] special section isn't useful
for stripping the "flaky" restriction from the --all-features test, as
it appears to be documented in the example debcargo.toml.

--dkg


signature.asc
Description: PGP signature

Bug#985761: unblock: plymouth/0.9.5-3

[Laurent Bigonville]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: couc...@debian.org

Please unblock package plymouth

So apparently I forgot to ask for an unblock my last upload of plymouth

[ Reason ]
The main change is the switch to the new "homeworld" theme

The other changes are:

- Removing a dependency against a package removed from the archive 
(ttf-dejavu-core)
- Remove the support for /etc/vconsole.conf that is not used anywhere in
  debian.

[ Impact ]
Plymouth uses the old theme from Buster

[ Tests ]
Reboot and the new theme is displayed.

The keymap is still read properly from /etc/default/keyboard

[ Risks ]
NA

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock plymouth/0.9.5-3
diff -Nru plymouth-0.9.5/debian/changelog plymouth-0.9.5/debian/changelog
--- plymouth-0.9.5/debian/changelog 2020-12-09 15:58:50.0 +0100
+++ plymouth-0.9.5/debian/changelog 2021-03-02 13:18:12.0 +0100
@@ -1,3 +1,15 @@
+plymouth (0.9.5-3) unstable; urgency=medium
+
+  [ Laurent Bigonville ]
+  * debian/control: Remove dependency the ttf-dejavu-core alternative
+  * Don't use /etc/vconsole.conf after all as it's not used anywhere in debian
+  * d/p/0003-default-theme.patch: Switch to homeworld for bullseye
+
+  [ Simon McVittie ]
+  * Unfuzz 0008-show-delay.patch to apply cleanly
+
+ -- Laurent Bigonville   Tue, 02 Mar 2021 13:18:12 +0100
+
 plymouth (0.9.5-2) unstable; urgency=medium
 
   * debian/local/plymouth.hook: Copy logo-text-version-64.png in the initramfs
diff -Nru plymouth-0.9.5/debian/control plymouth-0.9.5/debian/control
--- plymouth-0.9.5/debian/control   2020-12-09 15:58:50.0 +0100
+++ plymouth-0.9.5/debian/control   2021-03-02 13:18:12.0 +0100
@@ -110,7 +110,7 @@
 Depends: fontconfig,
  fontconfig-config,
  fonts-cantarell,
- fonts-dejavu-core | ttf-dejavu-core,
+ fonts-dejavu-core,
  plymouth (= ${binary:Version}),
  plymouth-label (= ${binary:Version}),
  ${misc:Depends},
diff -Nru plymouth-0.9.5/debian/local/plymouth.hook 
plymouth-0.9.5/debian/local/plymouth.hook
--- plymouth-0.9.5/debian/local/plymouth.hook   2020-12-09 15:58:50.0 
+0100
+++ plymouth-0.9.5/debian/local/plymouth.hook   2021-03-02 13:18:12.0 
+0100
@@ -121,17 +121,12 @@
esac
fc-cache -s -y "${DESTDIR}" > /dev/null 2>&1
 
-   # copy /etc/default/keyboard and /etc/vconsole.conf (needed for 
keymap detection)
+   # copy /etc/default/keyboard (needed for keymap detection)
if [ -e /etc/default/keyboard ]
then
mkdir -p "${DESTDIR}/etc/default"
cp /etc/default/keyboard "${DESTDIR}/etc/default"
fi
-   if [ -e /etc/vconsole.conf ]
-   then
-   mkdir -p "${DESTDIR}/etc"
-   cp /etc/vconsole.conf "${DESTDIR}/etc"
-   fi
 
# for two-step
case "$(sed -n 's/^ModuleName=\(.*\)/\1/p' ${THEME})" in
diff -Nru plymouth-0.9.5/debian/patches/0003-default-theme.patch 
plymouth-0.9.5/debian/patches/0003-default-theme.patch
--- plymouth-0.9.5/debian/patches/0003-default-theme.patch  2020-12-09 
15:58:50.0 +0100
+++ plymouth-0.9.5/debian/patches/0003-default-theme.patch  2021-03-02 
13:18:12.0 +0100
@@ -7,7 +7,7 @@
  # Administrator customizations go in this file
  #[Daemon]
 -#Theme=fade-in
-+#Theme=futureprototype
++#Theme=homeworld
 --- a/src/plymouthd.defaults
 +++ b/src/plymouthd.defaults
 @@ -1,6 +1,6 @@
@@ -15,6 +15,6 @@
  # upgrades.
  [Daemon]
 -Theme=spinner
-+Theme=futureprototype
++Theme=homeworld
  ShowDelay=0
  DeviceTimeout=8
diff -Nru plymouth-0.9.5/debian/patches/0008-show-delay.patch 
plymouth-0.9.5/debian/patches/0008-show-delay.patch
--- plymouth-0.9.5/debian/patches/0008-show-delay.patch 2020-12-09 
15:58:50.0 +0100
+++ plymouth-0.9.5/debian/patches/0008-show-delay.patch 2021-03-02 
13:18:12.0 +0100
@@ -6,5 +6,5 @@
 @@ -1,3 +1,4 @@
  # Administrator customizations go in this file
  #[Daemon]
- #Theme=futureprototype
+ #Theme=homeworld
 +#ShowDelay=0
diff -Nru plymouth-0.9.5/debian/patches/fallback-etc-default-keyboard.patch 
plymouth-0.9.5/debian/patches/fallback-etc-default-keyboard.patch
--- plymouth-0.9.5/debian/patches/fallback-etc-default-keyboard.patch   
2020-12-09 15:58:50.0 +0100
+++ plymouth-0.9.5/debian/patches/fallback-etc-default-keyboard.patch   
2021-03-02 13:18:12.0 +0100
@@ -1,17 +1,17 @@
+Description: Use /etc/default/keyboard instead of /etc/vconsole.conf
+Forwarded: not-needed
+
 --- a/src/libply-splash-core/ply-terminal.c
 +++ b/src/libply-splash-core/ply-terminal.c
-@@ -136,6 +136,14 @@ 

Bug#952950: nss: Replace PKCS11 headers provided by OASIS

[Bastian Germann]

On Sun, 14 Feb 2021 00:29:59 +0100 t...@gaussglocke.de wrote:
> On Mon, 2 Mar 2020 17:16:09 +0800 Alvin Chen  wrote:
> > You can use an alternative header like p11-kit which is licensed under
> > a more liberal license.
> I had a look at the PKCS #11 headers; the biggest problem is that NSS
> uses version 3.00 while the p11-kit headers have been forked at 2.40 and
> not (yet?) updated, so a few structs and #defines are missing.
> 
> There's also a minor issue with CK_GCM_PARAMS, which used to have the
> wrong layout due to a documentation/header mismatch. NSS has two
> candidates of that struct, CK_GCM_PARAMS_V3 and CK_NSS_PARAMS, and
> selects one of those in pkcs11n.h depending on the NSS_PKCS11_2_0_COMPAT
> macro.
> 
> I might be looking into this a bit more and see if I can fix the p11-kit
> headers, if the Mozilla team agrees that this is a viable way to resolve
> this
> bug.

Upstream had a discussion about the license at
https://phabricator.services.mozilla.com/D63241 and with OASIS at
https://markmail.org/thread/4juvugfvj45iyrmp

Bug#985754: Bug #985754: dino-im

[Martin]

Thanks Sebastian for finding the bug,
thanks Michel for finding the upstream fix!
Will upload now!

Bug#985604: sweethome3d svg export bug

[Markus Koschany]

Am Montag, den 22.03.2021, 07:55 +0200 schrieb Andrius Merkys:
> Control: severity 985604 important
> Control: tags 985604 + confirmed
> 
> Hello,
> 
> On 2021-03-20 18:05, Антон Скрипка wrote:
> > When export to SVG:
> > 
> > Java 3D: implicit antialiasing enabled
> > java.lang.NoClassDefFoundError:
> > org/freehep/graphicsbase/util/UserProperties
> 
> I confirm this bug. Apparently, sweethome3d does not locate JAR of
> libfreehep-graphicsbase-java. I have fixed this [1], will try to get the
> fix for bullseye release.

Thanks for taking care of this Andrius. This must have been changed when
freehep was updated a while ago.

Markus


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

Bug#985733: ITP: jaraco.classes -- additional routines for obtaining the class names

[Jeroen Ploemen]

Package: wnpp
Severity: wishlist

Needed for recent versions of cherrypy3


pgphOZG9MBseU.pgp
Description: OpenPGP digital signature

Bug#985731: ITP: jaraco.text -- jaraco text manipulation functions

[Jeroen Ploemen]

Package: wnpp
Severity: wishlist

Needed for recent versions of cherrypy3


pgpzNtlYXk5QQ.pgp
Description: OpenPGP digital signature

Bug#985732: ITP: jaraco.collections -- models and classes to supplement the stdlib 'collections' module

[Jeroen Ploemen]

Package: wnpp
Severity: wishlist

Needed for recent versions of cherrypy3


pgpJ9r8I99fgx.pgp
Description: OpenPGP digital signature

Bug#985749: apt: "apt-mark hold" flag lost on package upgrade using --ignore-hold

[Sven-Haegar Koch]

On Mon, 22 Mar 2021, David Kalnischkies wrote:

> On Mon, Mar 22, 2021 at 10:21:59PM +0100, Sven-Haegar Koch wrote:
> > On some of my hosts I have a single or a very small number of packages
> > that I am only allowed to upgrade with specific procedures, pre-arranged
> > maintenance window and so on.
> > 
> > But for the rest of the packages I want to install Debian (security)
> > updates as soon as possible.
> > 
> > "apt-mark hold" sounds exactly like what I want.
> 
> I would think you are better of with apt_preferences as that is intended
> to control which packages are allowed to be upgraded (from where). As
> that is more powerful in some sense it is also not that easy to handle
> though: There is no simple flag e.g. – but using specific files for each
> you can disable as needed might be workable.

This is what I used before, always needing to move the preferences file 
away and back into place, which is a pain. And I am missing the nice 
note by the "held packages" part in the apt-get output to remind me to 
plan the next scheduled upgrade of those.

Right now I work around the loosing of the apt-mark by just running a 
cronjob every hour re-applying the mark. Very ugly but works.

> (It might be an interesting idea to allow preferences to be tagged and
>  to then to be ignored based on tag selection from the commandline…
>  that currently doesn't exist at all though and is just a silly random
>  idea popping into my head as I wrote this mail)

Sounds at least like an interesting idea.

Or perhaps just a commandline way to specify additional pin files 
outside of those included from /etc/apt/preferences.d directory 
automatically. If those specified from commandline are included after 
the currently read files you could override "do not upgrade" pins with 
it.

> > I hold the package, and with normal upgrade/dist-upgrade it works
> > exactly as expected.
> > 
> > But when I then upgrade these single package later using --ignore-hold,
> > the hold flag is lost afterwards.
> 
> holds are stored by dpkg as a "selection state", which e.g. install or
> deinstall are, too, and which will override the old selection state sort
> of by design.
> 
> It is also this way since the dawn of time, so that is kinda unlikely to
> change – resolving this bug might be as "simple" as adding a note that
> holds will be (potentially) lost if they are ignored.
> 
> Sorry, as that is probably not what you wanted to hear.

Thanks.

I think a note in the apt-get manpage on the options (--ignore-hold and 
--allow-change-held-packages) would already have helped me a lot - it 
took very long to figure out that my problem was indeed loosing the 
mark after upgrading the package - as usually the availability of the 
next version of a marked package happens weeks or months later.

And when you discover the mark missing on a dist-upgrade call then, you 
mostly think "I thought I set it, did I really also on this server?" :)

Never even got the idea that the hold would not be supposed to 
survive, neither from apt-get nor from apt-mark manpages.

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

Bug#985760: amd64-microcode: jessie-lts has newer version than stretch(-lts)

[Andreas Beckmann]

Package: amd64-microcode
Version: 3.20160316.3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: fixed -1 3.20181128.1

[jessie-lts]
Package: amd64-microcode
Version: 3.20181128.1~deb8u1

[stretch,stretch-lts]
Package: amd64-microcode
Version: 3.20160316.3

non-monotonic versions prevent proper upgrades.


Andreas

Bug#985754:

[Michel Le Bihan]

Upstream fixed this in
https://github.com/dino/dino/commit/9acb54df9254609f2fe4de83c9047d408412de28.patch

Bug#985721: unblock: fossil/1:2.15~rc1-1

[Sebastian Ramacher]

Control: tags -1 + moreinfo

On 2021-03-22 16:37:43 +, Barak A. Pearlmutter wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package fossil
> 
> [ Reason ]
> 
> Marked for autoremoval due to #985124.
> 
> The issue was fixed upstream. Given the nature of the package, I think
> tracking their release candidate is better than cherry-picking the
> change that appears directly related to this issue. They made a number
> of other safety-related fixes to ensure robustness and security in the
> face of old or compiled-with-wrong-options versions of SQLITE3. And
> nothing that looks scary.
> 
> [ Impact ]
> 
> Will allow fossil to be in the release.
> 
> [ Tests ]
> 
> There is a comprehensive test suite, which can be run automatically.
> It is disabled in debian/rules because the makefile says it needs to
> be run in a fossil repo that will be discarded after the test because
> the tests can corrupt it. Well, it used to say this: the comment is
> gone, so maybe it's okay now. But in any case, the system passes all
> tests right now.
> 
> [ Risks ]
> 
> This is a leaf package.
> 
> It ticks various boxes for security sensitivity, sort of the union of
> the security sensitivity of git and a web server and a wiki. Upstream
> is extremely responsive and careful. I think the best option is to
> follow upstream's recommendation, which is to track their releases.
> 
> [ Checklist ]
>   [X] all changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [ ] attach debdiff against the package in testing
> 
> I'm attaching the debdiff, but it's large. Due mainly to changes in
> the enclosed sqlite3 (unused unless the debian version is too old or
> otherwise unsuitable), and tweaks to static material in the integrated
> wiki.

 212 files changed, 12355 insertions(+), 12425 deletions(-)

We cannot review that in any reasonable way. Please provide a filtered debdiff.

Cheers

> 
> unblock fossil/1:2.15~rc2-1
> <#part type="application/octet-stream" filename="~/tmp/ddiff2" 
> disposition=attachment>
> <#/part>
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#985759: unblock: mosquitto/2.0.9-1

[Roger A. Light]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mosquitto

[ Reason ]
Mosquitto 2.0.8 is currently in testing, Mosquitto 2.0.9 was released on
2021-03-11 and has sufficiently important fixes in it that I believe
should be in a Debian release.

The full debdiff is 1110 lines. If I reduce that to code-only changes it
drops to 387 (the remainder are documentation and extra tests), with
about 150 lines of actual affected code. It is a small bugfix release
with low risk but some reasonably important fixes.

[ Impact ]
I have listed the fixes below that I think are worth mentioning. The
other changes are of minor impact or are fixing strict compiler
warnings.

Client and library: There is a fairly minor security issue that affects
outgoing client connections only - if an empty or corrupt CA certificate
is provided to a client, then the initial connection would fail but
subsequent connections would succeed without verifying the remote server
certificate. There is a new test for this behaviour, but it is not in
the 2.0.9 release.

Build: The CMake build script was not enabling epoll(), so poll() was
being used instead which has a very detrimental impact on performance.

Server: Messages published with QoS 0 were not being delivered when
`max_queued_bytes` was configured. This has a big impact on users
wanting to use QoS 0, which is the most common QoS, but also set some
client limits. There is a new test to check this behaviour.

Server: If the `max_keepalive` option was set, this did not apply to
clients connecting with keepalive set to 0 (which means "infinite keepalive").
This gives a very straightforward means to circumvent the wishes of the
server operator, although in itself it isn't very important.

Server: The behaviour setting acceptable TLS versions did not match the
documentation.

Server: Messages to '$' prefixed MQTT topics were being rejected. This
is not security critical but very annoying for a user wanting to use
that feature.

[ Tests ]
The release introduces a new test that covers one issue. A test
exists for the CA issue but is not part of this release.

[ Risks ]
I believe this to be low risk. Most of the code changes are reasonably
simple.

shairport-sync, kamailio-mqtt-module, and baresip-core depend on
libmosquitto1. The changes to the library code are trivial.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
mosquitto_2.0.8-mosquitto-2.0.9.debdiff is the full debdiff.
mosquitto_2.0.8-mosquitto-2.0.9-code.debdiff is the code only debdiff.

unblock mosquitto/2.0.9-1

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-48-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru mosquitto-2.0.8/ChangeLog.txt mosquitto-2.0.9/ChangeLog.txt
--- mosquitto-2.0.8/ChangeLog.txt   2021-02-25 17:28:19.0 +
+++ mosquitto-2.0.9/ChangeLog.txt   2021-03-11 22:37:20.0 +
@@ -1,3 +1,39 @@
+2.0.9 - 2021-03-11
+==
+
+Security:
+- If an empty or invalid CA file was provided to the client library for
+  verifying the remote broker, then the initial connection would fail but
+  subsequent connections would succeed without verifying the remote broker
+  certificate. Closes #2130.
+- If an empty or invalid CA file was provided to the broker for verifying the
+  remote broker for an outgoing bridge connection then the initial connection
+  would fail but subsequent connections would succeed without verifying the
+  remote broker certificate. Closes #2130.
+
+Broker:
+- Fix encrypted bridge connections incorrectly connecting when `bridge_cafile`
+  is empty or invalid. Closes #2130.
+- Fix `tls_version` behaviour not matching documentation. It was setting the
+  exact TLS version to use, not the minimium TLS version to use. Closes #2110.
+- Fix messages to `$` prefixed topics being rejected. Closes #2111.
+- Fix QoS 0 messages not being delivered when max_queued_bytes was configured.
+  Closes #2123.
+- Fix bridge increasing backoff calculation.
+- Improve handling of invalid combinations of listener address and bind
+  interface configurations. Closes #2081.
+- Fix `max_keepalive` option not applying to clients connecting with keepalive
+  set to 0. Closes #2117.
+
+Client library:
+- Fix encrypted connections incorrectly connecting when the CA file passed to
+  `mosquitto_tls_set()` is empty or invalid. Closes #2130.
+- Fix connections retrying 

Bug#985758: mozc: tegaki-zinnia-japanese shouldn't be a dependency after handwriting support was removed

[Daniel Tang]

Source: mozc
Severity: normal
X-Debbugs-Cc: danielzgtg.opensou...@gmail.com

This was orignally reported in Ubuntu downstream at
https://bugs.launchpad.net/ubuntu/+source/mozc/+bug/1920775 . I am
reporting it upstream here in Debian as per the maintainer's instructions.

Summary:

The Mozc packages shouldn't depend on tegaki-zinnia-japanese, a 26.1 MB 
handwriting support package, after handwriting support was removed from Mozc ( 
https://github.com/google/mozc/issues/477#issuecomment-739475097 ). The 
tegaki-zinnia project is also unmaintained ( 
https://github.com/tegaki/tegaki/issues/13#issuecomment-301248025 ).

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

Kernel: Linux 5.11.7-surface (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#985749: apt: "apt-mark hold" flag lost on package upgrade using --ignore-hold

[David Kalnischkies]

On Mon, Mar 22, 2021 at 10:21:59PM +0100, Sven-Haegar Koch wrote:
> On some of my hosts I have a single or a very small number of packages
> that I am only allowed to upgrade with specific procedures, pre-arranged
> maintenance window and so on.
> 
> But for the rest of the packages I want to install Debian (security)
> updates as soon as possible.
> 
> "apt-mark hold" sounds exactly like what I want.

I would think you are better of with apt_preferences as that is intended
to control which packages are allowed to be upgraded (from where). As
that is more powerful in some sense it is also not that easy to handle
though: There is no simple flag e.g. – but using specific files for each
you can disable as needed might be workable.

(It might be an interesting idea to allow preferences to be tagged and
 to then to be ignored based on tag selection from the commandline…
 that currently doesn't exist at all though and is just a silly random
 idea popping into my head as I wrote this mail)


> I hold the package, and with normal upgrade/dist-upgrade it works
> exactly as expected.
> 
> But when I then upgrade these single package later using --ignore-hold,
> the hold flag is lost afterwards.

holds are stored by dpkg as a "selection state", which e.g. install or
deinstall are, too, and which will override the old selection state sort
of by design.

It is also this way since the dawn of time, so that is kinda unlikely to
change – resolving this bug might be as "simple" as adding a note that
holds will be (potentially) lost if they are ignored.

Sorry, as that is probably not what you wanted to hear.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#985757: sredird FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: sredird
Version: 2.2.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

sredird fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
sredird cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru sredird-2.2.1/debian/changelog 
sredird-2.2.1/debian/changelog
--- sredird-2.2.1/debian/changelog  2016-12-30 05:44:42.0 +0100
+++ sredird-2.2.1/debian/changelog  2021-03-22 11:03:53.0 +0100
@@ -1,3 +1,10 @@
+sredird (2.2.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 22 Mar 2021 11:03:53 +0100
+
 sredird (2.2.1-2) unstable; urgency=medium
 
   * Merged NMU and updated to debhelper 9.
diff --minimal -Nru sredird-2.2.1/debian/rules sredird-2.2.1/debian/rules
--- sredird-2.2.1/debian/rules  2003-07-08 15:37:07.0 +0200
+++ sredird-2.2.1/debian/rules  2021-03-22 11:03:52.0 +0100
@@ -31,9 +31,7 @@
 
 build-stamp: configure-stamp 
dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE)
+   dh_auto_build
#/usr/bin/docbook-to-man debian/sredird.sgml > sredird.1
 
touch build-stamp

Bug#985667: pkgconf: make use of personalities to replace the cross wrapper

[Helmut Grohne]

Hi Andrej,

On Sun, Mar 21, 2021 at 07:25:58PM +0100, Andrej Shadura wrote:
> Since pkgconf added support for personalities [1], it is now possible to
> implement cross support without pkgconf-cross-wrapper and most of the
> related machinery.

Let me sketch a proposal on how to implement this:

 * Get rid of the "old" way: Drop the dpkg hook and the cross wrapper.
 * Rename the pkgconf binary package to pkgconf-bin. Don't miss out on
   Breaks + Replaces. Mark pkgconf-bin Multi-Arch: foreign.
 * Create a new binary package "pkgconf". It depends on pkgconf-bin. It
   contains two things:
* The /usr/bin/-pkgconf -> pkgconf symlink.
* The personality file relevant to .
 * Possibly add a build profile called pkg.pkgconf.personalityonly. When
   enabling it the entire package build is skipped and the only package
   built is the new pkgconf package. In particular, this profile should
   not use a C compiler. I'm not sure whether this profile is truly
   needed, but it should be simple if we figure out that it is.
 * Optionally, pkgconf-bin can provide pkgconf-for-build to follow the
   convention established in binutils.

However, this is mixing two different aspects. The personality approach
can also be implemented with the dpkg hook while dropping the cross
wrapper only. I do prefer the hook-less way though, becaue it is less
magic and easier to get right in the presence of DPKG_ROOT.

Helmut

Bug#985756: topline FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: topline
Version: 0.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

topline fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
topline cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru topline-0.3/debian/changelog topline-0.3/debian/changelog
--- topline-0.3/debian/changelog2020-02-04 05:18:32.0 +0100
+++ topline-0.3/debian/changelog2021-03-22 23:06:22.0 +0100
@@ -1,3 +1,10 @@
+topline (0.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 22 Mar 2021 23:06:22 +0100
+
 topline (0.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru topline-0.3/debian/rules topline-0.3/debian/rules
--- topline-0.3/debian/rules2020-02-04 05:09:29.0 +0100
+++ topline-0.3/debian/rules2021-03-22 23:06:15.0 +0100
@@ -9,5 +9,5 @@
dh $@
 
 override_dh_auto_build:
-   +$(MAKE) CFLAGS="$(shell dpkg-buildflags --get CFLAGS) $(shell 
dpkg-buildflags --get CPPFLAGS)" \
+dh_auto_build -- CFLAGS="$(shell dpkg-buildflags --get CFLAGS) $(shell 
dpkg-buildflags --get CPPFLAGS)" \
LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)"

Bug#985749: apt: "apt-mark hold" flag lost on package upgrade using --ignore-hold

[Julian Andres Klode]

Control: reassign -1 dpkg

On Mon, Mar 22, 2021 at 10:21:59PM +0100, Sven-Haegar Koch wrote:
> Package: apt
> Version: 2.2.2
> Severity: minor
> 
> Dear Maintainer,
> 
> On some of my hosts I have a single or a very small number of packages
> that I am only allowed to upgrade with specific procedures, pre-arranged
> maintenance window and so on.
> 
> But for the rest of the packages I want to install Debian (security)
> updates as soon as possible.
> 
> "apt-mark hold" sounds exactly like what I want.

No, you want to pin them using apt_preferences(5).

> 
> I hold the package, and with normal upgrade/dist-upgrade it works
> exactly as expected.
> 
> But when I then upgrade these single package later using --ignore-hold,
> the hold flag is lost afterwards.
> 
> The flag is documented in "man apt-get" as
> 
>--ignore-hold
>Ignore package holds; this causes apt-get to ignore a hold placed
>on a package. This may be useful in conjunction with dist-upgrade
>to override a large number of undesired holds. Configuration Item:
>APT::Ignore-Hold.
> 
> So I expect the flag on the package to be ignored for this apt-get
> execution, not changed or removed.

That's the correct behavior - a package has one selection state; and
when you tell it to install something that was hold, that state changes
from hold to install.

Anyway, I think this is a dpkg topic, not an apt one, though I might be
wrong, since we do some temporary state changes, but not sure about the
extend; I think this is really dpkg's decision, though.

The flag ought to be called --unset-hold, but oh well.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#985739: libkrb5-3: libkrb5 requires undefined symbol from libk5crypto during upgrade from buster to bullseye

[Sam Hartman]

control: tags -1 confirmed

I haven't explicitly reproduced this, but based on the description I am
confident this is an issue.

What happened is that  upstream dropped an internal symbol
krb5int_c_combine_keys that is used by the old library.
So once libk5crypto3 is upgraded, libkrb5-3 breaks.

Interestingly it looks like libkrb5-3 from version 1.18 will work fine
with the old libk5crypto3.
A breaks relationship would certainly make things better.
I'm not 100% sure it's good enough if krb5 is effectively in the
pseudo-essential set.

I asked on IRC and was confused by the answers I got.
So I'm investigating.

Bug#985755: debian-installer: Bullseye netinst Installer doesn't find RTL8723DE Network Hardware

[Kenneth Parker]

Package: debian-installer
Severity: important
X-Debbugs-Cc: sea7k...@gmail.com

Dear Maintainer,


   * What led up to the situation?
Attempt to install Bullseye on HP Laptop, using netinst

   * What exactly did you do (or not do) that was effective (or ineffective)?
Tried to Complete Install, past Network Questions.

   * What was the outcome of this action?
Incomplete Text-only System.

   * What outcome did you expect instead?
Working Bullseye System.



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

Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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

Bug#985754: dino-im: /<>/qlite/src/column.vala:99.32-99.37: error: `double' is not a supported generic type argument, use `?' to box value types

[Sebastian Ramacher]

Source: dino-im
Version: 0.2.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

dino-im FTBFS with vala in bullseye and sid:
| /<>/qlite/src/column.vala:99.32-99.37: error: `double' is not a 
supported generic type argument, use `?' to box value types
| public class Real : Column {
|^^
| Compilation failed: 1 error(s), 0 warning(s)

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#985647: telegram-desktop: Actively works against KDE Window rules

[Shai Berger]

Hi Nicholas,

On Sun, 21 Mar 2021 16:38:20 +0300
Nicholas Guriev  wrote:

> If you prefer to see KDE's titlebar on Telegram Desktop, set the
> System window frame checkbox in advanced settings inside the app.
> 

Thanks for the tip. In case anyone else sees this -- initially, when
you set the checkbox, Telegram's own titlebar disappears and the KDE one
does not appear, leaving the window with no titlebar at all. Only after
closing and reopening the window (e.g. by clicking the Telegram tray
icon), the KDE titlebar shows up.

I should note that even with this, the rule
Virtual Desktop: Apply Initially / All Desktops
Does not achieve anything. And it used to. 

Bug#985753: CVE-2021-20178 CVE-2021-20180 CVE-2021-20191

[Moritz Muehlenhoff]

Package: ansible
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2021-20191
https://bugzilla.redhat.com/show_bug.cgi?id=1916813
https://github.com/ansible-collections/cisco.nxos/pull/227
https://github.com/ansible-collections/cisco.nxos/commit/120956963f47502151a358e4a7bc2a87f71813aa

CVE-2021-20180
https://bugzilla.redhat.com/show_bug.cgi?id=1915808
https://github.com/ansible-collections/community.general/pull/1635
https://github.com/ansible-collections/community.general/commit/1d0c5e2ba47724c31a18d7b08b9daf13df8829dc

CVE-2021-20178
https://bugzilla.redhat.com/show_bug.cgi?id=1914774
https://github.com/ansible-collections/community.general/pull/1621
https://github.com/ansible-collections/community.general/commit/3560aeb12f7061bf21d63ca0e1e19feb99c57de3

Cheers,
Moritz  

Bug#985752: ITP: perltidier -- tweaks to Perl::Tidy to support some syntactic sugar

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Perl Group 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: perltidier
  Version : 1.18
  Upstream Author : Mark Grimes 
* URL : https://metacpan.org/release/Perl-Tidy-Sweetened
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : tweaks to Perl::Tidy to support some syntactic sugar

 There are a number of modules on CPAN
 that allow users to write their classes with a more "modern" syntax.
 These tools eliminate the need to shift off $self,
 can support type checking
 and offer other improvements.
 Unfortunately, they can break the support tools
 that the Perl community has come to rely on.
 This module attempts to work around those issues.
 .
 The module uses Perl::Tidy's "prefilter" and "postfilter" hooks
 to support "method" and "func" keywords,
 including the (possibly multi-line) parameter lists.
 This is quite an ugly hack,
 but it is the recommended method of supporting these new keywords.
 The resulting formatted code will leave the parameter lists untouched.
 .
 Perl::Tidy::Sweetened attempts to support the syntax
 outlined in the following modules,
 but most of the new syntax styles should work:
  * p5-mop
  * Method::Signatures::Simple
  * MooseX::Method::Signatures
  * MooseX::Declare
  * Moops
  * perl 5.20 signatures
  * Kavorka

This package will be maintained in the Perl team.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmBZAGEACgkQLHwxRsGg
ASEhaw/9GFkhNsEj3EpcfxryDuqGPhPI4od/Q/NrMviotNk+gk/+pndlZK/n8cn6
9wSiPjFUS1fosVUXtl9PxnV9Tq/4BrUIweLrJJCRoYK3UEoWF5zmvsSEioplwar4
odKnbSIbmyeD0hRM99qYd7bfYzewPMpkTUL9NLwo7d3qRwJ+57UU/OjXzDV1lY6U
3nKJKK0DV8IOWSjhWIluIhQ+NLSGRnGv6klqH17QzvSd4XG7EaslkMaiV/YgaKbQ
PFtLm/FudI64cNGWbAqqrrsoBAQGf+E8uXRA2yVVFC6oJEdtZEzPY1c97zYjUzzV
qLc43EAb9EtAOSunKjaiOxHli7jvfE4S+xzgMOasDnvJN6RFfGZHA+V6wL3Ll3aJ
B8gBnpcLpkzGT2TgQAtAoekCw7Bffs41vqnn3YWD1eerYPb19o5hsAPtFFc2o2pB
he2Lh6xb3r3s9Q6rzcugxCS4uEexy+prL/NSZ5oLdAQjqwTRl/cDV1DX3Bw3YflK
GpYfEpncLDV6l4DsMTOVQ7pW3SBTBe9C1p9Y8o76iyf4HHV2hzWw4wPD3uvxKMCu
W4ZcWQ/gAiwagQ644WBzVT14KmcI2Q9Mj+3aKBK19YgujAl2kSOoItQEzFFOMZ3D
HzD8/F189c+WXntZDrNRFE5ygh4vuttV1si3402pqZqXZFx0s2w=
=IGAR
-END PGP SIGNATURE-

Bug#985751: otrs2: broken symlinks: /var/lib/otrs/fonts/DejaVu*.ttf -> /usr/share/fonts/truetype/ttf-dejavu/DejaVu*.ttf

[Andreas Beckmann]

Package: otrs2
Version: 6.0.32-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m22.1s ERROR: FAIL: Broken symlinks:
  /var/lib/otrs/fonts/DejaVuSansMono.ttf -> 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf (otrs2)
  /var/lib/otrs/fonts/DejaVuSansMono-Oblique.ttf -> 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Oblique.ttf (otrs2)
  /var/lib/otrs/fonts/DejaVuSansMono-BoldOblique.ttf -> 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-BoldOblique.ttf (otrs2)
  /var/lib/otrs/fonts/DejaVuSansMono-Bold.ttf -> 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf (otrs2)
  /var/lib/otrs/fonts/DejaVuSans.ttf -> 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf (otrs2)
  /var/lib/otrs/fonts/DejaVuSans-Oblique.ttf -> 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Oblique.ttf (otrs2)
  /var/lib/otrs/fonts/DejaVuSans-BoldOblique.ttf -> 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-BoldOblique.ttf (otrs2)
  /var/lib/otrs/fonts/DejaVuSans-Bold.ttf -> 
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf (otrs2)
  /usr/share/otrs/ARCHIVE -> /var/lib/otrs/ARCHIVE (otrs2)

The fonts are now in /usr/share/fonts/truetype/dejavu/ ... (s/ttf-//)

If the ARCHIVE link is needed, should the target be created by
the package upon installation?


cheers,

Andreas


otrs2_6.0.32-2.log.gz
Description: application/gzip

Bug#985390: unblock: squid/4.13-7

[Santiago Garcia Mantinan]

> > Fixing a couple of nasty bugs discovered late,
> Yes, due to handling of a new binary package that you had migrated into
> bullseye the day before that wasn't allowed anymore exactly to avoid
> this class of bugs.

Agreed, this was something that several users had asked for and that we, the
screen team, agreed on making, but nobody had the time till I was able to do
it, yes, it was late on the cycle, but I think we can get it right before
releasing.

> > Loss of config and logs and service deactivated when switching squid flavour
> > and purging the old one.
> And now you don't purge the configuration and logs at all. Policy isn't
> totally clear on this (the text is lightly ambiguous), but *I* expect
> purging to remove my configuration and logs, what else is the delta
> between removal and purging? However, I'm wondering if I want you to fix

The package has traditionally left, the cache (something that is probably
not usefull at all) without being removed from the disk just because it
would take a lot of time to remove it (reading the comments on postrm
script)
# We do not remove /var/spool/squid because that might
# take a lot of time. Most of the time it is on a seperate
# disk anyway and it is faster to do a mkfs on it..

I thought that leaving the logs which can be even legally needed, wouldn't
hurt, in my case when I found this it was a problem as I lost all the logs I
had on the system (luckily I had a backup).


> that at this moment at the risk of not getting it right. However, I

You are right.

> think you're current message is confusing though and needs improvement:
> 1) it doesn't mention the configuration file(s)

The configuration file (which was forcebly removed by postrm before) is
removed by dpkg if squid and squid-openssl are both purged, so as far as
config goes, it still does what you would spect.

> 2) it doesn't mention that the log is shared with that other
> (potentially installed) package. There's context missing here for
> sysadmins of why you're not doing it in the package. What happens if
> somebody just did exactly as told and deleted the log directory?

Agreed, I can try to get a better message on a -9 version of it.

> -#DEBHELPER#
> +# Automatically added by dh_installinit/13.3.4
>   ^
> 
> Highly confusing, don't you think, for something that's not at all
> automatically added.

Sure, I didn't remove this to minimize the changes between the binary
packages, and given that this was a temporary fix, I thougt it would be
better to leave it like that, but I'll remove it on -9.

Regards...
-- 
Manty/BestiaTester -> http://manty.net

Bug#985536: The Bug wont occour on Debian 11 Live Testing iso

[Floriplum]

Hello,

I tried expangind my array while booted from a debian 11 Live Image. When 
booted from this image i can expand the array without problems.  
After the rebuilt is done im going to test it again with a debian 10 Live 
Image, but after that i cant do much since i then have no disks to add to my 
array left.

Greetings
Florian

Bug#985233: O: lmbench -- Utilities to benchmark UNIX systems

[Andreas Beckmann]

Hi Al,

On Sun, 14 Mar 2021 15:17:52 -0600 Al Stone  wrote:

I intend to orphan the lmbench package.  I no longer use it,


Can you push the changes and tag from the -5 upload, please?

And could you try to move the package on salsa from your personal 
namespace to the 'debian' or 'hpc-team' namespace? (I think that should 
be Settings -> General -> Advanced -> Transfer project, but I have never 
used it.) There is no need to do an upload to update the Vcs URLs.


Thanks,

Andreas, who might adopt it for the HPC team

Bug#985750: unblock: gazebo/11.1.0+dfsg-6

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gazebo

[ Reason ]
The version in testing was build with an old version of protobuf so
software using libgazebo-dev and the current protobuf version in testing
fail to build, like gazebo_ros (not in Debian). The fix is to rebuild
against the current protobuf API version and to depend on that to make
sure it is rebuild automatically in future.

The gazebo package only builds on amd64 and i386 and was blocked from
migration due to britney not being smarter. Discussing this in
#debian-devel, elbrus proposed to mark the only autopkgtest as
superficial as it not really testing enough of the package. So the diff
includes this as well.

[ Impact ]
The protobuf headers in libgazebo-dev would not be usable.

[ Tests ]
There are no automated tests, compiling gazebo_ros manually works after
the rebuild.

[ Risks ]
There is no risk, as the libgazebo-dev already depends on
libprotobuf-dev which provides the protobufapi package.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock gazebo/11.1.0+dfsg-6
diff --git a/debian/changelog b/debian/changelog
index 6ee8a113..7e75fc8b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+gazebo (11.1.0+dfsg-6) unstable; urgency=medium
+
+  * Team upload.
+  * Mark test superficial
+
+ -- Jochen Sprickerhof   Mon, 22 Mar 2021 22:21:38 +0100
+
+gazebo (11.1.0+dfsg-5) unstable; urgency=medium
+
+  * Team upload.
+  * libgazebo-dev Depends on Protobuf API version (Closes: #985660)
+
+ -- Jochen Sprickerhof   Sun, 21 Mar 2021 22:21:29 +0100
+
 gazebo (11.1.0+dfsg-4) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 161cefd4..5ac5de9b 100644
--- a/debian/control
+++ b/debian/control
@@ -172,7 +172,8 @@ Depends: libtbb-dev,
  libgazebo11 (= ${binary:Version}),
  gazebo-common (= ${source:Version}),
  gazebo-plugin-base (= ${binary:Version}),
- ${misc:Depends}
+ ${misc:Depends},
+ ${protobuf:API},
 Breaks: libgazebo7-dev, libgazebo9-dev (<< 11.0.0+dfsg-1~)
 Replaces: libgazebo7-dev, libgazebo9-dev (<< 11.0.0+dfsg-1~)
 Description: Open Source Robotics Simulator - Development Files
diff --git a/debian/rules b/debian/rules
index c5b852a6..7268f462 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,11 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# see #985660
+# extract the protobuf API version package and add it to d/control
+# Needed because protobuf generated headers are only compatible with that 
version
+protobufapi := $(shell dpkg-query -W -f '$${Provides}' libprotobuf-dev | grep 
-o 'protobuf-api-[^ ]*')
+
 override_dh_auto_configure:
dh_auto_configure -- \
 -DUSE_HOST_CFLAGS:BOOL=False \
@@ -18,6 +23,9 @@ override_dh_install:
# Remove old script
rm -f debian/gazebo/usr/bin/gzprop
 
+execute_before_dh_gencontrol:
+   echo 'protobuf:API=$(protobufapi)' >> debian/libgazebo-dev.substvars
+
 # Tests needs an X server running and GPU acceleration
 override_dh_auto_test:
 
diff --git a/debian/tests/control b/debian/tests/control
index 3a872e84..9de62eb0 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,3 @@
 Tests: build
 Depends: @, pkg-config, build-essential
+Restrictions: superficial

Bug#985556: flatpak/1.2.5-0+deb10u4 FTBFS on i386

[Aurelien Jarno]

On 2021-03-21 12:15, Philipp Kern wrote:
> On 20.03.21 13:32, Simon McVittie wrote:
> > On Sat, 20 Mar 2021 at 09:16:45 +0100, Salvatore Bonaccorso wrote:
> >> On Sat, Mar 20, 2021 at 12:12:39AM +, Simon McVittie wrote:
> >>> Could x86-conova-01.debian.org be an IPv6-only buildd?
> > ...
> >>> Or, if not that, could it be the case that this buildd is firewalled or
> >>> otherwise restricted such that connections from the build to a test
> >>> server listening on an arbitrary high port number on the loopback
> >>> interface will fail?
> >>
> >> JFTR, this might indeed be the case. I gave it back a couple of times
> >> and building on x86-conova-01.debian.org failed. The last one got
> >> picked on buildd-x86-grnet-01 which now seems to have built.
> > 
> > If we now have buildds that are more restrictive or limited than
> > the buildds that were used at the time stable was frozen, then
> > it would probably be good if it was possible to arrange for only
> > testing/unstable/experimental packages to be built on those buildds,
> > with stable updates built on buildds that more closely resemble the ones
> > they were originally tested on - otherwise we'll get random build
> > regressions.
> 
> The buildd is IPv6-only. I'm somewhat torn given that we have enough
> buildd coverage that a give-back would likely solve the problem. At the
> same time you can't avoid a particular buildd either. So I concur, as
> much as it hurts me in this day and age, that we should at least
> temporarily disable stable/oldstable builds on the IPv6-only buildds.
> 
> I have commented out stretch and buster (and their corresponding
> security and backports suites) on x86-conova-01 for now. I'll definitely
> leave bullseye on, though. Not sure if there's another IPv6-only buildd
> lingering around.

Thanks for doing that change that fully makes sense. I have done the
same change on arm-conova-03 which is also IPv6-only.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#985543: Problem resolved, details below

[Daniel Hevron Pereh]

  
  
I'd like to report that after an update I did just now the
  problem is resolved. I don't know what really caused it but I'm
  adding a list of the updated packages:


Start-Date: 2021-03-22  19:17:34
  Commandline: packagekit role='update-packages'
  Upgrade: udev:amd64 (247.3-1, 247.3-3), libnss-myhostname:amd64
  (247.3-1, 247.3-3), systemd-timesyncd:amd64 (247.3-1, 247.3-3),
  libpam-systemd:amd64 (247.3-1, 247.3-3), libsystemd0:amd64
  (247.3-1, 247.3-3), libnss-systemd:amd64 (247.3-1, 247.3-3),
  systemd:amd64 (247.3-1, 247.3-3), libudev1:amd64 (247.3-1,
  247.3-3), systemd-sysv:amd64 (247.3-1, 247.3-3)
  End-Date: 2021-03-22  19:17:53


so maybe it was a udev rule? I don't really know how to check, if
  it even necessary. but I guess this bug can be closed?


Thank you for your affords and attention!
Daniel

  




OpenPGP_signature
Description: OpenPGP digital signature

Bug#985749: apt: "apt-mark hold" flag lost on package upgrade using --ignore-hold

[Sven-Haegar Koch]

Package: apt
Version: 2.2.2
Severity: minor

Dear Maintainer,

On some of my hosts I have a single or a very small number of packages
that I am only allowed to upgrade with specific procedures, pre-arranged
maintenance window and so on.

But for the rest of the packages I want to install Debian (security)
updates as soon as possible.

"apt-mark hold" sounds exactly like what I want.

I hold the package, and with normal upgrade/dist-upgrade it works
exactly as expected.

But when I then upgrade these single package later using --ignore-hold,
the hold flag is lost afterwards.

The flag is documented in "man apt-get" as

   --ignore-hold
   Ignore package holds; this causes apt-get to ignore a hold placed
   on a package. This may be useful in conjunction with dist-upgrade
   to override a large number of undesired holds. Configuration Item:
   APT::Ignore-Hold.

So I expect the flag on the package to be ignored for this apt-get
execution, not changed or removed.


Example with docker-ce packages (just because they have multiple
versions in their repository so it was easy to get back to an old
release to show here):

==> Starting with an oudated package version installed

# apt-mark hold docker-ce docker-ce-cli
docker-ce set on hold.
docker-ce-cli set on hold.
# apt-mark showhold
docker-ce
docker-ce-cli

==> Hold flags set

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  docker-ce docker-ce-cli
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

==> A normal dist-upgrade does not touch them, as they are held.

# apt-get install --ignore-hold docker-ce docker-ce-cli
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  aufs-tools cgroupfs-mount | cgroup-lite
Recommended packages:
  apparmor docker-ce-rootless-extras
The following held packages will be changed:
  docker-ce docker-ce-cli
The following packages will be upgraded:
  docker-ce docker-ce-cli
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 66.2 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
...

==> apt called with --ignore-hold ignores the hold, and upgrades them.

# apt-mark showhold
#

==> But afterwards hold flag is lost!

==> Now whenever the next package release comes out every
==> "apt-get dist-upgrade" will upgrade them, easy to miss
==> and abort when processing a bigger number of hosts.

Greetings,
Haegar



-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/preferences.d/kde-experimental.disabled present, but not 
submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'oldstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.27-1
ii  libapt-pkg6.0   2.2.2
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-6
ii  libgnutls30 3.7.1-1
ii  libseccomp2 2.5.1-1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-3

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
ii  apt-doc 2.2.2
ii  aptitude0.8.13-3
ii  dpkg-dev1.20.7.1
ii  gnupg   2.2.27-1
ii  gnupg1  1.4.23-1.1
ii  gnupg2  2.2.27-1
ii  powermgmt-base  1.36
ii  synaptic0.90.2

-- debconf-show failed

Bug#985748: botan: OASIS copyright exclusion

[Bastian Germann]

Source: botan
Version: 2.17.3+dfsg-3
Severity: minor

The OASIS PKCS#11 headers are excluded from the source but they are
still referenced in debian/copyright. Please remove the references.

Also, the Files-Excluded field should be used to remove exclude the
files from the source package instead of manually deleting them
according to README.source.

Bug#985390: unblock: squid/4.13-7

[Paul Gevers]

Control: tag -1 moreinfo

Hi Santiago,

On 17-03-2021 09:01, Santiago Garcia Mantinan wrote:
> Fixing a couple of nasty bugs discovered late,

Yes, due to handling of a new binary package that you had migrated into
bullseye the day before that wasn't allowed anymore exactly to avoid
this class of bugs.

> Loss of config and logs and service deactivated when switching squid flavour
> and purging the old one.

And now you don't purge the configuration and logs at all. Policy isn't
totally clear on this (the text is lightly ambiguous), but *I* expect
purging to remove my configuration and logs, what else is the delta
between removal and purging? However, I'm wondering if I want you to fix
that at this moment at the risk of not getting it right. However, I
think you're current message is confusing though and needs improvement:
1) it doesn't mention the configuration file(s)
2) it doesn't mention that the log is shared with that other
(potentially installed) package. There's context missing here for
sysadmins of why you're not doing it in the package. What happens if
somebody just did exactly as told and deleted the log directory?

-#DEBHELPER#
+# Automatically added by dh_installinit/13.3.4
  ^

Highly confusing, don't you think, for something that's not at all
automatically added.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985688: chatty: segfault when syncing history with certain accounts

[Vagrant Cascadian]

On 2021-03-22, Vagrant Cascadian wrote:
> On 2021-03-22, Guido Günther wrote:
>> Could you provide a gdb backtrace with debugging symbols?
>
> Thanks for the quick response.
>
> Hopefully this is what you were looking for (swapped out my client with
> USERNAME@EXAMPLE and the connection to a multi-user-chat with
> MUC@EXAMPLE):

The MUC is disc...@conference.soprani.ca, and someone else on that MUC
was unable to add it in chatty, so maybe there's some safeguard in
chatty to prevent incompatible JID/MUC? Since I had added the MUC with
another client chatty is blindly trying to sync when MAM is enabled?



live well,
  vagrant


signature.asc
Description: PGP signature

Bug#903794: lmbench-doc: broken symlinks: /usr/share/doc/lmbench-doc/man/*.8 -> lmbench.8

[Andreas Beckmann]

Followup-For: Bug #903794
Control: found -1 3.0-a9+debian.1-5
Control: tag -1 patch

Please apply the attached patch for moving the manpage symlinks to the
right place.


Andreas
>From 3c2d868282662549f0fc7814e65254d27a2aa8e4 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Mon, 22 Mar 2021 22:11:25 +0100
Subject: [PATCH] fix manpage symlinks

---
 debian/lmbench-doc.dirs  | 2 --
 debian/lmbench-doc.links | 3 ---
 debian/lmbench.links | 3 +++
 3 files changed, 3 insertions(+), 5 deletions(-)
 delete mode 100644 debian/lmbench-doc.dirs
 delete mode 100644 debian/lmbench-doc.links

diff --git a/debian/lmbench-doc.dirs b/debian/lmbench-doc.dirs
deleted file mode 100644
index 26000ed..000
--- a/debian/lmbench-doc.dirs
+++ /dev/null
@@ -1,2 +0,0 @@
-usr/share/doc/lmbench-doc
-usr/share/doc/lmbench-doc/man
diff --git a/debian/lmbench-doc.links b/debian/lmbench-doc.links
deleted file mode 100644
index 79454fe..000
--- a/debian/lmbench-doc.links
+++ /dev/null
@@ -1,3 +0,0 @@
-usr/share/doc/lmbench-doc/man/lmbench.8 usr/share/doc/lmbench-doc/man/hello.8
-usr/share/doc/lmbench-doc/man/lmbench.8 
usr/share/doc/lmbench-doc/man/flushdisk.8
-usr/share/doc/lmbench-doc/man/lmbench.8 usr/share/doc/lmbench-doc/man/memsize.8
diff --git a/debian/lmbench.links b/debian/lmbench.links
index a3431e6..2c6fc99 100644
--- a/debian/lmbench.links
+++ b/debian/lmbench.links
@@ -1,2 +1,5 @@
 usr/share/man/man8/lmbench.8.gz usr/share/man/man8/lmhttp.8.gz
 usr/share/man/man8/lmbench.8.gz usr/share/man/man8/msleep.8.gz
+usr/share/man/man8/lmbench.8.gz usr/share/man/man8/hello.8.gz
+usr/share/man/man8/lmbench.8.gz usr/share/man/man8/flushdisk.8.gz
+usr/share/man/man8/lmbench.8.gz usr/share/man/man8/memsize.8.gz
-- 
2.20.1

Bug#985747: qttools5-dev-tools: Qt Designer and Qt Linguist as separate packages

[Thomas Uhle]

Package: src:qttools-opensource-src
Version: 5.11.3-4
Severity: normal

Dear maintainers,

could you please put Qt Designer as well as Qt Linguist in separate 
packages qt5-designer and qt5-linguist resp. (similar to qt5-assistant and 
qdoc-qt5) and then lower the dependencies to 'Recommends: qt5-assistant, 
qt5-designer, qt5-linguist'. The hard dependency on qt5-assistant would be 
moved to both new packages in turn.
Next to the linguist executable, package qt5-linguist should also include 
its companions like lrelease, lupdate, etc., the corresponding man pages, 
the phrase books, the Linguist pixmap icon and its application desktop 
file. So its dependencies would then just look like this for instance:


Versions of packages qt5-linguist depends on:
ii  libc6 2.28-10
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg1-1+deb10u4
ii  libqt5gui55.11.3+dfsg1-1+deb10u4
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u4
ii  libqt5widgets55.11.3+dfsg1-1+deb10u4
ii  libqt5xml55.11.3+dfsg1-1+deb10u4
ii  libstdc++68.3.0-6
ii  qt5-assistant 5.11.3-4
ii  qtchooser 66-2

For qt5-designer, this would be alike.

Thank you in advance!

Thomas Uhle


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qttools5-dev-tools depends on:
ii  libc6 2.28-10
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg1-1+deb10u4
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u4
ii  libqt5designer5   5.11.3-4
ii  libqt5designercomponents5 5.11.3-4
ii  libqt5gui55.11.3+dfsg1-1+deb10u4
ii  libqt5help5   5.11.3-4
ii  libqt5network55.11.3+dfsg1-1+deb10u4
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u4
ii  libqt5quickwidgets5   5.11.3+dfsg1-1+deb10u4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u4
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1+deb10u4
ii  libqt5xml55.11.3+dfsg1-1+deb10u4
ii  libstdc++68.3.0-6
ii  qdoc-qt5  5.11.3-4
ii  qt5-assistant 5.11.3-4
ii  qtchooser 66-2

qttools5-dev-tools recommends no packages.

qttools5-dev-tools suggests no packages.

Bug#386246: debhelper: scripts silently succeed on nonexisting package build dir

[Niels Thykier]

On Sat, 19 May 2018 11:38:00 + Niels Thykier  wrote:
> Control: tags -1 moreinfo
> 
> On Wed, 6 Sep 2006 11:34:37 +0200 Martin Pitt  wrote:
> > Package: debhelper
> > Version: 5.0.37.3
> > 
> > Hi!
> > 
> > While evaluating a curious kernel build failure in Ubuntu (where we
> > use a dh_strip wrapper to automatically generate debug symbol packages
> > for everything) I noticed a questionable behaviour: If the
> > package build directory does not exist, dh_* exits successfully rather
> > than failing (example in the built pmount source directory):
> > 
> >   $ ls -d debian/pmount debian/pmou
> >   ls: debian/pmou: No such file or directory
> >   debian/pmount
> > 
> >   $ dh_strip -ppmount --tmpdir=debian/pmou; echo $?
> >   Can't stat debian/pmou: No such file or directory
> >at /usr/bin/dh_strip line 192
> >   0
> > 
> > This also happens without --tmpdir:
> >  
> >   $ dh_strip -ppmount; echo $?
> >   Can't stat debian/pmount: No such file or directory
> >at /usr/bin/dh_strip line 192
> >   0
> > 
> > This also happens with dh_fixperms, so I guess dh_strip is not the
> > only affected script.
> > 
> > IMHO dh_* should really fail in that case. Otherwise packages with
> > typos or bugs debian/rules silently build and such failures might go
> > unnoticed. (in our kernel example, a make prerequisite was missing and
> > thus dh_strip did not have any effect; without our wrapper we would
> > never have noticed).
> > 
> > Thank you,
> > 
> > Martin
> > 
> > [...]
> 
> Hi Martin,
> 
> I appreciate the report and the issue.  In general, I agree with the
> sentiment, but in this case I find it difficult to implement in general.
> 
> The problem occurs because debhelper lazily generates the package build
> directories.  As such, a missing package build directory simply implies
> that no helper needed to install anything into the package so far.  What
> if this helper is simply the first helper that has anything to do in
> this package build directory?
> 
> Therefore, I cannot make dh_* fail on a missing package build directory
> in the general case.  Of course, a missing package build directory with
> the -P smells like it would be an issue - although, I would not be
> surprised if people rely on this to work (e.g. using -p for a
> package excluded by dpkg-buildpackage -A/-B).
>   If we are doing this check, then we need to talk about which helpers
> would that be and can we come with is the guiding principle for choosing
> them?
> 
> Thanks,
> ~Niels


Given the age of the bug and lack of feedback on the proposal, I am
taking the liberty of closing this bug.

Feel free to reopen it with the requested additional information if it
is still relevant.

Thanks,
~Niels

Bug#985746: unblock: kpmcore/20.12.3-2

[Aurélien COUDERC]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Debian Qt/KDE Maintainers 

Please unblock package kpmcore

[ Reason ]
It contains the backport of an upstream fix for not being able to
display S.M.A.R.T. information in KDE Partition Manager for some disk
states.

[ Impact ]
Users can’t display S.M.A.R.T. information from Partition Manager for
disks having some kind of issues.

[ Tests ]
No failing disk at hand, but I did test that displaying S.M.A.R.T.
information for valid disks still works.

[ Risks ]
Oneliner, coming from upstream, risk is low.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock kpmcore/20.12.3-2
diff -Nru kpmcore-20.12.3/debian/changelog kpmcore-20.12.3/debian/changelog
--- kpmcore-20.12.3/debian/changelog2021-03-08 23:23:00.0 +0100
+++ kpmcore-20.12.3/debian/changelog2021-03-22 11:36:09.0 +0100
@@ -1,3 +1,10 @@
+kpmcore (20.12.3-2) unstable; urgency=medium
+
+  * Backport upstream fix so that S.M.A.R.T. information display always works
+whatever the disk state.
+
+ -- Aurélien COUDERC   Mon, 22 Mar 2021 11:36:09 +0100
+
 kpmcore (20.12.3-1) unstable; urgency=medium
 
   * New upstream release (20.12.3).
diff -Nru kpmcore-20.12.3/debian/patches/series 
kpmcore-20.12.3/debian/patches/series
--- kpmcore-20.12.3/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ kpmcore-20.12.3/debian/patches/series   2021-03-22 11:14:09.0 
+0100
@@ -0,0 +1 @@
+upstream_2ea9ff49_fix_smartctl_exit_status_success_check.patch
diff -Nru 
kpmcore-20.12.3/debian/patches/upstream_2ea9ff49_fix_smartctl_exit_status_success_check.patch
 
kpmcore-20.12.3/debian/patches/upstream_2ea9ff49_fix_smartctl_exit_status_success_check.patch
--- 
kpmcore-20.12.3/debian/patches/upstream_2ea9ff49_fix_smartctl_exit_status_success_check.patch
   1970-01-01 01:00:00.0 +0100
+++ 
kpmcore-20.12.3/debian/patches/upstream_2ea9ff49_fix_smartctl_exit_status_success_check.patch
   2021-03-22 11:24:15.0 +0100
@@ -0,0 +1,52 @@
+Origin: upstream, 
https://invent.kde.org/system/kpmcore/commit/2ea9ff49124750ece175cb1f27a1492fc50287a3
+From: Yaroslav Sidlovsky 
+Date: Wed, 17 Mar 2021 15:37:30 +0300
+Subject: [PATCH] Fix smartctl exit status success check
+ According to the smartctl man page:
+ ```
+ EXIT STATUS
+ The  exit  statuses of smartctl are defined by a bitmask.  If all is well 
with the disk, the exit status (return value) of smartctl is 0 (all bits turned 
off).  If a problem occurs, or an error, potential error, or fault is detected, 
then a non-zero status is
+ returned.  In this case, the eight different bits in the exit status have the 
following meanings for ATA disks; some of these values may also be returned for 
SCSI disks.
+ .
+ Bit 0: Command line did not parse.
+ .
+ Bit 1: Device open failed, device did not return an IDENTIFY DEVICE 
structure, or device is in a low-power mode (see '-n' option above).
+ .
+ Bit 2: Some SMART or other ATA command to the disk failed, or there was a 
checksum error in a SMART data structure (see '-b' option above).
+ .
+ Bit 3: SMART status check returned "DISK FAILING".
+ .
+ Bit 4: We found prefail Attributes <= threshold.
+ .
+ Bit 5: SMART status check returned "DISK OK" but we found that some (usage or 
prefail) Attributes have been <= threshold at some time in the past.
+ .
+ Bit 6: The device error log contains records of errors.
+ .
+ Bit 7: The device self-test log contains records of errors.  [ATA only] 
Failed self-tests outdated by a newer successful extended self-test are ignored.
+ ```
+ .
+ BUG: 429028
+---
+ src/core/smartparser.cpp | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/src/core/smartparser.cpp b/src/core/smartparser.cpp
+index 80c73f1..9170a0f 100644
+--- a/src/core/smartparser.cpp
 b/src/core/smartparser.cpp
+@@ -117,7 +117,11 @@ void SmartParser::loadSmartOutput()
+ if (m_SmartOutput.isEmpty()) {
+ ExternalCommand smartctl(QStringLiteral("smartctl"), { 
QStringLiteral("--all"), QStringLiteral("--json"), devicePath() });
+ 
+-if (smartctl.run() && smartctl.exitCode() == 0) {
++// Exit status of smartctl is a bitfield, check that bits 0 and 1 are 
not set:
++//  - bit 0: command line did not parse;
++//  - bit 1: device open failed.
++// See `man 8 smartctl` for more details.
++if (smartctl.run() && (smartctl.exitCode() & 1) == 0 && 
(smartctl.exitCode() & 2) == 0) {
+ QByteArray output = smartctl.rawOutput();
+ 
+ m_SmartOutput = QJsonDocument::fromJson(output);
+-- 
+GitLab
+

Bug#985745: unblock: desktop-base/11.0.3

[Aurélien COUDERC]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Debian Desktop Team 

Please unblock package desktop-base

[ Reason ]
This last upload includes a couple of targeted fixes:
- Fix alternatives leftover after package uninstallation.
- Fix for unreadable GRUB text due to background color at some
  resolutions.
- Fix for Plymouth text display in multi-screen configurations for all
  other themes than bullseye’s homeworld theme (homeworld was fixed in
  the previous upload).
- Fix typo in bullseye theme metadata.

[ Impact ]
Users won’t get the above fixes.

[ Tests ]
I manually tested the fixes for all changes listed above.

[ Risks ]
The risk is very low: a couple of oneliners and some SVG image work.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I’m excluding the SVG diff of GRUB images from the debdiff as it adds a
lot of noise and not much readable information.

unblock desktop-base/11.0.3
diff -Nru --exclude grub-16x9.svg --exclude grub-4x3.svg 
desktop-base-11.0.2/debian/changelog desktop-base-11.0.3/debian/changelog
--- desktop-base-11.0.2/debian/changelog2021-03-02 00:37:18.0 
+0100
+++ desktop-base-11.0.3/debian/changelog2021-03-21 22:35:17.0 
+0100
@@ -1,3 +1,16 @@
+desktop-base (11.0.3) unstable; urgency=medium
+
+  * Make Debian logo and text darker on GRUB backgrounds to avoid grub’s own
+text being unreadable on top of these. (Closes: #983884)
+  * Also remove futurePrototype alternative for desktop-theme in prerm
+maintainer script. (Closes: #985267)
+  * Fix Name metadata for homeworld theme’s wallpaper.
+  * Also fix plymouth text display in multi-screen configurations for previous
+themes: futureprototype, joy, lines, moonlight, softwaves (fixes more
+cases of #956426).
+
+ -- Aurélien COUDERC   Sun, 21 Mar 2021 22:35:17 +0100
+
 desktop-base (11.0.2) unstable; urgency=medium
 
   [ Holger Levsen ]
diff -Nru --exclude grub-16x9.svg --exclude grub-4x3.svg 
desktop-base-11.0.2/debian/prerm desktop-base-11.0.3/debian/prerm
--- desktop-base-11.0.2/debian/prerm2021-03-01 21:46:50.0 +0100
+++ desktop-base-11.0.3/debian/prerm2021-03-18 13:45:17.0 +0100
@@ -182,8 +182,9 @@
 desktop-theme \
 /usr/share/desktop-base/$theme-theme
 done << EOF
-softwaves
+futureprototype
 moonlight
+softwaves
 lines
 joy
 joy-inksplat
diff -Nru --exclude grub-16x9.svg --exclude grub-4x3.svg 
desktop-base-11.0.2/futureprototype-theme/plymouth/futureprototype.script 
desktop-base-11.0.3/futureprototype-theme/plymouth/futureprototype.script
--- desktop-base-11.0.2/futureprototype-theme/plymouth/futureprototype.script   
2020-11-16 23:06:27.0 +0100
+++ desktop-base-11.0.3/futureprototype-theme/plymouth/futureprototype.script   
2021-03-21 15:05:41.0 +0100
@@ -119,7 +119,7 @@
 #Debug("y = " + y);
 
 text_height = first_line_height * 7.5;
-min_height = Window.GetHeight();
+min_height = window_max.height;
 #Debug("text_height=" + text_height + "; min_height=" + min_height);
 
 if (y + text_height > min_height)
diff -Nru --exclude grub-16x9.svg --exclude grub-4x3.svg 
desktop-base-11.0.2/homeworld-theme/wallpaper/metadata.desktop 
desktop-base-11.0.3/homeworld-theme/wallpaper/metadata.desktop
--- desktop-base-11.0.2/homeworld-theme/wallpaper/metadata.desktop  
2021-03-01 21:46:50.0 +0100
+++ desktop-base-11.0.3/homeworld-theme/wallpaper/metadata.desktop  
2021-03-18 13:38:20.0 +0100
@@ -1,5 +1,5 @@
 [Desktop Entry]
-Name=futurePrototype
+Name=Homeworld
 X-KDE-PluginInfo-Name=Homeworld
 X-KDE-PluginInfo-Author=Juliet Taka
 X-KDE-PluginInfo-Email=juliettetaka.be...@gmail.com
diff -Nru --exclude grub-16x9.svg --exclude grub-4x3.svg 
desktop-base-11.0.2/joy-theme/plymouth/joy.script 
desktop-base-11.0.3/joy-theme/plymouth/joy.script
--- desktop-base-11.0.2/joy-theme/plymouth/joy.script   2020-11-16 
23:06:27.0 +0100
+++ desktop-base-11.0.3/joy-theme/plymouth/joy.script   2021-03-21 
15:05:41.0 +0100
@@ -114,7 +114,7 @@
 
 text_height = first_line_height * 7.5;
 
-min_height = Window.GetHeight();
+min_height = window_max.height;
 if (y + text_height > min_height)
 y = min_height - text_height;
 
diff -Nru --exclude grub-16x9.svg --exclude grub-4x3.svg 
desktop-base-11.0.2/lines-theme/plymouth/lines.script 
desktop-base-11.0.3/lines-theme/plymouth/lines.script
--- desktop-base-11.0.2/lines-theme/plymouth/lines.script   2020-11-16 
23:06:27.0 +0100
+++ desktop-base-11.0.3/lines-theme/plymouth/lines.script   2021-03-21 
15:05:41.0 +0100
@@ -210,7 +210,7 @@
 
 text_height = first_line_height * 7.5;
 
-min_height = Window.GetHeight();
+min_height = window_max.height;
 if (y + text_height > 

Bug#985543: yubikey-luks: after upgrade and reboot - yubikey "not detected" (but blinking)

[Daniel Hevron Pereh]

> Could you share a few details?
>
> * dpkg -l "*yubi*"
> * dpkg -l "*cryptsetup*"
> * cat /etc/crypttab
> * Screenshots of the prompt, error messages, maybe boot in recovery mode



* dpkg -l "*yubi*"


| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name    Version Architecture Description
+++-===-===--===
ii  libyubikey-udev 1.20.0-3    all  udev rules 
for unprivileged access to YubiKeys
ii  libyubikey0 1.13-6  amd64 Yubikey OTP 
handling library runtime
ii  python3-yubikey-manager 4.0.0~a1-2  all Python 3 library for 
configuring a YubiKey — transitional package
ii  yubikey-luks    0.5.1+29.g5df2b95-6 all YubiKey two factor 
authentication for LUKS disks
ii  yubikey-personalization 1.20.0-3    amd64 Personalization 
tool for Yubikey OTP tokens
ii  yubioath-desktop    5.0.4+post1-1   amd64 Graphical 
interface for displaying OATH codes with a Yubikey




* dpkg -l "*cryptsetup*"


| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---===
ii  cryptsetup    2:2.3.4-2    amd64    disk encryption 
support - startup scripts
ii  cryptsetup-bin    2:2.3.4-2    amd64    disk encryption 
support - command line tools
ii  cryptsetup-initramfs  2:2.3.4-2    all  disk encryption 
support - initramfs integration
ii  cryptsetup-run    2:2.3.4-2    all  transitional dummy 
package for cryptsetup
ii  libcryptsetup12:amd64 2:2.3.4-2    amd64    disk encryption 
support - shared library



* cat /etc/crypttab


sda3_crypt UUID=18a87353-c256-4da6-88ab-6ac75b0d84ce none 
luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript



thank you!

Daniel



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985744: libapache2-mod-auth-gssapi: Upstream repo has moved

[Robbie Harwood (frozencemetery)]

Package: libapache2-mod-auth-gssapi
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

We've moved the repo for mod_auth_gssapi to
https://github.com/gssapi/mod_auth_gssapi .  GitHub should redirect
everything, but just in case.

Thanks,
--Robbie

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (700, 'unstable-debug'), (700, 'testing-debug'), (700, 
'unstable'), (700, 'testing'), (300, 'experimental-debug'), (300, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-4-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 libapache2-mod-auth-gssapi depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.46-4
ii  libc6   2.31-10
ii  libgssapi-krb5-21.18.3-4
ii  libssl1.1   1.1.1j-1

libapache2-mod-auth-gssapi recommends no packages.

libapache2-mod-auth-gssapi suggests no packages.

Bug#982388: d1x-rebirth: Crashes when I try to start a new or load a saved game

[Nathan A. Stine]

Package: d1x-rebirth
Version: 0.58.1-1.2
Followup-For: Bug #982388
X-Debbugs-Cc: nathan.st...@gmail.com

Hi all,

I believe I've ran into the same error as the original submitter. I find that
the error appears when trying to view the credits as well. Here's a backtrace:

Thread 1 "d1x-rebirth" received signal SIGSEGV, Segmentation fault.
fluid_hashtable_lookup_node (hash_return=0x0, key=0x7fffca90,
hashtable=0x56642840) at ./src/utils/fluid_hash.c:169
169 ./src/utils/fluid_hash.c: No such file or directory.
(gdb) bt
#0  fluid_hashtable_lookup_node (hash_return=0x0, key=0x7fffca90,
hashtable=0x56642840) at ./src/utils/fluid_hash.c:169
#1  fluid_hashtable_lookup (hashtable=hashtable@entry=0x56642840,
key=0x7fffca90) at ./src/utils/fluid_hash.c:740
#2  0x7731a35c in fluid_settings_get
(settings=settings@entry=0x56642840, name=name@entry=0x77350cbe
"synth.gain",
value=value@entry=0x7fffcbe0) at ./src/utils/fluid_settings.c:400
#3  0x7731ab21 in fluid_settings_callback_num (settings=0x56642840,
name=name@entry=0x77350cbe "synth.gain",
callback=callback@entry=0x0, data=data@entry=0x0) at
./src/utils/fluid_settings.c:743
#4  0x77330b7a in delete_fluid_synth (synth=0x56635400) at
./src/synth/fluid_synth.c:1017
#5  delete_fluid_synth (synth=0x56635400) at ./src/synth/fluid_synth.c:1003
#6  0x77c7631b in fluidsynth_freesong () from /lib/x86_64-linux-
gnu/libSDL_mixer-1.2.so.0
#7  0x77c69597 in Mix_FreeMusic () from /lib/x86_64-linux-
gnu/libSDL_mixer-1.2.so.0
#8  0x5560b178 in mix_free_music () at arch/sdl/digi_mixer_music.c:119
#9  mix_play_file (filename=0x56cab010 "credits.hmp", loop=loop@entry=1,
hook_finished_track=hook_finished_track@entry=0x0)
at arch/sdl/digi_mixer_music.c:43
#10 0x555eac7e in songs_play_file (filename=,
repeat=repeat@entry=1,
hook_finished_track=hook_finished_track@entry=0x0) at main/songs.c:300
#11 0x555eb266 in songs_play_song (songnum=songnum@entry=4,
repeat=repeat@entry=1) at main/songs.c:363
#12 0x55586975 in credits_show
(credits_filename=credits_filename@entry=0x0) at main/credits.c:238
#13 0x555bab57 in do_option (select=) at main/menu.c:602
#14 0x555d2ec0 in newmenu_key_command (wind=,
event=0x7fffe0e0, menu=0x56ad5ea0)
at main/newmenu.c:1019
#15 0x555695eb in event_send (event=0x7fffe0e0) at
arch/sdl/event.c:130
#16 0x5556a868 in key_handler (kevent=kevent@entry=0x7fffe110) at
arch/sdl/key.c:427
#17 0x55569777 in event_poll () at arch/sdl/event.c:43
#18 0x5556984e in event_process () at arch/sdl/event.c:152
#19 0xe1af in main (argc=1, argv=) at
main/inferno.c:437

I find that if I disable sound in the options, the program no longer crashes
and I can play the game without any other problems.

Best regards,

Nathan A. Stine

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 d1x-rebirth depends on:
ii  libc6   2.31-9
ii  libgl1  1.3.2-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libphysfs1  3.0.2-5
ii  libsdl-mixer1.2 1.2.12-16+b1
ii  libsdl1.2debian 1.2.15+dfsg2-6

Versions of packages d1x-rebirth recommends:
ii  freepats  20060219-3
ii  timidity  2.14.0-8

d1x-rebirth suggests no packages.

Bug#985688: chatty: segfault when syncing history with certain accounts

[Vagrant Cascadian]

On 2021-03-22, Guido Günther wrote:
> Could you provide a gdb backtrace with debugging symbols?

Thanks for the quick response.

Hopefully this is what you were looking for (swapped out my client with
USERNAME@EXAMPLE and the connection to a multi-user-chat with
MUC@EXAMPLE):

(gdb) r
Starting program: /usr/bin/chatty
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x71272700 (LWP 3560323)]
[New Thread 0x70a71700 (LWP 3560324)]
[New Thread 0x7fffebfff700 (LWP 3560325)]
[New Thread 0x7fffeb7fe700 (LWP 3560326)]
[New Thread 0x7fffeaffd700 (LWP 3560327)]
[New Thread 0x7fffea7fc700 (LWP 3560328)]
[New Thread 0x7fffe9ffb700 (LWP 3560329)]

(sm.puri.Chatty:3560301): chatty-folks-WARNING **: 13:38:26.372: Error:
Error calling StartServiceByName for
org.gnome.evolution.dataserver.Sources5: Unit
evolution-source-registry.service not found.
[Thread 0x7fffeaffd700 (LWP 3560327) exited]
[Thread 0x7fffea7fc700 (LWP 3560328) exited]
[New Thread 0x7fffea7fc700 (LWP 3560330)]
[New Thread 0x7fffeaffd700 (LWP 3560331)]
[New Thread 0x7fffbfe85700 (LWP 3560332)]

** (sm.puri.Chatty:3560301): CRITICAL **: 13:38:27.041:
   purple_presence_get_active_status: assertion 'presence != NULL'
   failed

** (sm.puri.Chatty:3560301): CRITICAL **: 13:38:27.041:
   purple_status_is_available: assertion 'status != NULL' failed
[Detaching after fork from child process 3560333]

** (sm.puri.Chatty:3560301): CRITICAL **: 13:38:27.043:
   purple_presence_get_active_status: assertion 'presence != NULL'
   failed

** (sm.puri.Chatty:3560301): CRITICAL **: 13:38:27.047:
   purple_presence_is_online: assertion 'presence != NULL' failed

** (sm.puri.Chatty:3560301): CRITICAL **: 13:38:27.054:
   purple_presence_is_online: assertion 'presence != NULL' failed
[Detaching after fork from child process 3560334]
[Detaching after fork from child process 3560353]

** (sm.puri.Chatty:3560301): CRITICAL **: 13:38:28.063:
   xmlnode_set_attrib_full: assertion 'value != NULL' failed

** (sm.puri.Chatty:3560301): CRITICAL **: 13:38:28.063:
   purple_find_conversation_with_account: assertion 'name != NULL'
   failed

** (sm.puri.Chatty:3560301): CRITICAL **: 13:38:28.063:
   purple_conversation_new: assertion 'name != NULL' failed

Thread 1 "chatty" received signal SIGSEGV, Segmentation fault.
cb_chatty_mam_msg_received (pc=, type=,
id=, from=,
to=, msg=) at
../src/xeps/chatty-xep-0313.c:800
800 ../src/xeps/chatty-xep-0313.c: No such file or directory.
(gdb) bt
#0  cb_chatty_mam_msg_received (pc=, type=, id=, from=,
to=, msg=) at
../src/xeps/chatty-xep-0313.c:800
#1  0x771351b4 in
purple_marshal_BOOLEAN__POINTER_POINTER_POINTER_POINTER_POINTER_POINTER
(
cb=, args=, data=,
return_val=0x7fffdb28)
at ././libpurple/signals.c:1019
#2  0x77133e05 in purple_signal_emit_vargs_return_1
(instance=, signal=0x7fffdb28 "",
signal@entry=0x770818c2 "jabber-receiving-message",
args=args@entry=0x7fffdb80)
at ././libpurple/signals.c:563
#3  0x77133f6e in purple_signal_emit_return_1
(instance=,
signal=signal@entry=0x770818c2 "jabber-receiving-message") at
././libpurple/signals.c:506
#4  0x7706f1f4 in jabber_message_parse (js=0x55c97ee0,
packet=0x556a34b0)
at ././libpurple/protocols/jabber/message.c:530
#5  0x77071794 in jabber_parser_element_end_libxml
(user_data=0x55c97ee0, element_name=,
prefix=, namespace=) at
././libpurple/protocols/jabber/parser.c:169
#6  0x759174d7 in xmlParseEndTag2 (ctxt=0x55d8e3d0,
prefix=0x0, URI=0x55d8fe14 "jabber:client",
nsNr=0, tlen=0, line=) at ../../parser.c:9690
#7  0x75921ed9 in xmlParseTryOrFinish
(ctxt=ctxt@entry=0x55d8e3d0, terminate=terminate@entry=0)
at ../../parser.c:11568
#8  0x75923138 in xmlParseChunk__internal_alias
(ctxt=0x55d8e3d0,
chunk=0x77098b00  "rplebfa0ca76'>, terminate=terminate@entry=0) at
../../parser.c:12281
#9  0x77071c5e in jabber_parser_process (js=0x55c97ee0,
buf=, len=)
at ././libpurple/protocols/jabber/parser.c:279
#10 0x77060a3a in jabber_recv_cb_ssl (data=0x55c979f0,
gsc=0x55d39190, cond=)
at ././libpurple/protocols/jabber/jabber.c:694
#11 0x5556f502 in purple_glib_io_invoke (source=,
condition=,
data=0x55699940) at ../src/chatty-manager.c:299
#12 0x77c9bd6f in g_main_dispatch (context=0x556375d0) at
../../../glib/gmain.c:3325
#13 g_main_context_dispatch (context=0x556375d0) at
../../../glib/gmain.c:4043
--Type  for more, q to quit, c to continue without paging--
#14 0x77c9c118 in g_main_context_iterate
(context=context@entry=0x556375d0, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
../../../glib/gmain.c:4119
#15 0x77c9c1cf in g_main_context_iteration
(context=context@entry=0x556375d0, may_block=may_block@entry=1)
at 

Bug#985743: firmware-qcom-soc: broken symlink: /lib/firmware/qcom/sdm845/wlanmdsp.mbn -> ../../ath10k/WCN3990/hw1.0/wlanmdsp.mbn

[Andreas Beckmann]

Package: firmware-qcom-soc
Version: 20210315-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m15.9s ERROR: FAIL: Broken symlinks:
  /lib/firmware/qcom/sdm845/wlanmdsp.mbn -> 
../../ath10k/WCN3990/hw1.0/wlanmdsp.mbn (firmware-qcom-soc)


Is firmware-qcom-soc missing a dependency on firmware-atheros ?


cheers,

Andreas


firmware-qcom-soc_20210315-1.log.gz
Description: application/gzip

Bug#985741: debcargo 2.4.4 adds --no-default-features to every feature-specific test in debian/tests/control

[Daniel Kahn Gillmor]

Package: debcargo
Version: 2.4.4
Control: affects -1 src:rust-sequoia-openpgp

in rust-sequoia-openpgp 1.0.0-1 (generated with debcargo 2.4.3), we see
this example test of the "compression-deflate" feature:

Test-Command: /usr/share/cargo/bin/cargo-auto-test sequoia-openpgp 1.0.0 
--all-targets --features compression-deflate
Features: test-name=librust-sequoia-openpgp+compression-deflate-dev

But in rust-sequoia-openpgp 1.1.0-1 (generated with debcargo 2.4.4, with
no upstream changes to compression-related stuff), we have this test of
the "compression-deflate" feature:

Test-Command: /usr/share/cargo/bin/cargo-auto-test sequoia-openpgp 1.1.0 
--all-targets --no-default-features --features compression-deflate
Features: 
test-name=librust-sequoia-openpgp+compression-deflate-dev:compression-deflate

The test is named slightly differently, but the biggest change is that
it now includes the --no-default-features flag.

This is a subtle but important difference.

Here is a full set of feature-related tests that we can imagine running:

 a) no features enabled at all

 b) all features enabled together

 c) only default features, enabled together

 d) one test per non-default feature, with the default features also enabled

 e) one test per feature, with no other features enabled.

This change from 2.4.3 to 2.4.4 effectively swaps out the tests in (d)
for the tests in (e).

(fwiw, i can also imagine some sort of horrible combinatorial explosion
where we try to test every possible combination of features; i won't get
into that here)

For rust-sequoia-openpgp, where at least one crypto-backend feature must
be enabled (and nettle is the only crypto-backend feature on debian
systems), and the default featureset does include crypto-nettle, all the
tests in (d) should succeed, while most of the tests in (e) are
likely to fail.

I'd prefer to test the combinations of features in rust-sequoia-openpgp
that feel most useful to me (and to minimize the number of tests that
we need to mark as flakey) so i'd prefer to cover (d) instead of (e).

I can see a handful of different possible ways to resolve this:

 0) revert to the 2.4.3 behavior, by dropping --no-default-features from
the feature-specific tests.

 1) introduce a variable debcargo.toml that lets the maintainer choose
between (d) and (e), e.g., "test_with_default_features" as a variable
for the packages.lib section. 

 2) generate even more tests per package, including both (d) and (e)
automatically (and distinctly) as long as there are some default
features.

 3) stick with the 2.4.4 behavior, but clearly document that these extra
tests will be run with --no-default-features.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#985742: qttools5-dev-tools: Please provide application desktop file for qdbusviewer

[Thomas Uhle]

Package: qttools5-dev-tools
Version: 5.11.3-4
Severity: normal

Dear maintainers,

could you please add an application desktop file for qdbusviewer.

Thank you in advance!

Thomas Uhle


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qttools5-dev-tools depends on:
ii  libc6 2.28-10
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg1-1+deb10u4
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u4
ii  libqt5designer5   5.11.3-4
ii  libqt5designercomponents5 5.11.3-4
ii  libqt5gui55.11.3+dfsg1-1+deb10u4
ii  libqt5help5   5.11.3-4
ii  libqt5network55.11.3+dfsg1-1+deb10u4
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u4
ii  libqt5quickwidgets5   5.11.3+dfsg1-1+deb10u4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u4
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1+deb10u4
ii  libqt5xml55.11.3+dfsg1-1+deb10u4
ii  libstdc++68.3.0-6
ii  qdoc-qt5  5.11.3-4
ii  qt5-assistant 5.11.3-4
ii  qtchooser 66-2

qttools5-dev-tools recommends no packages.

qttools5-dev-tools suggests no packages.

Bug#985740: firmware-brcm80211: broken symlink: /lib/firmware/brcm/brcmfmac43362-sdio.lemaker,bananapro.txt -> brcmfmac43362-sdio.cubietech,cubietruck.txt

[Andreas Beckmann]

Package: firmware-brcm80211
Version: 20210315-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m14.6s ERROR: FAIL: Broken symlinks:
  /lib/firmware/brcm/brcmfmac43362-sdio.lemaker,bananapro.txt -> 
brcmfmac43362-sdio.cubietech,cubietruck.txt (firmware-brcm80211)


cheers,

Andreas


firmware-brcm80211_20210315-1.log.gz
Description: application/gzip

Bug#985738: firmware-sof-signed: broken symlinks: /lib/firmware/intel/sof/{,community/}sof-jsl.ri -> {,../}v1.6.1/intel-signed/sof-jsl-v1.6.1.ri

[Andreas Beckmann]

Package: firmware-sof-signed
Version: 1.6.1-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m14.5s ERROR: FAIL: Broken symlinks:
  /lib/firmware/intel/sof/sof-jsl.ri -> v1.6.1/intel-signed/sof-jsl-v1.6.1.ri 
(firmware-sof-signed)
  /lib/firmware/intel/sof/community/sof-jsl.ri -> 
../v1.6.1/public-signed/sof-jsl-v1.6.1.ri (firmware-sof-signed)


cheers,

Andreas


firmware-sof-signed_1.6.1-2.log.gz
Description: application/gzip

Bug#632691: RFC: calling lrelease automatically in qmake mode

[Niels Thykier]

Control: tags -1 wontfix

On Tue, 05 Jul 2011 00:57:25 +0200 Leo 'costela' Antunes
 wrote:
> Package: debhelper
> Version: 8.9.0
> Severity: wishlist
> 
> [CC'ing original qmake module author for input]
> 
> Hi,
> 
> Would it be feasible to automatically call lrelease[0] if we find
> a TRANSLATIONS variable in any *.pro file?
> If the idea sounds reasonable I could try to come up with a patch
> (though my perl-foo is considerably rusty). The main problem I can
> think of is how to build a clean function, since lrelease doesn't seem
> to provide an easy way to remove all generated *.qm files.
> 
> 
> Cheers
> 
> [0] http://doc.qt.nokia.com/latest/linguist-manager.html
> 
> 
> [...]


Thanks for the suggestion.

I have decided to wontfix this request.  As I understand it, qt has
officially blessed cmake as the new replacement for qmake now.  While
qmake is still supported, I expect it to dwindle in popularity over
time.  Also, given that no one (including the past and present debhelper
maintainer) has stepped up to get the issues clarified and a patch
written for this bug, it seems unlikely it will happen before cmake
replaces qmake.

If a well tested patch appear, I am open to reconsider the wontfix.

Thanks,
~Niels

Bug#985737: convertdate: autopkgtest failure

[Sebastian Ramacher]

Source: convertdate
Version: 2.3.2-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

The autopkgtests of convertdate fail everywhere:
| test_jwday (tests.test_utils.TestConvertdate) ... ok
|
| ==
| ERROR: test_equinox_jd (tests.test_persian.testPersian) (y=1000, jd=2086381)
| --
| Traceback (most recent call last):
|   File 
"/tmp/autopkgtest-lxc.ctbufrn7/downtmp/autopkgtest_tmp/tests/test_persian.py", 
line 43, in test_equinox_jd
| self.assertEqual(persian.equinox_jd(gyear), jd)
|   File "/usr/lib/python3/dist-packages/convertdate/persian.py", line 51, in 
equinox_jd
| deltat_jd = mean_jd - Epoch.tt2ut(gyear, 3) / (24 * 60 * 60.)
|   File "/usr/lib/python3/dist-packages/pymeeus/Epoch.py", line 1403, in tt2ut
| dt = 1574.2 + u * (
| UnboundLocalError: local variable 'u' referenced before assignment

See
https://ci.debian.net/data/autopkgtest/testing/amd64/c/convertdate/11090578/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#985736: duplicate symbols in symbols file

[Matthias Klose]

Package: src:libraw
Version: 0.20.2-1

$ sort -u debian/libraw20.symbols | wc -l
599

$ wc -l debian/libraw20.symbols
1197 debian/libraw20.symbols

looks like all symbols are listed twice ... please fix.

Bug#985705: courier-authlib: upgrades broken due the move of the tools

[Andrey Rahmatullin]

Control: tags -1 + moreinfo


On Mon, Mar 22, 2021 at 09:10:29AM -0400, PICCORO McKAY Lenz wrote:
> Package: courier-authlib
> Version: 0.71.0-1
Why is this version set here?

> i just try the upgrade case from stretch to lasted 
You can upgrade stretch only to buster.
On the other hand, 0.71.0-1 is present only in old testing, not in any
stable.

> when i try to upgrade got this error:
> 
> dpkg: error al procesar el archivo
> /var/cache/apt/archives/courier-authdaemon_0.71.1-2_i386.deb
> (--unpack):
>  intentando sobreescribir `/usr/sbin/authenumerate', que está también
> en el paquete courier-authlib 0.71.0-1
> dpkg: considerando la desconfiguración de courier-authdaemon, ya que
> lo rompería la instalación de `courier-base' ...
I cannot reproduce this. You need to explain how to reproduce this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#960419: dh_link: Add option to check for identical file contents before replacing

[Niels Thykier]

Control: tags -1 wontfix

On Fri, 15 May 2020 10:21:17 +0200 Matthijs Kooijman 
wrote:
> Hey Niels,
> 
> > As far as I can tell, the underlying desire is to do some form of
> > deduplication.
> Yes, indeed.
> 
> > If so, then I think this is similar to #888397 with an expanded scope
> > and a proposal for doing this via dh_link (rather than dh_installdocs
> > or a new helper).
> 
> I guess my proposal is actually more narrow and specific. That other
> report asks about more generic deduplication (run on the entire package,
> or maybe a subset of files) that automatically finds duplicate files. I
> guess that could be useful, but is also quickly a lot more complicated
> (more work to find duplicates, which is the canonical one, any
> exceptions). I'm also less inclined to completely automate this, I'd
> rather make some more explicit choices (though something like "link files
> in *this* directory to *that* directory if you find duplicates" could be
> a nice compromise between automatic and manual work, maybe).
> 
> Regardless, my suggestion would allow manual and explicit deduplication
> to become a bit easier, at the expense of having to manually track the
> list of duplicate files on upstream changes (but with my suggestions,
> detecting files that are no longer duplicated is automatic, and lintian
> can I think already detect *new* duplicate files, so together that would
> allow adequately fixing all duplicates).
> 
> I think that both issues are thus sufficiently separate (in how they
> work and would be implemented) and can be valuable to eventually
> implement side-by-side, so I would suggest keeping both issues open for
> now.
> 
> Gr.
> 
> Matthijs


Thanks for the suggestion.

I have decided to tag this wontfix. If there is interest in this
feature, please consider prototyping it outside of debhelper (e.g. via a
dh sequence add-on).  Should it become successful, I will reconsider the
wontfix tag.

Thanks
~Niels

Bug#888397: debhelper: enhance dh_installdocs or add a helper to deduplicate files

[Niels Thykier]

Control: tags -1 wontfix

On Thu, 25 Jan 2018 02:39:05 +0100 Andreas Beckmann  wrote:
> Package: debhelper
> Severity: wishlist
> 
> Hi,
> 
> doxygen (and probably other tools) may generate duplicate files,
> e.g. as can be seen in this Lintian report:
> 
> X: opencl-clhpp-headers-doc: duplicate-files 
> usr/share/doc/opencl-clhpp-headers/html/search/all_c.js 
> usr/share/doc/opencl-clhpp-headers/html/search/functions_b.js
> X: opencl-clhpp-headers-doc: duplicate-files 
> usr/share/doc/opencl-clhpp-headers/html/search/all_10.js 
> usr/share/doc/opencl-clhpp-headers/html/search/typedefs_4.js
> X: opencl-clhpp-headers-doc: duplicate-files 
> usr/share/doc/opencl-clhpp-headers/html/search/all_5.js 
> usr/share/doc/opencl-clhpp-headers/html/search/typedefs_2.js
> 
> It would be nice if debhelper could provide some means to deduplicate
> such files - either as a separate helper or integrated into
> dh_installdocs (since I assume that could handle be the primary source
> of automatically generated duplicate files).
> Since these are generated duplicate files and from one version of the
> generator to the next they may change, be renamed, be moved around, ...
> the maintainer as a mere user of the generator should not really have
> to care about these files - either by manually deduplicating or by
> adding lintian overrides.
> 
> 
> Andreas
> 
> PS: for opencl-clhpp-headers-doc I now deduplicate manually with a
> call to hardlink ... works since the dupes are within the same
> directory, otherwise lintian would complain about cross-directory
> hardlinks
> 
> 


Thanks for the suggestion.

I have decided to tag this wontfix. If there is interest in this
feature, please consider prototyping it outside of debhelper (e.g. via a
dh sequence add-on).  Should it become successful, I will reconsider the
wontfix tag.

Thanks
~Niels

Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine

[maximilian attems]

Dear Ryutaroh,

> It is Raspberry Pi 4B 8GB model.

I see thank you for all the dmesg.
 
> > please show affected dmesg output working and non working,
> > the difference between 20210208-3 20210208-4 is minimal,
> > hence it should be easy to find out what broke?
> 
> Not at all, unfortunately.
> 20210208-3 was completely broken on RPi4B as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984489
> 20210208-1 to 20210208-3 were broken...
> The last working version was 20201218-3, and I apt-mark-holded 
> firmware-brcm80211.
> I unhold it in the weekend and found this issue.

please excuse my ignorance first, but are you sure that these
bootflags are still adequate for the latest cypress firmware?

concerning bluetooth unfortunately this seems missing firmware
in latest upstream firmware git (see #962038 ) or possible wget info
https://wiki.debian.org/RaspberryPi4#Bluetooth
 
> I attach dmesg of 20201218-3, 20210208-4, and 20210315-1.
> It was also interesting that installation of 20210315-1 causes boot failure
> and showed "Give root password for maintainance"...
> Should I file a separete report against 20210315-1?
> 20210315-1~exp1 was booted fine...

this should not be reproducible as 20210315-1 and 20210315-1~exp1 are
unchanged (just uploaded into experimental before unstable).
 
Thank you for your report!
maximilian

Bug#985735: unblock: freediameter/1.2.1-8

[Thorsten Alteholz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package freediameter

The package is affected by CVE-2020-6098, which is marked as RC by the 
security team in #985088.

The mentioned fix is only minimal, so the risk should be low.

unblock freediameter/1.2.1-8

   Thorsten

Bug#985692: unblock: sweethome3d/6.4.2+dfsg-2

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-03-22 12:03:55 +0200, Andrius Merkys wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Dear release-team,
> 
> I am seeking pre-approval to upload sweethome3d/6.4.2+dfsg-2.

Please go ahead and removed the moreinfo tag once the version is
available in unstable.

Cheers

> 
> [ Reason ]
> sweethome3d/6.4.2+dfsg-1 is affected by #985604 which is of severity:
> important. sweethome3d/6.4.2+dfsg-2 fixes this bug in unstable. The fix
> is simple, it only contains an instruction for sweethome3d to add a
> missing JAR to its CLASSPATH.
> 
> [ Impact ]
> Without the fix, users of sweethome3d will not be able to use SVG export
> feature.
> 
> [ Tests ]
> * Built on clean sid chroot;
> * Tested SVG export feature in sid.
> 
> [ Risks ]
> Changes are minimal and should not affect other packages negatively.
> 
> [ Checklist ]
>   [*] all changes are documented in the d/changelog
>   [*] I reviewed all changes and I approve them
>   [*] attach debdiff against the package in testing
> 
> unblock sweethome3d/6.4.2+dfsg-2
> 
> Best,
> Andrius

> diff -Nru sweethome3d-6.4.2+dfsg/debian/changelog 
> sweethome3d-6.4.2+dfsg/debian/changelog
> --- sweethome3d-6.4.2+dfsg/debian/changelog   2020-09-19 16:53:24.0 
> -0400
> +++ sweethome3d-6.4.2+dfsg/debian/changelog   2021-03-22 05:44:09.0 
> -0400
> @@ -1,3 +1,10 @@
> +sweethome3d (6.4.2+dfsg-2) unstable; urgency=medium
> +
> +  * Team upload.
> +  * Locating freehep-graphicsbase (Closes: #985604)
> +
> + -- Andrius Merkys   Mon, 22 Mar 2021 05:44:09 -0400
> +
>  sweethome3d (6.4.2+dfsg-1) unstable; urgency=medium
>  
>* New upstream version 6.4.2+dfsg.
> diff -Nru sweethome3d-6.4.2+dfsg/debian/sweethome3d.sh 
> sweethome3d-6.4.2+dfsg/debian/sweethome3d.sh
> --- sweethome3d-6.4.2+dfsg/debian/sweethome3d.sh  2020-09-19 
> 16:53:24.0 -0400
> +++ sweethome3d-6.4.2+dfsg/debian/sweethome3d.sh  2021-03-22 
> 05:43:57.0 -0400
> @@ -13,7 +13,7 @@
>  
>  find_jars j3dcore j3dutils vecmath batik
>  find_jars sunflow itext janino freehep-util freehep-io freehep-xml
> -find_jars freehep-graphics2d freehep-graphicsio freehep-graphicsio-svg
> +find_jars freehep-graphics2d freehep-graphicsbase freehep-graphicsio 
> freehep-graphicsio-svg
>  find_jars /usr/share/sweethome3d/sweethome3d.jar
>  find_jars /usr/share/icedtea-web/netx.jar
>  


-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#985714: unblock: yubikey-manager/4.0.0~a1-3

[Sebastian Ramacher]

Hi Taowa

On 2021-03-22 12:02:30 -0400, Taowa wrote:
> Hi Sebastian,
> 
> Sebastian Ramacher, 2021-03-22 11:46 -0400:
> > Thankfully the package does not install the .mypy_cache, but listing all
> > the caches in package_data seems odd.
> [...] 
> > Note that python3-cryptography and python3-fido2 in stable do not
> > satisfy these version requirements. I would expect that the version
> > requirements would be reflected in Depends. Also listing both >= 0.15.1
> > and >= 17.0.0 for pyopenssl is redundant.
> 
> Both of these were already being done in the package prior to my upload.
> All I did was change them from an ln at clean-time to a patch. Seeing as
> I'm not the one wro wrote setup.py, I'm not in a position where I feel
> comfortably changing it, especially during a freeze. If, however, you
> feel that's best, I can certainly try.
>  
> > This change is not documented and also not really necessary.
> My bad.
> 
> How should I move forward with this? A new upload without the lintian
> override or change to the build process?

setup.py can be fixed after the release of bullseye, but please fix
the dependencies of the binary packages to reflect the version
constraints from setup.py.

I'd prefer if the lintian override was also reverted. That's stuff for
bookworm.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#985734: cantata: Please update build dependencies

[Thomas Uhle]

Package: src:cantata
Version: 2.3.3.ds1-1
Severity: normal

Dear maintainers,

can you please update the build dependencies to build a full-grown binary 
release of Cantata. That would need to add libavahi-common-dev, 
libavahi-client-dev and libdbus-1-dev as build dependencies as well as to 
replace libcdparanoia-dev by libcdio-paranoia-dev.  On the other hand you 
could remove some build dependencies that are no longer used, that is 
libphonon4qt5-dev, libvlc-dev, libvlccore-dev and libx11-dev because 
QtMultimedia has been used instead of Phonon since more than 8 years for 
instance. Also qtbase5-dev no longer directly depends on libx11-dev, and 
Cantata does also not need X11 headers to be compiled having a Qt version 
without X11 support. So I think an indirect dependency on libx11-dev via 
qtbase5-dev (which in turn depends on libxext-dev ...) would be 
sufficient.


Thank you in advance!

Thomas Uhle


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cantata depends on:
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-1
ii  libavcodec58  7:4.1.6-1~deb10u1
ii  libavformat58 7:4.1.6-1~deb10u1
ii  libavutil56   7:4.1.6-1~deb10u1
ii  libc6 2.28-10
ii  libcddb2  1.3.2-6
ii  libcdparanoia03.10.2+debian-13
ii  libebur128-1  1.2.4-2
ii  libgcc1   1:8.3.0-6
ii  libmpg123-0   1.25.10-2
ii  libmtp9   1.1.16-2
ii  libmusicbrainz5cc2v5  5.1.0+git20150707-9
ii  libqt5concurrent5 5.11.3+dfsg1-1+deb10u4
ii  libqt5core5a  5.11.3+dfsg1-1+deb10u4
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u4
ii  libqt5gui55.11.3+dfsg1-1+deb10u4
ii  libqt5multimedia5 5.11.3-2
ii  libqt5network55.11.3+dfsg1-1+deb10u4
ii  libqt5sql55.11.3+dfsg1-1+deb10u4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1+deb10u4
ii  libqt5svg55.11.3-2
ii  libqt5widgets55.11.3+dfsg1-1+deb10u4
ii  libqt5xml55.11.3+dfsg1-1+deb10u4
ii  libstdc++68.3.0-6
ii  libtag1v5 1.11.1+dfsg.1-2
ii  libudev1  241-7~deb10u6
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages cantata recommends:
ii  liburi-perl   1.76-1
ii  perl-base [libio-socket-ip-perl]  5.28.1-6+deb10u1

Versions of packages cantata suggests:
ii  media-player-info  24-2
ii  mpd0.21.11-1

Bug#985729: rust-regex empty pattern support is flawed

[Daniel Kahn Gillmor]

Package: src:rust-regex
Version: 1.3.7-1
Control: forwarded -1 https://gitlab.com/sequoia-pgp/sequoia/-/issues/694
Control: affects -1 src:rust-sequoia-openpgp
Control: clone -1 -2
Control: reassign -2 src:rust-regex-syntax 0.6.17-1

In the above-mentioned report for Sequoia's OpenPGP crate, we observe
how the regex crate fails to support some of the test cases that sequoia
includes.

This appears to be the main changelog issue between these two
regex-related crates from their debian-related version to the next
upstream version: regex-syntax (0.6.17 vs. 0.6.18) and regex (1.3.7
vs. 1.3.8).

I could work around this test failure in rust-sequoia-openpgp by patching
out the relevant test lines, but given that the changes between the
versions mentioned above seem fairly closely targeted to the minor
version bump in the regex-related packages, and this change is pretty
much the only thing in those packages, it might make more sense to just
bump rust-regex{,-syntax} to include these fixes for better handling of
empty regex patterns.

  --dkg


signature.asc
Description: PGP signature

Bug#985727: The sentence may need to be adapted as well

[Nelson A. de Oliveira]

Probably "You can resume an unsent report using" should also be
rephrased to "You can resume the unsent report using".
But you get the idea :-)

Thanks!

Nelson

Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1

[Sebastian Andrzej Siewior]

On 2020-07-21 16:53:23 [+0200], Santiago Ruano Rincón wrote:
> diff -Nru bzip2-1.0.6/debian/rules bzip2-1.0.6/debian/rules
> --- bzip2-1.0.6/debian/rules  2019-06-24 22:16:40.0 +0200
> +++ bzip2-1.0.6/debian/rules  2020-07-21 10:31:21.0 +0200
> @@ -14,6 +14,9 @@
>  DEB_BUILD_MAINT_OPTIONS := hardening=+all
>  DEB_CFLAGS_MAINT_APPEND := -Wall -Winline
>  DEB_CPPFLAGS_MAINT_APPEND := -D_REENTRANT
> +# This -D_FILE_OFFSET_BITS=64 is needed to make bzip2 able to handle > 
> 2GB-size
> +# files in 32-bit archs. See #944557
> +DEB_CPPFLAGS_MAINT_APPEND += -D_FILE_OFFSET_BITS=64

Isn't the preferred way to add "future=+lfs" to DEB_BUILD_MAINT_OPTIONS
?
>  include /usr/share/dpkg/buildflags.mk
>  
>  include /usr/share/dpkg/pkg-info.mk

Sebastian

Bug#985728: ITP: howdy -- Infrared Facial Authentication Module for Linux

[Lem Severein]

Package: wnpp
Severity: wishlist
Owner: Lem Severein 

* Package name: howdy
  Version : 3.0.0
  Upstream Author : Lem Severein 
* URL : https://boltgolt.nl/howdy
* License : MIT
  Programming Lang: Python, C++
  Description : Infrared Facial Authentication Module for Linux

Howdy provides Windows Hello style authentication for Linux. Use 
your built-in infrared emitters and camera in combination with 
facial recognition to prove who you are.

Based on visitor and download statistics Howdy is already used on 
tens of thousands of systems. Currently distributed with a PPA or 
deb file directly. Version 3.0.0 will introduce large changes and
 make Howdy a lot more mature. I think it's time to try and 
package it within the main debian archive.

I am the main developer and maintainer of this package, and i
intend to continue to support Howdy. I'm not sure in what team 
this package would fit, but a sponsor would be nice.

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

Resending because I managed to accidently clear TO:

On 2021-03-22 19:48:31 [+0100], Cc 959...@bugs.debian.org wrote:
> On 2021-02-24 23:23:07 [+0100], To Kurt Roeckx wrote:
> > On 2021-02-10 21:52:46 [+0100], To Kurt Roeckx wrote:
> > > OpenSSL upstream announced [0] 1.1.1j for next Tuesday with a security
> > > fix classified as MODERATE [1].
> 
> So this happened. OpenSSL upstream announced [0] 1.1.1k for next
> Thursday (25th).
> 
> I will prepare 1.1.1k for unstable, do buster-security based on
> 1.1.1d-0+deb10u5 and then come back with an updated pu :)
> 
> [0] https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html
>  
Sebastian

Bug#955208: [Pkg-rust-maintainers] Bug#955208: rustc: rustup is not available on Debian

[Matt Corallo]

What is the use-case for rustup being packaged? rustup is just a thin wrapper around downloading binaries from a third 
party, so why not just download it from the same third-party? It is geared at installing things in the local users' home 
directory anyway.


Packaging rustup doesn't address the many limitations of rustup's rustc vs Debian's (excellently-packaged) rustc (eg 
cross-language LTO, LLVM plugins, etc).


Matt

On Sat, 4 Apr 2020 01:19:59 +0100 Ximin Luo  wrote:

Hi all,

I agree that rustup should be in Debian. Achieving this is currently blocked on 
either of these two issues:

- https://github.com/rust-lang/rustup/issues/835 OR
- https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22

If you want to help, achieving either of these would help to unblock progress.

X

Ralph Giles:
> I would also like to start off with a Debian-packaged rustup rather
> than having to install it from upstream.
> 
> It's been discussed before, but I think no one was pursuaded to start

> maintaining a package. IIRC one issue was that rustup likes to update
> itself. You'd need to check how difficult it would be to have the
> system rustup always just install any updates in the user's .cargo
> subtree, without trying to write to the root filesytem. The user's
> local version would then take precedence through the normal PATH
> setting.
> 
> I think there was also some concern about support over the lifetime of

> a debian release, should upstream change their API sufficiently to stop
> the packaged version working.
> 
>  -r
> 
> On Sat, 2020-03-28 at 14:04 +0100, Martin Monperrus wrote:

>> Package: rustc
>> Version: 1.40.0+dfsg1-5
>> Severity: normal
>>
>> Dear Awesome Rust Debian Maintainers,
>>
>> I notice that rustup is not packaged for Debian. One option is to go
>> through
>> snap (https://snapcraft.io/install/rustup/debian) but native packages
>> are
>> preferable.
>>
>> Since rustup is used by many projects, it would be great to have it
>> natively on
>> Debian:
>>
>> apt-get install rustup
>>
>> What do you think?
>>
>> Best regards,
>>
>> --Martin
>>
>>
>>
>>
>>
>> -- System Information:
>> Debian Release: bullseye/sid

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-02-24 23:23:07 [+0100], To Kurt Roeckx wrote:
> On 2021-02-10 21:52:46 [+0100], To Kurt Roeckx wrote:
> > OpenSSL upstream announced [0] 1.1.1j for next Tuesday with a security
> > fix classified as MODERATE [1].

So this happened. OpenSSL upstream announced [0] 1.1.1k for next
Thursday (25th).

I will prepare 1.1.1k for unstable, do buster-security based on
1.1.1d-0+deb10u5 and then come back with an updated pu :)

[0] https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html
 
Sebastian

Bug#985727: reportbug: Include temp filename in resume message

[Nelson A. de Oliveira]

Package: reportbug
Version: 7.10.3
Severity: wishlist
Tags: patch

Hi!

Right now we have this in reportbug:

=
(...)
Report will be sent to Debian Bug Tracking System 
Submit this report on reportbug (e to edit) [y|n|a|c|E|i|l|m|p|q|d|t|?]? q
Saving a backup of the report at 
/tmp/reportbug-reportbug-backup-20210322152508-0y4gcuye
Bug report written to /tmp/reportbug-reportbug-20210322152405-lg_io06p
Hint: You can resume an unsent report using reportbug -r TEMPFILE
Thank you for using reportbug
=

But we could have TEMPFILE replaced by it's proper value:

=
(...)
Report will be sent to Debian Bug Tracking System 
Submit this report on reportbug (e to edit) [y|n|a|c|E|i|l|m|p|q|d|t|?]? q
Saving a backup of the report at 
/tmp/reportbug-reportbug-backup-20210322154048-ya0gfvgt
Bug report written to /tmp/reportbug-reportbug-20210322153953-pf6cdu5s
Hint: You can resume an unsent report using:
  reportbug -r /tmp/reportbug-reportbug-20210322153953-pf6cdu5s
Thank you for using reportbug
=

A possible patch is attached.

Thank you!

Best regards,
Nelson

-- Package-specific info:
** Environment settings:
DEBEMAIL="nao...@gmail.com"
INTERFACE="text"

** /home/naoliv/.reportbugrc:
reportbug_version "3.25"
mode advanced
ui text
no-cc
header "X-Debbugs-CC: nao...@gmail.com"

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt2.3.0
ii  python33.9.2-2
ii  python3-reportbug  7.10.3
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
pn  debconf-utils   
pn  debsums 
pn  dlocate 
ii  dma [mail-transport-agent]  0.13-1
pn  emacs-bin-common
ii  file1:5.39-3
ii  gnupg   2.2.27-1
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4

Versions of packages python3-reportbug depends on:
ii  apt2.3.0
ii  file   1:5.39-3
ii  python33.9.2-2
ii  python3-apt2.1.7
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information
diff -ur reportbug-7.10.3/reportbug/submit.py 
reportbug-7.10.3-new/reportbug/submit.py
--- reportbug-7.10.3/reportbug/submit.py2021-01-24 08:55:25.0 
-0300
+++ reportbug-7.10.3-new/reportbug/submit.py2021-03-22 15:40:38.373659270 
-0300
@@ -405,7 +405,8 @@
 fh.close()
 
 ui.long_message(f'Wrote bug report to {msgname}\n'
-'Hint: You can resume an unsent report using 
reportbug -r TEMPFILE')
+'Hint: You can resume an unsent report using:\n'
+f'  reportbug -r {msgname}')
 # Handle when some recipients are refused.
 if refused:
 for (addr, err) in refused.items():
@@ -416,14 +417,16 @@
 fh.close()
 
 ui.long_message(f'Wrote bug report to {msgname}\n'
-'Hint: You can resume an unsent report using reportbug -r 
TEMPFILE')
+'Hint: You can resume an unsent report using:\n'
+f'  reportbug -r {msgname}')
 else:
 try:
 pipe.write(message)
 pipe.flush()
 if msgname:
 ui.long_message(f'Bug report written to {msgname}\n'
-'Hint: You can resume an unsent report using reportbug 
-r TEMPFILE')
+'Hint: You can resume an unsent report using:\n'
+f'  reportbug -r {msgname}')
 except IOError:
 failed = True
 pipe.close()
@@ -435,7 +438,8 @@
 fh.close()
 ui.long_message('Error: send/write operation failed, bug report '
 f'saved to {msgname}\n'
-'Hint: You can resume an unsent report using 
reportbug -r TEMPFILE')
+'Hint: You can resume an unsent report using:\n'
+f'  reportbug -r {msgname}')
 
 if mua:
 ewrite("Spawning %s...\n", mua.executable)

Bug#985726: benchmark: autopkgtest regression: test depends on removed g++-8

[Paul Gevers]

Source: benchmark
Version: 1.5.2-2
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer,

Your package has an autopkgtest, great! However, recently it started to
fail [1] because g++-8 was removed from Debian and your test hard-codes
that dependency.

Paul

[1] https://ci.debian.net/packages/b/benchmark/



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985725: slurm-wlm: flaky autopkgtest: srun: Required node not available (down, drained or reserved)

[Paul Gevers]

Source: slurm-wlm
Version: 20.11.4-1
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 on
all architectures I checked. I have copied some of the output below. Can
you please look into it and fix it? Either the output to stderr is
actually OK, then a allow-stderr restriction is enough to fix the issue,
or it's actually showing that there's a real issue that needs fixing (as
the test itself doesn't fail).

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.

Paul

https://ci.debian.net/packages/s/slurm-wlm/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/s/slurm-wlm/11213446/log.gz

autopkgtest [09:10:26]: test srun: [---
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
test*up   infinite  1unk localhost
NODELIST   NODES PARTITION STATE
localhost  1 test* unk
srun: Required node not available (down, drained or reserved)
srun: job 2 queued and waiting for resources
srun: job 2 has been allocated resources
autopkgtest [09:10:31]: test srun: ---]
autopkgtest [09:10:31]: test srun:  - - - - - - - - - - results - - - -
- - - - - -
srun FAIL stderr: srun: Required node not available
(down, drained or reserved)
autopkgtest [09:10:31]: test srun:  - - - - - - - - - - stderr - - - - -
- - - - -



OpenPGP_signature
Description: OpenPGP digital signature

Bug#882375: Thanks

[Ulrike Uhlig]

Hi Daniel,

On 22.03.21 19:02, asciiw...@seznam.cz wrote:

On Thu, 23 Nov 2017 14:16:00 + u  wrote:

thanks for your patch, I will try to add this as soon as I can, once
reviewed.



is there any progress regarding this? It has been almost three years and the 
AppStream metadata file still seems to be missing.


As I am not a pidgin user myself anymore, I'm not taking care of this 
package, even though I am still part of the privacy team.


To my knowledge, Clément (nodens) c/would potentially take care of it as 
part of his work.


Cheers!
Ulrike

Bug#985452: cowbuilder: add cron job to remove stray cow.[0-9]* dirs from /var/cache/pbuilder/build

[Mattia Rizzolo]

Control: tag -1 -patch
Control: retitle -1 cowbuilder: leaves around stray 
/var/cache/pbuilder/build/cow.[0-9]+

On Thu, Mar 18, 2021 at 02:19:46PM +0100, Hans-Christoph Steiner wrote:
> I've been using cowbuilder a long time.  I recently noticed that I had
> ~20gigs of stuff in /var/cache/pbuilder/build:

mh, that's indeed not nice.

> There were no active sessions, so it seems these are just forgotten
> detritus.  I propose adding a cron job to clean those up.  I attached
> one that works for me.

Sorry, but a cronjob for this kind of things is not the proper solution.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#882375: Thanks

[asciiwolf]

On Thu, 23 Nov 2017 14:16:00 + u  wrote:
> Hi!
>
> thanks for your patch, I will try to add this as soon as I can, once
> reviewed.
>
> Cheers!
> u.
>
>

Hello,

is there any progress regarding this? It has been almost three years and the 
AppStream metadata file still seems to be missing.

Regards,
Daniel

Bug#985724: libkainjow-mustache: autopkgtest failure due to output on stderr

[Graham Inggs]

Source: libkainjow-mustache
Version: 4.1+ds-1
Severity: important
Tags: patch
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: fails-always

Hi Maintainer

The autopkgtests of libkainjow-mustache fail on armhf[1] and
ppc64el[2] due to output on stderr.  As these are simply notes output
by GCC, this can be solved by allowing such output as follows:

--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,3 @@
 Test-Command: make
 Depends: build-essential, catch
+Restrictions: allow-stderr

Regards
Graham


[1] https://ci.debian.net/packages/libk/libkainjow-mustache/testing/armhf/
[2] https://ci.debian.net/packages/libk/libkainjow-mustache/testing/ppc64el/

Bug#985710: mirror submission for mirror.0-1.cloud

[Sefroyek Pardaz Engineering]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.0-1.cloud
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Sefroyek Pardaz Engineering 
Country: IR Iran, Islamic Republic of
Location: https://0-1.ir
Sponsor: Sefroyek Pardaz Engineering https://0-1.ir




Trace Url: http://mirror.0-1.cloud/debian/project/trace/
Trace Url: http://mirror.0-1.cloud/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.0-1.cloud/debian/project/trace/mirror.0-1.cloud

Bug#985711: mirror submission for mirror.0-1.cloud

[Sefroyek Pardaz Engineering]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.0-1.cloud
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Sefroyek Pardaz Engineering 
Country: IR Iran, Islamic Republic of
Location: https://0-1.ir
Sponsor: Sefroyek Pardaz Engineering https://0-1.ir




Trace Url: http://mirror.0-1.cloud/debian/project/trace/
Trace Url: http://mirror.0-1.cloud/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.0-1.cloud/debian/project/trace/mirror.0-1.cloud

Bug#985723: libusb-1.0-0: libusb-1.0 1.0.24 fails to work with some card readers

[Priit Jõerüüt]

Package: libusb-1.0-0
Version: 2:1.0.24-2
Severity: important

Dear Maintainer,


   * What led up to the situation?

The upgrade of named package.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Upgrade libusb-1.0-0 from 1.0.23 to 1.0.24 in 2020-12-16.

   * What was the outcome of this action?

Internal card reader Broadcom Corp. BCM5880 in Dell Latitude stopped working

   * What outcome did you expect instead?

Internal card reader Broadcom Corp. BCM5880 to continue working as it did
before throughout previous iterations of libusb.

   * Additional information

In 1.0.24 release cycle a kind of fix was introduced in this lib (more here
https://github.com/libusb/libusb/issues/850). As a result many slightly buggy
hardware implementations stopped to work. This seems to affect a lot of Dell
Latitude laptops with internal cardreaders.

This libusb issue is not Debian-specific and affects all distros (e.g.
https://aur.archlinux.org/packages/qdigidoc4/ 2021-02-07 16:58 comment) and
libusb ports to non-Linux OS'es as well.

This means, that in countries, that rely heavily on digital id solutions (eg.
Open-EID https://www.id.ee in Estonia, where 99% of everyday life needs digital
authentication and signatures online), internal card readers in these type of
computers cannot be used with Bullseye. Also Belgium, Lithuania and other
countries that use similar solutions and Debian installations to be upgraded to
Bullseye will be affected.

Libusb bug #850 will be fixed in 1.0.25 (yet to be released). We are now very
late in Bullseye release cycle, but would it be possible to include this patch
of #850 for Bullseye?

Currently only alternative is either to use external cardreader or downgrade to
1.0.23.

Bug#985706: ITP: node-peek-readable -- Read and peek from a readable stream

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-de...@lists.debian.org, vive...@protonmail.com

* Package name: node-peek-readable
  Version : 3.1.3
  Upstream Author : 2017, Borewit (https://github.com/Borewit)
* URL : https://github.com/Borewit/peek-readable#readme
* License : Expat
  Programming Lang: Javascript
  Description : Read and peek from a readable stream

 A promise based asynchronous stream reader, which makes reading from a stream
 easy.
 .
 Allows to read and peek from a Readable Stream
 .
 Note that peek-readable was formally released as then-read-stream.

Bug#985716: kdump-tools passes wrong arguments to makedumpfile

[dann frazier]

On Mon, Mar 22, 2021 at 11:31 AM dann frazier  wrote:
> Thanks for the report Ioanna! Could you test the branch here? I'm
> still trying to figure out how to propose it in a merge...
> https://salsa.debian.org/dannf/kdump-tools/-/commits/bug985716

Oh, figured it out - please feel free to comment here:
https://salsa.debian.org/debian/kdump-tools/-/merge_requests/6