Bug#1012789: linucnc runtime prob with tiff is because of tiff

[Petter Reinholdtsen]

Upstream worked around this problem by dropping the use of libtk-img in
https://github.com/LinuxCNC/linuxcnc/commit/98a847899ee6bc59406bcee9fc79bac310e2bdd8
 >.
Thus this will be fixed in the next upload from upstream master, or
Debian can fetch the patch.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1011640: libhowardhinnant-date-dev: CMake library name problems

[Michael Welsh Duggan]

Just want to send a ping about the Threads bug.

-- 
Michael Welsh Duggan
(m...@md5i.com)

Bug#1013952: qemu: issue passing prop_array parameter

[mc36]

hi,

On 6/28/22 07:01, Michael Tokarev wrote:

It is much better to bring this issue upstream instead of using Debian BTS.



okk, i'll do so...

thanks,
cs

Bug#1013952: qemu: issue passing prop_array parameter

[Michael Tokarev]

28.06.2022 00:34, mc36 wrote:

Package: qemu
Version: 1:7.0+dfsg-1
Severity: normal

Dear Maintainer,

i'm trying to bring up a dev env for route offloading. linux switchdev offers
an emulated
switch called rocker. qemu also supports it, but i have issues passing the
array paraemter
for the front panel ports:

mc36@noti:~$ qemu-system-x86_64 -enable-kvm -m 1g -cpu host -cdrom
Downloads/debian-11.3.0-amd64-netinst.iso -netdev
socket,id=dev0,udp=10.10.10.227:30042,localaddr=:30042 -device rocker,len-
ports=4,name=sw,len-ports=2,ports[0]=dev0
qemu-system-x86_64: -device rocker,len-ports=4,name=sw,len-
ports=2,ports[0]=dev0: Property 'rocker.ports[0]' not found
mc36@noti:~$


It is much better to bring this issue upstream instead of using Debian BTS.

Thanks,

/mjt

Bug#1013920: Info received (Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

[lkcl]

https://www.debian.org/doc/debian-policy/ch-archive.html#the-debian-free-software-guidelines

urrr 50% of the clauses of DFSG 2.1 are violated

section 2.1 3 is violated

3. Derived Works

The license must allow modifications and derived works, and must allow them
to be distributed under the same terms as the license of the
original software.

the additional conditions remove the redistribution rights normally associated
with Free Software Licenses, requiring explicit consent should "modifications
and derived works" be made.

section 2.1.5 is violated

5 No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.

distribibutors constitute a "group of persons" and consequently they are
discriminated against by the imposition of the restriction requiring explicit
permission to modify.

section 2.1 4 is also violated

4 Integrity of The Author’s Source Code

The license may restrict source-code from being distributed in
 modified form only if the license allows the distribution of “patch files”
 with the source code for the purpose of modifying the program at
build time.
The license must explicitly permit distribution of software built
from modified source code.

with the Trademark License creating an additional (Aggregate) License that
overrides and nullifies the "normal" expected Copyright Licenses, section 4
is violated.

section 2.1 7 is violated

7 Distribution of License

The rights attached to the program must apply to all to whom the
program is redistributed without the need for execution of an additional
license by those parties.

the imposition of the additional License Conditions from the Trademark
*are themselves* a violation of this condition

section 2.1 7 is violated as already discussed

section 2.1 9 is violated

9 License Must Not Contaminate Other Software

The license must not place restrictions on other software that is
distributed along with the licensed software.

given that the linux kernel will soon be critically dependent on having
a rust compiler...

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

And FWIW, attached is an end-of-log extract of creating a driverless IPP 
printer ("cupsweb3") from cups web interface, then printing a test page.  
Again, s-c-p reports job completed, but nothing printed.

There are continued references to "ipp/faxout" - and no references to ipp/print.

Eg:

line
2584 D [28/Jun/2022:02:55:42 +0100] [Job 42] Calling 
FindDeviceById(cups-cupsweb3)
2585 D [28/Jun/2022:02:55:42 +0100] [Job 42] Resolved as 
\"ipp://mfcl2740dw.local:631/ipp/faxout\"...

Might this be relevant?

Thanks,
Gareth

cupsweb.txt.xz
Description: application/xz

Bug#1012647: (no subject)

[S.]

Hi there, thanks very much for this speedy fix!
I confirm that broadcom-sta-dkms_6.30.223.271-20 from Testing also fixes the 
compilation issue on a Bullseye system with the 5.18 kernel from Backports. 
Would it be possible to send the fixed DKMS package to Bullseye-Backports as 
well?
Thanks again!

Bug#1012246: nvidia-graphics-drivers-tesla-510: fails on ppc64el due to transitive GPL symbol usage

[Andreas Beckmann]

Control: severity -1 important
Control: tag -1 - sid bookworm

I've temporarily disabled the autopkgtest on ppc64el.


Andreas

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Axel Beckert]

Hi Russ,

Russ Allbery wrote:
> So in short, I think I talked myself back around to your solution.
> :)

Same to me, I talked myself back around to your (previous) opinion.
:-) Hilarious!

So we both seem to have had good arguments. :-)

Hrm, a serious thought on this: Why not implement both variants?

What if we

* make unknown-locale-code look at ISO 639-1, 639-2, 639-3 and even
  639-5 for generally valid codes, and then

* add a new, maybe pedantic-level warning which is only emitted if a
  language group is used in a locale name, i.e. check locales against
  ISO 639-5 and if one of these (which IIRC include the language groups
  present in ISO 639-2) is used as locale, we emit a tag which might
  be named locale-uses-language-group-code or similar?

This currently sounds if it would make use of all our arguments for
and against including ISO 639-2, would be backwards compatible and
more precise and helpful.

Ok, and I should really go to bed now. :-) 

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Axel Beckert]

Hi,

one more comment:

Russ Allbery wrote:
> I worked out the same thing, and I'm fairly sure that means that this is
> not a valid locale.  It's the code for the Berber language *group*, and
> the individual members of that group have their own 639-3 codes, so that
> seems to imply to me that those translations were tagged with the wrong
> code.

So I wondered what they should actually be tagged as. "Judeo-Berber"
is the only language with the string "berber" I found in ISO 639-3.

Unfortunately I found no mapping between ISO 639-2/-5 language groups
and actual languages in ISO 639-3 — in neither of JSON files for these
three parts.

So I dug around in Wikipedia and figured out that Judeo-Berber is a
"Non-Zenati Northern Berber language". And it using the Hebrew
alphabet seems to be a unique characteristic. Which again seems rather
specific and if it's a Berber language and hasn't Hebrew letters, it's
likely not Judeo-Berber.

Given https://en.wikipedia.org/wiki/File:Linguistic_Diagram_Berber.png
(from https://en.wikipedia.org/wiki/Berber_languages) there are tons
of possible languages gathered under "Berber languages", so the longer
the more I tend to agree with Russ' arguments to stay with ISO 639-3
only.

Plus maybe add a few more notes to the tag description to explain why
language groups are probably no good idea for locales.

Still would be happy about input from Toddy on this. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Russ Allbery]

Axel Beckert  writes:

> Anyway, JFTR: I just looked at how lintian in Debian Stable (i.e.
> 2.104.0 in Bullseye) does the locale code lookup. It had it's own data
> file for that (and hence now using iso-codes is good as it is no more
> duplicating these 33kB of data) and that file
> (/usr/share/lintian/data/files/locale-codes) states:

>   # List of locale codes.  This is derived from the ISO 639-1, ISO
>   # 639-2, and ISO 639-3 standards.

> And indeed, "ber" was in that file.

> So previously lintian did use ISO 639-1, 639-2 and 639-3.

> So using just ISO 639-3 was either an accident, on purpose or a
> regression and has been introduced when lintian was switching to
> iso-code's files as data source in commit
> https://salsa.debian.org/lintian/lintian/-/commit/fcaded19

What I think I managed to reconstruct from reading about this [1] is that
639-2 was the original work to supplement 639-1 (which is limited to
two-letter codes and omits a lot of smaller languages).  However, ISO
639-2 also assigned codes to language families and some other things,
wherease ISO 639-3 is limited to just languages and the families moved to
ISO 639-5.

[1] https://en.wikipedia.org/wiki/ISO_639-2 mostly.

Looking at ISO 639-5, I think a lot of those wouldn't make sense as
translations.  It has a lot of things like zhx (Chinese family), cpe (all
English-based creoles), or grk (Greek languages).  Some of those (cpe for
example) also appear in ISO 639-2, which implies to me that 639-2 is a bit
too broad for useful translations.

That said, reading more about the Berber languages [2], I understand how
this happened with this group in particular.  Specifically, this:

A listing of the other Berber languages is complicated by their
closeness; there is little distinction between language and
dialect. The primary difficulty of subclassification, however, lies in
the eastern Berber languages, where there is little agreement.

probably implies that the languages are sufficiently mutually
comprehensible that it may make sense to translate something to "Berber"
without specifying a specific language in the family.  (I could imagine
that sometimes it may avoid political and social issues to not specify a
specific language from the family, although I have no idea if that's the
case here.)

[2] https://en.wikipedia.org/wiki/Berber_languages

However, that wouldn't really make sense for "cpe" (creoles are very
different from each other even if they're English-based).  So that still
feels to me like it leans away from including everything in 639-2.

I think I may be talking myself into adding an exception list of non-639-3
language codes that nonetheless are used by translators.  But that's an
ongoing maintenance burden, so maybe that's not the right move either.

The alternate argument is that Lintian's check is really mostly there to
catch typos, and maybe we should assume anyone who uses any 639-2 or 639-3
code knows what they're doing.  And since that's what Lintian used to do,
it has the benefit of fixing a regression and I don't think anyone was
complaining about the breadth of the previous list, just the duplication
of information.

So in short, I think I talked myself back around to your solution.  :)
(Maybe all of this can be captured in comments for the next poor
maintainer who has to try to understand what's going on.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1013962: please include serial module in signed grub-efi package

[Joseph Nahmias]

Package: grub-efi-amd64-bin
Version: 2.06-3
Severity: wishlist
X-Debbugs-Cc: j...@nahmias.net

Hello,

I was trying to debug why the grub menu was not showing up on my VMs
(emulated) serial console. I ended up dropping to the grub command-line
and running:

  grub> serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
  error: prohibited by secure boot policy.

Please add the grub serial module to enable this important
functionality when using secure boot!

Much appreciated,
--Joe


-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/1 CPU thread; PREEMPT)
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 grub-efi-amd64-bin depends on:
ii  grub-common  2.06-3

Versions of packages grub-efi-amd64-bin recommends:
ii  efibootmgr 17-1
ii  grub-efi-amd64-signed  1+2.06+3

grub-efi-amd64-bin suggests no packages.

-- no debconf information

Bug#1013961: ITP: structured-logging-clojure

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jérôme Charaoui 

   Package name : structured-logging-clojure
   Version  : 0.2.0
   Upstream author  : PuppetLabs, Inc
   URL  : https://github.com/puppetlabs/structured-logging
   License  : Apache-2.0
   Programming Lang : Clojure
   Description  : Write data structures to your logs from clojure.

structured-logging is a library that helps you to:

 * write arbitrary JSON to your logs, making it easier to interface 
with log analysis tools.
 * write messages to arbitrarily named loggers, instead of just the one 
named after the namespace in which the log statement appears.


It is built on clojure.tools.logging, but it only works with logback.


Thanks,

-- Jerome

Bug#1013960: rapidjson: Rethink debian license GPL-2+

[Bastian Germann]

Source: rapidjson
Severity: normal
Version: 1.1.0+dfsg2-7

The debian/ directory including debian/patches is currently licensed under 
GPL-2+.
As the patches are not exempt from that license the resulting binaries have to 
comply with GPL-2+ as well.
This causes a problem for reverse dependencies that have incompatible licenses, 
e.g., monero includes files
licensed under RSA-MD.

Would you please consider relicensing at least debian/patches?

Bug#1013959: Upgrade package to latest upstream version

[Jérôme Charaoui]

Package: mockito
Version: 2.23.0-2
Severity: wishlist

Dear maintainer,

Please upgrade mockito to the latest version, 4.6.1.

The currently packaged version, 2.23.0, was released in 2018 and the 
upstream project has released many dozens of updates since then.


In particular, the current version is missing the JUnit Jupiter 
extension which is needed to runs the testsuite for a project I'm 
currently packaging in Debian, logstash-logback-encoder.


Thank you!

-- Jerome

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Axel Beckert]

Control: tag -1 + help

Hi Russ,

Russ Allbery wrote:
> > But upon deeper inspection I found that this is likely not an issue in
> > iso-codes as "ber" is correctly not in
> > /usr/share/iso-codes/json/iso_639-3.json but in …/iso_639-2.json and
> > …/iso_639-5.json as it is a code for a language group. (Which kinda
> > makes it suspicious for me to be used in locales. But then again I'm
> > not a linguist.)
> 
> Sorry, I followed up on the bug and forgot to explicitly cc Lintian

Not needed. I got the message via the lintian ML / maintainer address.
(Somehow I though didn't get my own messages to that bug report back
via the list.)

> I worked out the same thing, and I'm fairly sure that means that this is
> not a valid locale.  It's the code for the Berber language *group*, and
> the individual members of that group have their own 639-3 codes, so that
> seems to imply to me that those translations were tagged with the wrong
> code.

Yep, I also noticed that. I'm just not sure where exactly the border
between just a group of languages, which has no common grounds to be
spoken anywhere, and a group of very similar languages, which likely
can be understood by members of another language from the same group
and maybe even have a common written language, is.

Toddy may indeed have some more input for us here.

> Fabio also followed up and noted that there are a few translations for ber
> in Launchpad, but they're all partial and probably not usable.

Ok, I didn't get that mail. So maybe I really didn't get your initial
mail, just another mail from you to the bug report. :-)

> Tobias probably knows more, as iso-codes maintainer, but my guess is that
> this is a mistake on the Launchpad side and those translations should be
> for one of the specific languages of the group rather than being coded to
> the 639-5 language group code.  I think Lintian should still continue to
> use 639-3.
> 
> That said, I'll leave it to you to decide if you want to hang on to the
> bug or not.  :)

Thanks for your input here. Actually that variant so far was my second
choice (the stricter one) so far. See the very end of that one long
mail from me. :-)

Anyway, JFTR: I just looked at how lintian in Debian Stable (i.e.
2.104.0 in Bullseye) does the locale code lookup. It had it's own data
file for that (and hence now using iso-codes is good as it is no more
duplicating these 33kB of data) and that file
(/usr/share/lintian/data/files/locale-codes) states:

  # List of locale codes.  This is derived from the ISO 639-1, ISO
  # 639-2, and ISO 639-3 standards.

And indeed, "ber" was in that file.

So previously lintian did use ISO 639-1, 639-2 and 639-3.

So using just ISO 639-3 was either an accident, on purpose or a
regression and has been introduced when lintian was switching to
iso-code's files as data source in commit
https://salsa.debian.org/lintian/lintian/-/commit/fcaded19

Unfortunately this commit was tagged "Gbp-Dch: ignore" in git
(why?!?), so it didn't appear in debian/changelog. *g* (I may
retroactively add it to the debian/changelog entry of 2.115.0 like I
already added the item about switching to Text::Glob which also caused
bugs.)

Anyway, with you proposing a more strict checking here and I was at
least initially proposing to get back to the more laxer parsing used
previously, it would be really good to have some additionaly input
from someone with a bit more experience on that topic. I hope that
Toddy can provide that. :-)

Tagging as help for that reason.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1013957: unbound: Rethink debian license GPL-3+

[Bastian Germann]

Source: unbound
Severity: normal
Version: 1.16.0-2

The debian/ directory including debian/patches is currently licensed under 
GPL-3+.
As the patches are not exempt from that license the resulting binaries have to 
comply with GPL-3+ as well.
This causes a problem for reverse dependencies that have incompatible licenses, 
e.g., monero includes files
licensed under RSA-MD.

Would you please consider relicensing at least debian/patches?

Bug#1013958: xfce4-terminal: open URL ignores exo-open settings (and debian settings)

[Chris Waters]

Package: xfce4-terminal
Version: 1.0.4-1
Severity: normal

