date:20230116

SPDX itself might have an answer that is satisfactory:

"The original replaceable text appears on the SPDX License List webpage in red 
text."

"Omittable text appears on the SPDX License List webpage in blue text."

https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/[1]

On Monday, January 16, 2023 11:48:48 PM MST Soren Stoutner wrote:
> There appears to be some question of opinion as to if the Debian MIT (Expat)
> License is the same as the SPDX MIT License.
> 
> https://www.debian.org/legal/licenses/mit[1]
> 
> https://spdx.org/licenses/MIT.html[2]
> 
> Can somebody at Debian Legal please comment?


-- 
Soren Stoutner
so...@stoutner.com


[1] 
https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/


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

Bug#1029055: Debian Expat and SPDX MIT License Text

Hi,

Soren Stoutner wrote:
> There appears to be some question of opinion

Not opinion. Just the point of what the meaning of _text colors_
*rollingeyes* in a license do mean. I just ignored them and then those
two licenses differ.

> as to if the Debian MIT (Expat) License is 
> the same as the SPDX MIT License.
[…]
> Can somebody at Debian Legal please comment?

Yes, thanks! I'd prefer to have a good explanation, too.

Please also note that I didn't mark the bug report as wontfix, just as
moreinfo.

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#1029055: Debian Expat and SPDX MIT License Text

There appears to be some question of opinion as to if the Debian MIT (Expat) 
License is 
the same as the SPDX MIT License.

https://www.debian.org/legal/licenses/mit[1]

https://spdx.org/licenses/MIT.html[2]

Can somebody at Debian Legal please comment?

-- 
Soren Stoutner
so...@stoutner.com


[1] https://www.debian.org/legal/licenses/mit
[2] https://spdx.org/licenses/MIT.html


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

Bug#1029055: MIT License Text

Axel Beckert wrote:
> As mentioned before exactly that exception is the reason why I think
> that these two license texts are not the same. I though see no
> explanation what the meaning of the colors on the SPDX website is.
> Until that is clarified, for me, the two texts clearly differ for me.

And just to state the obvious, this is the wdiff which I made for myself
during our previous discussion in #1002053:

$ dwdiff mit expat
[-MIT License-]

Copyright (c) [- -] {+1998, 1999, 2000 Thai
Open Source Software Center Ltd+}

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice [-(including the
next paragraph)-] shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

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#1029056: [Pkg-deepin-devel] Bug#1029056: papirus-icon-theme: Needs dependency on librsvg2-common

2023-01-16 Thread John Crawley


Thank you for the quick response.

Your argument makes logical sense.

In practice, on a Debian Bullseye system, there are unfortunately many packages 
which fail to declare the needed dependency. I guess in theory it would be 
possible to reverse the logic and ask: why should a file manager know what kind 
of icons it will be asked to display? A hard dependency on an svg rendering 
library makes as little sense at that end. So where should it be declared?

But anyway, until there's some kind of framework to connect providers and 
consumers, a Recommends: from papirus-icon-theme will help, and someone 
assembling a desktop from scratch can add librsvg2-common to the default 
install list.

Best wishes,
John

Bug#1028451: 2nd DisplayPort doesn't get video

2023-01-16 Thread Salvatore Bonaccorso

Hi,

Thanks all who have contributed to the descussion! Much appreciated.

On Mon, Jan 16, 2023 at 03:08:22PM -0700, Sam Hartman wrote:
> > "Moritz" == Moritz Mühlenhoff  writes:
> Moritz> Not moving to 6.1.x (which is most likely the next Linux
> Moritz> kernel LTS) is by far a worse regression since it applies to
> Moritz> every single Debian system.
> 
> Moritz> As a community distro without paid, full time kernel
> Moritz> maintainers we can't just randomly stick to an older kernel
> Moritz> tree and decide to assess/backport hundreds of patches sent
> Moritz> to stable@ every week.
> 
> I think we're all agreed on that point.
> What we can do is delay the release if we have a serious enough bug that
> is not fixed yet.
> I think what people are saying on this bug is that this issue is serious
> enough it should be considered as a release blocker---something that
> could actually delay the release.

I do agree, this is defintively an issue we would not would want to
have in a stable release, so the assessment of marking it RC is
defintively right.

While 6.0.y is now EOL, and 6.1 was aimed to be the LTS release, and
the reason we would like to pick that for bookworm, there was not yet
an official announce for it, in part because of reported regressions,
cf. https://lore.kernel.org/all/y53bputyk+3dj...@kroah.com/ and
https://lore.kernel.org/all/20230114084719.ga6...@1wt.eu/ for some
context.

> From where I sit, thinking about what I've deployed in the last five
> years, I agree with that analysis: this *might* be serious enough to
> delay the release until there is a fix.
> Given that  we can't stick on 6.0, I think we should try to get this
> into testing as soon as possible so we can see how big of an impact it
> is in practice.
> I don't like to see testing broken, but I like to see stable broken in
> serious ways even less.
> And so I'd recommend we see  how badly this is going to hurt us.

I will bite the bullet (taking full responsibility for it if
necessary, don't blame the other kernel team members) and ask here now
the release team: Can we let linux 6.1.4-1 despite the RC bug
reported, migrate to testing, so we can move on to 6.1.y? Let's keep
the bug as RC severity. I'm currently working on uploading as well
6.1.6 or 6.1.7 (depending on the timing) further after that to
unstable.  Unfortuantely there is still not a solution to address
#1028451 but will contain other important fixes (including security
ones).

Thank you for considering it,

Odyx, I feel sorry, this will knowingly impact your and others!

Regards,
Salvatore

Bug#1029055: MIT License Text

Control: tag -1 + moreinfo

Hi,

thanks for the separate bug report.

Soren Stoutner wrote:
> I just noticed that AppStream specifies that their licenses use the text 
> listed by SPDX.
> 
> As the text of the MIT License at https://spdx.org/licenses/MIT.html[1] is 
> the same as the 
> Debian MIT License (Expat) at https://www.debian.org/legal/licenses/mit 
> (except for the 
> instructions in blue),

As mentioned before exactly that exception is the reason why I think
that these two license texts are not the same. I though see no
explanation what the meaning of the colors on the SPDX website is.
Until that is clarified, for me, the two texts clearly differ for me.

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#1029057: llvm-toolchain-15 cannot be built without git

2023-01-16 Thread Jian-Hon Pan

Package: llvm-toolchain-15
Version: 1:15.0.6-4

When I try to build llvm-toolchain-15 by myself, it shows the error:

CMake Warning at cmake/modules/VersionFromVCS.cmake:49 (message):
  Git not found.  Version cannot be determined.
Call Stack (most recent call first):
  CMakeLists.txt:992 (get_source_info)
  
Then, I trace the code [1] and make sure it needs git for build.
I think git should be in the Build-Depends of llvm-toolchain-15, too.

[1]: 
https://github.com/llvm/llvm-project/blob/8dfdcc7b7bf66834a761bd8de445840ef68e4d1a/llvm/cmake/modules/VersionFromVCS.cmake#L7-L50

Jian-Hong Pan

Bug#1029056: [Pkg-deepin-devel] Bug#1029056: papirus-icon-theme: Needs dependency on librsvg2-common

2023-01-16 Thread Boyuan Yang

Hi,

在 2023-01-17星期二的 13:56 +0900，John Crawley写道：
> Package: papirus-icon-theme
> Version: 20210201-1
> Severity: normal
> X-Debbugs-Cc: j...@bunsenlabs.org
> 
> Dear Maintainer,
> 
>     * What led up to the situation?
> On a Debian Bullseye system without librsvg2-common installed, Papirus icons
> were not correctly displayed.
> 
>     * What exactly did you do that was effective?
> Install librsvg2-common.
> 
>     * What was the outcome of this action?
> Icons were correctly displayed.
> 
> ( This might have been the underlying issue in bug #982901 )
> 
> Because it is a dependency of many other packages, librsvg2-common will
> often already be installed, hiding the dependency from papirus-icon-theme.
> 
> gnome-icon-theme depends on, and adwaita-icon-theme recommends librsvg2-
> common.
> As a theme using svg icons, papirus-icon-theme could be expected to depend
> on, or at least recommend, librsvg2-common too.

Logically I very much dislike the idea of adding dependency from an icon theme
to some package that provides the SVG parsing functionality (e.g., librsvg2-
common). Such dependency should be handled by whoever *consumes* SVG icons
(e.g., spacefm), not the package that *provides* SVG icons. Why should an icon
theme package know that some random desktop software will need a "librsvg2-
common" to parse SVG correctly? What if that desktop software actually needs
some other SVG parsing library (e.g., libqt5svg5) ? Why *should* I know that?
This does not make any sense.

Back to actual packaging: I could add a recommendation to librsvg2-common, but
I will definitely not opt to go for a hard dependency. I will make the upload
shortly.

Thanks,
Boyuan Yang


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

Bug#1029056: papirus-icon-theme: Needs dependency on librsvg2-common

2023-01-16 Thread John Crawley


Package: papirus-icon-theme
Version: 20210201-1
Severity: normal
X-Debbugs-Cc: j...@bunsenlabs.org

Dear Maintainer,

   * What led up to the situation?
On a Debian Bullseye system without librsvg2-common installed, Papirus icons 
were not correctly displayed.

   * What exactly did you do that was effective?
Install librsvg2-common.

   * What was the outcome of this action?
Icons were correctly displayed.

( This might have been the underlying issue in bug #982901 )

Because it is a dependency of many other packages, librsvg2-common will often 
already be installed, hiding the dependency from papirus-icon-theme.

gnome-icon-theme depends on, and adwaita-icon-theme recommends librsvg2-common.
As a theme using svg icons, papirus-icon-theme could be expected to depend on, 
or at least recommend, librsvg2-common too.

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
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 papirus-icon-theme depends on:
ii  hicolor-icon-theme  0.17-2

papirus-icon-theme recommends no packages.

Versions of packages papirus-icon-theme suggests:
pn  libreoffice-style-papirus  

-- no debconf information

--
John

Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed

2023-01-16 Thread Vagrant Cascadian

Control: tags 1028343 pending

On 2023-01-11, Karsten Merker wrote:
> On Wed, Jan 11, 2023 at 09:21:42AM -0800 Vagrant Cascadian wrote:
>> Definitely would be good to mention to upstream. Please Cc me if you do!
>
> I've sent the bugreport upstream:
> https://lists.denx.de/pipermail/u-boot/2023-January/504466.html

Thanks, that worked well!

A patch was submitted upstream, and I've tested and committed the patch
to the packaging for Debian, so should be included in the next upload:

  
https://salsa.debian.org/debian/u-boot/-/commit/8ebfba031bc7dad7594669ed00eb8a17c6ed3808
  
https://salsa.debian.org/debian/u-boot/-/commit/f2aad8950a124f011c926445361b90efe76c8dd2


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1029055: MIT License Text

I just noticed that AppStream specifies that their licenses use the text listed 
by SPDX.

As the text of the MIT License at https://spdx.org/licenses/MIT.html[1] is the 
same as the 
Debian MIT License (Expat) at https://www.debian.org/legal/licenses/mit (except 
for the 
instructions in blue), there probably shouldn’t be any question that these are 
simply two 
different names for the same license (for reasons that probably shouldn’t 
surprise me, 
open-source people can’t just get along and agree on a name).

-- 
Soren Stoutner
so...@stoutner.com


[1] https://spdx.org/licenses/MIT.html


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

Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)

I created a new bug report to discuss this issue as the root cause ends up 
being different than what was originally reported here.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029055[1]

-- 
Soren Stoutner
so...@stoutner.com


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029055


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

Bug#1013222: Private headers

2023-01-16 Thread Rodney Dawes