If I right-click on a URL in the terminal, and then choose "Open Link"
on the pop-up menu, the link is opened in Chromium, even though I have
Firefox selected as the default for both exo-open and Debian's
x-www-browser alternative. If I type "exo-open --launch WebBrowser
http://debian.org;, the URL is opened in Firefox (as expected), but
xfce4-terminal's internal code seems to ignore all my settings!

Bug#1012354: Please add support for systemd-binfmt

[Sean Whitton]

Hello,

On Sat 18 Jun 2022 at 10:37AM +02, Michael Biebl wrote:

> Am 14.06.22 um 21:59 schrieb Michael Biebl:
>> Am 14.06.22 um 21:50 schrieb Sean Whitton:
>>> Hello,
>>>
>>> On Tue 14 Jun 2022 at 09:39PM +02, Michael Biebl wrote:
>>>
 Hi Sean

 Am 13.06.22 um 03:14 schrieb Sean Whitton:
> Thanks for the patch.  I take it you got the sbcl.conf from the
> binfmt-conf package?  So systemd-binfmt means that these config files
> get stored in packages rather than all stored in binfmt-conf?

 I'm confused. What's the "binfmt-conf" package?
>>>
>>> Sorry, I meant binfmt-support.
>>
>> Ok, then that's a no.
>>
>> I looked at that kind of binfmt configuration the sbcl package ships
>> (i.e. debian/binfmt) and created sbcl.conf from that information.
>
> Maybe that was a bit misleading.
> What I meant to say is that the information in sbcl.conf is not coming
> from the binfmt-support package but from the binfmt config file shipped
> in sbcl as debian/binfmt.
> And in the same way, sbcl.conf should be shipped in the sbcl package.

Cool, thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1013956: ITP: logstash-logback-encoder

[Jérôme Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jérôme Charaoui 

   Package name : logstash-logback-encoder
   Version  : 7.2
   Upstream author  : Phil Clay and contributors
   URL  : https://github.com/logfellow/logstash-logback-encoder
   License  : Apache-2.0, Expat
   Programming Lang : Java
   Description  : a library that provides logback encoders, 
layouts, and appenders to log in JSON and other formats supported by Jackson


Originally written to support output in logstash's JSON format, this 
library has evolved into a highly-configurable, general-purpose, 
structured logging mechanism for JSON and other Jackson dataformats. The 
structure of the output, and the data it contains, is fully configurable.


This is a dependency for puppetlabs/structured-logging, itself a 
dependency for PuppetDB 7.



Thanks,

-- Jerome

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

Sorry, I forgot to compress the log.

Added printer name is "DLIPP", logging relating to which seems to start at line 
1537.

Gareth

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Russ Allbery]

Axel Beckert  writes:

> Thanks for your effort, Russ! That was my first guess, too.

> But upon deeper inspection I found that this is likely not an issue in
> iso-codes as "ber" is correctly not in
> /usr/share/iso-codes/json/iso_639-3.json but in …/iso_639-2.json and
> …/iso_639-5.json as it is a code for a language group. (Which kinda
> makes it suspicious for me to be used in locales. But then again I'm
> not a linguist.)

Sorry, I followed up on the bug and forgot to explicitly cc Lintian and of
course that message didn't come through.

I worked out the same thing, and I'm fairly sure that means that this is
not a valid locale.  It's the code for the Berber language *group*, and
the individual members of that group have their own 639-3 codes, so that
seems to imply to me that those translations were tagged with the wrong
code.

Fabio also followed up and noted that there are a few translations for ber
in Launchpad, but they're all partial and probably not usable.

Tobias probably knows more, as iso-codes maintainer, but my guess is that
this is a mistake on the Launchpad side and those translations should be
for one of the specific languages of the group rather than being coded to
the 639-5 language group code.  I think Lintian should still continue to
use 639-3.

That said, I'll leave it to you to decide if you want to hang on to the
bug or not.  :)

-- 
Russ Allbery (r...@debian.org)  

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Axel Beckert]

Control: affects -1 - lintian
Control: reassign -1 lintian
Control: found -1 2.115.1

Hi Russ,

Russ Allbery wrote:
> Thanks for the report!  Lintian gets the canonical list of locales from
> the iso-codes package, and if I'm reading the last modification times from
> its Salsa repository correctly, it may have been a bit since it was
> updated.
> 
> I'm reassigning this bug to iso-codes for further investigation and cc'ing
> the maintainer.

Thanks for your effort, Russ! That was my first guess, too.

But upon deeper inspection I found that this is likely not an issue in
iso-codes as "ber" is correctly not in
/usr/share/iso-codes/json/iso_639-3.json but in …/iso_639-2.json and
…/iso_639-5.json as it is a code for a language group. (Which kinda
makes it suspicious for me to be used in locales. But then again I'm
not a linguist.)

Lintian only uses …/iso_639-3.json as of now. And according to source
code comments it thinks that ISO 639-1 and ISO 639-2 are both subsets
of ISO 639-3 which is clearly wrong.

In the end it is one of the cases where the POSIX specification is
ambiguous as it doesn't state which part of ISO 639 is relevant. (And
ISO doesn't make this easier as ISO 639-1 was just called "ISO 639"
when it was first published in 1967.)

So reassigning back to lintian. :-)

I'll implement a change in lintian which also takes ISO 639-2 into
account.

Toddy: I though wouldn't be unhappy if you could have a look at my
reasoning in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013946#33 which I
unfortunately didn't Cc to you. My main question is: Which parts of
ISO 639 are valid for usage in POSIX locales? I couldn't answer it
even after like 2 hours of digging standards and Wikipedia. Maybe you
can. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1013942: maildir-utils: please package new upstream version 1.8

[Norbert Preining]

Hi

> Note, that the Debian Emacs team would adopt and update the package, if
> you don't like to be bothered with it anymore.

Feel free to do whatever you want with it.

BR

Norbert

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Axel Beckert]

user lintian-ma...@debian.org
usertag 1013946 + false-positive unknown-locale-code
tag 1013946 + confirmed
retitle 1013946 lintian: [FP] Wrongly reports unknown-locale-code "ber" (POSIX 
locales: ISO 639-2 vs 639-3 vs 639-5)
kthxbye

Hi Fabio,

Fabio Fantoni wrote:
> Package: lintian
> Version: 2.115.1
> Severity: normal
> 
> Hi, on a lintian output I saw:
> 
> W: xapps-common: unknown-locale-code ber [usr/share/locale/ber/]
> 
> but ber locale exists:
> https://www.loc.gov/standards/iso639-2/php/langcodes_name.php?code_ID=54

thanks for your bug report. This brought up a quite diffcult question:
Which parts of ISO 639 are meant to be used for POSIX locales.


Summary / TL;DR
---

It is currently not clear if this is really false positive or a true
positive. It basically boils down to the question which parts of ISO
639 should be used for POSIX locales: ISO 639-2, 639-3, 639-5 or a
combination of these? Lintian currently uses only ISO 639-3 — which
includes probably all of ISO 639-1 and most but not all of ISO 639-2.

And ISO 639-3 doesn't currently doesn't include "ber" (which is a
group of languages and not a language) but includes e.g. "jbe"
("Judeo-Berber"). ISO 639-2 and 639-5 though do include "ber".

For locales, POSIX refers to ISO/IEC 15897. And that one refers to ISO
639, but not explicitly to any part of it.

I came to the conclusion to expand this lintian check from only using
ISO 639-3 to also ISO 639-2 (which both also include ISO 639-1) and
hence make "ber" a locale accepted by lintian.

For a more detailed reasoning and the used sources, see below.


Long Story and Reasoning


It seems as if Lintian only takes ISO 639-3 into account, not ISO
639-2. And https://iso639-3.sil.org/about says

  At the core of ISO 639-3 are the individual languages already
  accounted for in ISO 639-2. The large number of living languages in
  the initial inventory of ISO 639-3 beyond those already included in
  ISO 639-2 was derived primarily from […]

For me, it's currently not clear if that means that all languages in
ISO 639-2 are literally included in ISO 639-3 (i.e. ISO 639-3 is a
superset of ISO 639-2) or if ISO 639-3 is just an addition to
ISO 639-2 (i.e. the languages in ISO 639-2 and ISO 639-3 are
disjunct).

In the former case, this would be a bug in the package iso-codes (or
isoquery, depending on the data model; see below), in the latter case
this would be a bug in Lintian as it would need to take ISO 639-2 into
account here, too.

And "ber" is in ISO 639-2 since 2009 according to
https://www.loc.gov/standards/iso639-2/php/code_changes_bycode.php?code_ID=54

And "isoquery" also finds it in ISO 639-2, but not ISO 639-3:

  → isoquery -i 639-3 ber
  isoquery: The code "ber" is not defined in ISO 639-3.
  → isoquery -i 639-2 ber
  ber Berber languages
  →

And indeed, the word "ber" can only be found in the ISO 639-3 and ISO
639-5 datasets:

  → fgrep -wA1 ber /usr/share/iso-codes/json/iso_639-?.json
  /usr/share/iso-codes/json/iso_639-2.json:  "alpha_3": "ber",
  /usr/share/iso-codes/json/iso_639-2.json-  "name": "Berber languages"
  --
  /usr/share/iso-codes/json/iso_639-5.json:  "alpha_3": "ber",
  /usr/share/iso-codes/json/iso_639-5.json-  "name": "Berber languages"

ISO 639-5 is also said to be a "supplement" according to
https://www.loc.gov/standards/iso639-5/

Then again there are three letter codes for languages like "deu" (and
its alias "ger") for German which are in both, ISO 639-2 as well as
ISO 639-3, but not ISO 639-5. For me, this only adds to the confusion.

Relevant file is lib/Lintian/Check/Files/Locales.pm at lines 69 to 90
as of today:

 69 has ISO639_3_by_alpha3 => (
 70 is => 'rw',
 71 lazy => 1,
 72 default => sub {
 73 my ($self) = @_;
 74 
 75 local $ENV{LC_ALL} = 'C';
 76 
 77 my $bytes = 
path('/usr/share/iso-codes/json/iso_639-3.json')->slurp;
 78 my $json = decode_json($bytes);
 79 
 80 my %iso639_3;
 81 for my $entry (@{$json->{'639-3'}}) {
 82 
 83 my $alpha_3 = $entry->{alpha_3};
 84 
 85 $iso639_3{$alpha_3} = $entry;
 86 }
 87 
 88 return \%iso639_3;
 89 }
 90 );

Lines 100 to 122 though give a hint that the author of this code
thinks that ISO 639-3 is just a union of ISO 639-1 and ISO 639-2:

100 my %CODES;
101 for my $entry (values %{$self->ISO639_3_by_alpha3}) {
   
102 
103 my $type = $entry->{type};
104 
105 # 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692548#10
106 next
107   if $type eq $RESERVED || $type eq $SPECIAL;
108 
109 # also have two letters, ISO 639-1
 ^
110  

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Fabio Fantoni]

Il 27/06/2022 23:53, Russ Allbery ha scritto:

Russ Allbery  writes:

Fabio Fantoni  writes:

Hi, on a lintian output I saw:
W: xapps-common: unknown-locale-code ber [usr/share/locale/ber/]
but ber locale exists:
https://www.loc.gov/standards/iso639-2/php/langcodes_name.php?code_ID=54

Thanks for the report!  Lintian gets the canonical list of locales from
the iso-codes package, and if I'm reading the last modification times from
its Salsa repository correctly, it may have been a bit since it was
updated.
I'm reassigning this bug to iso-codes for further investigation and cc'ing
the maintainer.

Hm, sorry about the self-follow-up.  I looked at this a bit further, and
now I think this may be intentional.  I believe ber refers to a language
*group* rather than a single language, and thus is an ISO 639-5 code but
not an ISO 639-3 code.

Lintian specifically uses ISO 639-3 to get a list of known locale
identifiers.

Do you know if an ISO 639-5 locale works properly on a Debian system, in
the sense that it can be used for translations and the other normal locale
things?  ber seems to be the code for the Berber *family* of languages,
which has multiple members that have their own ISO 639-3 codes.  I'm not
sure that locale information for the entire family, as opposed to
individual members of that family, makes sense.

I don't know if "ber" locale works but in xapp and other cinnamon 
components there is a partial translation related, this is why I 
encountered this warning on lintian, the translation is done with 
launchpad: https://translations.launchpad.net/linuxmint/latest/+lang/ber


ber is supported in launchpad, transifex 
(https://www.transifex.com/explore/languages/) that I use, I don't 
search on others.


from another search now I found this: 
https://www.debian.org/international/l10n/po/ber.en.html and seems ber 
is used only in few packages and all with partial translation so I 
suppose thatthere are no users using it, even if it works there are too 
few translated strings




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013955: libapache2-mod-auth-kerb: memory leak plus incorrect handling of keytabs

[Sorin Manolache]

Package: libapache2-mod-auth-kerb
Version: 5.4-2.5
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: sor...@gmail.com

Dear Maintainer,

I think there are two problems with the code:

In authenticate_user_gss the keytab path (configured by the Krb5Keytab conf 
directive) is in the process environment using a putenv call.

First, there is an obvious memory leak because the string put into the 
environment is malloc'ed. It is never freed. Moreover, this malloc and putenv 
happens at every request.

Second, not only that putenv is not thread-safe but it may lead to functional 
bugs. Let us assume that we have two different directories, each with its own 
Krb5Keytab conf directive, each pointing to a different keytab file. When two 
requests are handled by two threads in parallel, each will putenv 
KRB5_KTNAME=/path/to/keytab. It is possible that the calls to the GSSAPI/Krb5 
functions of one thread use the value of the environment variable KRB5_KTNAME 
set by the other thread.

I've written a patch to correct these two problems. The patch works in my setup 
but I have to tested it exhaustively. Please have a look.

Thank you and best regards,
Sorin

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libapache2-mod-auth-kerb depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.54-1
ii  krb5-config 2.6+nmu1
ii  libc6   2.33-7
ii  libcom-err2 1.46.5-2
ii  libgssapi-krb5-21.19.2-2+b2
ii  libkrb5-3   1.19.2-2+b2

libapache2-mod-auth-kerb recommends no packages.

libapache2-mod-auth-kerb suggests no packages.

-- no debconf information
Index: mod_auth_kerb-5.4/src/mod_auth_kerb.c
===
--- mod_auth_kerb-5.4.orig/src/mod_auth_kerb.c
+++ mod_auth_kerb-5.4/src/mod_auth_kerb.c
@@ -228,7 +228,8 @@ static const char *
 cmd_delegationlock(cmd_parms *cmd, void *dconf, const char *a1);
 
 static int
-obtain_server_credentials(request_rec *r, const char *service_name);
+obtain_server_credentials(request_rec *r, const char *service_name,
+ const char *kt_name);
 
 #ifdef STANDARD20_MODULE_STUFF
 #define command(name, func, var, type, usage)   \
@@ -1245,14 +1246,12 @@ end:
 }
 
 static int
-get_gss_creds(request_rec *r,
-  kerb_auth_config *conf,
- gss_cred_id_t *server_creds)
+get_server_name(request_rec *r,
+   kerb_auth_config *conf,
+   gss_name_t *server_name)
 {
gss_buffer_desc token = GSS_C_EMPTY_BUFFER;
-   OM_uint32 major_status, minor_status, minor_status2;
-   gss_name_t server_name = GSS_C_NO_NAME;
-   gss_cred_usage_t usage = GSS_C_ACCEPT;
+   OM_uint32 major_status, minor_status;
char buf[1024];
int have_server_princ;
 
@@ -1260,8 +1259,8 @@ get_gss_creds(request_rec *r,
have_server_princ = conf->krb_service_name && 
strchr(conf->krb_service_name, '/') != NULL;
if (have_server_princ)
   strncpy(buf, conf->krb_service_name, sizeof(buf));
-   else if (conf->krb_service_name && strcmp(conf->krb_service_name,"Any") == 
0) {  
-  *server_creds = GSS_C_NO_CREDENTIAL;
+   else if (conf->krb_service_name && strcmp(conf->krb_service_name,"Any") == 
0) {
+  *server_name = GSS_C_NO_NAME;
   return 0;
}
else
@@ -1274,7 +1273,7 @@ get_gss_creds(request_rec *r,
 
major_status = gss_import_name(_status, ,
  (have_server_princ) ? (gss_OID) 
GSS_KRB5_NT_PRINCIPAL_NAME : (gss_OID) GSS_C_NT_HOSTBASED_SERVICE,
- _name);
+ server_name);
memset(, 0, sizeof(token));
if (GSS_ERROR(major_status)) {
   log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
@@ -1283,7 +1282,7 @@ get_gss_creds(request_rec *r,
   return HTTP_INTERNAL_SERVER_ERROR;
}
 
-   major_status = gss_display_name(_status, server_name, , NULL);
+   major_status = gss_display_name(_status, *server_name, , NULL);
if (GSS_ERROR(major_status)) {
   /* Perhaps we could just ignore this error but it's safer to give up now,
  I think */
@@ -1295,15 +1294,46 @@ get_gss_creds(request_rec *r,
 
log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "Acquiring creds for %s",
  token.value);
+   gss_release_buffer(_status, );
+
+   return 0;
+}
+
+static int
+get_gss_creds(request_rec *r,
+  kerb_auth_config *conf,
+ gss_cred_id_t *server_creds)
+{
+   OM_uint32 major_status, minor_status, minor_status2;
+   

Bug#1013954: transition: opencv

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition the new opencv version, containing a fix for
building with ffmpeg 5.0 (#1004718). The autogenerated ben tracker looks
fine and I've successfully rebuild all reverse dependencies listed on it
except:

already ftbfs due to other changes:

digikam #1004769
openimageio #1012176
os-autoinst #1013533
pytorch #1004782

newly filled:

sight #1013903

Cheers Jochen

Bug#1013937: Fails to upload to cloud with "SSL handshake failed"

[Boyuan Yang]

Hi,

在 2022-06-27星期一的 22:24 +0200，martin f krafft写道：
> Regarding the following, written by "Boyuan Yang" on 2022-06-27 at 15:54
> Uhr -0400:
> > I cannot reproduce this issue on my Debian Sid workstation. Can you
> > provide a Debian Sid virtual machine image that is able to reliably
> > reproduce the issue, as well as detailed instruction on how to trigger
> > the error?
> No, I cannot produce such an image easily. I can reliably reproduce the
> issue, and so I am happy to work with you, including providing strace
> etc.. I already did check strace, and I found nothing useful. Check for
> yourself in the attached?

Looking at your original report, I found that you were using some old
version of Qt5 libraries and OpenSSL libraries that are already dropped in
Both Debian Sid and Debian Testing. Currently you are supposed to be using
Qt5 5.15.4 and openssl 3.0.x, not Qt5 5.15.2 and OpenSSL 1.1.1. Could you
check your system again and make sure that these libraries are up-to-date as
provided by the repository? In other words, please perform "sudo apt update"
and "sudo apt full-upgrade" and install all reasonable package updates.

Thanks,
Boyuan Yang


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

Bug#1013953: amispammer: noisily fails for IPv6 IPs

[Adam Borowski]

Package: amispammer
Version: 3.3-2.1
Severity: normal
Tags: ipv6

Hi!
When trying ｢amispammer -i｣ on an IPv6 address, it spams me with multiple
screenfuls of:

Thread 44 terminated abnormally: empty label in "zombie.dnsbl.sorbs.net" at 
/usr/share/perl5/Net/DNS/Question.pm line 79 thread 44.

Queries about IPv4 servers work fine.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-rc4-00017-g7468b46b5d67 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages amispammer depends on:
ii  libemail-sender-perl  2.500-1
ii  libnet-address-ip-local-perl  0.1.2-4
ii  libnet-dns-perl   1.34-1
ii  libwww-perl   6.67-1
ii  perl  5.34.0-4

amispammer recommends no packages.

amispammer suggests no packages.

-- no debconf information

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Russ Allbery]

Russ Allbery  writes:
> Fabio Fantoni  writes:

>> Hi, on a lintian output I saw:

>> W: xapps-common: unknown-locale-code ber [usr/share/locale/ber/]

>> but ber locale exists:
>> https://www.loc.gov/standards/iso639-2/php/langcodes_name.php?code_ID=54

> Thanks for the report!  Lintian gets the canonical list of locales from
> the iso-codes package, and if I'm reading the last modification times from
> its Salsa repository correctly, it may have been a bit since it was
> updated.

> I'm reassigning this bug to iso-codes for further investigation and cc'ing
> the maintainer.

Hm, sorry about the self-follow-up.  I looked at this a bit further, and
now I think this may be intentional.  I believe ber refers to a language
*group* rather than a single language, and thus is an ISO 639-5 code but
not an ISO 639-3 code.

Lintian specifically uses ISO 639-3 to get a list of known locale
identifiers.

Do you know if an ISO 639-5 locale works properly on a Debian system, in
the sense that it can be used for translations and the other normal locale
things?  ber seems to be the code for the Berber *family* of languages,
which has multiple members that have their own ISO 639-3 codes.  I'm not
sure that locale information for the entire family, as opposed to
individual members of that family, makes sense.

-- 
Russ Allbery (r...@debian.org)  

Bug#994944: gtk4 broadwayd

[Gary Kramlich]

We (Pidgin) use broadway for our unit tests that require gtk to be
initialized/running.

Thanks,

--
Gary Kramlich 

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Russ Allbery]

Control: reassign -1 iso-codes
Control: retitle -1 ber locale missing from iso_639-3.json
Control: affects -1 lintian

Fabio Fantoni  writes:

> Hi, on a lintian output I saw:

> W: xapps-common: unknown-locale-code ber [usr/share/locale/ber/]

> but ber locale exists:
> https://www.loc.gov/standards/iso639-2/php/langcodes_name.php?code_ID=54

Thanks for the report!  Lintian gets the canonical list of locales from
the iso-codes package, and if I'm reading the last modification times from
its Salsa repository correctly, it may have been a bit since it was
updated.

I'm reassigning this bug to iso-codes for further investigation and cc'ing
the maintainer.

-- 
Russ Allbery (r...@debian.org)  

Bug#1013952: qemu: issue passing prop_array parameter

[mc36]

Package: qemu
Version: 1:7.0+dfsg-1
Severity: normal

Dear Maintainer,

i'm trying to bring up a dev env for route offloading. linux switchdev offers
an emulated
switch called rocker. qemu also supports it, but i have issues passing the
array paraemter
for the front panel ports:

mc36@noti:~$ qemu-system-x86_64 -enable-kvm -m 1g -cpu host -cdrom
Downloads/debian-11.3.0-amd64-netinst.iso -netdev
socket,id=dev0,udp=10.10.10.227:30042,localaddr=:30042 -device rocker,len-
ports=4,name=sw,len-ports=2,ports[0]=dev0
qemu-system-x86_64: -device rocker,len-ports=4,name=sw,len-
ports=2,ports[0]=dev0: Property 'rocker.ports[0]' not found
mc36@noti:~$

thanks,
csaba


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
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)

-- no debconf information

Bug#1013951: linux-image-5.18.0-2-amd64: please enable CONFIG_ROCKER properly

[mc36]

Package: src:linux
Version: 5.18.5-1
Severity: wishlist

Dear Maintainer,

trying to bring up a dev env to offload routing. one solution is the emulated
switchdev called rocker.
during my experimentation i noticed that the named driver is partially
enabled... so my question is,
could you please compile the future kernels with CONFIG_ROCKER=m?

thanks,
csaba

mc36@noti:~$ cat /boot/config-5.18.0-2-amd64 | grep ROCKER
CONFIG_NET_VENDOR_ROCKER=y
# CONFIG_ROCKER is not set
mc36@noti:~$


-- Package-specific info:
** Version:
Linux version 5.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.50.20220615) #1 SMP 
PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.18.0-2-amd64 
root=UUID=9e3f4c2b-0bb2-4ff1-b204-ff83d95d443e ro panic=10 
snd_hda_intel.dmic_detect=0

** Not tainted

** Kernel log:
[593376.643226] CIFS: Status code returned 0xc0d0 
STATUS_REQUEST_NOT_ACCEPTED
[597024.532429] CIFS: Status code returned 0xc0d0 
STATUS_REQUEST_NOT_ACCEPTED
[597024.532459] cifs_setup_session: 2 callbacks suppressed
[597024.532465] CIFS: VFS: \\nas.mchome.nop.hu Send error in SessSetup = -5
[597024.552683] CIFS: Status code returned 0xc0d0 
STATUS_REQUEST_NOT_ACCEPTED
[597024.552703] CIFS: VFS: \\nas.mchome.nop.hu Send error in SessSetup = -5
[597024.571723] CIFS: Status code returned 0xc0d0 
STATUS_REQUEST_NOT_ACCEPTED
[597024.571749] CIFS: VFS: \\nas.mchome.nop.hu Send error in SessSetup = -5
[597024.591757] CIFS: Status code returned 0xc0d0 
STATUS_REQUEST_NOT_ACCEPTED
[597024.591776] CIFS: VFS: \\nas.mchome.nop.hu Send error in SessSetup = -5
[597024.611400] CIFS: Status code returned 0xc0d0 
STATUS_REQUEST_NOT_ACCEPTED
[597024.611426] CIFS: VFS: \\nas.mchome.nop.hu Send error in SessSetup = -5
[599200.912059] atkbd serio0: Unknown key pressed (translated set 2, code 0x6d 
on isa0060/serio0).
[599200.912076] atkbd serio0: Use 'setkeycodes 6d ' to make it known.
[599200.974484] atkbd serio0: Unknown key released (translated set 2, code 0x6d 
on isa0060/serio0).
[599200.974498] atkbd serio0: Use 'setkeycodes 6d ' to make it known.
[612095.552353] Process accounting resumed
[612096.660322] Process accounting resumed
[649936.230490] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 
on isa0060/serio0).
[649936.230498] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649936.257692] atkbd serio0: Unknown key released (translated set 2, code 0x65 
on isa0060/serio0).
[649936.257700] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649936.384571] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 
on isa0060/serio0).
[649936.384595] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649936.419813] atkbd serio0: Unknown key released (translated set 2, code 0x65 
on isa0060/serio0).
[649936.419820] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649936.557799] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 
on isa0060/serio0).
[649936.557807] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649936.634336] atkbd serio0: Unknown key released (translated set 2, code 0x65 
on isa0060/serio0).
[649936.634343] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649936.866973] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 
on isa0060/serio0).
[649936.866981] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649937.000889] atkbd serio0: Unknown key released (translated set 2, code 0x65 
on isa0060/serio0).
[649937.000896] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649990.974854] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 
on isa0060/serio0).
[649990.974873] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649991.004051] atkbd serio0: Unknown key released (translated set 2, code 0x65 
on isa0060/serio0).
[649991.004071] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649991.093685] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 
on isa0060/serio0).
[649991.093704] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649991.137000] atkbd serio0: Unknown key released (translated set 2, code 0x65 
on isa0060/serio0).
[649991.137020] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649991.218560] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 
on isa0060/serio0).
[649991.218576] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649991.296099] atkbd serio0: Unknown key released (translated set 2, code 0x65 
on isa0060/serio0).
[649991.296114] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649991.383719] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 
on isa0060/serio0).
[649991.383734] atkbd serio0: Use 'setkeycodes 65 ' to make it known.
[649991.426012] atkbd serio0: Unknown key released (translated set 2, code 0x65 
on isa0060/serio0).
[649991.426027] atkbd serio0: Use 'setkeycodes 65 ' to make it known.

Bug#1013950: libvte-2.91-0: Add gtk4 vte library versions

[Willem van den Akker]

Package: libvte-2.91-0
Version: 0.68.0-1+b1
Severity: wishlist
X-Debbugs-Cc: wvdak...@wilsoft.nl

Dear Maintainer,

I am migrating one of my packages to gtk4. For this application libvte-2.91-dev
is needed. However there is no gtk4 version in the repository.
I build the library (just enable the gtk4 option in the meson-option file).
However it would be nice is this is included for bookworm so I can upload the
gtk4 version

TIA
WIllem


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 libvte-2.91-0 depends on:
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libfribidi0  1.0.8-2.1
ii  libgcc-s112.1.0-2
ii  libglib2.0-0 2.72.2-2
ii  libgnutls30  3.7.6-2
ii  libgtk-3-0   3.24.34-1
ii  libicu71 71.1-3
ii  libpango-1.0-0   1.50.7+ds-1
ii  libpangocairo-1.0-0  1.50.7+ds-1
ii  libpcre2-8-0 10.40-1
ii  libstdc++6   12.1.0-2
ii  libsystemd0  251.2-6
ii  libvte-2.91-common   0.68.0-1+b1
ii  zlib1g   1:1.2.11.dfsg-4

libvte-2.91-0 recommends no packages.

libvte-2.91-0 suggests no packages.

-- no debconf information

Bug#1013949: ITP: coq-hott -- Coq library for homotopy type theory

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: coq-hott
  Version : 8.15
  Upstream Author : Andrej Bauer, Jason Gross, Peter LeFanu Lumsdaine, Michael
Shulman, Bas Pitters
* URL : https://github.com/HoTT/HoTT
* License : BSD-2-clause
  Programming Lang: Coq
  Description : Coq library for homotopy type theory
 This library is a formalization of homotopy type
 theory for Coq, where propositional equality is
 interpreted as homotopy and type isomorphism as
 homotopy equivalence.
 .
 Coq is a proof assistant for higher-order logic.

I plan to maintain it within the Debian OCaml Maintainers team, along with the
rest of the Coq-related packages.

Cheers,

J.Puydt

Bug#1013948: zfs-fuse: Homepage in Metadata points to porn site

[Julia Mono Brunenberg]

Package: zfs-fuse
Version: 0.7.0-21
Severity: minor

Dear Maintainer,

at least the following package versions list the following homepage in the 
package
metadata (possibly somehwhere else, too?):

Version: 0.7.0-22+b1
Homepage: http://zfs-fuse.net

Version: 0.7.0-21
Homepage: http://zfs-fuse.net

The domain currently points to a porn site. I don't know if this is a domain 
hijack,
 or a hacked homepage ... but maybe someone can check with upstream?