On Mon, 2023-01-16 at 23:35 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Maintaining Qt already takes a lot of time, adding private headers
> only makes things worse. So if you want to do porting and the headers
> are not yet there you will have to build Qt itself or fix the problem
> where it really belongs: upstream.

Upstream? Where it's not a problem, because they ship and install the
private headers?

No, this is an issue in Debian, because the headers are being
specifically excluded from packaging, rather than installed. Other
distributions provide these files without such politics. Why is it so
hard to maintain in Debian? Fedora, OpenSUSE, Arch, etc… all have these
files available for installation and developing against. So, surely the
"maintenance burden" is not so high, right? Debian has britney to run
autopackage tests, specifically to prevent things breaking, no? Those
things still are going to break, when those files aren't provided,
since they can no longer build, no?

There is nothing speculative here. The files are required to build many
things against Qt, regardless of whether it is version 5 or 6.

Leaving the files out, only makes it harder for anyone to rely on
distribution provided packages. These are necessary for shipping KDE
Plasma 6, and many other things, in Debian.

Bug#1029055: lintian: Lintian does not recognize the AppStream's metainfo.xml MIT license is the same as Debian's Expat license

Package: lintian
Version: 2.115.3
Severity: wishlist

Debian has recently started requesting that graphical programs install
AppStream metainfo.xml files.

https://appstream.debian.org/sid/main/issues/electrum.html

The AppStream specification has a very restricted listed of possible licenses
for the metainfo.xml file.

FSFAP

MIT

0BSD

CC0-1.0

CC-BY-3.0

CC-BY-4.0

CC-BY-SA-3.0

CC-BY-SA-4.0

GFDL-1.1

GFDL-1.2

GFDL-1.3

BSL-1.0

FTL

FSFUL

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license

No specific text is given for what they mean by the MIT license. The MIT
license is a bit problematic because there are more than one license that has
been called the MIT license over the years.

https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants

https://www.gnu.org/licenses/license-list.en.html#Expat

When most people say MIT they mean Expat, so it is standard in the industry to
assume that when no specific text is given MIT == Expat.

Debian prefers the Expat name to the MIT name for this reason.

https://www.debian.org/legal/licenses/mit

The documentation for the Debian machine-readable copyright file says the
following.

"There are many versions of the MIT license. Please use Expat instead, when it
matches."

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

The Electrum package, which is licensed upstream as MIT, is listed as Expat in
debian/copyright according to the instructions in the copyright format and
because the upstream MIT license matches exactly the Debian legal Expat example.

Because the AppStream metainfo.xml file does not allow the use of the Expat
name, or it will fail validation with appstreamcli, I licensed the metainfo.xml
file as MIT. This made it easy to submit it upstream, which has already
accepted it for the next release.

In the meantime, I included the metadata.xml file in the debian directory for
the current release. However, Lintian complained that Expat != MIT.

I considered creating a override, but according to the instruction at
https://lintian.debian.org/manual/index.html#overrides it seemed more
appropriate to file a bug against Lintian, as every time there is an AppStream
file with a MIT license this will create a false positive if matched against
Expat.

To work around this, I currently created a duplicate section in
debian/copyright, which doesn't seem like an efficient long-term solution.

https://salsa.debian.org/sorenstoutner/electrum/-/blob/master/debian/copyright

I personally wish that those creating licenses had been more careful about the
naming thereof. Secondarily, I wish that AppStream had followed best practices
and allowed the use of the Expat name. However, given that neither of those
things are within my control, the next best option is to make Lintian smart
enough to work around this specific situation.

This was originally discussed at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002053 but was moved to this
separate bug report because it didn't end up being the same root problem.

Bug#1028649: Segmentation fault invoking bus.get_unique_name()

2023-01-16 Thread Michael Deegan

Package: python3-pystemd
Version: 0.7.0-5+b2
Followup-For: Bug #1028649

FWIW this bug still exists with version 0.11.0 installed via pip.

-MD

-- 
-
Michael Deegan   Hugaholic  https://www.deegan.id.au/
  Jung, zr jbeel?  --

Bug#1013222: Private headers

2023-01-16 Thread Lisandro Damián Nicanor Pérez Meyer

Hi!

El lun, 16 de ene. de 2023 21:59, Rodney Dawes 
escribió:

> On Mon, 2023-01-16 at 21:35 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > Hi
> >
> > Private packages have only been created when required for other Qt
> > submodules or key plasma packages, no more.
>
> They are required for key plasma packages here, as well. It is
> necessary to use these private headers to be able to write plugins to
> Qt itself, such as for providing support for additional wayland
> protocols in Qt, and to provide input method support on Wayland using
> Qt API. I found this issue as I was getting build errors on doing some
> work to port the wayland code in maliit-framework to Qt6.



You will probably need to build qt yourself to do that in the meantime.

>
> > That's because kwin required those headers. As soon as kwin switches
> > to Qt6 we will know if we need to make them available.
>
> If kwin is also using them, then you can be assured they will still be
> needed, as very little has changed in QtWayland in 6.x from 5.x. As I
> have found, they are still needed for the on-screen keyboard support.
>

Then when time comes the packages will be added


> And no, existing private headers are not free, it is a real pain
> > because they normally just make transitions more complicated.
> >
> > Ideally people should work with Qt upstream in order to avoid
> > requiring private headers.
>
> Most of these needs are long standing issues which I'm sure Qt upstream
> is well aware of. Third party style plugins for example is a well known
> case where one must use private API, and it is still the case.
> Migrating things from private to public API is never a simple task, and
> even if we could get it done, it would likely take years to get there.
>



I know, I have been complaining about that for over a decade now. With
upstream :-)

Maintaining Qt already takes a lot of time, adding private headers only
makes things worse. So if you want to do porting and the headers are not
yet there you will have to build Qt itself or fix the problem where it
really belongs: upstream.

Bug#1027844: btrfsmaintenance: noted BTRFS_BALANCE_PERIOD default in /etc/default/btrfsmaintenance is inconsistent w/systemd timer

2023-01-16 Thread andy

hello -

thanks for the feedback...  some comments inline.  i must stress that
while i am a multi-year user of btrfs i do not read the linux-btrfs
mailing list and my opinions should be given appropriate weight.

On Sat, 2023-01-14 at 21:47 -0500, Nicholas D Steeves wrote:
> 
[...]
> Oh yeah!  I had forgotten about this minor issue.  The reason I
> hadn't
> harmonised the files, doing this implicitly says that I (and Debian)
> might recommend weekly balanced, or recommend monthly balances.
> 
> From what I've been able to gather, metadata balances have been
> considered to be actively harmful for some time; This is mostly at
> the
> level of tribal knowledge on the linux-btrfs mailing list.  It's also
> the case that empty block groups are now automatically reclaimed by
> the
> kernel, so a periodic balance only seems to be useful in
> space-constrained situations where a lot of [meta]data churn occurs.

regarding balance recommendations, my initial thought would be to make
the language in the README.Debian stronger.  i had read that "Some
advocate not running it at all" but to me that implies "may be
unnecessary" rather than "may be actively harmful."  on the basis of
the latter i am certainly considering setting the balance.timer back to
disabled.  alternatively/additionally are there default options that
might make it safe(r)?  e.g., Marc MERLIN's `btrfs-scrub`[1] (which i
used previously) suggested that "a null [metadata] rebalance should
help corner cases."

from my pov i'd still like to see the values harmonized.  i originally
noticed the inconsistency because what i believed was the default
setting was creating a seemingly unnecessary systemd override file. 
this became a nagging question to resolve :)  if the (informed) user
has chosen to enable the btrfs-balance.timer then i would say harmonize
the value at "monthly" (1/4 the opportunity for issues).

> Thus, if I do anything, I'm inclined to set the period for balance to
> "none" everywhere.

given that one already needs to manually enable the service via
`systemctl enable btrfs-balance.timer` i don't think it's necessary to
set the default value to "none."  this would result in the (imho)
counter-intuitive behavior of enabling something only to have it do
nothing.  although an add'l comment re: the potential for harm in
`/etc/default/btrfs` that one would hopefully see when changing the
value from "none" to e.g., "monthly" may be the best way to ensure that
they are an informed user.  so i could go either way on that.

> Also, what do you think about enabling the systemd patch watcher, so
> that the timers are updated automatically when
> /etc/default/btrfsmaintenance is modified?

as a sysadmin the steps of modifying a file and then running a command
for it to take effect is a normal part of my workflow.  so i'm fine
leaving it disabled by default.  other users might feel differently.

thank you...

andy

1. https://marc.merlins.org/linux/scripts/btrfs-scrub

-- 
andy 
diatribes

Bug#1029054: starts consuming 100% CPU

2023-01-16 Thread Per Eric Rosén


Package: mate-applets-common
Version: 1.24.1-1
Severity: normal
X-Debbugs-Cc: p...@rosnix.net

battstat-applet installed by default with Mate, on upgraded system.
A couple of times per week, battstat-applet start consuming 100%
of CPU, increasing system load highly.

No obvious connection to, for example, external power changes, and
seemingly not directly after interacting with the app.

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera)
Release:4
Codename:   chimaera
Architecture: x86_64

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages mate-applets-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2

mate-applets-common recommends no packages.

mate-applets-common suggests no packages.

-- no debconf information

Bug#1028503: UDD: Unknown "yes" value for Forwarded field in patch metadata

2023-01-16 Thread Paul Wise

On Sat, 2023-01-14 at 18:41 +0100, Guillem Jover wrote:

> I otherwise do not know how we can mark patches as forwarded when
> for example you send them directly to upstream via email or to a mailing
> list that has no public archive or similar.

Just as you can mark a BTS bug as forwarded to an email address,
presumably you could do something similar for patches? Then people
wanting to know the status could email that address to find out.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#1013222: Private headers

2023-01-16 Thread Rodney Dawes

On Mon, 2023-01-16 at 21:35 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Hi
> 
> Private packages have only been created when required for other Qt
> submodules or key plasma packages, no more.

They are required for key plasma packages here, as well. It is
necessary to use these private headers to be able to write plugins to
Qt itself, such as for providing support for additional wayland
protocols in Qt, and to provide input method support on Wayland using
Qt API. I found this issue as I was getting build errors on doing some
work to port the wayland code in maliit-framework to Qt6.

> 
> That's because kwin required those headers. As soon as kwin switches
> to Qt6 we will know if we need to make them available.

If kwin is also using them, then you can be assured they will still be
needed, as very little has changed in QtWayland in 6.x from 5.x. As I
have found, they are still needed for the on-screen keyboard support.

> And no, existing private headers are not free, it is a real pain
> because they normally just make transitions more complicated.
> 
> Ideally people should work with Qt upstream in order to avoid
> requiring private headers.

Most of these needs are long standing issues which I'm sure Qt upstream
is well aware of. Third party style plugins for example is a well known
case where one must use private API, and it is still the case.
Migrating things from private to public API is never a simple task, and
even if we could get it done, it would likely take years to get there.

Bug#1013222: Private headers

2023-01-16 Thread Lisandro Damián Nicanor Pérez Meyer

Hi

El lun, 16 de ene. de 2023 19:03, Rodney Dawes 
escribió:

> On Mon, 25 Jul 2022 16:29:28 -0300 =?UTF-
> 8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=
>  wrote:
> > Hi!
> >
> > I would really love to know why Telegram developers require so many
> > private headers from Qt. They shouldn't be using them at all, and if
> > they really require some private part they need to work with upstream
> > to make it public API.
>
> This isn't only an issue for Telegram. Many projects require private
> headers for various reasons, because developing plugins to Qt itself is
> necessary to improve the system. The Qt packages have a long history of
> including `-private-dev` packages for the various components which
> provide private API that may be necessary to use in certain situations.
>

Private packages have only been created when required for other Qt
submodules or key plasma packages, no more.

>
> There is no reason for that to stop happening with Qt 6.x.

Qt6 is following the same rule. Believe me, I have been involved in Qt
packaging since Qt4 :-)

Especially
> given the upstream source is installing them during the build. The
> qtwayland5-private-dev package is available in Debian, and so should a
> qt6-wayland-private-dev package be made available containing the
> includes, cmake files, libraries, etc… necessary to use the QtWayland
> private API with Qt6.

That's because kwin required those headers. As soon as kwin switches to Qt6
we will know if we need to make them available.

And no, existing private headers are not free, it is a real pain because
they normally just make transitions more complicated.

Ideally people should work with Qt upstream in order to avoid requiring
private headers.

Bug#1029053: lintian: Should report Vcs-Browser fields pointing to Salsa/Gitlab/Github and ending in .git

Package: lintian
Version: 2.115.4~git
Severity: wishlist

In
https://salsa.debian.org/lintian/lintian/-/merge_requests/390#note_367701
Willian Desportes (X-Debbugs-Cc'ed) suggested to implement the same as
Lintian MR !390 (GitHub and GitLab URLs shouldn't end with .git) also
for Vcs-Browser. With which I agree.

Edward Betts figured out that there are indeed about 1800 packages in
Debian where this tag would be emitted:
https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+Vcs-Browse.*salsa.*git=0

Then again Gitlab (and hence also Salsa) as well as Github do a redirect
to the correct URL if you access these URLs with a browser. So I'd say
at most "Severity: info", maybe even only "Severity: pedantic".

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  clzip [lzip-decompressor]   1.13-4
ii  diffstat1.65-1
ii  dpkg1.21.18
ii  dpkg-dev1.21.18
ii  file1:5.44-2
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
ii  libdigest-sha-perl  6.03-1+b1
ii  libdpkg-perl1.21.18
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lunzip [lzip-decompressor]  1.13-4
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.2-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-4
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xlunzip [lzip-decompressor] 0.7-6
ii  xz-utils5.4.1-0.0

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.40-2
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1029052: black: might want to strengthen the dependency on python3-click to the 8 release in bookworm

2023-01-16 Thread Alban Browaeys

Package: black
Version: 22.12.0-1
Severity: normal

Dear Maintainer,
I ran ansible-lint which depends on black.
It outputted a warning:
WARNING  Ignore loading rule from 
/usr/lib/python3/dist-packages/ansiblelint/rules/jinja.py due to cannot import 
name 'ParameterSource' from 'click.core' 
(/usr/lib/python3/dist-packages/click/core.py)

If I upgrade from python3-lick 7.1.2-1 bullseye to bookworm 8.1.3-2 this 
warning disappear.
 ansible-lint has no direct dependency on python3-click. This dependency is 
pulled via ansible-lint dependency on black.

Cheers,
Alban



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

Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages black depends on:
ii  python33.10.6-1
ii  python3-click  8.1.3-2
ii  python3-mypy-extensions0.4.3-2
ii  python3-pathspec   0.10.1-1
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-platformdirs   2.5.2-1
ii  python3-tomli  1.2.2-2~bpo11+1
ii  python3-typing-extensions  3.7.4.3-1

black recommends no packages.

Versions of packages black suggests:
pn  python-black-doc  

-- no debconf information

Bug#1022787: Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

Hi,

Axel Beckert wrote:
> Aurelien Jarno wrote:
> > Given we got no decision from the MIPS porters before the toolchain
> > freeze, we'll have to live with the executable stack on mips*el for
> > bookworm.
> > 
> > Therefore I believe it's a good idea to disable that tag on mips*el on
> > the lintian side.
> 
> Ok, thanks. Will look into it now.

Fixed in git with this commit, referring to #1025436 and #1022787:

https://salsa.debian.org/lintian/lintian/-/commit/80ec3ca960e73a0717719d1329331f86d387c4ae

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#1028336: adduser: [INTL:nl] Dutch translation for the adduser package

2023-01-16 Thread Frans Spiesschaert

Hi,

Marc Haber schreef op ma 16-01-2023 om 21:26 [+0100]:
> Hi,
> 
> thanks for your work. Can you add a license statement please and update
> the Project-Id-Version?

Sure and done.
Attached is an updated po file

Greetings,
Frans


nl.po.gz
Description: application/gzip

Bug#1029051: ITP: ruby-puppetserver-ca-cli

2023-01-16 Thread Jérôme Charaoui




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

   Package name : ruby-puppetserver-ca-cli
   Version  : 2.3.6
   Upstream author  : Puppet, Inc. 
   URL  : https://github.com/puppetlabs/puppetserver-ca-cli
   License  : Apache-2.0
   Programming Lang : Ruby
   Description  : configuration management system, ca cli library

Puppet is a configuration management system that allows you to define 
the state of your IT infrastructure, then automatically enforces the 
correct state.


This gem provides the functionality behind the Puppet Server CA interactions


Thanks,

-- Jerome

Bug#1028962: isc-dhcp-client: -x option no longer works (looks like apparmor configuration prevents it from having any effect)

2023-01-16 Thread Francesco Poli

Control: tags -1 + unreproducible

On Mon, 16 Jan 2023 14:28:05 +0100 Santiago Ruano Rincón wrote:

[...]
> I am not able to reproduce this with my current setup.

Nor am I! :-o

> I can successfully run dhclient -x and it stops the related process.

I tried again today and now I can also use the "-x" option and the
"ifdown" command, as well, without any unexpected behavior.

That's really awkward.
What's different in my box, with respect to yesterday?!?

There have been other package upgrades, of course, but no one looks
related to AppArmor or to isc-dhcp-client.

There has been a poweroff and a boot (well, actually, two of them, if I
recall correctly), but we are talking about Debian GNU/Linux here, not
about That Other Operating System™ that needs to be rebooted for each
and every little trifle!;-)
Hence I would be a little surprised, if it turned out that the reboot
helped...

What else could have changed the result?

> 
> Anyway, could you please test the attached patch?

Thanks for preparing the patch, but I am not going to test it for the
time being, since I am currently unable to reproduce the bug...

[...]
> > Moreover, even the first strategy (ifdown/ifup) now seems to fail to
> > work perfectly. After issueing the following command:
> > 
> >   # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE
> ...
> 
> Do you see the same apparmor DENIED messages?

Yes, I saw the same AppArmor error message in /var/log/kern.log, when I
tried ifdown yesterday.

Somehow everything seems to work flawlessly today.

Hence, I am tagging this bug report as 'unreproducible' and leaving the
'moreinfo' tag.
If I don't come back with additional information for some time, please
feel free to close the bug report.

And many thanks for your prompt and kind reply!
Bye.:-)

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

pgpOiLCsblQOQ.pgp
Description: PGP signature

Bug#1029050: gcc-snapshot: FTBFS on hurd-i386 (and other archs?)

2023-01-16 Thread Svante Signell

Source: gcc-snapshot
Version: 20230108-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

gcc-snapshot in sid FTBFS on hurd-i386 due to that some patches are not
applied when building gcc-snapshot. After the statement in rules.patch
ifeq ($(single_package),yes)
  debian_patches =
endif
previously defined patches are cleared, causing the build failure, see
below.

debian/ files causing the problem:

debian/rules.defs:
ifneq (,$(findstring gcc-snapshot, $(PKGSOURCE)))
  single_package = yes
  trunk_build = yes

debian/rules.patch:
ifeq ($(single_package),yes)
  debian_patches =
endif

Thanks!

Bug#1028451: 2nd DisplayPort doesn't get video

2023-01-16 Thread Sam Hartman

> "Moritz" == Moritz Mühlenhoff  writes:
Moritz> Not moving to 6.1.x (which is most likely the next Linux
Moritz> kernel LTS) is by far a worse regression since it applies to
Moritz> every single Debian system.

Moritz> As a community distro without paid, full time kernel
Moritz> maintainers we can't just randomly stick to an older kernel
Moritz> tree and decide to assess/backport hundreds of patches sent
Moritz> to stable@ every week.

I think we're all agreed on that point.
What we can do is delay the release if we have a serious enough bug that
is not fixed yet.
I think what people are saying on this bug is that this issue is serious
enough it should be considered as a release blocker---something that
could actually delay the release.

From where I sit, thinking about what I've deployed in the last five
years, I agree with that analysis: this *might* be serious enough to
delay the release until there is a fix.
Given that  we can't stick on 6.0, I think we should try to get this
into testing as soon as possible so we can see how big of an impact it
is in practice.
I don't like to see testing broken, but I like to see stable broken in
serious ways even less.
And so I'd recommend we see  how badly this is going to hurt us.


signature.asc
Description: PGP signature

Bug#1023284: libevent: FTBFS with glibc 2.36

2023-01-16 Thread Nicolas Mora


Hello,

I opened an issue upstream [1] to ask for feedbacks. Azat suggest to 
change the function signature from


void evutil_secure_rng_add_bytes(const char *buf, size_t n);

to:
int evutil_secure_rng_add_bytes(const char *buf, size_t n)

and make evutil_secure_rng_add_bytes to return -1, to make it more 
explicit that the function is no-oped.


I understand and I tend to agree with this suggestion, but I'm wondering 
if this solution is correct for this bug?


The symbol would still be the same, but would the signature change 
introduce problems in the libevent package dependencies and build-deps?


Any thoughts?

/Nicolas

[1] https://github.com/libevent/libevent/issues/1393

Bug#1013222: Private headers

2023-01-16 Thread Rodney Dawes

On Mon, 25 Jul 2022 16:29:28 -0300 =?UTF-
8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=
 wrote:
> Hi!
> 
> I would really love to know why Telegram developers require so many
> private headers from Qt. They shouldn't be using them at all, and if
> they really require some private part they need to work with upstream
> to make it public API.

This isn't only an issue for Telegram. Many projects require private
headers for various reasons, because developing plugins to Qt itself is
necessary to improve the system. The Qt packages have a long history of
including `-private-dev` packages for the various components which
provide private API that may be necessary to use in certain situations.

There is no reason for that to stop happening with Qt 6.x. Especially
given the upstream source is installing them during the build. The
qtwayland5-private-dev package is available in Debian, and so should a
qt6-wayland-private-dev package be made available containing the
includes, cmake files, libraries, etc… necessary to use the QtWayland
private API with Qt6.

Bug#993589: distro-info-data: Please consider shipping default mirror URLs per distro

2023-01-16 Thread stefanor

Hi Johannes (2023.01.16_21:28:53_+)
> I like the idea of distro-info & distro-info-data taking on more
> responsibility, but it probably means we need to redesign the data
> schema. I'm thinking YAML/toml data.
> 
> That in turn means rewriting the distro-info libraries (at least to
> provide a new API for the new data).

To expand on that. I think Debian and Ubuntu have got a little closer in
their release models. Both now have LTS and ELTS (with different
semantics).

If we start including more distros (like Devuan), we should probably try
harder to have the same code for working with all the distros data, and
have it be more configuration-driven. At the moment the Ubuntu and
Debian code in distro-info is quite different.

We'll also probably need a script to generate data in the old CSV
format, for current stable releases.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1022787: Bug#1025436: Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

Hi Aurelien,

your reply is just in time! Because about five minutes ago, I started
to continue working on Lintian for this evening. The plan: Making the
long overdue upload as I fixed the last part of arm64 autopkgtest
failures last night. :-)

Aurelien Jarno wrote:
> Given we got no decision from the MIPS porters before the toolchain
> freeze, we'll have to live with the executable stack on mips*el for
> bookworm.
> 
> Therefore I believe it's a good idea to disable that tag on mips*el on
> the lintian side.

Ok, thanks. Will look into it 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#1029049: vim: please backport patch 9.0.1080

2023-01-16 Thread Andrea Pappacoda

Source: vim
Version: 2:9.0.1000
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, could you please consider backporting patch 9.0.1080? It is needed to fix
the keyprotocol option on the foot terminal, according to this upstream bug
report: https://github.com/vim/vim/issues/11781

Thank you!


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCY8XEXRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p4VHAQDZd1dcTYGJqznuA/yr06TlCBxKvQDc
mBryv33hDyJ0OgEAwopHjy9lTATjeR1Pw3IrEUXwKsQZPuignkxI+aaQigc=
=lowV
-END PGP SIGNATURE-
>From afa3f1cc7258d34c32a299a3cc6aece89f67fb47 Mon Sep 17 00:00:00 2001
From: Bram Moolenaar 
Date: Mon, 19 Dec 2022 18:56:48 +
Subject: [PATCH] patch 9.0.1080: the "kitty" terminfo entry is not widespread

Problem:The "kitty" terminfo entry is not widespread, resulting in the
kitty terminal not working properly.
Solution:   Go back to using "xterm-kitty" and avoid the problems it causes in
another way.
---
 runtime/doc/term.txt | 11 +++---
 src/os_unix.c|  5 -
 src/term.c   | 51 +---
 src/version.c|  2 ++
 4 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt
index 50ba187ab969..146ef478fe53 100644
--- a/runtime/doc/term.txt
+++ b/runtime/doc/term.txt
@@ -306,9 +306,14 @@ One of the problems is that the value for $TERM is set to 
"xterm-kitty".  For
 Vim this is an indication that the terminal is xterm-compatible and the
 builtin xterm termcap entries should be used.  Many other terminals depend on
 this.  However, Kitty is not fully xterm compatible.  The author suggested to
-ignore the "xterm-" prefix and use the terminfo entry anyway, but that
-conflicts with what is needed for other terminals.  Therefore Vim removes the
-"xterm-" prefix from "xterm-kitty" when it comes from $TERM.
+ignore the "xterm-" prefix and use the terminfo entry anyway, so that is what
+happens now, the builtin xterm termcap entries are not used.  However, the
+t_RV is set, otherwise other things would not work, such as automatically
+setting 'ttymouse' to "sgr".
+
+It is not clear why kitty sets $TERM to "xterm-kitty", the terminal isn't
+really xterm compatible.  "kitty" would be more appropriate, but a terminfo
+entry with that name is not widespread.
 
 Note that using the kitty keyboard protocol is a separate feature, see
 |kitty-keyboard-protocol|.
diff --git a/src/os_unix.c b/src/os_unix.c
index bd75ccae1403..9d8d466507ca 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -2353,6 +2353,8 @@ mch_restore_title(int which)
 /*
  * Return TRUE if "name" looks like some xterm name.
  * This matches "xterm.*", thus "xterm-256color", "xterm-kitty", etc.
+ * Do not consider "xterm-kitty" an xterm, it is not fully xterm compatible,
+ * using the "xterm-kitty" terminfo entry should work better.
  * Seiichi Sato mentioned that "mlterm" works like xterm.
  */
 int
@@ -2360,7 +2362,8 @@ vim_is_xterm(char_u *name)
 {
 if (name == NULL)
return FALSE;
-return (STRNICMP(name, "xterm", 5) == 0
+return ((STRNICMP(name, "xterm", 5) == 0
+&& STRNICMP(name, "xterm-kitty", 11) != 0)
|| STRNICMP(name, "nxterm", 6) == 0
|| STRNICMP(name, "kterm", 5) == 0
|| STRNICMP(name, "mlterm", 6) == 0
diff --git a/src/term.c b/src/term.c
index 7a70af450ca3..cd6b3b9cf62b 100644
--- a/src/term.c
+++ b/src/term.c
@@ -1675,6 +1675,12 @@ static char *(key_names[]) =
 #endif
 
 #ifdef HAVE_TGETENT
+/*
+ * Get the termcap entries we need with tgetstr(), tgetflag() and tgetnum().
+ * "invoke_tgetent()" must have been called before.
+ * If "*height" or "*width" are not zero then use the "li" and "col" entries to
+ * get their value.
+ */
 static void
 get_term_entries(int *height, int *width)
 {
@@ -2033,14 +2039,6 @@ set_termname(char_u *term)
 #endif
parse_builtin_tcap(term);
 
-   // Use the 'keyprotocol' option to adjust the t_TE and t_TI
-   // termcap entries if there is an entry maching "term".
-   keyprot_T kpc = match_keyprotocol(term);
-   if (kpc == KEYPROTOCOL_KITTY)
-   apply_builtin_tcap(term, builtin_kitty, TRUE);
-   else if (kpc == KEYPROTOCOL_MOK2)
-   apply_builtin_tcap(term, builtin_mok2, TRUE);
-
 #ifdef FEAT_GUI
if (term_is_gui(term))

Bug#1028452: unblock: golang-1.19/1.19.5-1

Am Thu, Jan 12, 2023 at 09:17:18PM +0100 schrieb Paul Gevers:
> On 12-01-2023 16:50, Shengjing Zhu wrote:
> > > But this bug report triggered me: did the golang security situation
> > > already improved during this release cycle. I may be misremembering, but
> > > I recall the problems on the security archive side haven't been fixed,
> > > have they?
> > 
> > For some reference, I did several security updates for golang-1.15 for
> > bullseye, but we didn't rebuild other packages. These security updates
> > are not urgent enough anyway.
> > And others also update some Go packages for bullseye. In general, we
> > just do the usual update for stable release.
> > 
> > As for the security archive, IIRC, for bullseye, the security team did
> >   need to ask ftp-master to copy some individual packages manually. I'm
> > not sure how it is going now. But given the low update frequency I
> > overseved for bullseye, probably that works.
> 
> Do you agree with this view for bookworm? I know you want the situation
> improved, but as far as I am aware nobody (from either side) has been
> pushing this forward so it feels a bit late to make this blocking.

I agree with what Shengjing wrote.

The situation around Go isn't great, but it's pretty much identical to
what we had in past releases, so no specific concerns there. Let's simply
carry over the existing entry from the release notes.

The biggest blocker to fixing this on the toolchain level (like e.g. a
script which programatically detects dependencies in need of rebuilds
and issues binNMUs) is still the split ftp.d.o/security.d.o, which
prevents binNMUs and causes a lot of churn with Built-Using whenever
a Go-based program is updated.

One possible solution discussed was to import all of each stable distro
into security.debian.org, but that disk space demand would mean to
move security-master to baremetal (it's currently a Ganeti VM). I don't
think there has ever been a solution/outcome so far TTBOMK.

Cheers,
Moritz

Bug#1029048: torsocks: Consider update Debian Package with latest upstream commits on master branch

2023-01-16 Thread Clément Hermann

Package: torsocks
Version: 2.3.0-3
Severity: wishlist

Hi,

upstream has some interesting commits in the Master branch (but no
release).

Notably, it seems now to handle syscall passthrough instead of dropping
them with a warning. We might want that in Bookworm (but this need to
happen soon).

https://gitweb.torproject.org/torsocks.git/commit/?id=67cee6c7976b4e103e6f9c3a70e767ffe54368e0

Thanks Unit193 for pointing that out!

Cheers,

--
nodens

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

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 torsocks depends on:
ii  libc6  2.36-7

Versions of packages torsocks recommends:
ii  tor  0.4.7.12-1

torsocks suggests no packages.

-- no debconf information

Bug#1029047: software-properties-qt: software-property-qt should depends on lazr

2023-01-16 Thread Vincent-Xavier JUMEL

Package: software-properties-qt
Version: 0.99.30-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When launching software-properties-qt, I get the following message :

❯ /usr/bin/software-properties-qt
Traceback (most recent call last):
  File "/usr/bin/software-properties-qt", line 36, in 
from softwareproperties.qt.SoftwarePropertiesQt import SoftwarePropertiesQt
  File 
"/usr/lib/python3/dist-packages/softwareproperties/qt/SoftwarePropertiesQt.py", 
line 45, in 
from softwareproperties.SoftwareProperties import SoftwareProperties
  File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
62, in 
from softwareproperties.shortcuts import shortcut_handler
  File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line 
23, in 
from softwareproperties.ppa import PPAShortcutHandler
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 25, in 

from lazr.restfulclient.errors import (NotFound, BadRequest, Unauthorized)
ModuleNotFoundError: No module named 'lazr'

The package should include a runtime depends on python3-lazr.uri.

Thanks,

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

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

Versions of packages software-properties-qt depends on:
ii  debconf-kde-helper   1.1.0-1
ii  python3  3.11.1-1
ii  python3-pyqt55.15.7+dfsg-3+b3
ii  python3-software-properties  0.99.30-3
ii  software-properties-common   0.99.30-3

software-properties-qt recommends no packages.

Versions of packages software-properties-qt suggests:
ii  plasma-discover  5.26.5-2

-- no debconf information

-- 
Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net

Société Libre, Logiciel Libre http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org

Bug#1028451: 2nd DisplayPort doesn't get video

Am Mon, Jan 16, 2023 at 12:46:37PM + schrieb Didier 'OdyX' Raboud:
> > I understand that would be annoying for you, but I don't think that it would
> > affect the majority of our users.
> 
> Hrm. More and more laptops come with usb-c only, and dongles/docks become more
> and more common.
> 
> It's clearly a serious regression, as such setups "just worked" with 6.0.

Not moving to 6.1.x (which is most likely the next Linux kernel LTS) is by far
a worse regression since it applies to every single Debian system.

As a community distro without paid, full time kernel maintainers we can't
just randomly stick to an older kernel tree and decide to assess/backport
hundreds of patches sent to stable@ every week.

Cheers,
Moritz

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

2023-01-16 Thread Aurelien Jarno

Hi,

On 2023-01-16 13:26, Guillem Jover wrote:
> Hi!
> 
> On Mon, 2023-01-16 at 12:47:23 +0100, Axel Beckert wrote:
> > Aurelien Jarno wrote:
> > > On 2022-10-26 22:09, Aurelien Jarno wrote:
> > > > Note that the other official architecture still have a kernel
> > > > compatibility set to 3.2, so that will make a difference between
> > > > architectures. There are discussions to increase it upstream, but this
> > > > won't happened for bookworm. 
> > > > 
> > > > On 2022-10-25 21:07, Simon McVittie wrote:
> > > > > Or, if the mips porters consider this backwards compatibility to be
> > > > > more important than the security hardening of a non-executable stack,
> > > > > then Lintian should stop issuing warnings about the executable stack 
> > > > > on
> > > > > mips*el to improve its signal/noise ratio.
> > > > 
> > > > At this stage there is nothing that can be done on the glibc side, the
> > > > decision has to be taken by the mips porters.
> > > 
> > > We are getting very close to the toolchain freeze. Any decision about
> > > that?
> > 
> > JFYI: There is the request to disable this tag completely on MIPS
> > architectures in https://bugs.debian.org/1025436
> > 
> > Now I wonder if this would actually help or worsen the situation for
> > the glibc maintainers.
> > 
> > Guillem: You wrote something about "bullseye" in #1025436. I think you
> > meant "bookworm" instead. Am I right?
> 
> Indeed, sorry, I was going by Aurelien's comment, but botched the
> release name. :) But in any case, I'll defer to whatever take Aurelien
> or other glibc maintainers have on this.

Given we got no decision from the MIPS porters before the toolchain
freeze, we'll have to live with the executable stack on mips*el for
bookworm.

Therefore I believe it's a good idea to disable that tag on mips*el on
the lintian side.

Cheers
Aurelien

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

Bug#1029046: Wayland session doesn't get back to life post-suspend

2023-01-16 Thread Didier 'OdyX' Raboud

Package: linux-image-6.1.0-1-amd64
Version: 6.1.4-1
Severity: important

Hello there,

this is a regression from 6.0.0 too; after post-suspend wakeup, my
plasma wayland session stays frozen; the two DisplayPort screens light
up, backgrounds are shown, but the mouse doesn't move, nothing works.

I'm reportbug'ging this from a SysRQ-R, Ctrl-Alt-F2 text tty.

>From cursory dmesg reading, it seems amdgpu has an "IB test failed"
_before_ kernel suspend.

This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't
light up", so feel free to close the bug; I'll test if I get the same
symptoms on an unpatched kernel anyway :-)

Best,

OdyX


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

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

Versions of packages linux-image-6.1.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-1-amd64 recommends:
ii  apparmor 3.0.8-1
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-efi-amd64  2.06-7
pn  linux-doc-6.1

Bug#993589: distro-info-data: Please consider shipping default mirror URLs per distro

2023-01-16 Thread Stefano Rivera

Hi Johannes (2021.09.03_09:09:02_-0400)
> we currently carry Debian mirror URLs in many different packages. It
> would be great if there could be one package that shipped a machine
> readable list of the currently correct mirror URLs for each distro.

I've put some thought into this bug (and similar ones) over the years.

I like the idea of distro-info & distro-info-data taking on more
responsibility, but it probably means we need to redesign the data
schema. I'm thinking YAML/toml data.

That in turn means rewriting the distro-info libraries (at least to
provide a new API for the new data).

I'd be tempted to write the canonical implementation in rust and have
bindings in Perl/Python/C. But we could also have completely separate
implementations as we do right now.

So, basically, from my PoV, the reason this bug has languished is
because these are big changes and I haven't felt the urge to start on
them. If somebody were to propose a data model, I'd be happy to review
it and discuss next steps.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1028423: RFS: spek/0.8.5-1 [ITP] [RC] -- acoustic spectrum analyser

2023-01-16 Thread Matteo Bini

Hi Bastian,
thank you for your precious help.

I think I've fixed everything, I just don't know what do you mean with
> Please drop debian/autoreconf.*.
There is no file named autoreconf.*. inside the debian dir.
What exactly should I do?

You can download the DFSG package with dget:
dget -x https://mentors.debian.net/debian/pool/main/s/spek/spek_0.8.5+dfsg-1.dsc

Please, I think we can make it! I'm trying to be as fast as possible.
Forgive my ignorance: many things are new to me.
Have a good night.

--
Matteo Bini

Bug#747303: openssh-server: Please move pam_selinux open call higher in the session PAM stack

2023-01-16 Thread Christian Göttsche

control: user selinux-de...@lists.alioth.debian.org
control: usertag -1 selinux

Hi,

an improved patch, which also reorders pam_motd, can be found at
https://salsa.debian.org/ssh-team/openssh/-/merge_requests/20.

Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t


Hi Axel,

On 15-01-2023 23:07, Axel Beckert wrote:

TL;DR:


[...]

You're awesome. And indeed, what a shame of your time.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029045: ledgersmb: login page Perl error in default config

2023-01-16 Thread JB


Package: ledgersmb
Version: 1.6.9+ds-2+deb11u3
Severity: important
X-Debbugs-Cc: j-dbug.666.114.1...@x.firehead.org

Dear Maintainer,

I installed LedgerSMB with defaults on Debian-11 with systemd.  It 
starts fine

with Starman, but when I go to http://localhost:5762/login.pl it shows only
this message:

-
Error!

Can't locate object method "new" via package "Template" at 
/usr/share/ledgersmb/bin/../lib/LedgerSMB/Template.pm line 599.


dbversion: , company: 1.6.9
-

Thus leaving the package in an unusable state.


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-20-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ledgersmb depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.77
ii  dpkg  1.20.12
ii  libcarp-always-perl   0.16-1
ii  libcgi-emulate-psgi-perl  0.23-1
ii  libcgi-simple-perl    1.115-2
ii  libclass-c3-xs-perl   0.15-1+b1
ii  libconfig-inifiles-perl   3.03-1
ii  libdata-uuid-perl 1.226-1+b1
ii  libdatetime-format-strptime-perl  1.7800-1
ii  libdatetime-perl  2:1.54-1
ii  libdbd-pg-perl    3.14.2-1+b1
ii  libdbi-perl   1.643-3+b1
ii  libhtml-escape-perl   1.10-1+b3
ii  libhttp-exception-perl    0.04007-1
ii  libio-stringy-perl    2.111-3
ii  libjs-dojo-dijit  1.15.4+dfsg1-1+deb11u1
ii  libjson-perl  4.03000-1
ii  liblocale-codes-perl  3.66-1
ii  liblocale-maketext-lexicon-perl   1.00-1.1
ii  liblog-log4perl-perl  1.54-1
ii  libmime-lite-perl 3.031-1
ii  libmime-types-perl    2.18-1
ii  libmoose-perl 2.2014-2
ii  libmoosex-nonmoose-perl   0.26-1.1
ii  libnamespace-autoclean-perl   0.29-1
ii  libnumber-format-perl 1.75-1.1
ii  libpgobject-perl  2.2.0-1
ii  libpgobject-simple-perl   3.02-1.1
ii  libpgobject-simple-role-perl  2.02-1.1
ii  libpgobject-type-bigfloat-perl    2.001-1
ii  libpgobject-type-bytestring-perl  1.2.3-1
ii  libpgobject-type-datetime-perl    2.02-1
ii  libpgobject-util-dbadmin-perl 1.4.0-1
ii  libpgobject-util-dbmethod-perl    1.00.003-1
ii  libplack-builder-conditionals-perl    0.05-1.1
ii  libplack-middleware-reverseproxy-perl 0.16-1
ii  libplack-perl 1.0048-1
ii  libplack-request-withencoding-perl    0.14-1
ii  libtemplate-perl  2.27-1+b3
ii  libtext-markdown-perl 1.31-3
ii  libtry-tiny-perl  0.30-1
ii  libversion-compare-perl   0.14-1.1
ii  libxml-simple-perl    2.25-1
ii  perl  5.32.1-4+deb11u2
ii  postgresql-client 13+225
ii  postgresql-client-13 [postgresql-client]  13.9-0+deb11u1
ii  postgresql-contrib    13+225
ii  starman   0.4015-1
ii  ucf   3.0043

Versions of packages ledgersmb recommends:
pn  libjson-xs-perl    
pn  liblatex-driver-perl   
pn  libmath-bigint-gmp-perl    
pn  libtemplate-plugin-latex-perl  
pn  libtex-encode-perl 
ii  lighttpd   1.4.59-1+deb11u2
pn  texlive-latex-recommended  

Versions of packages ledgersmb suggests:
pn  default-mta | mail-transport-agent  
pn  latex-cjk-all   
pn  libimage-size-perl  
pn  libopenoffice-oodoc-perl    
pn  libx12-parser-perl  
pn  lpr 
ii  postgresql  13+225
pn  texlive-xetex   

-- debconf information:
* ledgersmb/lsmb_proxy: Lighttpd
* ledgersmb/admin_login: lsmb_dbadmin

Bug#1004226: autopkgtest: qemu only boots qcow2 images


Control: tags -1 pending

On Sat, 22 Jan 2022 19:35:49 -0800 Ryan Tandy  wrote:
I'm attaching a patch to use format=qcow2 for the overlay image. Please 
let me know if you'd prefer a Salsa merge request instead.


Thanks. Pushed to salsa.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#984229: mccs: diff for NMU version 1:1.1-9.1

2023-01-16 Thread Ralf Treinen

Hi Adrien,

On Mon, Jan 16, 2023 at 07:34:53PM +0200, Adrian Bunk wrote:

> I've prepared an NMU for mccs (versioned as 1:1.1-9.1) and uploaded
> it to DELAYED/14. Please feel free to tell me if I should cancel it.

thanks a lot, I just uploaded version 1.1-10, which includes your patch,
to unstable.

Cheers -Ralf.

Bug#1028336: adduser: [INTL:nl] Dutch translation for the adduser package

2023-01-16 Thread Marc Haber

Hi,

thanks for your work. Can you add a license statement please and update
the Project-Id-Version?

Greetings
Marc

On Mon, Jan 09, 2023 at 05:54:07PM +0100, Frans Spiesschaert wrote:
> Please find attached the updated Dutch po file for the adduser package. 
> A draft was posted a few weeks ago to the debian-l10n-dutch mailing list
> asking for review. 
> Please add it to your next package revision. 
> It should be put as "po/nl.po" in your package build tree. 
> 
> 
> -- 
> Kind regards,
> Frans Spiesschaert
> 



-- 
-
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#1029044: gcc-12-cross-mipsen: source and binary version go out of sync

Source: gcc-12-cross-mipsen
Version: 1+c2
Severity: serious

Dear maintainer,

The current version in unstable is stuck, because the mips64el build
is kept in Uploaded state. Asking around on #d-buildd, I got the
following discussion:

[20:09:34]  mips64el 3days in uploaded state feels like an issue, 
right? https://buildd.debian.org/status/package.php?p=gcc-12-cross-mipsen
[20:18:32]  probably means dak rejected it
[20:18:45]  Your upload included the binary package 
cpp-12-mips-linux-gnu, version 12.2.0-13cross1, for mips64el,
[20:18:48]  however unstable already has version 12.2.0-14cross2.
[20:19:09]  
coccia:/srv/ftp-master.debian.org/queue/reject/gcc-12-cross-mipsen_3+c1_mips64el-buildd.changes.reason
[20:29:57]  the higher version is
[20:29:57]  Source: gcc-12-cross-mipsen (2+c1)
[20:30:23]  so the generated version numbers are broken
[20:32:07]  not for the first time afair
[[21:04:30]  adsb: thanks for looking; but the source is 3+c1, no? or 
did the older one generate a newer binary?

You may want to check your logic.

Paul

Bug#1029043: AttributeError: module 'adonthell' has no attribute 'audio_load_wave'

2023-01-16 Thread Davide Prina

Package: adonthell
Version: 0.3.8-2.1
Severity: normal
X-Debbugs-Cc: davide.pr...@null.net


Dear Mainteiner,

I have installed the adonthell package, but if I try to execute it I
get:

$ adonthell-wastesedge
Traceback (most recent call last):
  File "/usr/share/games/adonthell/games/wastesedge/scripts/init.py", line 234, 
in 
adonthell.audio_load_wave (0, "audio/select.wav")
^
AttributeError: module 'adonthell' has no attribute 'audio_load_wave'
exec_file: init load failed:

I don't know Python language... I have done some search and found that
adonthell.audio_load_wave do not exists but exists adonthell.audio.load_wave

I have see that there are a lot similar problems in the init.py file and
not only this one.

Ciao
Davide

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

Kernel: Linux 6.0.12-dp-20221218 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 adonthell depends on:
ii  libc62.36-8
ii  libgcc-s112.2.0-13
ii  libpython3.113.11.1-2
ii  libsdl2-2.0-02.26.2+dfsg-1
ii  libsdl2-mixer-2.0-0  2.6.2+dfsg-2
ii  libsdl2-ttf-2.0-02.20.1+dfsg-2
ii  libstdc++6   12.2.0-13
ii  python3  3.10.6-3+b1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages adonthell recommends:
ii  adonthell-data  0.3.8-1

adonthell suggests no packages.

-- no debconf information

Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)

Hi Soren,

Soren Stoutner wrote:
> On Sunday, January 15, 2023 5:17:10 PM MST Axel Beckert wrote:
> > > Debian, of course, prefers the Expat name as it is more precise.
> > 
> > According to
> > https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_a
> > nd_SPDX SPDX does not have the Expat license. They do have though the "MIT
> > License" (the one and only ;-), so that would imply that they're not the
> > same license.
> 
> Anyone who tells you there is a One And Only MIT License is trolling you.  ;)

Seems as if I should used more smileys on that sentence. Consider
having been trolled by myself. ;-)

> https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants

Or said otherwise: I read exactly that page (and
https://www.gnu.org/licenses/license-list.en.html#Expat) before
sending my reply.

> "The name 'MIT License' is potentially ambiguous.

Yes, but IMHO https://spdx.org/licenses/ managed to get quite a good
list on all the variants including unamigous short names for them.
Except that they miss the "Expat license".

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#1029042: jenkins-job-builder: flaky autopkgtest (host dependent)


Source: jenkins-job-builder
Version: 3.11.0-4
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails on amd64. The failures seem related on the host 
that runs the test. ci-worker13 is a beefy machine [1], while the other 
amd64 workers are much more moderate [2].


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.

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

Paul

[1] https://metal.equinix.com/product/servers/m3-large/
[2] https://aws.amazon.com/ec2/instance-types/m5/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029041: O: gftp -- X/GTK+ and console FTP client (metapackage)

2023-01-16 Thread Andreas Rönnquist



Package: wnpp
Severity: normal
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gftp

I intend to orphan the gftp package. It looked like upstream would
migrate to gtk3 and was a bit active, but since then the activity seems
to have died off. For users using this, filezilla seems like a
reasonable replacement. (Which I too have migrated to).



The package description is:
 gFTP is a multithreaded FTP client, available in two versions:
  * version for X, written using GLib and GTK+
  * version for the console, using only GLib
 .
 This is an upgrade convenience package, it's only useful for depending on.

Bug#1028964: noweb: Want to use documentclass scrbook instead of book

2023-01-16 Thread Mechtilde Stehmann


Hello Hubert,

then I will prepare it for an upload.
What is your preferred way?
Should I do it as anew revision and register my name into debian/control?
Or should I do it as NMU?

Kind regards

'Mechtilde


Am 16.01.23 um 03:57 schrieb Hubert Chathi:

On Sun, 15 Jan 2023 12:47:04 +0100, Mechtilde Stehmann  
said:


At upstream there is an additional line, so there it is line 16.



I also filled a patch. You can find a patch under
https://github.com/nrnrnr/noweb/pull/28/files


Most of the changes look pretty straightforward, but why did you remove
the "\def\nwgitversion{|GITVERSION|}" line?

(Also, I'd recommend that you give your PR a more descriptive name)

Bug#1029040: 389-ds-base: systemd unit file not restarting ldap server after segfault

2023-01-16 Thread laforge

Package: 389-ds-base
Version: 1.4.4.11-2
Severity: normal

Dear Maintainer,

I recently noticed that the systemd unit file distributed with this
package does not specify any Restart= policy.  According to the systemd
documentation, this means the implicit default of Restart=no is used.

This is rather sad, as any bug in the server (such as one that leads to
its segfault) will render the service disabled without recovering
automatically.

I've recently ran into that situation:

Jan 16 16:17:07 REDACTED ns-slapd[166]: [16/Jan/2023:16:17:07.675187250 +] 
- NOTICE - bdb_db_compact_one_db - compactdb: compact userRoot - 1 pages freed
Jan 16 16:17:07 REDACTED systemd[1]: dirsrv@ldap.service: Main process exited, 
code=killed, status=11/SEGV
Jan 16 16:17:07 REDACTED systemd[1]: dirsrv@ldap.service: Failed with result 
'signal'.
Jan 16 16:17:07 REDACTED systemd[1]: dirsrv@ldap.service: Consumed 3h 5min 
10.445s CPU time.

Now of course in an ideal world processed would never segfault.
However, that's besides the point.  A vital service like LDAP should
attempt to recover/respawn after it crashes for whatever reason.

So I would like to suggest that a "Restart=always" line is added to the
dirsrv@.service file.

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages 389-ds-base depends on:
ii  389-ds-base-libs 1.4.4.11-2
ii  acl  2.2.53-10
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.77
ii  ldap-utils   2.4.57+dfsg-3+deb11u1
ii  libc62.31-13+deb11u5
ii  libcrypt11:4.4.18-4
ii  libdb5.3 5.3.28+dfsg1-0.8
ii  libicu67 67.1-7
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  libmozilla-ldap-perl 1.5.3-3+b2
ii  libnetaddr-ip-perl   4.079+dfsg-1+b5
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1+deb11u2
ii  libpam0g 1.4.0-9+deb11u1
ii  libsasl2-2   2.1.27+dfsg-2.1+deb11u1
ii  libsasl2-modules-gssapi-mit  2.1.27+dfsg-2.1+deb11u1
ii  libsnmp405.9+dfsg-4+deb11u1
ii  libsocket-getaddrinfo-perl   0.22-3
ii  libsystemd0  247.3-7+deb11u1
ii  perl 5.32.1-4+deb11u2
ii  python3  3.9.2-3
ii  python3-lib389   1.4.4.11-2
ii  python3-selinux  3.1-3
ii  python3-semanage 3.1-1+b2
ii  python3-sepolicy 3.1-1
ii  systemd  247.3-7+deb11u1

389-ds-base recommends no packages.

389-ds-base suggests no packages.

-- Configuration Files:
/etc/dirsrv/config/certmap.conf [Errno 13] Permission denied: 
'/etc/dirsrv/config/certmap.conf'
/etc/dirsrv/config/ldap-agent.conf [Errno 13] Permission denied: 
'/etc/dirsrv/config/ldap-agent.conf'
/etc/dirsrv/config/slapd-collations.conf [Errno 13] Permission denied: 
'/etc/dirsrv/config/slapd-collations.conf'
/etc/dirsrv/config/template-initconfig [Errno 13] Permission denied: 
'/etc/dirsrv/config/template-initconfig'
/etc/dirsrv/schema/99user.ldif [Errno 13] Permission denied: 
'/etc/dirsrv/schema/99user.ldif'

-- no debconf information

Bug#1029039: shiro: CVE-2023-22602

Source: shiro
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for shiro.

CVE-2023-22602[0]:
| When using Apache Shiro before 1.11.0 together with Spring Boot 2.6+,
| a specially crafted HTTP request may cause an authentication bypass.
| The authentication bypass occurs when Shiro and Spring Boot are using
| different pattern-matching techniques. Both Shiro and Spring Boot 
| 2.6 default to Ant style pattern matching. Mitigation: Update to
| Apache Shiro 1.11.0, or set the following Spring Boot configuration
| value: `spring.mvc.pathmatch.matching-strategy = ant_path_matcher`

https://lists.apache.org/thread/dzj0k2smpzzgj6g666hrbrgsrlf9yhkl

Given that we don't include Spring Boot in Debian, this has little
impact. I doubt mixing Shiro as packaged in Debian with an externally
deployed Spring Boot is any realistic scenario...

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-22602
https://www.cve.org/CVERecord?id=CVE-2023-22602

Please adjust the affected versions in the BTS as needed.

Bug#1029037: radare2: CVE-2023-0302

Source: radare2
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for radare2.

CVE-2023-0302[0]:
| Failure to Sanitize Special Elements into a Different Plane (Special
| Element Injection) in GitHub repository radareorg/radare2 prior to
| 5.8.2.

https://huntr.dev/bounties/583133af-7ae6-4a21-beef-a4b0182cf82e/
https://github.com/radareorg/radare2/commit/961f0e723903011d4f54c2396e44efa91fcc74ce


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-0302
https://www.cve.org/CVERecord?id=CVE-2023-0302

Please adjust the affected versions in the BTS as needed.

Bug#1029038: zip4j: CVE-2023-22899

Source: zip4j
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for zip4j.

CVE-2023-22899[0]:
| Zip4j through 2.11.2, as used in Threema and other products, does not
| always check the MAC when decrypting a ZIP archive.

https://github.com/srikanth-lingala/zip4j/issues/485
https://github.com/srikanth-lingala/zip4j/commit/597b31afb473a40e8252de5b5def1876bab198d3


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-22899
https://www.cve.org/CVERecord?id=CVE-2023-22899

Please adjust the affected versions in the BTS as needed.

Bug#1025274: Bug#819332: License question about sf2 soundfont in Tuxguitar

2023-01-16 Thread tony mancill

On Mon, Jan 16, 2023 at 08:33:07AM -0800, tony mancill wrote:
> On Sun, Jan 15, 2023 at 10:02:55PM +0100, Helmar Gerloni wrote:
> > > https://lists.debian.org/debian-legal/2023/01/msg5.html
> > > https://lists.debian.org/debian-mentors/2023/01/msg00097.html
> > Roberto, Tobias, thanks for your answers.
> > 
> > I have removed MagicSFver2.sf2 from the package and added a note to 
> > README.Debian.
> > The new package now depends on fluid-soundfont-gm, see
> > https://mentors.debian.net/package/tuxguitar/
> > 
> > The package builds and runs on amd64 and in Qemu for arm64. It looks pretty 
> > good to me now.
> > Maybe someone can take a look and upload it?
> > If there is anything more I can do, just let me know.
> 
> Hello Helmar,
> 
> I am reviewing the updated package now and will either sponsor an upload
> if everything looks good or provide feedback.

The update looks great!  I have updated debian/copyright to document
the files that are licensed under a license other than the LGPL, but
otherwise everything looks good.  I will upload today.

For the time-being, I will push the updated sources and tag to the
current java-team repo [1], but we may want adjust that before the
bullseye release since the package is no longer team-maintained.

Thank you for your work on this!
tony

[1] https://salsa.debian.org/java-team/tuxguitar

Bug#1028496:

2023-01-16 Thread Alessio Di Sandro

+1
It would be great if you could package the 525.xx version, as none of
the GeForce RTX 40 series is currently supported in Debian, not
through the proprietary drivers nor nouveau.

Thanks,
Alessio

Bug#1029036: inventor: includes non-free source


Source: inventor
Version: 2.1.5-10-25
Severity: serious

Your package cointains stdmacro with the comment:

.\"Copyright (c) 1984 AT
.\"  All Rights Reserved
.\" THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT
.\"   The copyright notice above does not evidence any actual
.\"   or intended publication of such source code.

This file is non-free, so please repack to get rid of it.

Bug#1029035: ncl: includes non-free source


Source: ncl
Version: 6.6.2-12
Severity: serious

Your source package includes lex.yy_linux.c which has:

/*  Copyright (c) 1989 AT */
/*All Rights Reserved   */

/*  THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT */
/*  The copyright notice above does not evidence any*/
/*  actual or intended publication of such source code. */

Please repack getting rid of that file.

Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)

On Sunday, January 15, 2023 5:17:10 PM MST Axel Beckert wrote:
> > Debian, of course, prefers the Expat name as it is more precise.
> 
> According to
> https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_a
> nd_SPDX SPDX does not have the Expat license. They do have though the "MIT
> License" (the one and only ;-), so that would imply that they're not the
> same license.

Anyone who tells you there is a One And Only MIT License is trolling you.  ;)

https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants[1]

"The name 'MIT License' is potentially ambiguous. The Massachusetts Institute 
of 
Technology has been using many licenses for software since its creation; for 
example, MIT 
offers four licensing options for the FFTW[2] C source code library, one of 
which is the GPL 
v2.0[3] and the other three of which are not open-source[4]. The term 'MIT 
License' has also 
been used to refer to the *Expat License* (used for the XML parsing library 
Expat[5]) and to 
the *X11 License* (also called '*MIT/X Consortium License'*; used for X Window 
System[6] 
by the MIT X Consortium[7]). Furthermore, the 'MIT License' as published by the 
Open 
Source Initiative[8] is the same as the Expat License. Due to this differing 
use of terms, 
some prefer to avoid the name 'MIT License'. The Free Software Foundation[9] 
argues that 
the term is misleading and ambiguous, and recommends against its use.”

https://www.gnu.org/licenses/license-list.html#Expat[10]

As noted in the quote above, and in the second link, the license that is most 
commonly 
called the MIT License is what is appropriately referred to as the Expat 
license in Debian.

https://www.debian.org/legal/licenses/mit[11]

If you prefer I can open a separate bug about this issue, as it is my belief 
that Lintian 
should consider an Expat license in debian/copyright to not be a conflict with 
a MIT license 
in an AppStream metainfo.xml file.

-- 
Soren Stoutner
so...@stoutner.com

[1] https://en.wikipedia.org/wiki/MIT_License#Ambiguity_and_variants
[2] https://en.wikipedia.org/wiki/FFTW
[3] https://en.wikipedia.org/wiki/GNU_General_Public_License
[4] https://en.wikipedia.org/wiki/Open-source_software
[5] https://en.wikipedia.org/wiki/Expat_(library)
[6] https://en.wikipedia.org/wiki/X_Window_System
[7] https://en.wikipedia.org/wiki/MIT_X_Consortium
[8] https://en.wikipedia.org/wiki/Open_Source_Initiative
[9] https://en.wikipedia.org/wiki/Free_Software_Foundation
[10] https://www.gnu.org/licenses/license-list.html#Expat
[11] https://www.debian.org/legal/licenses/mit

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

Bug#1029034: snack: includes non-free source


Source: snack
Version: 2.2.10.20090623-dfsg-10
Severity: serious

jkFormant.c contains the following license info:

/* formant.c */
/*
 * This software has been licensed to the Centre of Speech Technology, KTH
 * by AT Corp. and Microsoft Corp. with the terms in the accompanying
 * file BSD.txt, which is a BSD style license.
 *
 *"Copyright (c) 1987-1990  AT, Inc.
 *"Copyright (c) 1986-1990  Entropic Speech, Inc.
 *"Copyright (c) 1990-1994  Entropic Research Laboratory, Inc.
 *   All rights reserved"
 *
 * Written by:  David Talkin
 * Revised by: John Shore
 *
 */

[...]

/*  Copyright (c) 1987, 1988, 1989 AT */
/*All Rights Reserved   */

/*  THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT */
/*  The copyright notice above does not evidence any*/
/*  actual or intended publication of such source code. */

/* downsample.c */


While the file part that is copied from formant.c is okay to be included in 
Debian, the part from downsample.c is not.
Please repack the source package getting rid of the file.

Bug#1029033: RFS: ruby-mdl/0.12.0-2 -- Markdown lint tool

2023-01-16 Thread Norwid Behrnd

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ruby-mdl":

 * Package name : ruby-mdl
   Version  : 0.12.0-2
   Upstream contact : ["p...@ipom.com"]
 * URL  : https://github.com/markdownlint/markdownlint
 * License  : MIT
 * Vcs  : https://salsa.debian.org/nbehrnd/ruby-mdl
   Section  : ruby

The source builds the following binary packages:

  ruby-mdl - Markdown lint tool

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

  https://mentors.debian.net/package/ruby-mdl/

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

  dget -x
  https://mentors.debian.net/debian/pool/main/r/ruby-mdl/ruby-mdl_0.12.0-2.dsc

Changes since the last upload:

 ruby-mdl (0.12.0-2) unstable; urgency=medium
 .
   * Source only upload for migration to testing

Regards,
-- 
  Norwid Behrnd

Bug#1029032: ITP: python-google-api-core -- Google API client core library

2023-01-16 Thread GCS

Package: wnpp
Severity: wishlist
Owner: Laszlo Boszormenyi (GCS) 

* Package name: python-google-api-core
  Version : 1.34.0
  Upstream Author : 2014- Google Inc.
* URL : https://github.com/googleapis/python-api-core
* License : Apache-2.0
  Programming Lang: Python
  Description : Google API client core library
This library is not meant to be stand-alone. Instead it defines common
helpers used by all Google API clients.

Bug#1029031: dcap: includes non-free source


There are more affected files in plugins/gssapi. I guess you have to get rid of 
dcap-tunnel-gsi.
As you are the maintainer for the only reverse dependency gfal2-plugin-dcap you 
can coordinate the uploads.

Bug#1029031: dcap: includes non-free source


Source: dcap
Severity: serious
Version: 2.47.12-4

plugins/gssapi/gssIoTunnel.c has the following comment:

 *   Copyright (c) 2000,2001,2002 DESY Hamburg DMG-Division
 *   All rights reserved.
 *
 *   THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF
 * DESY Hamburg DMG-Division
 *
 * Copyright (c) 1997 - 2002 Kungliga Tekniska H�gskolan (Royal Institute of
 * Technology, Stockholm, Sweden). All rights reserved.

Please repack the source package to get rid of the file.

Bug#1021079: NMU w/o ppc64el?

2023-01-16 Thread Adam Borowski

On Mon, Jan 16, 2023 at 08:26:37AM +0200, Konstantinos Margaritis wrote:
> On 15/1/23 03:33, Adam Borowski wrote:
> > Hi!
> > As you're apparently too busy to either fix ppc or suggest a different plan,
> > I'd make a NMU dropping ppc64el for now so the package can be released with
> > Bookworm.
> > 
> > Please say if I shouldn't.

> It is true that I am busy during this period, which may explain the lack of
> communication. Now regarding vectorscan w/o ppc64le, I have 2 serious bugs I
> want to fix before a new version upload (5.4.9), one is on Arm (a regression
> compared to x86) and the other is the failure on ppc64le. How long do I have
> to make an upload and ensure bookworm release? If that is too soon, then I
> will make an upload asap myself disabling ppc64le until I fix this locally.

Feb 12 is the cut-off; the package must be in testing at that time.  Then if
you have autopkgtests (vectorscan does), there's two more months before hard
freeze.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1029030: [INTL:es] Spanish translation of the debconf template

Package: diaspora-installer
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# diaspora-installer po-debconf translation to Spanish.
# Copyright (C) 2015 Software in the Public Interest
# This file is distributed under the same license as the diaspora-installer 
package.
#
# Changes:
# - Initial translation
# Jonathan Bustillos , 2015.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducción en
# http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: diaspora-installer\n"
"Report-Msgid-Bugs-To: diaspora-instal...@packages.debian.org\n"
"POT-Creation-Date: 2017-04-27 12:48+0530\n"
"PO-Revision-Date: 2023-01-05 17:46+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid "Host name for this instance of Diaspora:"
msgstr "Nombre de equipo para esta instancia de Diaspora:"

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"Please choose the host name which should be used to access this instance of "
"Diaspora."
msgstr ""
"Elija el nombre de equipo que se debe utilizar para acceder a esta instancia "
"de Diaspora."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"This should be the fully qualified name as seen from the Internet, with the "
"domain name that will be used to access the pod."
msgstr ""
"Debe ser el nombre completamente cualificado como se ve a través de "
"Internet, con el nombre de dominio que se utilizará para acceder al «pod»."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"If a reverse proxy is used, give the hostname that the proxy server responds "
"to."
msgstr ""
"Si se utiliza un proxy inverso, introduzca el nombre de equipo del servidor "
"proxy."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"This host name should not be modified after the initial setup because it is "
"hard-coded in the database."
msgstr ""
"El nombre de equipo no debe ser modificado después de la configuración "
"inicial ya que está codificado en la base de datos."

#. Type: note
#. Description
#: ../diaspora-common.templates:2001
msgid "PostgreSQL application password"
msgstr "Introduzca la contraseña de PostgreSQL"

#. Type: note
#. Description
#: ../diaspora-common.templates:2001
msgid ""
"You can leave the PostgreSQL application password blank, as the \"ident\" "
"authentication method is used, allowing the diaspora user on the system to "
"connect to the Diaspora database without a password."
msgstr ""
"Puede dejar la contraseña de PostgreSQL en blanco, ya que se utiliza el "
"método de autenticación «ident», que permite al usuario de diaspora "
"conectarse a la base de datos de Diaspora sin contraseña."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid "Enable https?"
msgstr "¿Activar https?"

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Enabling https means that an SSL/TLS certificate is required to access this "
"Diaspora instance (as Nginx will be configured to respond only to https "
"requests). A self-signed certificate is enough for local testing (and can be "
"generated using, for instance, the package easy-rsa), but will not be "
"accepted for federation with other Diaspora pods."
msgstr ""
"Activar https significa que se requiere un certificado SSL/TLS para acceder "
"a esta instancia de Diaspora (debido a que Nginx se configurará sólo para "
"responder a las solicitudes https). Un certificado autofirmado es suficiente "
"para una prueba local (y se puede generar utilizando, por ejemplo, el "
"paquete easy-rsa), pero no será aceptado para la federación con otros «pods» "
"de Diaspora."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Some certificate authorities like Let's Encrypt (letsencrypt.org), StartSSL "
"(startssl.com) offer free SSL/TLS certificates that work with Diaspora; "
"however, certificates provided by CAcert will not work with Diaspora."
msgstr ""
"Algunas autoridades de certificación como

Bug#1029029: [INTL:es] Spanish translation of the debconf template

Package: mini-buildd
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# mini-buildd po-debconf translation to Spanish
# Copyright (C) 2010-2013 Software in the Public Interest
# This file is distributed under the same license as the mini-buildd package.
#
# Changes:
#   - Initial translation
#   Francisco Javier Cuadrado , 2010
#
#   - Updates
#   Matías Bellone , 2013
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
#   info -n '(gettext)PO Files'
#   info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
#   - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducción en
# http://www.debian.org/intl/spanish/notas
#
#   - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
msgid ""
msgstr ""
"Project-Id-Version: mini-buildd 0.8.13\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2022-12-28 19:22+\n"
"PO-Revision-Date: 2023-01-05 15:59+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian l10n Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: note
#. Description
#: ../mini-buildd.templates:2001
msgid "mini-buildd data purge warning"
msgstr "Advertencia sobre purga de datos de mini-buildd"

#. Type: note
#. Description
#: ../mini-buildd.templates:2001
msgid "You have chosen to purge mini-buildd."
msgstr "Ha seleccionado purgar mini-buildd."

#. Type: note
#. Description
#: ../mini-buildd.templates:2001
msgid ""
"As a consequence, the mini-buildd user will be removed along with all the "
"files it owns, possibly including Debian repositories."
msgstr ""
"Como resultado de esta acción, se eliminará el usuario mini-buildd junto con "
"todos los archivos que le pertenecen, entre los que posiblemente se "
"encuentren repositorios Debian."

#. Type: note
#. Description
#: ../mini-buildd.templates:2001
msgid "To keep this data, you need to back it up now."
msgstr ""
"Si quiere mantener estos datos, debe realizar una copia de seguridad ahora."

#. Type: string
#. Description
#: ../mini-buildd.templates:3001
msgid "Home path:"
msgstr "Ruta del directorio personal («/home»):"

#. Type: string
#. Description
#: ../mini-buildd.templates:3001
msgid ""
"Please choose the directory where mini-buildd data will be stored. The "
"directory will also be the home directory for the mini-buildd user."
msgstr ""
"Seleccione el directorio donde se almacenarán los datos de mini-buildd. Este "
"directorio también será el directorio personal («/home») del usuario mini-"
"buildd."

#. Type: string
#. Description
#: ../mini-buildd.templates:3001
msgid ""
"It should have enough space for all the builders and repositories you plan "
"to use."
msgstr ""
"Debe tener suficiente espacio para todos los constructores y repositorios "
"que planea utilizar."

#. Type: password
#. Description
#: ../mini-buildd.templates:4001
msgid "Administrator password for mini-buildd:"
msgstr "Contraseña del administrador de mini-buildd:"

#. Type: password
#. Description
#: ../mini-buildd.templates:4001
msgid ""
"Please choose the password for the administrative user of mini-buildd. This "
"password will be used for the \"admin\" user in mini-buildd's web interface "
"and API."
msgstr ""
"Elija una contraseña para el usuario administrador de mini-buildd. Se "
"utilizará esta contraseña para el usuario «admin» en la interfaz web de mini-"
"buildd y en la API."

#. Type: password
#. Description
#: ../mini-buildd.templates:4001
msgid ""
"If you enter a password, this will also trigger the creation of a local "
"\"admin\" user (if not existing already)."
msgstr ""
"Si introduce una contraseña se creará un usuario «admin» local (si aún no "
"existe)."

#. Type: password
#. Description
#: ../mini-buildd.templates:4001
msgid ""
"If you leave this empty, nothing will be done (no potential \"admin\" user "
"creation, no password change)."
msgstr ""
"Si deja este campo vacío no se realizará ninguna acción (no se creará ningún "
"usuario «admin» ni tampoco se cambiará la contraseña)."

#. Type: string
#. Description
#: ../mini-buildd.templates:5001
msgid "Extra options:"
msgstr "Opciones adicionales:"

#. Type: string
#. Description
#: ../mini-buildd.templates:5001
msgid ""
"Using no extra options is perfectly fine, and would run (unencrypted) HTTP "
"on port 8066."
msgstr ""
"Si no configura ninguna opción adicional, el servicio se ejecutará sin "
"cifrar (HTTP) en el puerto 8066."

#. Type: string
#. Description
#:

Bug#1029028: [INTL:es] Spanish translation of the debconf template

Package: nova
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# nova po-debconf translation to Spanish.
# Copyright (C) 2013 Software in the Public Interest
# This file is distributed under the same license as the nova package.
#
# Changes:
# - Initial translation
# Jonathan Bustillos , 2012.
#
# - Updates
# Jonathan Bustillos , 2012, 2013, 2014.
# Matías Bellone , 2013.
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducción en
# http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
msgid ""
msgstr ""
"Project-Id-Version: nova\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2022-12-28 19:45+\n"
"PO-Revision-Date: 2023-01-05 15:47+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: string
#. Description
#: ../nova-common.templates.in:2001
msgid "Value for my_ip:"
msgstr "Valor para my_ip:"

#. Type: string
#. Description
#: ../nova-common.templates.in:2001
msgid "This value will be stored in the my_ip directive of nova.conf."
msgstr ""
"Este valor será almacenado en la directiva «my_ip» del archivo «nova.conf»."

#. Type: string
#. Description
#: ../nova-common.templates.in:3001
msgid "Neutron server URL:"
msgstr "URL del servidor Neutron:"

#. Type: string
#. Description
#: ../nova-common.templates.in:3001
msgid "Please enter the URL of the Neutron server."
msgstr "Introduzca la URL del servidor Neutron."

#. Type: string
#. Description
#: ../nova-common.templates.in:4001
msgid "Neutron admin tenant name:"
msgstr "Nombre del inquilino («tenant») administrador del servidor Neutron:"

#. Type: string
#. Description
#: ../nova-common.templates.in:4001
msgid ""
"Nova needs to be able to communicate with Neutron through Keystone. "
"Therefore Nova needs to know the Neutron admin tenant, username and password."
msgstr ""
"Nova necesita comunicarse con Neutron a través de Keystone. Por lo tanto, "
"Nova debe conocer el inquilino («tenant») administrador de Neutron, el "
"usuario y la contraseña."

#. Type: string
#. Description
#: ../nova-common.templates.in:4001
msgid "Please enter the name of the admin tenant for Neutron."
msgstr ""
"Introduzca el nombre del inquilino («tenant») administrador para Neutron."

#. Type: string
#. Description
#: ../nova-common.templates.in:5001
msgid "Neutron administrator username:"
msgstr "Nombre del administrador de Neutron:"

#. Type: string
#. Description
#: ../nova-common.templates.in:5001
msgid "Please enter the username of the Neutron administrator."
msgstr "Introduzca el nombre de usuario del administrador de Neutron."

#. Type: password
#. Description
#: ../nova-common.templates.in:6001
msgid "Neutron administrator password:"
msgstr "Contraseña del administrador de Neutron:"

#. Type: password
#. Description
#: ../nova-common.templates.in:6001
msgid "Please enter the password of the Neutron administrator."
msgstr "Introduzca la contraseña del administrador de Neutron."

#. Type: password
#. Description
#: ../nova-common.templates.in:7001
msgid "Metadata proxy shared secret:"
msgstr "Secreto compartido del proxy de metadatos:"

#. Type: password
#. Description
#: ../nova-common.templates.in:7001
msgid ""
"VM instances using Neutron to handle networking retrieve their metadata "
"through the Neutron metadata agent, which serves as a proxy to the Nova "
"metadata REST API server."
msgstr ""
"Las máquinas virtuales que utilizan Neutron para gestionar la red, obtienen "
"sus metadatos a través del agente de metadatos de Neutron, que actúa como un "
"proxy para el servidor de metadatos de la API REST de Nova."

#. Type: password
#. Description
#: ../nova-common.templates.in:7001
msgid ""
"Please enter the password that should be used to protect communications "
"between the Neutron metadata proxy agent and the Nova metadata server. The "
"same shared password should be used when setting up the neutron-metadata-"
"agent package."
msgstr ""
"Introduzca la contraseña que se utilizará para proteger las comunicaciones "
"entre el agente proxy de metadatos de Neutron y el servidor de metadatos de "
"Nova. Debe usar la misma contraseña compartida cuando configure el paquete "

Bug#1029027: [INTL:es] Spanish translation of the debconf template

Package: uptimed
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# uptimed po-debconf translation to spanish
# Copyright (C) 2004 Software in the Public Interest
# This file is distributed under the same license as the uptimed package.
#
# Changes:
# - Initial translation
#   Rudy Godoy , 2006
#
#
#  Traductores, si no conoce el formato PO, merece la pena leer la
#  documentación de gettext, especialmente las secciones dedicadas a este
#  formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
#   http://www.debian.org/intl/spanish/coordinacion
#   especialmente las notas de traducción en
#   http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
#   /usr/share/doc/po-debconf/README-trans
#   o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
msgid ""
msgstr ""
"Project-Id-Version: uptimed 0.3.8\n"
"Report-Msgid-Bugs-To: upti...@packages.debian.org\n"
"POT-Creation-Date: 2018-01-28 22:11+0800\n"
"PO-Revision-Date: 2023-01-05 08:04+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian l10n Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: string
#. Description
#: ../uptimed.templates:2001
msgid "Delay between database updates (seconds):"
msgstr "Demora entre actualizaciones de la base de datos (en segundos):"

#. Type: string
#. Description
#: ../uptimed.templates:2001
msgid ""
"Uptimed will update its database regularly so that the uptime doesn't get "
"lost in case of a system crash. You can set how frequently this will happen "
"(use higher values if you want to avoid disk activity, for instance on a "
"laptop)."
msgstr ""
"Uptimed actualizará su base de datos periódicamente para evitar que se "
"pierda el tiempo de actividad en caso de que el sistema colapse. Puede "
"configurar la frecuencia de actualización (use valores altos si desea evitar "
"actividad del disco, por ejemplo, en un equipo portátil)."

#. Type: string
#. Description
#: ../uptimed.templates:3001
msgid "Number of records that should be kept:"
msgstr "Número de registros que desea mantener:"

#. Type: string
#. Description
#: ../uptimed.templates:3001
msgid ""
"Uptimed can limit the number of records to be kept to the highest n, to keep "
"an unlimited number of records set this value to 0"
msgstr ""
"Uptimed puede limitar el número de registros que desea conservar hasta un "
"valor máximo de «n». Si quiere mantener un número ilimitado de registros, "
"configure este valor a «0»"

#. Type: string
#. Description
#: ../uptimed.templates:3001
msgid ""
"Be aware that uptime data will be lost if the limit has been reached and/or "
"the number records is reduced."
msgstr ""
"Tenga en cuenta que los datos de tiempo de actividad se perderán si se ha "
"alcanzado el límite y/o se ha reducido el número de registros."

#. Type: select
#. Choices
#: ../uptimed.templates:4001
msgid "Never"
msgstr "Nunca"

#. Type: select
#. Choices
#: ../uptimed.templates:4001
msgid "Record"
msgstr "Marca"

#. Type: select
#. Choices
#: ../uptimed.templates:4001
msgid "Milestone"
msgstr "Hito"

#. Type: select
#. Choices
#: ../uptimed.templates:4001
msgid "Both"
msgstr "Ambos"

#. Type: select
#. Description
#: ../uptimed.templates:4002
msgid "Send mails if a milestone or record is reached:"
msgstr "Enviar correos si se alcanza un hito o una marca:"

#. Type: select
#. Description
#: ../uptimed.templates:4002
msgid ""
"Uptimed can be configured to send a mail each time a record is broken or a "
"\"milestone\" is reached. You can choose whether you:"
msgstr ""
"Puede configurar Uptimed para enviar un correo cada vez que se bate una "
"marca o se alcance un hito. Puede elegir entre las siguientes opciones:"

#. Type: select
#. Description
#: ../uptimed.templates:4002
msgid ""
" * never want to receive these mails;\n"
" * want to be notified only when a record is broken;\n"
" * would like to know about milestones;\n"
" * are interested in both."
msgstr ""
" * no quiero recibir este tipo de correos;\n"
" * quiero recibir notificaciones sólo cuando se alcance una marca;\n"
" * me gustaría recibir notificaciones de los hitos;\n"
" * me interesa recibir ambas notificaciones."

#. Type: string
#. Description
#: ../uptimed.templates:5001
msgid "Uptimed email recipient:"
msgstr "Dirección de correo electrónico para notificaciones de Uptimed:"

#. Type: string
#. Description
#: ../uptimed.templates:5001
msgid ""
"Since you have chosen to be sent emails, you should specify where to send "
"these mails."
msgstr ""
"Puesto que ha elegido que se envíen notificaciones, debe indicar

Bug#1029026: [INTL:es] Spanish translation of the debconf template

Package: unattended-upgrades
Severity: wishlist
Tags: patch l10n

Hello,
You can find enclosed the Spanish translation template to be uploaded with the 
latest package build.
Cheers,

-- 
Camaleón# unattended-upgrades po-debconf translation to Spanish.
# Copyright (C) 2007 Software in the Public Interest, SPI Inc.
# This file is distributed under the same license as the unattended-upgrades 
package.
#
#  Changes:
# - Initial translation
#   Fernando González de Requena , 2009.
# -Reviewers:
#   Javier Fernandez-Sanguino 
#
#  Traductores, si no conoce el formato PO, merece la pena leer la
#  documentación de gettext, especialmente las secciones dedicadas a este
#  formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
#   http://www.debian.org/intl/spanish/
#   especialmente las notas y normas de traducción en
#   http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
#   /usr/share/doc/po-debconf/README-trans
#   o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
# Si tiene dudas o consultas sobre esta traducción consulte con el último
# traductor (campo Last-Translator) y ponga en copia a la lista de
# traducción de Debian al español ()
#
msgid ""
msgstr ""
"Project-Id-Version: unattended-upgrades 0.37debian1\n"
"Report-Msgid-Bugs-To: unattended-upgra...@packages.debian.org\n"
"POT-Creation-Date: 2017-12-12 23:02+0100\n"
"PO-Revision-Date: 2022-12-29 18:58+0100\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Automatically download and install stable updates?"
msgstr ""
"¿Desea descargar e instalar automáticamente las actualizaciones de la "
"versión estable?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Applying updates on a frequent basis is an important part of keeping systems "
"secure. By default, updates need to be applied manually using package  "
"management tools. Alternatively, you can choose to have this system  "
"automatically download and install important updates."
msgstr ""
"Para mantener el sistema seguro es importante instalar las actualizaciones "
"regularmente. De manera predeterminada, para poder realizar una "
"actualización tiene que utilizar una herramienta de gestión de paquetes. "
"Como alternativa, puede elegir que el sistema descargue e instale "
"automáticamente las actualizaciones importantes."

Bug#1029025: [INTL:es] Spanish translation of the debconf template