Best wishes,
 Julia


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (95, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zfs-fuse depends on:
ii  fuse   2.9.9-5
ii  libaio10.3.112-9
ii  libc6  2.31-13+deb11u3
ii  libfuse2   2.9.9-5
ii  libssl1.1  1.1.1n-0+deb11u3
ii  lsb-base   11.1.0
ii  zlib1g 1:1.2.11.dfsg-2+deb11u1

zfs-fuse recommends no packages.

Versions of packages zfs-fuse suggests:
pn  kpartx 
pn  nfs-kernel-server  

-- no debconf information

Bug#1013938: balboa: regression + flaky autopkgtest: regularly times out on amd64, i386 and s390x

[Sascha Steinbiss]

Hi Paul,

thanks for letting me know!


I noticed that there were several runs that took 2:47 (our timeout
time), while successful runs more in the order of minutes. This
started to happen recently.
This is likely related to #1012629 [1] (also see #1012804 [2]), a hang 
issue that was in fact caused by rocksdb and was eventually fixed in 
rocksdb 7.2.2-5. Could the version that is tested in the autopkgtest and 
its dependencies be still affected by that?


[...]
On top of that, when a test just hangs that's not good for our 
infrastructure. I'll put balboa on our reject_list for amd64, i386, and 
s390x.


I see. I wonder what the procedure to get off that list is?
With an updated autopkgtest chroot, the latest librocksdb and a rebuilt 
version of balboa the autopkgtest consistently succeeds for me; see 
attached log.


Cheers
Sascha


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012629
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012804Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  apt-utils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 446 kB of archives.
After this operation, 1,196 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian sid/main amd64 apt-utils amd64 2.5.0 [446 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 446 kB in 0s (1,135 kB/s)
Selecting previously unselected package apt-utils.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 12914 files and directories currently installed.)
Preparing to unpack .../apt-utils_2.5.0_amd64.deb ...
Unpacking apt-utils (2.5.0) ...
Setting up apt-utils (2.5.0) ...
Get:1 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  InRelease
Ign:1 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  InRelease
Get:2 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Release [816 B]
Get:2 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Release [816 B]
Get:3 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Release.gpg
Ign:3 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Release.gpg
Get:4 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Packages [4,116 B]
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  balboa balboa-backend-common balboa-backend-rocksdb curl libbrotli1 libcurl4
  libgflags2.2 libnghttp2-14 libpsl5 librocksdb7.2 librtmp1 libsnappy1v5
  libssh2-1
Recommended packages:
  ca-certificates publicsuffix
The following NEW packages will be installed:
  balboa balboa-backend-common balboa-backend-rocksdb curl libbrotli1 libcurl4
  libgflags2.2 libnghttp2-14 libpsl5 librocksdb7.2 librtmp1 libsnappy1v5
  libssh2-1
0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 4,323 kB/7,945 kB of archives.
After this operation, 25.9 MB of additional disk space will be used.
Get:1 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  balboa 2.0.0+ds-4 [3,236 kB]
Get:2 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  balboa-backend-common 2.0.0+ds-4 [354 kB]
Get:3 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  balboa-backend-rocksdb 2.0.0+ds-4 [31.6 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 libgflags2.2 amd64 2.2.2-2 [83.5 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 libsnappy1v5 amd64 1.1.9-2 [27.4 kB]
Get:6 http://deb.debian.org/debian sid/main amd64 librocksdb7.2 amd64 7.2.2-5 [2,921 kB]
Get:7 http://deb.debian.org/debian sid/main amd64 libbrotli1 amd64 1.0.9-2+b3 [276 kB]
Get:8 http://deb.debian.org/debian sid/main amd64 libnghttp2-14 amd64 1.47.0-1+b1 [76.3 kB]
Get:9 http://deb.debian.org/debian sid/main amd64 libpsl5 amd64 0.21.0-1.2 [57.3 kB]
Get:10 http://deb.debian.org/debian sid/main amd64 librtmp1 amd64 2.4+20151223.gitfa8646d.1-2+b2 [60.8 kB]
Get:11 http://deb.debian.org/debian sid/main amd64 libssh2-1 amd64 1.10.0-3+b1 [179 kB]
Get:12 http://deb.debian.org/debian sid/main amd64 libcurl4 amd64 7.83.1-2 [358 kB]
Get:13 http://deb.debian.org/debian sid/main amd64 curl amd64 7.83.1-2 [285 kB]
Fetched 4,323 kB in 2s 

Bug#1013947: RFS: python-jschema-to-python/1.0-1 [ITP] -- generate Python classes from a JSON schema

[Guilherme de Paula Xavier Segundo]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-jschema-to-python":

 * Package name: python-jschema-to-python
   Version : 1.2.3-1
   Upstream Author : https://github.com/microsoft/jschema-to-python/issues
 * URL : https://github.com/microsoft/jschema-to-python
 * License : Expat
 * Vcs : 
https://salsa.debian.org/python-team/packages/python-jschema-to-python
   Section : python

The source builds the following binary packages:

  python3-jschema-to-python - generate Python classes from a JSON schema

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/python-jschema-to-python/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-jschema-to-python/python-jschema-to-python_1.2.3-1.dsc

  git clone https://salsa.debian.org/gpxlnx/python-jschema-to-python

Changes for the initial release:

 python-jschema-to-python (1.2.3-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1013941)

Regards,
--
  Guilherme de Paula Xavier Segundo

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Fabio Fantoni]

Package: lintian
Version: 2.115.1
Severity: normal

Hi, on a lintian output I saw:

W: xapps-common: unknown-locale-code ber [usr/share/locale/ber/]

but ber locale exists: 
https://www.loc.gov/standards/iso639-2/php/langcodes_name.php?code_ID=54

Bug#983405: concurrency

[Marc Haber]

On Mon, Jun 27, 2022 at 11:20:45AM -0400, Matt Barry wrote:
> The simplest way I can think of to solve this is:
> 
> (start)
>   mkdir /tmp/adduser.lock
>   sleep and loop until mkdir succeeds
> 
> (end)
>   remove /tmp/adduser.lock
> 
> which should be atomic assuming a local /tmp.
> 
> One could possibly add a /tmp/adduser.lock/adduser.pid and check for a
> dead lock.. I hesitate to overcomplicate this one (and certainly don't
> want a dependency for it).

/run/adduser please, and probably a simple flock()? lock files in a
shell script are a minefield for code running as root, I hope it is
easier in perl.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1013937: Fails to upload to cloud with "SSL handshake failed"

[Boyuan Yang]

Control: tags -1 +unreproducible

Hi,


在 2022-06-27星期一的 20:40 +0200，martin f krafft写道：
> Package: flameshot
> Version: 12.0.0-1
> Severity: normal
> Trying to upload a shot to imgur ("the Cloud") results in an error "SSL
> handshake failed". Connections to api.imgur.net with e.g. gnutls-cli work

I cannot reproduce this issue on my Debian Sid workstation. Can you provide
a Debian Sid virtual machine image that is able to reliably reproduce the
issue, as well as detailed instruction on how to trigger the error?

Thanks,
Boyuan Yang


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

Bug#1013944: bullseye-pu: package cyrus-imapd/3.2.6-2+deb11u2

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Bookworm will provide cyrus-imapd 3.6.x. To permit a safe upgrade from
3.2.6, updtream provided a patch for versions 3.4 and 3.2. It ensure
that mailboxes have an unique id.

[ Impact ]
Risk during Bullseye to Bookworm upgrade.

[ Tests ]
Test passed
(https://salsa.debian.org/debian/cyrus-imapd/-/pipelines/393112)

[ Risks ]
This patch is the difference between 3.2.9 and 3.2.10, applied without
any change.

[ 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 (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Cyrus tools now check if mailbox id is really unique.

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index ca4d2a92..209a040f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+cyrus-imapd (3.2.6-2+deb11u2) bullseye; urgency=medium
+
+  * Ensure that ctl_cyrusdb -r and reconstruct now ensure the "uniqueid" field
+is present in and synchronised between mailboxes.db and cyrus.header.
+Required before 3.6.x upgrade
+
+ -- Yadd   Mon, 27 Jun 2022 21:41:17 +0200
+
 cyrus-imapd (3.2.6-2+deb11u1) bullseye; urgency=high
 
   * Replace string hashing algorithm (Closes: #993433, CVE-2021-33582)
diff --git a/debian/patches/prepare-3.6-upgrade.patch 
b/debian/patches/prepare-3.6-upgrade.patch
new file mode 100644
index ..a7b8aea0
--- /dev/null
+++ b/debian/patches/prepare-3.6-upgrade.patch
@@ -0,0 +1,244 @@
+Description: reconstruct mailboxes to prepare
+ ctl_cyrusdb -r and reconstruct now ensure the "uniqueid" field is present
+ in and synchronised between mailboxes.db and cyrus.header.
+Author: ellie timoney 
+Origin: upstream, https://github.com/cyrusimap/cyrus-imapd/commit/360e5d153
+ https://github.com/cyrusimap/cyrus-imapd/commit/93b01dd83
+ https://github.com/cyrusimap/cyrus-imapd/commit/0f59f9f36
+ https://github.com/cyrusimap/cyrus-imapd/commit/0ee7d128a
+ https://github.com/cyrusimap/cyrus-imapd/commit/2918ce8f0
+ https://github.com/cyrusimap/cyrus-imapd/commit/a330b471f
+ https://github.com/cyrusimap/cyrus-imapd/commit/df58b26cb
+Bug: https://github.com/cyrusimap/cyrus-imapd/pull/4100
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-06-27
+
+--- a/imap/ctl_cyrusdb.c
 b/imap/ctl_cyrusdb.c
+@@ -129,7 +129,7 @@
+ static int fixmbox(const mbentry_t *mbentry,
+void *rock __attribute__((unused)))
+ {
+-int r;
++int r, r2;
+ 
+ /* if MBTYPE_RESERVED, unset it & call mboxlist_delete */
+ if (mbentry->mbtype & MBTYPE_RESERVE) {
+@@ -172,12 +172,66 @@
+mbentry->name, cyrusdb_strerror(r));
+ }
+ 
++/* make sure every local mbentry has a uniqueid!  */
++if (!mbentry->uniqueid && mbentry_is_local_mailbox(mbentry)) {
++struct mailbox *mailbox = NULL;
++struct mboxlock *namespacelock = NULL;
++mbentry_t *copy = NULL;
++
++r = mailbox_open_iwl(mbentry->name, );
++if (r) {
++/* XXX what does it mean if there's an mbentry, but the mailbox
++ * XXX was not openable?
++ */
++syslog(LOG_DEBUG, "%s: mailbox_open_iwl %s returned %s",
++  __func__, mbentry->name, error_message(r));
++goto skip_uniqueid;
++}
++
++if (!mailbox->uniqueid) {
++/* yikes, no uniqueid in header either! */
++mailbox_make_uniqueid(mailbox);
++syslog(LOG_INFO, "mailbox %s header had no uniqueid, creating %s",
++ mbentry->name, mailbox->uniqueid);
++}
++
++copy = mboxlist_entry_copy(mbentry);
++copy->uniqueid = xstrdup(mailbox->uniqueid);
++syslog(LOG_INFO, "mbentry %s had no uniqueid, setting %s from header",
++ copy->name, copy->uniqueid);
++
++namespacelock = mboxname_usernamespacelock(copy->name);
++r = mboxlist_update(copy, /*localonly*/1);
++mboxname_release();
++if (r) {
++syslog(LOG_ERR, "failed to update mboxlist for %s: %s",
++mbentry->name, error_message(r));
++r2 = mailbox_abort(mailbox);
++if (r2) {
++syslog(LOG_ERR, "DBERROR: error aborting transaction: %s",
++cyrusdb_strerror(r2));
++}
++}
++else {
++r2 = mailbox_commit(mailbox);
++if (r2) {
++syslog(LOG_ERR, "DBERROR: error committing transaction: %s",
++cyrusdb_strerror(r2));
++}
++}
++mailbox_close();
++mboxlist_entry_free();
++
++skip_uniqueid:
++;   /* hush "label at end of compound statement" warning */
++}
++
+ return 0;
+ }
+ 
+ static void 

Bug#1013943: auto-multiple-choice: Autopkg Test fails

[Hilmar Preusse]

Source: auto-multiple-choice
Version: 1.5.2-2
Severity: normal

Dear Maintainer,

yesterday I uploaded a new snapshot of LaTeX packages. Since then the test
suite of your package fails to run [1]. Unfortunately the error message
does not give an idea, what the root cause could be.

Please be so kind to have a look.

Thanks,
  Hilmar

[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/a/auto-multiple-choice/23108471/log.gz

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

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


signature.asc
Description: PGP signature

Bug#1013942: maildir-utils: please package new upstream version 1.8

[Martin]

Package: maildir-utils
Severity: wishlist

Version 1.8 of mu has been released ereyesterday:

https://github.com/djcb/mu/blob/master/NEWS.org#18-released-on-june-25-2022

It contains relevant improvements over 1.6.x.

Note, that the Debian Emacs team would adopt and update the package, if
you don't like to be bothered with it anymore.

Bug#1013941: ITP: python-jschema-to-python -- generate Python classes from a JSON schema

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com

* Package name: python-jschema-to-python
  Version : 1.2.3
  Upstream Author : Microsoft Corporation
* URL : https://github.com/microsoft/jschema-to-python
* License : Expat
  Programming Lang: Python
  Description : generate Python classes from a JSON schema

 This package contains a module that generate Python classes from a JSON
 schema.
 .
 This package installs the library for Python 3.

 Reason for packaging:
 This package is one of the dependencies for cfn-lint
 (https://github.com/aws-cloudformation/cfn-lint)

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Mon 27 Jun 2022 at 19:31:11 +0100, Brian Potkin wrote:

>   >/var/lod/error_log

/var/log/error_log, of course.

-- 
Brian.

Bug#1013940: nfft breaks pynfft autopkgtest on i386: Segmentation fault

[Paul Gevers]

Source: nfft, pynfft
Control: found -1 nfft/3.3.2-2.1
Control: found -1 pynfft/1.3.2-5
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of nfft the autopkgtest of pynfft fails in testing 
when that autopkgtest is run with the binary packages of nfft from 
unstable. It passes when run with only packages from testing. In tabular 
form:


   passfail
nfft   from testing3.3.2-2.1
pynfft from testing1.3.2-5
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of nfft to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=nfft

https://ci.debian.net/data/autopkgtest/testing/i386/p/pynfft/23100486/log.gz

=== python3.9 ===
Segmentation fault
autopkgtest [15:22:19]: test python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013939: python-xarray: autopkgtest regression: Left and right DataArray objects are not close

[Paul Gevers]

Source: python-xarray
Version: 2022.06.0~rc1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of python-xarray the autopkgtest of python-xarray 
fails in testing when that autopkgtest is run with the binary packages 
of python-xarray from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
python-xarray  from testing2022.06.0~rc1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-xarray

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/23134419/log.gz

=== FAILURES 
===
___ test_weighted_operations_nonequal_coords 
___


def test_weighted_operations_nonequal_coords():
# There are no weights for a == 4, so that data point is ignored.
weights = DataArray(np.random.randn(4), dims=("a",), 
coords=dict(a=[0, 1, 2, 3]))
data = DataArray(np.random.randn(4), dims=("a",), 
coords=dict(a=[1, 2, 3, 4]))

check_weighted_operations(data, weights, dim="a", skipna=None)
q = 0.5
result = data.weighted(weights).quantile(q, dim="a")
# Expected value computed using code from 
https://aakinshin.net/posts/weighted-quantiles/ with values at a=1,2,3
expected = DataArray([0.9308707], coords={"quantile": 
[q]}).squeeze()

  assert_allclose(result, expected)

E   AssertionError: Left and right DataArray objects are not close
E   E   Differing values:
E   L
E   array(-0.289754)
E   R
E   array(0.930871)

/usr/lib/python3/dist-packages/xarray/tests/test_weighted.py:667: 
AssertionError


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013938: balboa: regression + flaky autopkgtest: regularly times out on amd64, i386 and s390x

[Paul Gevers]

Source: balboa
Version: 2.0.0+ds-4
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it was 
showing up on our "slow" page [1]. I noticed that there were several 
runs that took 2:47 (our timeout time), while successful runs more in 
the order of minutes. This started to happen recently.


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.

On top of that, when a test just hangs that's not good for our 
infrastructure. I'll put balboa on our reject_list for amd64, i386, and 
s390x.


Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

[1] https://ci.debian.net/status/slow/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013797: grub-efi: grub no longer offers to boot Windows

[Ralf Jung]

Ah, turns out I need to add "GRUB_DISABLE_OS_PROBER=false" in /etc/default/grub.
I think it is bad to silently change the default in an upgrade here, since it 
can leave people locked out of an OS they need.

GRUB_DISABLE_OS_PROBER is not even listed in /etc/default/grub.ucf-dist.

Kind regards,
Ralf

Bug#1013937: Fails to upload to cloud with "SSL handshake failed"

[martin f krafft]

Package: flameshot
Version: 12.0.0-1
Severity: normal

Trying to upload a shot to imgur ("the Cloud") results in an error 
"SSL handshake failed". Connections to `api.imgur.net` with e.g. 
`gnutls-cli` work without trouble.

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

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

Versions of packages flameshot depends on:
ii  hicolor-icon-theme  0.17-2
ii  libc6   2.33-7
ii  libgcc-s1   12.1.0-1
ii  libqt5core5a5.15.2+dfsg-16+b2
ii  libqt5dbus5 5.15.2+dfsg-16+b2
ii  libqt5gui5  5.15.2+dfsg-16+b2
ii  libqt5network5  5.15.2+dfsg-16+b2
ii  libqt5svg5  5.15.2-4
ii  libqt5widgets5  5.15.2+dfsg-16+b2
ii  libstdc++6  12.1.0-1

Versions of packages flameshot recommends:
ii  grim1.4.0+ds-2
ii  xdg-desktop-portal-gtk  1.14.0-1

Versions of packages flameshot suggests:
ii  ca-certificates  20211016
ii  openssl  1.1.1o-1

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1013889: rpmlint: autopkgtest regression: No module named 'zstandard'

[Boyuan Yang]

Hi,

在 2022-06-26星期日的 22:12 +0200，Paul Gevers写道：
> Source: rpmlint
> Version: 2.3.0+ds1-0.1
> Severity: serious
> X-Debbugs-CC: Boyuan Yang 
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainer(s), Boyuan,
> 
> With a recent upload of rpmlint the autopkgtest of rpmlint fails in 
> testing when that autopkgtest is run with the binary packages of rpmlint 
> from unstable. It passes when run with only packages from testing. In 
> tabular form:
> 
>     pass    fail
> rpmlint    from testing    2.3.0+ds1-0.1
> all others from testing    from testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration to testing [1]. Can 
> you please investigate the situation and fix it?
> 
> More information about this bug and the reason for filing it can be found
> on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=rpmlint
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/rpmlint/23083611/log.gz
> 
>  ERRORS 
> 
> __ ERROR collecting test/test_cli.py 
> ___
> ImportError while importing test module 
> '/tmp/autopkgtest-lxc.i2hlbh7a/downtmp/build.cyC/src/test/test_cli.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> /usr/lib/python3/dist-packages/_pytest/python.py:578: in _importtestmodule
>  mod = import_path(self.fspath, mode=importmode)
> /usr/lib/python3/dist-packages/_pytest/pathlib.py:524: in import_path
>  importlib.import_module(module_name)
> /usr/lib/python3.10/importlib/__init__.py:126: in import_module
>  return _bootstrap._gcd_import(name[level:], package, level)
> :1050: in _gcd_import
>  ???
> :1027: in _find_and_load
>  ???
> :1006: in _find_and_load_unlocked
>  ???
> :688: in _load_unlocked
>  ???
> /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:170: in 
> exec_module
>  exec(co, module.__dict__)
> test/test_cli.py:4: in 
>  from rpmlint.cli import process_lint_args
> rpmlint/cli.py:6: in 
>  from rpmlint.lint import Lint
> rpmlint/lint.py:14: in 
>  from rpmlint.pkg import FakePkg, get_installed_pkgs, Pkg
> rpmlint/pkg.py:27: in 
>  import zstandard as zstd
> E   ModuleNotFoundError: No module named 'zstandard'

A new test dependency python-zstandard (
https://salsa.debian.org/python-team/packages/python-zstandard , not python-
zstd) is needed. This is now prepared and put into the NEW queue.

Thanks,
Boyuan Yang


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

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Mon 27 Jun 2022 at 18:43:16 +0100, Gareth Evans wrote:

> On Mon 27 Jun 2022, at 18:41, Till Kamppeter  wrote:
> [...]
> > Seems that it is able to access the printer for sending a job to it 
> > (done as user "lp"?) but not to poll the printer's capabilities via IPP 
> > (when running the "lpadmin" command).
> 
> The printer/queue was not created, so I didn't get as far as testing printing.
> 
> Which is to say that testqq didn't appear in system-config-printer.

ipp://192.168.0.14/ipp/print is the most fundamental URI available.
Assuming the IP address is unchanged, do (as root)

  cupsctl --debug-logging
  >/var/lod/error_log

Set up a driverless queue as before. Compress error_log with gz or xz
and send it here.

Cheers,

Brian.

Bug#1013935: dogtag-pki: flaky autopkgtest: regularly times out on amd64, armhf and s390x

[Paul Gevers]

Source: dogtag-pki
Version: 11.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it was 
showing up on our "slow" page [1]. I noticed that there were several 
runs that took 2:47 (our timeout time), while successful runs more in 
the order of minutes.


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.

On top of that, when a test just hangs that's not good for our 
infrastructure. I'll put dogtag-pki on our reject_list for amd64, armhf, 
and s390x.


Don't hesitate to reach out if you need help and some more information
from our infrastructure. E.g. I note that the runs on amd64 that I 
happen to check are run on ci-worker13 that, together with our armhf 
worker is running on a host with lots of CPUs (64 and 160) and RAM 
(256GB and 511GB) and also our s390x has 10 CPUs and 32 GB.


Paul

[1] https://ci.debian.net/status/slow/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013924: coreutils: runcon -c getfscon()s program verbatim but execve()s it; trojan moment?

[Pádraig Brady]

On 27/06/2022 16:04, наб wrote:

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

The strace for runcon -c true true (after a > true) contains
   getxattr("true", "security.selinux", "unconfined_u:object_r:user_tmp_t", 
255) = 36
   execve("/usr/local/sbin/true", ["true", "true"]) = -1 ENOENT
   execve("/usr/local/bin/true", ["true", "true"]) = -1 ENOENT
   execve("/sbin/true", ["true", "true"]) = -1 ENOENT
   execve("/bin/true", ["true", "true"]) = 0

This corresponds to getfscon("true"), execvp("true", ["true", NULL]).
(of course, this also errors if ./true doesn't exist).

So, uh: is this intentional? It certainly feels wrong? All invocations
take a PATH executable except this one which takes a PATH executable
that must *also* be a valid file? And also invites a trivial trojan
because the precomputed transition is to the file in the cwd, but the
program executed lives somewhere in PATH? Should -c just execv()
instead? Am I misunderstanding the usefulness of this?

Best,
наб


This is a fair point.
I.e. the following patch would be more correct operation.
I'll propose this upstream.

Now existing scripts would need to pass absolute paths to `runcon -c`
to work in the first place, so I don't know how much of a security
issue this is in practice.

thanks,
Pádraig

iff --git a/src/runcon.c b/src/runcon.c
index c4227c784..d85411c79 100644
--- a/src/runcon.c
+++ b/src/runcon.c
@@ -255,7 +255,7 @@ main (int argc, char **argv)
   if (cur_context != NULL)
 freecon (cur_context);

-  execvp (argv[optind], argv + optind);
+  (compute_trans ? execv : execvp) (argv[optind], argv + optind);

   int exit_status = errno == ENOENT ? EXIT_ENOENT : EXIT_CANNOT_INVOKE;
   error (0, errno, "%s", quote (argv[optind]));

Bug#1011688: synaptic: diff for NMU version 0.90.2+nmu1

[Boyuan Yang]

Control: tags 1011688 + patch
Control: tags 1011688 + pending

Dear maintainer,

I've prepared an NMU for synaptic (versioned as 0.90.2+nmu1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru synaptic-0.90.2/common/rconfiguration.cc synaptic-
0.90.2+nmu1/common/rconfiguration.cc
--- synaptic-0.90.2/common/rconfiguration.cc2020-11-16
03:56:34.0 -0500
+++ synaptic-0.90.2+nmu1/common/rconfiguration.cc   2022-06-27
14:01:08.0 -0400
@@ -30,6 +30,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
diff -Nru synaptic-0.90.2/configure.ac synaptic-0.90.2+nmu1/configure.ac
--- synaptic-0.90.2/configure.ac2020-11-16 03:56:34.0 -0500
+++ synaptic-0.90.2+nmu1/configure.ac   2022-06-27 14:01:08.0 -0400
@@ -1,5 +1,5 @@
 dnl Process this file with autoconf to produce a configure script.
-AC_INIT(synaptic, 0.90.2)
+AC_INIT(synaptic, 0.90.2+nmu1)
 
 AM_INIT_AUTOMAKE([subdir-objects -Wno-portability])
 AM_CONFIG_HEADER(config.h)
diff -Nru synaptic-0.90.2/debian/changelog synaptic-
0.90.2+nmu1/debian/changelog
--- synaptic-0.90.2/debian/changelog2020-11-16 03:56:34.0 -0500
+++ synaptic-0.90.2+nmu1/debian/changelog   2022-06-27
14:01:08.0 -0400
@@ -1,3 +1,12 @@
+synaptic (0.90.2+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * common/rconfiguration.cc: Include unistd.h to prevent FTBFS
+due to undefined getuid(2). (Closes: #1011688)
+  * configure.ac: Bump version string.
+
+ -- Boyuan Yang   Mon, 27 Jun 2022 14:01:08 -0400
+
 synaptic (0.90.2) unstable; urgency=medium
 
   [ Heimen Stoffels ]


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

Bug#1013920: Info received (Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel"))

[lkcl]

jeremy i didn't see your reply until i checked online.  you spotted the second 
half:

We will usually allow these uses as long as the modifications
are (1) relatively small and (2) very clearly communicated to
end-users.

i did not include this because DFSG 8 is already violated by the first
half.  the *very fact* of needing to ask is an unreasonable burden
that is directly in conflict with the entire Libre/Open Concept.

imagine a Copyright License that said, "you MUST come to us to
ask permission to distribute modified versions oh but otherwise this License is 
a Free/Open One, No Really"

absolutely everyone would freak out and agree that is non-free, and the package 
either moved to nonfree or pulled entirely.

this unfortunately is exactly what the Rust Trademark has done:
added *additional* Lawfully-enforceable requirements that must
legally be complied with or suffer the consequences.

* It's Free because Copyright License BSD (whatever)
* Oh But under the Trademark We Don't Grant Distribution
   Rights for Derivative Works

and no, the existence of the Copyright License does *not* invalidate or 
override the Legal requirement to also comply with Trademark Law.  it is 
astonishing the number of FOSS developers who genuinely believe that they can 
blatantly disregard Trademark Law "Because Open Source"

> For instance, here is an excerpt without context from Debian's policy:
> "You cannot use Debian trademarks in a company or organization name or
> as the name of a product or service."

this is standard fare as part of Trademark Law.  it causes "confusion".

l.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

On Mon 27 Jun 2022, at 18:41, Till Kamppeter  wrote:
[...]
> Seems that it is able to access the printer for sending a job to it 
> (done as user "lp"?) but not to poll the printer's capabilities via IPP 
> (when running the "lpadmin" command).

The printer/queue was not created, so I didn't get as far as testing printing.

Which is to say that testqq didn't appear in system-config-printer.

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Till Kamppeter]

On 27/06/2022 19:26, Gareth Evans wrote:


"testq" already exists, so I changed the queue name to avoid any potential 
caching effects etc in case that were possible.

$ sudo lpadmin -p testqq -v ipp://192.168.0.14/ipp/print -E -m 
driverless:ipp://192.168.0.14/ipp/print
lpadmin: Printer drivers are deprecated and will stop working in a future 
version of CUPS.
lpadmin: Unable to open PPD "/tmp/075ef62bac756": Missing PPD-Adobe-4.x header 
on line 0.

That's the first time I've seen this error message.


Seems that it is able to access the printer for sending a job to it 
(done as user "lp"?) but not to poll the printer's capabilities via IPP 
(when running the "lpadmin" command).

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

On Mon 27 Jun 2022, at 18:04, Brian Potkin  wrote:
[...]
> Set up
>
>   lpadmin -p testeveq -v ipp://192.168.0.14/ipp/print -E -m everywhere
>
> and print to testeveq as before. We expect this to work.

Yes, it prints

> Now
>
>   lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m 
> driverless:ipp://192.168.0.14/ipp/print
>
> and print to testq. How does that go?

"testq" already exists, so I changed the queue name to avoid any potential 
caching effects etc in case that were possible.

$ sudo lpadmin -p testqq -v ipp://192.168.0.14/ipp/print -E -m 
driverless:ipp://192.168.0.14/ipp/print
lpadmin: Printer drivers are deprecated and will stop working in a future 
version of CUPS.
lpadmin: Unable to open PPD "/tmp/075ef62bac756": Missing PPD-Adobe-4.x header 
on line 0.

That's the first time I've seen this error message.

Thanks,
Gareth

Bug#1013931: libtorrent-rasterbar2.0: Crash on exit

[Hilko Bengen]

Package: libtorrent-rasterbar2.0
Version: 2.0.6-3+b1
Severity: grave
X-Debbugs-Cc: none, Hilko Bengen 
Control: notfound -1 2.0.6-3

Dear Maintainer,

bug #1013470 about a nbdkit rebuild failure was reported and it turned
out that this happens because of a crash that happens even in trivial
cases:

,
| $ server/nbdkit plugins/torrent/.libs/nbdkit-torrent-plugin.so --help
| nbdkit [-4|--ipv4-only] [-6|--ipv6-only]
|[-D|--debug PLUGIN|FILTER|nbdkit.FLAG=N]
|[-e|--exportname EXPORTNAME] [--exit-with-parent]
|[--filter FILTER ...] [-f|--foreground]
|[-g|--group GROUP] [-i|--ipaddr IPADDR]
|[--log stderr|syslog|null]
|[-n|--newstyle] [--mask-handshake MASK] [--no-sr] [-o|--oldstyle]
|[-P|--pidfile PIDFILE]
|[-p|--port PORT] [-r|--readonly]
|[--run CMD] [-s|--single] [--selinux-label LABEL] [--swap]
|[-t|--threads THREADS]
|[--tls off|on|require]
|[--tls-certificates /path/to/certificates]
|[--tls-psk /path/to/pskfile] [--tls-verify-peer]
|[-U|--unix SOCKET] [-u|--user USER]
|[-v|--verbose] [-V|--version] [--vsock]
|PLUGIN [[KEY=]VALUE [KEY=VALUE [...]]]
| 
| nbdkit --dump-config
| 
| nbdkit PLUGIN --dump-plugin
| 
| nbdkit --help
| 
| Please read the nbdkit(1) manual page for full usage.
| 
| plugin: torrent (nbdkit bittorrent plugin)
| (plugins/torrent/.libs/nbdkit-torrent-plugin.so)
| torrent=   (required) Torrent or magnet link.
| file=DISK.iso  File to serve within torrent.
| cache=DIR  Set directory to store partial downloads.
| Segmentation fault
`

>From the output, it looks as if the crash occurred on a cleanup code
path.

Downgrading to 2.0.6-3 (before the OpenSSL 3 rebuild) makes the
segmentation fault go away.

The stacktrace below suggests that this is related to cleanup code
registered using atexit(3): pthread_rwlock_wrlock() is called with a
NULL pointer.

,
| $ gdb --args server/nbdkit plugins/torrent/.libs/nbdkit-torrent-plugin.so 
--help
| GNU gdb (Debian 12.1-2) 12.1
| Copyright (C) 2022 Free Software Foundation, Inc.
| [...]
| (gdb) run
| Starting program: /home/bengen/p/deb/nbdkit/server/nbdkit 
plugins/torrent/.libs/nbdkit-torrent-plugin.so --help
| [Thread debugging using libthread_db enabled]
| Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
| nbdkit [-4|--ipv4-only] [-6|--ipv6-only]
|[-D|--debug PLUGIN|FILTER|nbdkit.FLAG=N]
| [...]
| torrent=   (required) Torrent or magnet link.
| file=DISK.iso  File to serve within torrent.
| cache=DIR  Set directory to store partial downloads.
| 
| Program received signal SIGSEGV, Segmentation fault.
| __GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
| 27pthread_rwlock_wrlock.c: No such file or directory.
| (gdb) bt
| #0  __GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
| #1  0x76c8a8e9 in CRYPTO_THREAD_write_lock (lock=) at 
../crypto/threads_pthread.c:112
| #2  0x76ba7a03 in conf_modules_finish_int () at 
../crypto/conf/conf_mod.c:524
| #3  0x76ba8132 in CONF_modules_unload (all=1) at 
../crypto/conf/conf_mod.c:482
| #4  0x7726af24 in 
boost::asio::ssl::detail::openssl_init_base::do_init::~do_init 
(this=0x6157dc50, __in_chrg=)
| at /usr/include/boost/asio/ssl/detail/impl/openssl_init.ipp:90
| #5  
std::_Sp_counted_ptr::_M_dispose (
| this=) at /usr/include/c++/11/bits/shared_ptr_base.h:348
| #6  0x7726b09a in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release 
(this=0x6157db90)
| at /usr/include/c++/11/bits/shared_ptr_base.h:168
| #7  std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
(this=, __in_chrg=)
| at /usr/include/c++/11/bits/shared_ptr_base.h:705
| #8  std::__shared_ptr::~__shared_ptr (
| this=, __in_chrg=) at 
/usr/include/c++/11/bits/shared_ptr_base.h:1154
| #9  
std::shared_ptr::~shared_ptr
 (this=, __in_chrg=)
| at /usr/include/c++/11/bits/shared_ptr.h:122
| #10 0x77bb9f77 in __run_exit_handlers (status=status@entry=0, 
listp=0x77d4d738 <__exit_funcs>, 
| run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:108
| #11 0x77bba11a in __GI_exit (status=status@entry=0) at exit.c:139
| #12 0xa944 in main (argc=, argv=) 
at ./server/main.c:678
`

Cheers,
-Hilko

Bug#1013932: yade: FTBFS in unstable and testing

[Graham Inggs]

Source: yade
Version: 2022.01a-9
Severity: serious
Tags: ftbfs

Hi Maintainer

yade currently FTBFS in unstable and testing.  The  failure [1] was
picked up during the onetbb transition, but might not be related as
yade was test built before the transition was started.

I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=yade


--
Ran 93 tests in 9.139s

OK
 [92m*** ALL TESTS PASSED *** [0m
[x86-csail-01:2352391] *** Process received signal ***
[x86-csail-01:2352391] Signal: Segmentation fault (11)
[x86-csail-01:2352391] Signal code: Address not mapped (1)
[x86-csail-01:2352391] Failing at address: 0x7fee112ef5e0
Segmentation fault

Bug#1013933: Keep xsane out of Debian releases

[Jörg Frings-Fürst]

Package: xsane
Version: 0.999-12
Severity: serious


This is a placeholder RC bug to prevent xsane from entering testing
and making it to a Debian release. Xsane has not been maintained by
the Upstream author since 2014. Even the current fork does not show
much further development.

Because of the bugs in the GUI I don't think the current version
is suitable for a Debian release.

Should the fork develop positively, I will close this bug.


CU
Jörg


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 xsane depends on:
ii  libc62.33-7
ii  libgimp2.0   2.10.30-1+b1
ii  libglib2.0-0 2.72.2-2
ii  libgtk2.0-0  2.24.33-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  liblcms2-2   2.12~rc1-2
ii  libpng16-16  1.6.37-5
ii  libsane1 1.1.1-5
ii  libtiff5 4.4.0-2
ii  sensible-utils   0.0.17
ii  xsane-common 0.999-12
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages xsane recommends:
ii  cups-client 2.4.2-1
ii  firefox [www-browser]   101.0.1-1
ii  firefox-esr [www-browser]   91.10.0esr-1
ii  google-chrome-stable [www-browser]  103.0.5060.53-1
ii  hv3 [www-browser]   3.0~fossil20110109-8
ii  lynx [www-browser]  2.9.0dev.10-1

Versions of packages xsane suggests:
ii  gimp  2.10.30-1+b1
pn  gocr | cuneiform | tesseract-ocr | ocrad  
pn  gv
pn  hylafax-client | mgetty-fax   

-- no debconf information

Bug#1012196: buglist

[André Flechs]

Control: tags -1 -moreinfo

Hi Bastian,

I updated the package and send mails to almost all bugs.
There is only one issue left in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706983. How should I 
handle this?


Thanks again to David for the explanations.

Kind regards,
André

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Mon 27 Jun 2022 at 17:22:22 +0100, Gareth Evans wrote:

> On Mon 27 Jun 2022, at 17:11, Till Kamppeter  wrote:
> > And are you able to print now?
> >
> > Till
> >
> 
> Only to the queue added via lpadmin ... everywhere
> 
> No autodetected printers appear in system-config-printer or application print 
> dialogs.
> 
> $ sudo lpadmin -p testq -v 
> "ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local" -E -m 
> driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local"
> [sudo] password for user: 
> lpadmin: Printer drivers are deprecated and will stop working in a future 
> version of CUPS.
> 
> $ lp -d testq /etc/nsswitch.conf
> request id is testq-12 (1 file(s))
> 
> Nothing prints over 5GHz, nor 2.5GHz wifi connections.
> 
> Same behaviour as before in both cases - printer lights up but nothing prints.

The problem I have here is in understanding. A queue set up with the
cups-filters driverless for -m is based strongly on CUPS everywhere.

Here is a URI for the device. It is equivalent to what you already
have:

  ipp://192.168.0.14/ipp/print

Set up

  lpadmin -p testeveq -v ipp://192.168.0.14/ipp/print -E -m everywhere

and print to testeveq as before. We expect this to work.

Now

  lpadmin -p testq -v ipp://192.168.0.14/ipp/print -E -m 
driverless:ipp://192.168.0.14/ipp/print

and print to testq. How does that go?

Cheers,

Brian.

Bug#1013329: razor 2.85 is really 2.84

[Malte S. Stretz]

Hi vagrant,

thanks for pushing this to bdo.


On 21/06/2022 23:41, Vagrant Cascadian wrote:

On 2022-06-20, Malte S. Stretz wrote:

TL;DR: It looks like the Debian 2.85 razor package you've been recently
working on according to
https://salsa.debian.org/debian/razor/-/commits/debian/latest is really 2.84


>> […]


The current "upstream" version was uploaded to debian in 2008 currently
present in old-old-stable (e.g. two releases prior to the current stable
release):

   https://tracker.debian.org/news/303771/accepted-razor-1285-1-source-amd64/

The best thing might be to actually update to the newest upstream
release, if there is indeed one newer than 2.85... and kind of ignore
that unfortunate problem...

... though there might be security issues that are not correctly tracked
that are fixed in the upstream 2.85, but not in the debian packages
because of the version discrepancy; that might be worth confirming and
possibly notifying the security team.


The good news:  There doesn't seem to be any security relevant changes 
in https://github.com/toddr/Razor2-Client-Agent/compare/v2.84...v2.85


There even don't seem to be many functional changes, most of the changes 
are cleanup/build related things.  v2.86 also was just a build related 
thing.


The bad news:  All the current Debian patches won't apply anymore since 
there was some excessive reformatting applied upstream.


OTOH will some of them not be needed anymore since it looks they were 
partially incorporated upstream.



All that said, not sure I have the energy to tackle this kind of tangled
problem at the moment...


Would you like help with that?  My Debian packaging know how is a bit 
rusty but I could create a PR on Salsa which


* Merges the Upstream repo into the current Salsa repo (ie. switching it 
over to https://wiki.debian.org/PackagingWithGit#Using_the_upstream_repo 
without losing any history) at upstream v2.84

* Fixes up the Quilt patches and merge that state with upstream v2.85
* Bump the whole stuff to v2.86

What do I get out of that?  I'd like to include my IPv6 patch on top of 
all of this.


Regards,
Malte

Bug#1013930: src:iperf3: fails to migrate to testing for too long: piuparts regression, changes conffile

[Paul Gevers]

Source: iperf3
Version: 3.9-1
Severity: serious
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:iperf3 has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. The migration is blocked because 
piuparts reports a regression. A quick glance (piuparts log and your 
changelog) suggests you are now changing a conffile (not to be confused 
with a normal configuration file), see [3].


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=iperf3
[3] 
https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013929: src:goffice: fails to migrate to testing for too long: FTBFS on mips64el

[Paul Gevers]

Source: goffice
Version: 0.10.51-1
Severity: serious
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:goffice has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package fails to build from 
source on mips64el where it successfully built in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have tagged this bug to only affect sid and bookworm, so it doesn't 
affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=goffice



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

On Mon 27 Jun 2022, at 17:11, Till Kamppeter  wrote:
> And are you able to print now?
>
> Till
>

Only to the queue added via lpadmin ... everywhere

No autodetected printers appear in system-config-printer or application print 
dialogs.

$ sudo lpadmin -p testq -v 
"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local" -E -m 
driverless:"ipp://Brother%20MFC-L2740DW%20series._ipp._tcp.local"
[sudo] password for user: 
lpadmin: Printer drivers are deprecated and will stop working in a future 
version of CUPS.

$ lp -d testq /etc/nsswitch.conf
request id is testq-12 (1 file(s))

Nothing prints over 5GHz, nor 2.5GHz wifi connections.

Same behaviour as before in both cases - printer lights up but nothing prints.

Thanks,
Gareth

Bug#737634: Bug#1007717: Native source package format with non-native version

[Sean Whitton]

With three first preference votes for A and five first preference votes
for C, the outcome is no longer in doubt.  Therefore, using its powers
under constitution 6.1.5, the Technical Committee issues the following
advice:

  1. It is not a bug of any severity for a package with a non-native
 version number to use a native source package format.

  2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
 complain, when a non-native version number is used w/ 3.0 (native).

  3. We suggest that the wontfix tag on #737634 be reconsidered.

  4. We believe that there are indeed circumstances in which
 1.0-with-diff is the best choice for a particular source package,
 including, but not limited to, git-first packaging workflows.
 However, we recommend discontinuing use of 1.0-with-diff in other
 circumstances, to simplify the contents of the archive.

 This is because there is currently no other source format which is
 such that avoid both (i) uploading the whole source, including
 upstream, for every upload; and (ii) having to maintain
 debian/patches/ inside the package tree.

  5. We decline to comment on the recent source package format MBF.

-- 
Sean Whitton

Bug#1013928: ITP: golang-github-emersion-go-msgauth -- A Go library and tools for DKIM, DMARC and Authentication-Results

[Robin Jarry]

Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-github-emersion-go-msgauth
  Version : 0.6.6-1
  Upstream Author : Simon Ser
* URL : https://github.com/emersion/go-msgauth
* License : Expat
  Programming Lang: Go
  Description : A Go library and tools for DKIM, DMARC and 
Authentication-Results

 go-msgauth
 .
 godocs.io (https://godocs.io/github.com/emersion/go-msgauth) builds.sr.ht
 status (https://builds.sr.ht/~emersion/go-msgauth/commits/master)
 .
 A Go library and tools to authenticate e-mails:
 .
  * Create and verify DKIM signatures
(https://tools.ietf.org/html/rfc6376)
  * Create and parse Authentication-Results header fields
(https://tools.ietf.org/html/rfc7601)
  * Fetch DMARC (http://tools.ietf.org/html/rfc7489) records
 .
 DKIM godocs.io (https://godocs.io/github.com/emersion/go-msgauth/dkim)
 .
 Sign
 .
   r := strings.NewReader(mailString)
 .
   options := {
Domain: "example.org",
Selector: "brisbane",
Signer: privateKey,
   }
 .
   var b bytes.Buffer
   if err := dkim.Sign(, r, options); err != nil {
log.Fatal(err)
   }
 .
 Verify
 .
   r := strings.NewReader(mailString)
 .
   verifications, err := dkim.Verify(r)
   if err != nil {
log.Fatal(err)
   }
 .
   for _, v := range verifications {
if v.Err == nil {
log.Println("Valid signature for:", v.Domain)
} else {
log.Println("Invalid signature for:", v.Domain, v.Err)
}
   }
 .
 FAQ
 .
 **Why can't I verify a mail.Message directly?** A mail.Message header is
 already parsed, and whitespace characters (especially continuation
 lines) are removed. Thus, the signature computed from the parsed header
 is not the same as the one computed from the raw header.
 .
 **How can I publish my public key?** You have to add a TXT record to
 your DNS zone. See RFC 6376 appendix C
 (https://tools.ietf.org/html/rfc6376#appendix-C). You can use the dkim-
 keygen tool included in go-msgauth to generate the key and the TXT
 record.
 .
 Authentication-Results godocs.io
 (https://godocs.io/github.com/emersion/go-msgauth/authres)
 .
   // Format
   results := []authres.Result{
{Value: authres.ResultPass, From: "example.net"},
{Value: authres.ResultPass, Auth:
 "sen...@example.com"},
   }
   s := authres.Format("example.com", results)
   log.Println(s)
 .
   // Parse
   identifier, results, err := authres.Parse(s)
   if err != nil {
log.Fatal(err)
   }
 .
   log.Println(identifier, results)
 .
 DMARC godocs.io (https://godocs.io/github.com/emersion/go-msgauth/dmarc)
 .
 See the GoDoc page.
 .
 Tools
 .
 A few tools are included in go-msgauth:
 .
  * dkim-keygen: generate a DKIM key
  * dkim-milter: a mail filter to sign and verify DKIM signatures
  * dkim-verify: verify a DKIM-signed email
  * dmarc-lookup: lookup the DMARC policy of a domain
 .
 License
 .
 MIT


This is a new build dependency for aerc.

Bug#1013927: ITP: golang-github-arran4-golang-ical -- A ICS / ICal parser and serialiser for Golang.

[Robin Jarry]

Package: wnpp
Severity: wishlist
Owner: Robin Jarry 

* Package name: golang-github-arran4-golang-ical
  Version : 0.0~git20220517.fd89fefb0182-1
  Upstream Author : Arran Ubels
* URL : https://github.com/arran4/golang-ical
* License : Apache-2.0
  Programming Lang: Go
  Description : A  ICS / ICal parser and serialiser for Golang.

 golang-ical
 .
 A  ICS / ICal parser and serialiser for Golang.
 .
 Because the other libraries didn't quite do what I needed.
 .
 Usage, parsing:
 .
   cal, err := ParseCalendar(strings.NewReader(input))
 .
 .
 Creating:
 .
 cal := ics.NewCalendar()
 cal.SetMethod(ics.MethodRequest)
 event := cal.AddEvent(fmt.Sprintf("id@domain",
 p.SessionKey.IntID()))
 event.SetCreatedTime(time.Now())
 event.SetDtStampTime(time.Now())
 event.SetModifiedAt(time.Now())
 event.SetStartAt(time.Now())
 event.SetEndAt(time.Now())
 event.SetSummary("Summary")
 event.SetLocation("Address")
 event.SetDescription("Description")
 event.SetURL("https://URL/;)
 event.AddRrule(fmt.Sprintf("FREQ=YEARLY;BYMONTH=%d;BYMONTHDAY=%d",
 time.Now().Month(), time.Now().Day()))
 event.SetOrganizer("sender@domain", ics.WithCN("This Machine"))
 event.AddAttendee("reciever or participant",
 ics.CalendarUserTypeIndividual, ics.ParticipationStatusNeedsAction,
 ics.ParticipationRoleReqParticipant, ics.WithRSVP(true))
 return cal.Serialize()
 .
 Helper methods created as needed feel free to send a P.R. with more.

This is a new build dependency for aerc.

Bug#1013926: "bash: COMP_WORDS: bad array subscript" when completing in the middle of a command

[Krzysztof Aleksander Pyrkosz]

Package: bash-completion
Version: 1:2.11-2
Severity: normal
X-Debbugs-Cc: krzpyrk...@gmail.com

Dear Maintainer,

Completing this command just after first "./do" causes the completion script to 
output an error.

LLVM_PROFILE_FILE="foo.profraw" ./do && llvm-profdata merge -sparse *.profraw 
-o foo.profdata && llvm-cov show ./dojo_ut -instr-profile=foo.profdata | less

I've tried it on my desktop, server, and and ARM board. It crashes in
every case, but exclusively in this particular place, just after "./do",
no matter if there is, or isn't a file starting with this prefix.

Bug#1010348: horizon-eda isn't affected by it

[Uwe Steinmann]

I finally investigated this, but came to the conclusion that
horizon-eda isn't affected by it, because it doesn't use the
version of dxflib in the horizon-eda sources but links against
the version shipped by debian. Am I missing anything here?



signature.asc
Description: PGP signature

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Till Kamppeter]

And are you able to print now?

   Till

On 27/06/2022 17:57, Gareth Evans wrote:

However that is when the laptop is connected to 5GHz wifi.
If I change to the 2.5GHz connection (same router) on which (router and 
frequency) the printer is connected:

$ avahi-browse -rt _ipp._tcp
+ wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer
 local
= wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer
 local
hostname = [mfcl2740dw.local]
address = [192.168.0.14]
port = [631]
txt = ["print_wfds=T" "UUID=e3248000-80ce-11db-8000-30055ca3d8ec" "PaperMax=legal-A4" "kind=document,envelope,label" "URF=W8,CP1,IS4-1,MT1-3-4-5-8,OB10,PQ4,RS200-300-600,V1.3,DM1" "rfo=ipp/faxout" "TBCP=F" "Transparent=T" "Binary=T" 
"PaperCustom=T" "Scan=T" "Fax=T" "Duplex=T" "Copies=T" "Color=F" "usb_CMD=PJL,PCL,PCLXL,URF" "usb_MDL=MFC-L2740DW series" "usb_MFG=Brother" "priority=25" "adminurl=http://mfcl2740dw.local./net/net/airprint.html; "product=(Brother 
MFC-L2740DW series)" "ty=Brother MFC-L2740DW series" "note=" "rp=ipp/print" "pdl=application/octet-stream,image/urf,image/pwg-raster" "qtotal=1" "txtvers=1"]

$ avahi-browse -rt _uscan._tcp
$

Bug#1013925: ITP: clapper -- Simple and modern GNOME media player

[josch]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer Marin Rodrigues 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name : clapper
Version : 0.5.2
Upstream Author : Rafał Dzięgiel 
* URL : https://rafostar.github.io/clapper
* License : GPL3+, LGPL2+
Programming Lang: C, JavaScript
Description: Simple and modern GNOME media player
 Clapper is a GNOME media player built using GJS with GTK4 toolkit.
 The media player is using GStreamer as a media backend and renders
 everything via OpenGL. Player works natively on both Xorg and Wayland.
 It also supports hardware acceleration through VA-API on AMD/Intel 
GPUs,

 NVDEC on Nvidia and V4L2 on mobile devices.
 .
 The media player has an adaptive GUI. When viewing videos in "Windowed 
Mode",
 Clapper will use mostly unmodified GTK widgets to match your OS look 
nicely.
 When player enters "Fullscreen Mode" all GUI elements will become 
darker,
 bigger and semi-transparent for your viewing comfort. It also has a 
"Floating
 Mode" which displays only video on top of all other windows for a 
PiP-like

 viewing experience. Mobile friendly transitions are also supported.

I did some initial packaging here: 
https://salsa.debian.org/debian/clapper
This is the first time I'm packaging gobject-introspection or gstreamer 
stuff, so I'm also
looking for advice of whether I should keep this as one monolithic 
package or split it into
multiple library packages even though I doubt the development packages 
will be useful to

others.

I also hope this mail works because I'm on vacation and cannot use my 
usual reportbug
setup and instead am using my web mailer to send this mail. Fingers 
crossed!

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

On Mon 27 Jun 2022, at 16:57, Gareth Evans  wrote:

> However that is when the laptop is connected to 5GHz wifi.
> If I change to the 2.5GHz connection (same router) on which (router and 
> frequency) the printer is connected [...]

Switching back to 5GHz

$ avahi-browse -rt _ipp._tcp

now provides the same output as above.

Thanks,
Gareth

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

On Mon 27 Jun 2022, at 16:50, Gareth Evans  wrote:
> $ avahi-browse -rt _ipp._tcp
> + wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet 
> Printer local
> Failed to resolve service 'Brother MFC-L2740DW series' of type 
> '_ipp._tcp' in domain 'local': Timeout reached
>
> $ avahi-browse -rt _uscan._tcp
> $

However that is when the laptop is connected to 5GHz wifi.
If I change to the 2.5GHz connection (same router) on which (router and 
frequency) the printer is connected:

$ avahi-browse -rt _ipp._tcp
+ wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer
 local
= wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer
 local
   hostname = [mfcl2740dw.local]
   address = [192.168.0.14]
   port = [631]
   txt = ["print_wfds=T" "UUID=e3248000-80ce-11db-8000-30055ca3d8ec" 
"PaperMax=legal-A4" "kind=document,envelope,label" 
"URF=W8,CP1,IS4-1,MT1-3-4-5-8,OB10,PQ4,RS200-300-600,V1.3,DM1" "rfo=ipp/faxout" 
"TBCP=F" "Transparent=T" "Binary=T" "PaperCustom=T" "Scan=T" "Fax=T" "Duplex=T" 
"Copies=T" "Color=F" "usb_CMD=PJL,PCL,PCLXL,URF" "usb_MDL=MFC-L2740DW series" 
"usb_MFG=Brother" "priority=25" 
"adminurl=http://mfcl2740dw.local./net/net/airprint.html; "product=(Brother 
MFC-L2740DW series)" "ty=Brother MFC-L2740DW series" "note=" "rp=ipp/print" 
"pdl=application/octet-stream,image/urf,image/pwg-raster" "qtotal=1" 
"txtvers=1"]

$ avahi-browse -rt _uscan._tcp
$

Thanks
Gareth

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Gareth Evans]

On Mon 27 Jun 2022, at 13:20, Brian Potkin  wrote:
> [...] Please give
>
>   avahi-browse -rt _ipp._tcp
>   avahi-browse -rt _uscan._tcp
>

Given that there is one manually set-up printer/queue (via lpadmin ... 
everywhere)

$ avahi-browse -rt _ipp._tcp
+ wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer
 local
Failed to resolve service 'Brother MFC-L2740DW series' of type '_ipp._tcp' in 
domain 'local': Timeout reached

$ avahi-browse -rt _uscan._tcp
$

Thanks,
Gareth

Bug#1013873: lintian: "Cannot open" warnings on symlinks to files in other packages from same source

[Axel Beckert]

Control: severity -1 important

Hi Andreas,

Andreas Metzler wrote:
> lintian has recently started throwing errors like this for when run on
> exim4_..._amd64.changes (source + binary upload):
> 
> --
> Warning in processable ../exim4-daemon-heavy_4.96-1_amd64.deb: Cannot open 
> /dev/shm/lintian-pool-b_2HrMSwnf/exim4/exim4-daemon-heavy_4.96-1_amd64_binary/unpacked/usr/share/doc/exim4-daemon-heavy/README.Debian.gz
>  at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.
> warning: cannot run debian/readme check on package 
> binary:exim4-daemon-heavy_4.96-1_amd64
> --

Interesting. Thanks for the bug report!

> The respective file is a symlink to the file in exim4-base/:
> (sid)ametzler@argenau:/tmp/EXIM4/exim-4.96$ ls -l 
> debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz
> lrwxrwxrwx 1 ametzler ametzler 30 Jun 26 11:53 
> debian/exim4-daemon-heavy/usr/share/doc/exim4-daemon-heavy/README.Debian.gz 
> -> ../exim4-base/README.Debian.gz

Since ../exim4-base/README.Debian.gz is actually existing, I wonder if
that "<:gzip" in

109 open($fd, '<:gzip', $item->unpacked_path)

plays a role here. My current guess is that there is a "use
PerlIO::gzip;" missing in lib/Lintian/Check/Debian/Readme.pm since it
it seems required to make "<:gzip" work (wonder why it does only spew
runtime warnings because of that and doesn't bail out at compile time
already) and it is present in quite some other Lintian Perl modules:

~/lintian/lintian → git grep PerlIO::gzip
lib/Lintian/Data/Debhelper/Addons.pm:use PerlIO::gzip;
lib/Lintian/Data/Debhelper/Commands.pm:use PerlIO::gzip;
lib/Lintian/Data/Fonts.pm:use PerlIO::gzip;
lib/Lintian/Data/InitD/VirtualFacilities.pm:use PerlIO::gzip;
lib/Lintian/Processable/Installable/Overrides.pm:use PerlIO::gzip;
~/lintian/lintian →

Will check. And if I'm right with my guess, I'll likely will write a
test first for this type of bug as there are quite some more such
cases:

~/lintian/lintian → git grep -Fl '<:gzip' | xargs fgrep -L 'use PerlIO::gzip;'
lib/Lintian/Check/Debian/Readme.pm
lib/Lintian/Check/Documentation.pm
lib/Lintian/Check/Documentation/Manual.pm
lib/Lintian/Check/Documentation/Texinfo.pm
lib/Lintian/Check/Languages/Fortran/Gfortran.pm
lib/Lintian/Check/Languages/R.pm
lib/Lintian/Data/Authority/DocBaseManual.pm
lib/Lintian/Data/Authority/VimPolicy.pm
~/lintian/lintian → 

Raising severity to important because this issue has quite some impact
if my guess above is correct.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#820069: dhcpcd5: pending

[Martin-Éric Racine]

I'm adopting this package.

This issue will be resolved by splitting the binaries, exit hooks and
manual pages into dhcpcd-base (provides: dhcp-client) and leaving only
the init.d script and systemd unit in dhcpcd5.

This way, those who only need the binaries as a backend for
/etc/network/interfaces (ifupdown) can install dhcpcd-base, while
those who also need the daemonized automation can install dhcpcd5.

Martin-Éric

Bug#983405: concurrency

[Matt Barry]

The simplest way I can think of to solve this is:

(start)
mkdir /tmp/adduser.lock
sleep and loop until mkdir succeeds

(end)
remove /tmp/adduser.lock

which should be atomic assuming a local /tmp.

One could possibly add a /tmp/adduser.lock/adduser.pid and check for a
dead lock.. I hesitate to overcomplicate this one (and certainly don't
want a dependency for it).

Thoughts?

Bug#1013924: coreutils: runcon -c getfscon()s program verbatim but execve()s it; trojan moment?

[наб]

Package: coreutils
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

The strace for runcon -c true true (after a > true) contains
  getxattr("true", "security.selinux", "unconfined_u:object_r:user_tmp_t", 255) 
= 36
  execve("/usr/local/sbin/true", ["true", "true"]) = -1 ENOENT
  execve("/usr/local/bin/true", ["true", "true"]) = -1 ENOENT
  execve("/sbin/true", ["true", "true"]) = -1 ENOENT
  execve("/bin/true", ["true", "true"]) = 0

This corresponds to getfscon("true"), execvp("true", ["true", NULL]).
(of course, this also errors if ./true doesn't exist).

So, uh: is this intentional? It certainly feels wrong? All invocations
take a PATH executable except this one which takes a PATH executable
that must *also* be a valid file? And also invites a trivial trojan
because the precomputed transition is to the file in the cwd, but the
program executed lives somewhere in PATH? Should -c just execv()
instead? Am I misunderstanding the usefulness of this?

Best,
наб

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-15-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u3
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[lkcl]

the alternative is to work with the Mozilla Foundation to rewrite their 
Trademark License.

the *intent* is clear, they do not trust Licensees (distributors) to "damage" 
the rust API, which is perfectly reasonable.

therefore, why don't they just say that?

"if a distributor performs source code modifications to a
 published revision that cause security holes, cause API or
 language incompatibilities or cause other end-user
 complaints, then this a Trademark Violation"

something along these lines is waaay more sensible than pissing about trying to 
completely unreasonably "lock down" the source code.

normally i would suggest that they convert the Trademark to a Certification 
Mark because the rust API is a Standard, and its unit tests the Compliance 
Suite, but the fact that they sell T-Shirts and merchandise prohibits that from 
being accepted (sale of products including merchandise is commercial 
competition with Licensees, and is prohibited under Certification Mark Law but 
*not* Trademark Law ).

l.

Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[Geert Stappers]

On Mon, Jun 27, 2022 at 03:00:22PM +0100, lkcl wrote:
> hi Geert,

;-)


> sorry i have an odd mailer which can only toppost.

Acknowledge on "odd mailer"  and thanks for NOT
poluting the Bug Tracking System with topposts (thanks
for preventing needless scrolling)

> as in the initial post, i found a link that indicates that such explicit
> requests are in direct violation of DFSG Section 8, namely that others
> (including Derivatives) may take the source that goes through Debian
> and continue to use and distribute it without limit or restriction.

Ah, I missed that.


> the message to the Mozilla Foundation needs to be more along the lines,
> "please remove the restriction from the Trademark License so that we
> may comply with DFSG Section 8, otherwise we have to do an iceweasel".

Yeah, avoiding another iceweasel is a good thing.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#281639: RE: sed's documentation is non-free

[Bastian Germann]

Control: tags -1 - stretch buster bullseye bookworm

On Fri, 24 Feb 2017 06:33:03 + Assaf Gordon  wrote:

Hello,

If it helps in any way, the documentation in sed-4.4 (included in 
'stretch') as licensed under GFDLv1.3 and explicitly states:


  "with no Invariant Sections, no Front-Cover Texts, and no
   Back-Cover Texts."

http://git.savannah.gnu.org/cgit/sed.git/tree/doc/sed.texi#n39

regards,
 - assaf


I suggest to close this bug. It is fixed since stretch.

Bug#1009010: fix remaining bugs

[Antoine Beaupré]

On 2022-06-24 16:53:20, Georges Khaznadar wrote:
> Hello, please find as an attachment a patch to fix #1012190 and #981703
> and close them.

Hi,

thanks for the patches.

I am note sure they work though, see my comments below...

> -- 
> Georges KHAZNADAR et Jocelyne FOURNIER
> 22 rue des mouettes, 59240 Dunkerque France.
> Téléphone +33 (0)3 28 29 17 70
>
> diff --git a/debian/changelog b/debian/changelog
> index f5795bd..2c59b7e 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,18 @@
> +slop (7.6-2.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * added a file d/libslop7.6.shlibs; #closes: #1012190

I don't understand why this is necessary. #1012190 should be closed
automatically when 7.6 migrates to testing, it's already marked as fixed
in unstable, deliberately.

> +  * modified d/control
> ++ now libslop7.6 conflicts with libslop7.5 and replaces it

libslop7.5 doesn't exist as far as I know, why is that necessary?

> ++ added a strict dependency libdevel =>
> +  libslopy7.6(>= ${source:Version}), libslopy7.6(<= ${source:Version}.1~)

shouldn't the shlibs:Depends do the right thing here?

i should also note that the bug to fix here is #1009010 and it's going
to be fixed once 7.6-2 passes NEW (which it entered yesterday).

> +  * applied GSR's patch; closes: #981703

i'd rather have that merged in when upstream does that release, instead
of carrying that local patch...

> +  * modified d/rules to clean out bin/slop

[...]

> diff --git a/debian/rules b/debian/rules
> index bb2a2a9..61fae45 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -20,3 +20,8 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
>  # main packaging script based on dh7 syntax
>  %:
>   dh $@
> +
> +override_dh_auto_clean:
> + dh_auto_clean
> + # remove a binary file not cleaned by the Makefile
> + rm -f bin/slop

could you submit this upstream?

thanks.

-- 
Nothing incites to money-crimes like great poverty or great wealth.
- Mark Twain

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

[Vincent Lefevre]

On 2022-06-27 15:39:51 +0200, Vincent Lefevre wrote:
[...]
> but systemd-logind logged about the keyboard 10 seconds after the
> boot, thus 5 seconds *after* the display manager was started:
> 
> Jun 24 17:21:26 cventin systemd-logind[606]: Watching system buttons on 
> /dev/input/event2 (DELL Dell USB Entry Keyboard)
> 
> So, what happens with systemd-logind there?

Just in case:

cventin:~> systemd-analyze blame
10.812s NetworkManager-wait-online.service
 2.341s loadcpufreq.service
 1.298s nvidia-persistenced.service
 1.204s gpm.service
  716ms accounts-daemon.service
  669ms avahi-daemon.service
  607ms cups.service
  565ms dev-sda5.device
  519ms atd.service
  516ms atopacct.service
  445ms systemd-journal-flush.service
  441ms lightdm.service
  431ms e2scrub_reap.service
  430ms lm-sensors.service
  399ms polkit.service
  392ms cpufrequtils.service
  362ms systemd-modules-load.service
  352ms mcelog.service
  346ms rtkit-daemon.service
  342ms udisks2.service
  341ms atop.service
  325ms dbus.service
  322ms ModemManager.service
  320ms systemd-udev-trigger.service
  291ms systemd-logind.service
  276ms exim4.service
  249ms apparmor.service
  192ms user@118.service
  179ms user@1000.service
  168ms rsyslog.service
  153ms systemd-journald.service
  150ms ssh.service
  140ms systemd-udevd.service
  137ms apache2.service
  134ms colord.service
  125ms apache-htcacheclean.service
  117ms lvm2-monitor.service
  106ms NetworkManager.service
  103ms keyboard-setup.service
[...]

but the machine has 12 cores and I don't see a relation with
systemd-logind.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[lkcl]

hi Geert,

sorry i have an odd mailer which can only toppost.

as in the initial post, i found a link that indicates that such explicit 
requests are in direct violation of DFSG Section 8, namely that others 
(including Derivatives) may take the source that goes through Debian and 
continue to use and distribute it without limit or restriction.

the message to the Mozilla Foundation needs to be more along the lines, "please 
remove the restriction from the Trademark License so that we may comply with 
DFSG Section 8, otherwise we have to do an iceweasel".

l.

Bug#968467: RFP: python3-librosa -- module for audio and music processing

[David Bremner]

Emmanuel Arias  writes:

> Hi,
>
> I can help.
>
> Do you plan to move librosa under python team?
>
> In this case you should create the repository in the team.
>
> Cheers,
> Arias Emmanuel
> @eamanu
> yaerobi.com

Apologies for the belated reply. No, I have no plans to move librosa
under the python team (I'm not a member). Feel free to do so yourself;
the bug is an RFP, that means I request someone else to package it.

d

Bug#1013918: lintian: False positive: `chown --reference=foo bar.baz` triggers chown-with-dot

[Axel Beckert]

Control: user lintian-ma...@debian.org
Control: usertag -1 false-positive

Hi,

Guilhem Moulin wrote:
> roundcube-core's postinst contains
> 
> chown --reference="$CONFFILE" "$CONFFILE.ucftmp"
> 
> which triggers a false positive with tag chown-with-dot.  Indeed
> "chown --reference=foo bar.baz" matches
> 
> m{ \b chown \s+ (?: -\S+ \s+ )* ( \S+ [.] \S+ ) \b }x,
> 
> but that chown command has no ambiguous user.group argument.

Nice catch! Thanks for the bug report!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#968467:

[Nilson Silva]

Hello everybody!
This package is under my responsibility to put on Debian!

I already made the package However it is depending on the latest version of 
"numba" which is still in progress!


Nilson F. Silva

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

[Vincent Lefevre]

On 2022-06-27 13:27:23 +0200, Michael Biebl wrote:
> What I can see here is that "Before" the Xorg server was apparently ready
> after 16.597/16.818 and "After" it is after 15.909/14.644. So it is actually
> quicker?

Yes, the X server is started earlier (because the display manager is
started earlier, I assume).

> So is this maybe just a perceived slowness?

But this does not explain why the keyboard isn't available immediately
by the X server like on my laptop. The systemd-logind logs show the
same kind of delay.

For instance, on my laptop, a fraction of second after the boot:

Jun 23 04:29:32 zira kernel: usb 2-6.2: New USB device found, idVendor=05ac, 
idProduct=0221, bcdDevice= 0.69
Jun 23 04:29:32 zira kernel: usb 2-6.2: New USB device strings: Mfr=1, 
Product=2, SerialNumber=0
Jun 23 04:29:32 zira kernel: usb 2-6.2: Product: Apple Keyboard
Jun 23 04:29:32 zira kernel: usb 2-6.2: Manufacturer: Apple, Inc
Jun 23 04:29:32 zira kernel: input: Apple, Inc Apple Keyboard as 
/devices/pci:00/:00:14.0/usb2/2-6/2-6.2/2-6.2:1.0/0003:05AC:0221.0001/input/input9
Jun 23 04:29:32 zira kernel: apple 0003:05AC:0221.0001: input,hidraw0: USB HID 
v1.11 Keyboard [Apple, Inc Apple Keyboard] on usb-:00:14.0-6.2/input0
Jun 23 04:29:32 zira kernel: apple 0003:05AC:0221.0002: Fn key not found (Apple 
Wireless Keyboard clone?), disabling Fn key handling
Jun 23 04:29:32 zira kernel: input: Apple, Inc Apple Keyboard as 
/devices/pci:00/:00:14.0/usb2/2-6/2-6.2/2-6.2:1.1/0003:05AC:0221.0002/input/input10
Jun 23 04:29:32 zira kernel: apple 0003:05AC:0221.0002: input,hidraw1: USB HID 
v1.11 Device [Apple, Inc Apple Keyboard] on usb-:00:14.0-6.2/input1

5 seconds later, about the display manager:

Jun 23 04:29:37 zira lightdm[3347]: pam_unix(lightdm-greeter:session): session 
opened for user lightdm(uid=116) by (uid=0)
Jun 23 04:29:37 zira systemd-logind[846]: New session c1 of user lightdm.
Jun 23 04:29:37 zira systemd[3381]: pam_unix(systemd-user:session): session 
opened for user lightdm(uid=116) by (uid=0)
Jun 23 04:29:37 zira systemd[1]: Started Session c1 of User lightdm.

but systemd-logind logged about the keyboard just 1 second after the
boot (thus before lightdm):

Jun 23 04:29:33 zira systemd-logind[846]: Watching system buttons on 
/dev/input/event3 (Apple, Inc Apple Keyboard)

So everything is fine there.

But on my desktop machine, a fraction of second after the boot:

Jun 24 17:21:16 cventin kernel: usb 2-14: New USB device found, idVendor=413c, 
idProduct=2107, bcdDevice= 1.04
Jun 24 17:21:16 cventin kernel: usb 2-14: New USB device strings: Mfr=1, 
Product=2, SerialNumber=0
Jun 24 17:21:16 cventin kernel: usb 2-14: Product: Dell USB Entry Keyboard
Jun 24 17:21:16 cventin kernel: usb 2-14: Manufacturer: DELL
Jun 24 17:21:16 cventin kernel: input: DELL Dell USB Entry Keyboard as 
/devices/pci:00/:00:14.0/usb2/2-14/2-14:1.0/0003:413C:2107.0001/input/input2
Jun 24 17:21:16 cventin kernel: hid-generic 0003:413C:2107.0001: input,hidraw0: 
USB HID v1.11 Keyboard [DELL Dell USB Entry Keyboard] on 
usb-:00:14.0-14/input0

5 seconds later, about the display manager:

Jun 24 17:21:21 cventin lightdm[827]: pam_unix(lightdm-greeter:session): 
session opened for user lightdm(uid=118) by (uid=0)
Jun 24 17:21:21 cventin systemd[831]: pam_unix(systemd-user:session): session 
opened for user lightdm(uid=118) by (uid=0)
Jun 24 17:21:21 cventin systemd[1]: Started Session c1 of User lightdm.

but systemd-logind logged about the keyboard 10 seconds after the
boot, thus 5 seconds *after* the display manager was started:

Jun 24 17:21:26 cventin systemd-logind[606]: Watching system buttons on 
/dev/input/event2 (DELL Dell USB Entry Keyboard)

So, what happens with systemd-logind there?

Perhaps that's actually the real issue (which didn't exist in
early 2019 and gradually became more and more apparent with the
maximum reached in November 2019). And the change in systemd 251
just revealed it.

But there might also be something wrong in the dependencies of
the services.

> That said, as neither Yves-Alexis nor me is able to reproduce any issues
> here, your best bet, if you think this is related to systemd, is to run a
> git bisect to find the commit which changed the behaviour.

I'm wondering whether it could be related to this change:

Changes in udev:
[...]
* udevadm trigger gained a new --prioritized-subsystem= option to
  process certain subsystems (and all their parent devices) earlier.

  systemd-udev-trigger.service now uses this new option to trigger
  block and TPM devices first, hopefully making the boot a bit faster.

Also, I have plymouth installed on this machine. I should probably
try without it to see if this makes a difference.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[Geert Stappers]

On Mon, Jun 27, 2022 at 01:58:41PM +0100, lkcl wrote:
> everything is "fine" as long as:
>
> 1) the Mozilla Foundation acts reasonably and non-discriminatorily
> (FRAND applies to Trademarks just as it applies to patent Licensing)
> 2) the Mozilla Foundation does not appreciate quite how much power it
> actually has under Trademark Law.
>
> given that this is between Free Software Groups i would expect the
> discussion to remain civil and reasonable, and for them to drop or
> modify the unachievable nonfree constraint, but please for goodness
> sake do not let the civility of the interaction lull you into a sense
> of false safety.
>
> under the Trademark as they have defined it, the Mozilla Foundation
> is perfectly permitted to issue Debian a Legal Notice to Cease and
> Desist distribution of the Unlawfully patched rustc binaries.
>
> l.


Hi Luke,
Hi all others,


Let's continue thinking several steps ahead.

* Allow all room to move forward
* Accept there is NO  "request pending" documentation,
  trust https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920#10
  that it is "work in progress"
* Ask over six weeks how much you should worry about this
* Meanwhile team-up with other Linux distributions
* Meanwhile create a concept letter you want to have, like
We, Mozilla Foundation grant these Linux distributions
* foo
* bar
* debian
* baz
to distribute our Rust and our Cargo that we still
can recognice as our Rust and as our Cargo.
* Continue enjoying Rust and Cargo



Regards
Geert Stappers


P.S.

a Trade Mark is a request for respect, not a demand for respect.
And yes, respect is something like trust, it has to be earnt.
-- 
Silence is hard to parse

Bug#1007717: Ballot and call for votes

[Christoph Berg]

Re: Sean Whitton
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.

I vote: C > A > X > N

Christoph


signature.asc
Description: PGP signature

Bug#995492: lintian: Broken --fails-on=none as default never got reverted

[Axel Beckert]

Control: tag -1 - moreinfo

Hi Guillem,

Guillem Jover wrote:
> > Can you please elaborate what exactly is the bug? You refer to
> > something being problematic without explaining what actually is
> > problematic.
> 
> lintian used to exit with a non-zero value when it emitted at least
> one error tag. This was changed, for some reason, and then it stopped
> doing that, instead requiring users to specify --fail-on=error. This
> was supposedly reverted, but the patch that got applied that fixed
> this at the time of submission did not apply at the time it got
> committed due to refactoring, and it was ineffective. As such the
> --help output now is misleading, mentioning that the default --fail-on
> is "error" when it is not.

Thanks for that summary, it helped a lot. I'll have a look.

> I'd have to re-dig all this. I might just try to provide a patch, I
> think should probably be a one-liner.

A patch of course would be nice, but I won't mind if you don't provide
one.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#928224: Valgrind is broken on armhf

[Mathieu Malaterre]

% gdb "/usr/libexec/valgrind/memcheck-arm-linux"
GNU gdb (Debian 12.1-2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/libexec/valgrind/memcheck-arm-linux...
Reading symbols from
/usr/lib/debug/.build-id/c8/4acaae37749c83c7183bc7a37bbde299e52e82.debug...
(gdb) r
Starting program: /usr/libexec/valgrind/memcheck-arm-linux

Program received signal SIGILL, Illegal instruction.
vgPlain_am_startup (sp_at_startup=3204445888) at
m_aspacemgr/aspacemgr-linux.c:1626
1626   init_nsegment();
(gdb) bt full
#0  vgPlain_am_startup (sp_at_startup=3204445888) at
m_aspacemgr/aspacemgr-linux.c:1626
seg = {kind = 0, start = 0, end = 0, smode = SmLower, dev = 0,
ino = 0, offset = 5376491600740352, mode = 3204445892, fnIdx =
-1090521408, hasR = 0 '\000', hasW = 160 '\240', hasX = 37 '%',
  hasT = 88 'X', isCH = 248 '\370'}
suggested_clstack_end = 
__PRETTY_FUNCTION__ = "vgPlain_am_startup"
#1  0x580cc5e4 in valgrind_main (envp=0xbefff6cc, argv=0xbefff6c4,
argc=1) at m_main.c:1387
loglevel = 
i = 
vex_archinfo = {hwcaps = 0, endness = 0, hwcache_info =
{num_levels = 0, num_caches = 0, caches = 0x0,
icaches_maintain_coherence = 0 '\000'}, ppc_icache_line_szB = 0,
ppc_dcbz_szB = 0,
  ppc_dcbzl_szB = 0, arm64_dMinLine_lg2_szB = 0,
arm64_iMinLine_lg2_szB = 0, arm64_requires_fallback_LLSC = 0 '\000'}
need_help = 
tid_main = 0
addr2dihandle = 0x0
wd = 
need_help = 
tid_main = 
loglevel = 
i = 
addr2dihandle = 
__PRETTY_FUNCTION__ = "valgrind_main"
vex_archinfo = 
wd = 
tmp_str = 
res = 
val = 
res = 
val = 
s = 
n = 
res = 
val = 
s = 
n = 
val = 
ok = 
errmsg = 
limLo = 
limHi = 
aLocal = 
p = 
cp = 
vex_arch = 
ok = 
buf = 
buf2 = 
fd = 
r = 
nul = 
exename = 
client_auxv = 
client_auxv_len = 
--Type  for more, q to quit, c to continue without paging--
arg = 
s = 
ok = 
seg_starts = 
n_seg_starts = 
anu = 
change_ownership_v_c_OK = 
co_start = 
co_endPlus = 
buf = 
seg_starts = 
n_seg_starts = 
j = 
n = 
seg = 
anl = 
inaccessible_len = 
seg = 
seg = 
#2  _start_in_C_linux (pArgc=0xbefff6c0) at m_main.c:3081
r = 
argc = 1
argv = 0xbefff6c4
envp = 0xbefff6cc
#3  0x in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Bug#1013920: [Pkg-rust-maintainers] Bug#1013920: rust-all: Debian violating Rust Trademark (as serious a situation as "iceweasel")

[lkcl]

everything is "fine" as long as:

1) the Mozilla Foundation acts reasonably and non-discriminatorily (FRAND 
applies to Trademarks just as it applies to patent Licensing)
2) the Mozilla Foundation does not appreciate quite how much power it actually 
has under Trademark Law.

given that this is between Free Software Groups i would expect the discussion 
to remain civil and reasonable, and for them to drop or modify the unachievable 
nonfree constraint, but please for goodness sake do not let the civility of the 
interaction lull you into a sense of false safety.

under the Trademark as they have defined it, the Mozilla Foundation is 
perfectly permitted to issue Debian a Legal Notice to Cease and Desist 
distribution of the Unlawfully patched rustc binaries.

l.




On June 27, 2022 1:07:14 PM GMT+01:00, Sylvestre Ledru  
wrote:
>Hello
>
>I don't think it is a big deal but I will chat with some people on the
>Rust side about this.
>
>Cheers,
>Sylvestre (who managed the iceweasel/firefox thing)
>
>
>Le 27/06/2022 à 13:52, lkcl a écrit :
>> Package: rust-all
>> Severity: serious
>> Tags: upstream
>> Justification: Policy 2.1
>> 
>> https://internals.rust-lang.org/t/rust-s-freedom-flaws/11533
>> https://lists.debian.org/debian-legal/2021/05/msg6.html
>>
>https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/
>> 
>> this is an extremely serious situation that exposes debian to a
>greater
>> level of risk that was undergone for the last Mozilla-Foundation
>> Trademark fiasco, iceweasel
>> 
>> Rust's Trademark requirements are that "you must seek our explicit
>> permission before distributing patches".
>> 
>>  Uses that require explicit approval
>> 
>>  Distributing a **MODIFIED VERSION** of the Rust programming
>language
>>  or the Cargo package manager and calling it Rust or Cargo
>requires
>>  explicit, written permission from the Rust core team.
>> 
>> there are dozens of such patches and every single one of them, unless
>> explicit permission has been sought, is a DIRECT Trademark violation
>> 
>>  https://sources.debian.org/patches/rustc/1.36.0+dfsg1-2/
>> 
>> the over-ride of the Trademark on "Free" software is Lawful and
>> in this case makes rust (and cargo) non-free software.
>> 
>> unlike the Iceweasel debacle, the linux kernel is upstream merging
>> rust, potentially making the entire linux kernel critically dependent
>> on a non-free compiler.
>> 
>> there is the additional issue that although Debian might seek and
>> be granted explicit permission for a Trademark License Grant to
>> Distribute, that does not cover Derivatives, which would also
>> need to explicitly seek their own permission
>> 
>>  https://www.debian.org/derivatives/
>>  https://devuan.org
>> 
>> this has been discussed that DFSG Guideline 8 is violated by even
>> attempting to seek a License specific to Debian
>> 
>> 
>https://www.mail-archive.com/debian-legal@lists.debian.org/msg45464.html
>> 
>> this is an extremely serious situation that either requires pulling
>> rust and cargo from debian or a rename of both rust and cargo exactly
>> as was done with iceweasel.
>> 
>> failure to do so is also extremely serious because Unlawful
>Distribution
>> may still be considered grounds for financial compensation as well as
>> a Legal Notice to Cease and Desist, and also to remove all public and
>private
>> use of the Trademark from all Records.  mailing lists, bugtracker,
>> debian archives - everything.
>> 
>> this one cannot be ignored.
>> 
>> 
>> -- System Information:
>> 
>> ___
>> Pkg-rust-maintainers mailing list
>> pkg-rust-maintain...@alioth-lists.debian.net
>>
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers