Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Salvatore Bonaccorso]

Hi,

On Sat, Mar 26, 2022 at 05:19:03PM +0100, Petra Rübe-Pugliese wrote:
> On Sat 12 Mar 2022 at 21:31:38 +0100  Petra R.-P.  
> wrote:
> > On Sat 05 Mar 2022 at 17:59:51 +0100  Petra R.-P.  
> > wrote:
> > [...]
> > 
> > The error persists also in linux-image-5.16.0-4-686 (5.16.12-1) .
> 
>  ... and in linux-image-5.16.0-5-686 (5.16.14-1) ...

Thanks for constantly testing the new versions (there is 5.16.18-1
upcoming btw, or 5.17.1 in experiemntal).

Do we have a report upstream already about this issue?

Regards,
Salvatore

Bug#1008277: aideinit stops with error in rule

[Marc Haber]

Control: tags -1 moreinfo
thanks

On Sun, Mar 27, 2022 at 01:03:30PM +0200, Marc Haber wrote:
> On Fri, Mar 25, 2022 at 09:36:12PM +0100, Gwen wrote:
> >   ERROR: /etc/aide/aide.conf.d/31_aide_apt (stdout):105:70: error in rule 
> > '/var/lib/apt/lists/deb\.debian\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\.diff_Index)?$':
> >  invalid double slash (line: 
> > '/var/lib/apt/lists/deb\\.debian\\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\\.diff_Index)?$
> >  f VarFile')
> 
> This looks like an error parsing a sources.list line that contains an
> external repository. Can you show all sources.list lines that contain
> "autoinstall.plesk.com"?

May I remind?

Greetings
Marc

Bug#1008605: virtualbox depends on old python package

[Arnaud Rebillout]

On Tue, 29 Mar 2022 15:09:06 +0200 Michael Tatge  
wrote:> Package: virtualbox


> the virtualbox package doesn't install on sid anymore.
> Depends: python3 (< 3.10) but 3.10.4-1 is to be installed.

It seems that the package just needs to be rebuilt, a binNMU should do. 
I tried it (rebuilt the package locally on my machine, installed it) and 
it works.


Additionally, python 3.10 is supported, according to: 
https://salsa.debian.org/pkg-virtualbox-team/virtualbox/-/commit/055bd3a4


I can't do a binNMU myself though...

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#996028: [debian-mysql] Bug#996028: Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Johnny A. Solbu]

On Wednesday 30 March 2022 07:38, Otto Kekäläinen wrote:
> Please keep in mind that this is an open source project. You are
> welcome to debug the issue yourself and to contribute towards a fix
> for it. If you need somebody else to fix it for you, you might
> consider using a consultant or a support provider to investigate your
> particular installation and make fixes for your particular instance.

Are you telling me that unless I shell out some money,
_Debian_ is not going to even provide any hints on what needs to be done to fix 
what is supposed to be a simple «apt upgrade»?

-- 
Johnny A. Solbu
web site,   https://www.solbu.net
PGP key ID: 0x4F5AD64DFA687324


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

Bug#1007915: [Pkg-javascript-devel] Bug#1007915: node-wikibase-cli: incompatible with node-commander >= 8

[Andrius Merkys]

On 2022-03-30 07:50, Yadd wrote:
> /usr/bin/* links were wrong. I fixed all these issues

Thanks a lot!

Best,
Andrius

Bug#1008629: [debian-mysql] Bug#1008629: mariadb-server-core-10.3: MDEV-27937 no results on large prepared statement parameter list

[Otto Kekäläinen]

Thanks for reporting.

Upstream is scheduled to release new versions in about a month or so,
and the next Debian stable update date will show up at
https://release.debian.org/ when it is planned. There will be no extra
releases of MariaDB 1:10.3.3x in Debian 10 "Bullseye" than the next
stable update in some months. Thus, there are no releases to do extra
backports to at the moment.

Note that Debian as an open source project does not provide any
warranties or guarantees about software. If you are running MariaDB in
a commercial setting and you want to have a contract that guarantees
you always have a good version, you should seek a contract with one of
the commercial vendors of MariaDB.

Bug#1008649: ITS: dokuwiki

[Axel Beckert]

Package: dokuwiki
Severity: important

Dear Tanguy,

I hope this e-mail finds you well.

Debian's dokuwiki package looks as if it is no more maintained for quite
a while. See also my recent NMU to fix two RC bug reports which got it
back into testing at least.

Anton Gladky (X-Debbugs-Cc'ed) and myself are interested in having a
well-maintained dokuwiki package in Debian.

We currently intent to salvage Debian's dokuwiki package in accordance
with https://wiki.debian.org/PackageSalvaging and
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
as Debian's dokuwiki package seems eligible for the package salvaging
process due to these issues:

* It is in clear need of some love and care (open bugs, missing upstream
  releases—at least before my recent NMU—, lots of lintian
  warnings—unfortunately https://lintian.debian.org/sources/dokuwiki is
  currently not uptodate to show that there's still work to do even
  after my NMU—, etc.)

* AND there is the need to upload the package to deal with these issues
  (clearly was the case before my NMU and still is as the NMU only fixed
  the most urgent compatibility issues, see also comments in
  https://bugs.debian.org/1004330 and current lintian warnings)

* AND not only one but all of the following issues:

  * There is no visible [maintainer] activity regarding the package for
six months. [Actually there's no visible maintainer activity for 3.5
years. Last maintainer upload was on 2018-09-26, no reactions in the
BTS to open dokuwiki bugs after that upload.]

  * The last upload was an NMU and there was no maintainer upload within
one year. [Holger's NMU kinda doesn't count, but mine surely counts.]

  * Bugs exist for more than one major missing upstream version and the
first bug is older than one year. (Applies for
https://bugs.debian.org/cgi-bin/968453 before my recent NMU.)

In case you intend to become active again in the maintenance of Debian's
dokuwiki package, we would also co-maintain the package together with
you, maybe forming a Debian Dokuwiki Team on tracker.debian.org or so.

If we don't hear back from you, we will continue to package salving
process in 21 days (i.e. on or after 20th of April 2022) with an upload
to unstable into DELAYED/7 as documented in
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package

Please also feel free to tell us that we can continue earlier with
taking over the maintenance of Debian's dokuwiki package as well as to
telling us that you want to continue being listed as e.g. co-maintainer
(i.e. Uploader) of the package.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-5-amd64 (SMP w/2 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#996028: [debian-mysql] Bug#996028: Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Otto Kekäläinen]

On Tue, Mar 29, 2022 at 9:33 PM Johnny A. Solbu  wrote:
>
> On Sunday 20 February 2022 02:23, Otto Kekäläinen wrote:
> > Is the issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996028
> > still affecting people?
>
> We just hit it again on our server aftre4r upgrading just now, and I am not 
> sure why.
> We had to resort to enableing «innodb_force_recovery = 5» just to get the 
> mariadb server started.
>
>
> I am not sure how we are supposed to fix it.
> There is no clear guidance as to how we are supposed to fix this, not that i 
> can see anyway.
>
> Is there a _Clear_ and _simple_ explanation/guide as to how we are supposed 
> to fix this on our end?

Please keep in mind that this is an open source project. You are
welcome to debug the issue yourself and to contribute towards a fix
for it. If you need somebody else to fix it for you, you might
consider using a consultant or a support provider to investigate your
particular installation and make fixes for your particular instance.

https://www.debian.org/consultants/
https://mariadb.org/about/#service-providers

Bug#1008040: libelementary1 1.26.2-1+b1 should recommend same version of libelementary-bin

[Ross Vandegrift]

Control: tags -1 pending

On Mon, Mar 21, 2022 at 11:17:19AM +0100, Pavel Reznicek wrote:
> the bookworm version of libelementary1 (1.26.2-1+b1) recommends old (now 
> non-existing in archives) version of libelementary-bin: 1.26.2-1 instead of 
> 1.26.2-1+b1.

Thanks for the report, this will be fixed in the next upload.

Ross

Bug#990250: guile-2.2 FTBFS on musl: dh_missing complains about charset.alias

[Helmut Grohne]

Control: reopen -1
Control: tags -1 = ftbfs patch fixed-upstream

On Sun, Mar 06, 2022 at 07:11:54PM +0100, Helmut Grohne wrote:
> On Sun, Mar 06, 2022 at 12:04:20PM -0600, Rob Browning wrote:
> > Hmm, it looks like this may have changed in more recent 3.0 releases
> > (i.e. need_charset_alias is no longer mentioned anywhere in the tree).
> > I wonder if that means we need a different patch, or perhaps the problem
> > has been resolved.
> 
> Thank you for looking into this. I'm unsure at this point and we cannot
> really tell as jenkins has no signal in the noise of temporary failing
> builds since a while. Thus closing. If it happens to still be an issue,
> I'll file a new bug with a new patch.

I've tried dropping the patch and things weren't looking well. Yes, this
seems to have been fixed in 3.0 releases, but this bug is about 2.2. So
I think it would seem reasonable to include the patch in Debian without
any effort to upstreaming it as 2.2 likely is in maintenance mode
already.

Helmut

Bug#1008181: CVE-2017-5715

[Salvatore Bonaccorso]

Hi all,

On Fri, Mar 25, 2022 at 02:57:12PM -0300, Leandro Cunha wrote:
> Hi,
> 
> On Fri, Mar 25, 2022 at 2:38 PM Georgi Naplatanov  wrote:
> >
> > On 3/25/22 19:19, Leandro Cunha wrote:
> > > Hi,
> > >
> > > On Fri, Mar 25, 2022 at 4:19 AM Georgi Naplatanov  wrote:
> > >>
> > >> On 3/25/22 03:24, Leandro Cunha wrote:
> > >>> Hi,
> > >>>
> > >>> On Wed, Mar 23, 2022 at 6:18 PM Georgi Naplatanov  
> > >>> wrote:
> > 
> >  On 3/23/22 22:43, Leandro Cunha wrote:
> > > Hi,
> > >
> > > On Wed, Mar 23, 2022 at 2:33 PM Georgi Naplatanov  
> > > wrote:
> > >>
> > >> On 3/23/22 18:35, piorunz wrote:
> > >>> On 23/03/2022 15:41, Leandro Cunha wrote:
> > >>>
> >  Please, take into consideration what is in the link and you can
> >  consult through
> >  it about CVE: 
> >  https://security-tracker.debian.org/tracker/CVE-2017-5715
> > >>>
> > >>> Leandro,
> > >>> I've been on this website before I posted with 
> > >>> spectre-meltdown-checker
> > >>> results. I have vulnerable status just like author of this topic. I 
> > >>> am
> > >>> on intel-microcode 3.20210608.2, and by the look of it, this bug
> > >>> supposed to be fixed in:
> > >>>
> > >>> "intel-microcode: Some microcode updates to partially adress
> > >>> CVE-2017-5715 included in 3.20171215.1
> > >>> Further updates in 3.20180312.1"
> > >>>
> > >>> So my version of microcode is 3-4 years newer than that.
> > >>>
> > >>> Is it microcode problem, or spectre-meltdown-checker displaying 
> > >>> wrong
> > >>> information, or something else entirely?
> > >>>
> > >>
> > >> I want to mention that on the same computer with kernel Debian 
> > >> 5.10.92-2
> > >>
> > >> spectre-meltdown-checker
> > >>
> > >> reports that the system is not vulnerable to CVE-2017-5715
> > >>
> > >> Kind regards
> > >> Georgi
> > >>
> > >
> > > This script is reporting an already patched CVE as vulnerable.
> > 
> > 
> >  Are you sure this behavior on 5.10.103-1 is not some kind of 
> >  regression?
> >  What is the evidence that vulnerability is still fixed?
> > 
> > 
> >  Kind regards
> >  Georgi
> > 
> > >>>
> > >>> When replying to your email I was aware of the script issue that was 
> > >>> reporting
> > >>> several already resolved CVEs as unresolved. As Salvatore sent the 
> > >>> issue link.
> > >>> But it seems to me that this problem was solved 7 days ago, it would be
> > >>> interesting if there was an update or a backport to stable.
> > >>>
> > >>
> > >> Hi Leandro,
> > >>
> > >> I also think that an update would be nice.
> > >>
> > >> Kind regards
> > >> Georgi
> > >>
> > >
> > > I applied a patch from upstream and repackaged it from unstable.
> > > And this CVE is displayed as resolved.
> > >
> >
> > Thank you, Leandro!
> >
> > I guess that the patch will appear in Debian stable (11.4), right?
> >
> > Kind regards
> > Georgi
> >
> 
> This update must comply with the link below. I only did a test here.
> It is up to the maintainers to analyze this.
> I already see it as something necessary to be corrected.
> [1] 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-uploads-to-the-stable-and-oldstable-distributions

I would suggest to ask the maintainers if they can prepare an update
to be included in the next point release. This can happen directly or
to the bug #1008181.

Sylvestre and Holger, would you have time to include the bugfix as
well in the future bullseye point release?

Regards,
Salvatore

Bug#1007915: [Pkg-javascript-devel] Bug#1007915: node-wikibase-cli: incompatible with node-commander >= 8

[Yadd]

On 29/03/2022 18:17, Yadd wrote:

On 29/03/2022 17:44, Yadd wrote:

Hi Andrius,

you fix is enough for commander 8, I'm currently writing commander 9 
patch


Fixed and pushed. However package looks unusable because all bin/* 
commands are not in $PATH. You could either:

  * install all commands in /usr/bin
  * or change path in /usr/bin/wd and /usr/bin/wb


/usr/bin/* links were wrong. I fixed all these issues

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, Mar 24, 2022 at 11:56:02PM -0700, Josh Triplett wrote:
> On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote:
> > It would appear that the situation has deteriorated further. dpkg 1.21.2
> > now issues a warning on all merged-usr systems:
> > 
> > Setting up dpkg (1.21.2) ...
> > dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> > dpkg: warning: See .
> 
> Update: in dpkg 1.21.3, the warning now reads:
> 
> dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind 
> dpkg's
> dpkg: warning: back, breaking its core assumptions. This can cause silent file
> dpkg: warning: overwrites and disappearances, and its general tools 
> misbehavior.
> dpkg: warning: See .
> 
> While more explicit, I think the issue remains, both with this message
> and with the page it links to.

Update: we're now even further into full-blown "fights in the archive"
territory:

https://lists.debian.org/debian-devel-changes/2022/03/msg03658.html
Changed-By: Bastian Blank 
Changes:
 dpkg (1.21.5+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Revert rebellion against CTTE decision #994388:
 - Remove warning about unsupported system.
 - Don't install dpkg-fsys-usrunmess.

https://lists.debian.org/debian-devel-changes/2022/03/msg03660.html
Changed-By: Guillem Jover 
Changes:
 dpkg (1.21.6) unstable; urgency=medium
 .
   - This also clears a bullying NMU. -
 .
   [ Guillem Jover ]
   * Documentation:
 - man: Document untracked kernel module files handling in
   dpkg-fsys-usrunmess(8).

Bug#1008648: aconnectgui: Scissors don't break connections, they make them instead

[David Calman]

Package: aconnectgui
Version: 0.9.0rc2-1-10+b1
Severity: important
X-Debbugs-Cc: alt.people.davidcal...@gmail.com

Dear Maintainer,

I was trying to run Scala (the musical scale one written in Ada,
not the JVM one). To get sound output to work, I need to modprobe
snd_virmidi, start Timidity as a daemon, and make virmidi port 0
output to Timidity with aconnectgui or Patchage (patchage is not in main).  
The instructions actually say to start Timidity *after* setting up the
patch cable in aconnectgui/patchage but until I start Timidity
aconnectgui can't see the Timidity port.

That brings me to this bug: I have to restart alsa midi, modprobe -R
snd_virmidi, etc. (easier to reboot the system!) if I make a mistake,
because the scissors tool in aconnectgui doesn't break connections
like it's supposed to. Instead, it *makes* connections, like the
patch cable tool.

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

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

Versions of packages aconnectgui depends on:
ii  libasound2   1.2.4-1.1
ii  libc62.31-13+deb11u2
ii  libfltk1.1   1.1.10-29
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libgcc1  1:8.3.0-6
ii  libstdc++6   10.2.1-6

aconnectgui recommends no packages.

aconnectgui suggests no packages.

-- no debconf information

Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Johnny A. Solbu]

On Sunday 20 February 2022 02:23, Otto Kekäläinen wrote:
> Is the issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996028
> still affecting people?

We just hit it again on our server aftre4r upgrading just now, and I am not 
sure why.
We had to resort to enableing «innodb_force_recovery = 5» just to get the 
mariadb server started.


I am not sure how we are supposed to fix it.
There is no clear guidance as to how we are supposed to fix this, not that i 
can see anyway.

Is there a _Clear_ and _simple_ explanation/guide as to how we are supposed to 
fix this on our end?


-- 
Johnny A. Solbu
web site,   https://www.solbu.net
PGP key ID: 0x4F5AD64DFA687324


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

Bug#1000209: timidity-daemon: Fails to install or remove due to no timidity.service

[David Calman]

Package: timidity-daemon
Version: 2.14.0-8
Followup-For: Bug #1000209
X-Debbugs-Cc: alt.people.davidcal...@gmail.com

Dear Maintainer,

I tried to install timidity-daemon. It failed because of no timidity.service.
I tried to remove timidity-daemon. That also failed bc of no timidity.service.
Now I have a permanently broken package on my system.
Should the severity of this bug go up to reflect this?

Sincerely,
David

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

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

Versions of packages timidity-daemon depends on:
ii  adduser   3.118
ii  lsb-base  11.1.0
ii  timidity  2.14.0-8

timidity-daemon recommends no packages.

timidity-daemon suggests no packages.

-- no debconf information

Bug#1008647: greybird-gtk-theme: New upstream version available, 3.23.1

[Andrew Chadwick]

Package: greybird-gtk-theme
Version: 3.22.15-1
Severity: wishlist
X-Debbugs-Cc: a.t.chadw...@gmail.com

Dear Maintainer,

A new upstream version is available. Please can it be uploaded?

https://github.com/shimmerproject/Greybird/releases

cheers,
Andrew


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

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

Versions of packages greybird-gtk-theme depends on:
ii  gtk2-engines-murrine  0.98.2-3+b1

greybird-gtk-theme recommends no packages.

greybird-gtk-theme suggests no packages.

-- no debconf information

Bug#1008646: generic php-fpm.sock not created on sysvinit systems

[Joseph Nahmias]

Package: php7.4-fpm
Version: 7.4.28-1+deb11u1
Severity: normal
File: /etc/init.d/php7.4-fpm
Tags: patch
X-Debbugs-Cc: j...@nahmias.net

Hello,

I've noticed that the php7.4-fpm package doesn't create the generic socket file
/run/php/php-fpm.sock (managed by alternatives) when using sysvinit. It seems
this was rolled into the systemd service unit file, but wasn't added to the
sysvinit script. Here's a patch that adds it (along with an related bugfix
for the permissions of the /run/php directory):

--- /etc/init.d/php7.4-fpm.orig 2021-10-23 21:53:50.0 +
+++ /etc/init.d/php7.4-fpm  2022-03-30 02:31:05.339118410 +
@@ -49,6 +49,7 @@
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS 2>/dev/null \
|| return 2
+   /usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock 
/etc/php/7.4/fpm/pool.d/www.conf 74
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one.  As a last resort, sleep for some time.
@@ -77,6 +78,7 @@
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
+   /usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock 
/etc/php/7.4/fpm/pool.d/www.conf 74
return "$RETVAL"
 }

@@ -96,7 +98,7 @@
 case "$1" in
 start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
-   mkdir --mode=07500 /run/php
+   mkdir --parents --mode=0755 /run/php
chown www-data:www-data /run/php
case "$?" in
0)


-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'stable-debug'), 
(500, 'proposed-updates-debug')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-10-686-pae (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages php7.4-fpm depends on:
ii  libacl1 2.2.53-10
ii  libapparmor12.13.6-10
ii  libargon2-1 0~20171227-0.2
ii  libc6   2.31-13+deb11u2
ii  libmagic1   1:5.39-3
ii  libpcre2-8-010.36-2
ii  libsodium23 1.0.18-1
ii  libssl1.1   1.1.1k-1+deb11u1
ii  libsystemd0 247.3-6
ii  libxml2 2.9.10+dfsg-6.7
ii  mime-support3.66
ii  php7.4-cli  7.4.28-1+deb11u1
ii  php7.4-common   7.4.28-1+deb11u1
ii  php7.4-json 7.4.28-1+deb11u1
ii  php7.4-opcache  7.4.28-1+deb11u1
ii  procps  2:3.3.17-5
ii  tzdata  2021a-1+deb11u2
ii  ucf 3.0043
ii  zlib1g  1:1.2.11.dfsg-2

php7.4-fpm recommends no packages.

Versions of packages php7.4-fpm suggests:
pn  php-pear  

Versions of packages php7.4-common depends on:
ii  libc6   2.31-13+deb11u2
ii  libffi7 3.3-6
ii  libssl1.1   1.1.1k-1+deb11u1
ii  php-common  2:76
ii  ucf 3.0043


-- no debconf information

Bug#1008645: RM: nose2-cov -- ROM; Unmaintained; Upstream Dead; Useless

[Boyuan Yang]

Package: ftp.debian.org
X-Debbugs-Cc: by...@debian.org
Severity: normal


Dear FTP Masters,

I request removal of src:nose2-cov ( https://tracker.debian.org/pkg/nose2-cov
) from Debian unstable.

* This package is team-maintained, and the sole uploader has retired.
* The upstream of this package https://bitbucket.org/memedough/nose2-cov/ is
dead (404).
* This package is not used in Debian either as dependency or build-dependency
thus useless.
* The last upstream release at https://pypi.org/project/nose2-cov/#history
dates back in 2012.
* The package popcon is low (12).

As a result, please remove it from the archive. Thanks!

-- 
Best,
Boyuan Yang


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

Bug#1008644: ITP: nala -- commandline frontend for the apt package manager

[Blake Lee]

Package: wnpp
Severity: wishlist
Owner: Blake Lee 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: nala
  Version : 0.7.1
  Upstream Author : Blake Lee 
* URL : https://gitlab.com/volian/nala
* License : GPLv3+
  Programming Lang: Python
  Description : commandline frontend for the apt package manager

 nala is a frontend for the apt package manager. It has a lot
 of the same functionality, but formats the output to be more
 human readable. Also implements a history function to see past
 transactions and undo/redo them. Much like Fedora's dnf history.

This package is useful because it improves the UX of managing packages
through the command line with python3-apt. Additionally provides some
extra quality of life features such as a transaction history you can
interact with. I use nala daily, as do many others. Similar packages
include apt and aptitude. Nala improves upon the hardwork of the apt
team by formatting the output in a more readable manner.

At the moment I maintain this program on our GitLab. That is where we
accept bug reports and feature requests. I don't have any problems
accepting bug reports from Debian's system, or emails for that matter.
I regularly accept bug reports from our GitHub as well.

We currently have support for the German language, and I have someone
working on a Spanish po file as well.

Nala is still in active development, but it is very usable. I've had
many people ask me about getting this into the Official Debian repos so
this is my request for that.

I assume that I would be in need of a sponser considering I've never
uploaded anything into a Debian repository. But I did try my best to
make the debian files proper, and I personally use sbuild for building
the software.

In case it is required I do have our repo already mirrored into debian
salse https://salsa.debian.org/volian-team/nala

My users would be thrilled to hear this makes it into the official
repositories. I'm looking forward to your response.

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

[Sean Whitton]

Hello,

On Tue 29 Mar 2022 at 09:06PM +02, Lucas Nussbaum wrote:

> On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
>>
>> I don't think it's the preferred method.  I believe most of the project
>> sees git histories are the preferred tool for achieving the goal you
>> state.
>>
>> If we had only source packages for this purpose, then yes, 3.0 (quilt)
>> plus DEP-3 would be preferred.  But we have git, too, and indeed dgit.
>> Repositories for packages contain both upstream history and Debian
>> packaging history, and we have powerful git subcommands for extracting
>> information.  In many cases there is a good argument to be made that the
>> git history is part of the preferred form of modification.
>
> I think there are three different use cases to consider:

I agree that we should consider them separately.

>   A. preferred form for regular contributions to the package (typically
>   by the package maintainer)
>
>   B. preferred form for occasional contributions to the package (typically
>   by an NMUer, or by the security team)
>
>   C. preferred form for reviewing the packaging and Debian-specific
>   changes.
>
>
> I fully agree that the git repository is the preferred form for A.
> However, for B and C, I think that our lingua franca is the source
> package, and thus a source package that doesn't make it hard to
> understand things such as Debian-specific patches. Of course that
> could change if we were able to standardize on a git workflow (or
> a small set of git workflows), but I don't see this happenning anytime
> soon.

What you get from 'dgit clone' is designed to serve (B) and (C) well,
and somewhat sidesteps precisely the problems created by our having
multiple git workflows.

Please consider trying out dgit-user(7) and/or dgit-nmu-simple(7) next
time you need to engage in (B) or (C).  It's really very nice :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1008643: tracker.debian.org: please advertise if a package is part of the "key packages" set

[Sandro Tosi]

Package: tracker.debian.org
Severity: wishlist
X-Debbugs-Cc: mo...@debian.org

Hello,
there is a list of key packages at: 
https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

if would be nice if tracker.d.o would know about it, and display such
information in the package page.

Thanks,
Sandro

Bug#1008507:

[Joshua Hudson]

diff -ur glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c
glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c
--- glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29
17:50:12.558027042 -0700
+++ glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29
17:52:33.262157543 -0700
@@ -183,6 +183,11 @@
 case XFS_SUPER_MAGIC:
   return XFS_LINK_MAX;

+case MSDOS_SUPER_MAGIC:
+#ifdef EXFAT_SUPER_MAGIC // For when it gets added in about 30 years
+case EXFAT_SUPER_MAGIC:
+#endif
+  return 1;
 case LUSTRE_SUPER_MAGIC:
   return LUSTRE_LINK_MAX;

Bug#1008507:

[Joshua Hudson]

/* reproduce glibc bug */

/*
 * I don't typically care what the return of pathconf(..., _PC_LINK_MAX)
 * is; I just care whether or not it's greater than 1 because I'm checking
 * whether the filesystem supports hard links or not.
 */

#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
char file[40];
char dir[40];
char commandbuf[120];
sprintf(file, "/tmp/%u.img", getpid());
sprintf(dir, "/tmp/%u.mnt", getpid());
FILE *fimage = fopen(file, "wb");
fseek(fimage, 1440 * 1024 - 1, SEEK_SET);
fputc(0, fimage);
fclose(fimage);
mkdir(dir, 0);
sprintf(commandbuf, "mkfs.fat /tmp/%u.img", getpid());
if (system(commandbuf) != 0) {
rmdir(dir);
unlink(file);
return 1;
}

sprintf(commandbuf, "mount -o loop -t msdos %s %s", file, dir);
if (system(commandbuf) != 0) {
rmdir(dir);
unlink(file);
return 1;
}

int r;
printf("Testing pathconf(%s, _PC_LINK_MAX)...");
r = pathconf(dir, _PC_LINK_MAX) != 1;
printf(r ? "Failed\n" : "OK\n");
sprintf(commandbuf, "umount %s", dir);
system(commandbuf);
rmdir(dir);
unlink(file);
return r;
}

Bug#1003078: network-manager-gnome: Can't disable Networking/Wi-Fi, can't remove/edit connections (No polkit authorization)

[Ivan Vilata i Balaguer]

Hi Michael, thanks for having a look at this.

I updated packages a few days ago (I'm using `network-manager-gnome` version
1.24.0-2 now) and I just checked that all the issues that I described no
longer happen.

(Since you asked, I'm running plain i3wm on an X session.)

I guess that the issue can be closed.

Thanks again!


Michael Biebl (2022-03-29 22:20:04 +0200) wrote:

> Control: tags -1 + moreinfo
> 
> Which desktop environment is this?
> Can you provide steps how this can be reproduced?
> 
> 
> On Mon, 03 Jan 2022 19:36:59 +0100 Ivan Vilata i Balaguer 
> wrote:
> > Package: network-manager-gnome
> > Version: 1.24.0-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > After updating `network-manager-gnome`, the toggles "Enable Networking" and
> > "Enable Wi-Fi" that show on right-click over the `nm-applet` appear active 
> > but
> > grayed out and not responsive.  Also, if I choose "Edit Connections...", and
> > choose a connection in the "Network Connections" list, the "-" and gears
> > buttons in the bottom remain grayed out and a tooltip shows up with
> > "No polkit authorization to perform the action". […]

-- 
Ivan Vilata i Balaguer -- https://elvil.net/


signature.asc
Description: PGP signature

Bug#1008202: usrmerge: conversion fails in Docker container (due to overlayfs)

[Luca Boccassi]

Control: tags -1 patch

On Thu, 24 Mar 2022 18:55:59 +0100 Marco d'Itri  wrote:
> On Mar 24, Ansgar  wrote:
> 
> > For Debian, I think usrmerge.postinst should skip conversion in
case
> > overlayfs is used (without error, but possibly a warning message).
With
> I agree. The base image can be trivially converted anyway by
unpacking 
> it, using chroot, installing usrmerge and then repacking the image.
> 
> -- 
> ciao,
> Marco

Here's a MR that does that and a few bits of housekeeping:

https://salsa.debian.org/md/usrmerge/-/merge_requests/2

Tested with an unconverted chroot, opened with systemd-nspawn --
volatile=overlay --directory

-- 
Kind regards,
Luca Boccassi


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

Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail

[Daniel Kahn Gillmor]

On Tue 2022-03-29 19:09:50 +0100, Simon McVittie wrote:
> Major GNOME components are expected to be upgraded together, except for
> when that's unnecessary. That is an unsatisfying answer, but unfortunately
> it's the only true answer.

Thanks for the clarification, Simon, even if it's unsatisfying.  It's
disappointing to hear that about GNOME: i'd have expected the project
overall to have taken more time to think about API issues given the
amount of ecosystem knowledge (and dependency hell scars) that i'm sure
exists within the active developers.

I do understand the tradeoffs between rigidity and fluidity that you
describe, and how you can get unmanageable delays on one end, and hidden
breakage on the other. That tradeoff is precisely why i'm inclined to
gravitate toward declaring something API-like, even between "internal"
components.  I tend to think that approach will give the best balance
possible on that tradeoff, but i also recognize that getting there
requires some significant engineering investment (in both tooling and
training) if that's not already established practice.

>> GNOME typically does a good job in handling a novice user's behaviors
>> well without hassling them with confusing technical arcana, but that
>> means that silent and complete crashes like the one observed here just
>> look like unrecoverable breakage to the normal user who doesn't know
>> anything about stderr or how to launch settings from the terminal.
>
> Sorry, but that normal user probably should not be using unstable.

Agreed, the normal user is most likely to use a released version of
Ubuntu, which as you said is shipping a mixed set of packages.  Yikes!

Thanks very much for your work on GNOME, Simon!

   --dkg


signature.asc
Description: PGP signature

Bug#1007899: network-manager: L2TP-VPN doesn't work with network-manager version 1.36.2-1 (works with 1.34.0-1)

[Douglas Kosovic]

Hi Michael,

> Is there anything to fix on the network-manager package side or can
> this issue be closed?

With the upgrade of the network-manager package to 1.36.4-1, the
VPN routing issue appears to have been resolved.

I just checked again now that I'm not able to reproduce the issue,
so this issue can be closed.



Cheers,
Doug

Bug#1008572: ITP: xgboost-predictor-java -- Java implementation of XGBoost predictor for online prediction tasks

[M. Zhou]

On Tue, 2022-03-29 at 21:09 +0200, Pierre Gruet wrote:
> 
> > 
> > This team is dedicated to hardware acceleration,
> > machine learning, and deep learning. See
> > debian...@lists.debian.org
> > 
> 
> Now subscribed!
> 
> By the way, does the team have some policy? Or does it inherit its 
> policy from Debian Science or whatever?
> 

Many packages in the team were moved from the science team.
Simply following the science team policy is good enough.

Bug#1008641:

[Andreas Hasenack]

I believe these patches from upstream fix the build problem:

https://git.launchpad.net/ubuntu/+source/unbound/tree/debian/patches/python3.10.patch
https://git.launchpad.net/ubuntu/+source/unbound/tree/debian/patches/python3.10-2.patch

Bug#1008642: guix pull complains about "No such file or directory"

[Yuxuan Wang]

Package: guix
Version: 1.3.0-4
Severity: normal
X-Debbugs-Cc: fishyw...@gmail.com

Dear Maintainer,

I have been using both guix and nix-setup-systemd on this machine for a while,
until one day I run out of inodes on the root partition. At the time that
happened I knew it would be caused by one of guix and nix, but not sure which,
so I deleted both (by using `apt purge guix nix-setup-systemd` then
`rm -Rf /nix /gnu`).

When deleting both I realized that it's actually nix causing excessive inodes
used, not guix, so I tried to reinstall guix by `apt install guix`.

But after reinstalled guix it's no longer usable. Whenever I try guix pull it
throws:

$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 1d62b15 (100 new 
commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   1d62b15
guix pull: error: opening file 
`/gnu/store/046lwac3v42aw2ggvm7kgps143n4r768-xz.drv': No such file or directory

I checked my other machines with guix installed and they no longer have that
particular package under /gnu/store. My naive understanding is that it's a
package required by the versino of guix installed via `apt install guix`, but I
do not know how it should be populated during the first installation.

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages guix depends on:
ii  guile-3.0   3.0.8-2
ii  guile-3.0-libs  3.0.8-2
ii  guile-gcrypt0.3.0-4
ii  guile-git   0.5.2-3
ii  guile-gnutls3.7.3-4+b1
ii  guile-json  4.5.2-3
ii  guile-lzlib 0.0.2-3
ii  guile-sqlite3   0.1.3-3
ii  guile-ssh   0.13.1-6
ii  guile-zlib  0.1.0-4
ii  libbz2-1.0  1.0.8-5
ii  libc6   2.33-7
ii  libgcc-s1   12-20220319-1
ii  libgcrypt20 1.9.4-5
ii  libsqlite3-03.38.1-1
ii  libssh-dev  0.9.6-2
ii  libstdc++6  12-20220319-1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages guix recommends:
ii  nscd 2.33-7
ii  systemd  250.4-1

guix suggests no packages.

-- no debconf information

Bug#1004648: Please import upstream v1.18.6

[Nicholas D Steeves]

Control: retitle -1 Please import upstream v1.19.1

I imported 1.18.6 into the repo, and plan to upload when the blocking
bug is resolved.  That said, I decided to reuse this bug for upstream
v1.19.1, so have correspondingly retitled it; I won't close this bug
from the changelog of 1.18.6~ds1-1.

Cheers,
Nicholas


signature.asc
Description: PGP signature

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

[Bastian Blank]

On Tue, Mar 15, 2022 at 04:29:17PM +, Ian Jackson wrote:
>  1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
>  2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.

One additional point:
We currently have packages in the archive, which must be "3.0 (native)",
but are generated from other packages: all the secure boot signed
packages.

Example source package:
| Package: linux-signed-amd64
| Version: 5.17~rc8+1~exp1

is generated from binary package:
| Package: linux-image-amd64-signed-template
| Version: 5.17~rc8-1~exp1

Generating the source package needs to munge the version, just to
appease that version restriction.  This also means, adding dependencies
on versions is difficult, as both versions sort differently.  And bugs
are assigned to wrong versions, so version tracking does not work.

Regards,
Bastian

-- 
Kirk to Enterprise -- beam down yeoman Rand and a six-pack.

Bug#1008641: unbound: FTBFS: ./pythonmod/pythonmod.c:338: undefined reference to `_Py_fopen'

[Sebastian Ramacher]

Source: unbound
Version: 1.13.1-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)

unbound FTBFS:

libtool: link: ( cd ".libs" && rm -f "libunbound.la" && ln -s 
"../libunbound.la" "libunbound.la" )
./libtool --tag=CC --mode=link gcc   -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/python3.10 -DSRCDIR=. -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -pthread -I/usr/include/google -Wl,--as-needed 
-Wl,-z,relro -Wl,-z,now -o unbound acl_list.lo cachedump.lo daemon.lo 
shm_main.lo remote.lo stats.lo unbound.lo worker.lo  dns.lo infra.lo rrset.lo 
dname.lo msgencode.lo as112.lo msgparse.lo msgreply.lo packed_rrset.lo 
iterator.lo iter_delegpt.lo iter_donotq.lo iter_fwd.lo iter_hints.lo 
iter_priv.lo iter_resptype.lo iter_scrub.lo iter_utils.lo localzone.lo mesh.lo 
modstack.lo view.lo outbound_list.lo alloc.lo config_file.lo configlexer.lo 
configparser.lo fptr_wlist.lo edns.lo locks.lo log.lo mini_event.lo module.lo 
net_help.lo random.lo rbtree.lo regional.lo rtt.lo dnstree.lo lookup3.lo 
lruhash.lo slabhash.lo tcp_conn_limit.lo timehist.lo tube.lo winsock_event.lo 
autotrust.lo val_anchor.lo rpz.lo validator.lo val_kcache.lo val_kentry.lo 
val_neg.lo val_nsec3.lo val_nsec.lo val_secalgo.lo val_sigcrypt.lo val_utils.lo 
dns64.lo cachedb.lo redis.lo authzone.lo edns-subnet.lo subnetmod.lo 
addrtree.lo subnet-whitelist.lo pythonmod.lo pythonmod_utils.lo  dnstap.lo 
dnstap.pb-c.lo dnstap_fstrm.lo dtstream.lo respip.lo netevent.lo 
listen_dnsport.lo outside_network.lo ub_event.lo keyraw.lo sbuffer.lo 
wire2str.lo parse.lo parseutil.lo rrdef.lo str2wire.lo strlcat.lo strlcpy.lo 
arc4random.lo arc4random_uniform.lo arc4_lock.lo   -lssl -lprotobuf-c -levent 
-L/usr/lib/x86_64-linux-gnu -L/usr/lib/python3.10 -lpython3.10  -lsystemd 
-lcrypto 
libtool: link: gcc -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/python3.10 -DSRCDIR=. -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -I/usr/include/google -Wl,--as-needed -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -o unbound .libs/acl_list.o .libs/cachedump.o .libs/daemon.o 
.libs/shm_main.o .libs/remote.o .libs/stats.o .libs/unbound.o .libs/worker.o 
.libs/dns.o .libs/infra.o .libs/rrset.o .libs/dname.o .libs/msgencode.o 
.libs/as112.o .libs/msgparse.o .libs/msgreply.o .libs/packed_rrset.o 
.libs/iterator.o .libs/iter_delegpt.o .libs/iter_donotq.o .libs/iter_fwd.o 
.libs/iter_hints.o .libs/iter_priv.o .libs/iter_resptype.o .libs/iter_scrub.o 
.libs/iter_utils.o .libs/localzone.o .libs/mesh.o .libs/modstack.o .libs/view.o 
.libs/outbound_list.o .libs/alloc.o .libs/config_file.o .libs/configlexer.o 
.libs/configparser.o .libs/fptr_wlist.o .libs/edns.o .libs/locks.o .libs/log.o 
.libs/mini_event.o .libs/module.o .libs/net_help.o .libs/random.o 
.libs/rbtree.o .libs/regional.o .libs/rtt.o .libs/dnstree.o .libs/lookup3.o 
.libs/lruhash.o .libs/slabhash.o .libs/tcp_conn_limit.o .libs/timehist.o 
.libs/tube.o .libs/winsock_event.o .libs/autotrust.o .libs/val_anchor.o 
.libs/rpz.o .libs/validator.o .libs/val_kcache.o .libs/val_kentry.o 
.libs/val_neg.o .libs/val_nsec3.o .libs/val_nsec.o .libs/val_secalgo.o 
.libs/val_sigcrypt.o .libs/val_utils.o .libs/dns64.o .libs/cachedb.o 
.libs/redis.o .libs/authzone.o .libs/edns-subnet.o .libs/subnetmod.o 
.libs/addrtree.o .libs/subnet-whitelist.o .libs/pythonmod.o 
.libs/pythonmod_utils.o .libs/dnstap.o .libs/dnstap.pb-c.o .libs/dnstap_fstrm.o 
.libs/dtstream.o .libs/respip.o .libs/netevent.o .libs/listen_dnsport.o 
.libs/outside_network.o .libs/ub_event.o .libs/keyraw.o .libs/sbuffer.o 
.libs/wire2str.o .libs/parse.o .libs/parseutil.o .libs/rrdef.o .libs/str2wire.o 
.libs/strlcat.o .libs/strlcpy.o .libs/arc4random.o .libs/arc4random_uniform.o 
.libs/arc4_lock.o  -lssl -lprotobuf-c -levent -L/usr/lib/x86_64-linux-gnu 
-L/usr/lib/python3.10 -lpython3.10 -lsystemd -lcrypto -pthread 
/usr/bin/ld: .libs/pythonmod.o: in function `pythonmod_init':
./pythonmod/pythonmod.c:338: undefined reference to `_Py_fopen'
/usr/bin/ld: ./pythonmod/pythonmod.c:371: undefined reference to 
`PyParser_SimpleParseFile'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:350: unbound] Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=unbound&arch=amd64&ver=1.13.1-1%2Bb1&stamp=1648466560&raw=0

Cheers
-- 
Sebastian Ramacher

Bug#1008640: scikit-fmm: FTBFS: /usr/include/python3.10/object.h:133:33: error: lvalue required as increment operand

[Sebastian Ramacher]

Source: scikit-fmm
Version: 2019.1.30-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)

scikit-fmm FTBFS:

compile options: '-I/usr/lib/python3/dist-packages/numpy/core/include 
-Ibuild/src.linux-x86_64-3.9/numpy/distutils/include -I/usr/include/python3.9 
-c'
extra options: '-msse -msse2 -msse3'
x86_64-linux-gnu-g++: skfmm/pheap.cpp
x86_64-linux-gnu-g++: skfmm/heap.cpp
In file included from /usr/include/python3.10/Python.h:74,
 from skfmm/pheap.cpp:16:
skfmm/pheap.cpp: In function ‘void 
__pyx_tp_dealloc_5skfmm_5pheap_pheap(PyObject*)’:
/usr/include/python3.10/object.h:133:33: error: lvalue required as increment 
operand
  133 | #define Py_REFCNT(ob) _Py_REFCNT(_PyObject_CAST_CONST(ob))
  |   ~~^~
skfmm/pheap.cpp:1257:7: note: in expansion of macro ‘Py_REFCNT’
 1257 | ++Py_REFCNT(o);
  |   ^
/usr/include/python3.10/object.h:133:33: error: lvalue required as decrement 
operand
  133 | #define Py_REFCNT(ob) _Py_REFCNT(_PyObject_CAST_CONST(ob))
  |   ~~^~
skfmm/pheap.cpp:1260:7: note: in expansion of macro ‘Py_REFCNT’
 1260 | --Py_REFCNT(o);
  |   ^
In file included from /usr/include/python3.10/unicodeobject.h:1046,
 from /usr/include/python3.10/Python.h:83,
 from skfmm/pheap.cpp:16:
skfmm/pheap.cpp: In function ‘int __Pyx_ParseOptionalKeywords(PyObject*, 
PyObject***, PyObject*, PyObject**, Py_ssize_t, const char*)’:
/usr/include/python3.10/cpython/unicodeobject.h:451:61: warning: ‘Py_ssize_t 
_PyUnicode_get_wstr_length(PyObject*)’ is deprecated [-Wdeprecated-declarations]
  451 | #define PyUnicode_WSTR_LENGTH(op) 
_PyUnicode_get_wstr_length((PyObject*)op)
  |   
~~^~~
/usr/include/python3.10/cpython/unicodeobject.h:261:7: note: in expansion of 
macro ‘PyUnicode_WSTR_LENGTH’
  261 |   PyUnicode_WSTR_LENGTH(op) :\
  |   ^
skfmm/pheap.cpp:1598:22: note: in expansion of macro ‘PyUnicode_GET_SIZE’
 1598 | (PyUnicode_GET_SIZE(**name) != 
PyUnicode_GET_SIZE(key)) ? 1 :
  |  ^~
/usr/include/python3.10/cpython/unicodeobject.h:446:26: note: declared here
  446 | static inline Py_ssize_t _PyUnicode_get_wstr_length(PyObject *op) {
  |  ^~
/usr/include/python3.10/cpython/unicodeobject.h:262:33: warning: ‘Py_UNICODE* 
PyUnicode_AsUnicode(PyObject*)’ is deprecated [-Wdeprecated-declarations]
  262 |   ((void)PyUnicode_AsUnicode(_PyObject_CAST(op)),\
  |  ~~~^~~~
skfmm/pheap.cpp:1598:22: note: in expansion of macro ‘PyUnicode_GET_SIZE’
 1598 | (PyUnicode_GET_SIZE(**name) != 
PyUnicode_GET_SIZE(key)) ? 1 :
  |  ^~
/usr/include/python3.10/cpython/unicodeobject.h:580:45: note: declared here
  580 | Py_DEPRECATED(3.3) PyAPI_FUNC(Py_UNICODE *) PyUnicode_AsUnicode(
  | ^~~
/usr/include/python3.10/cpython/unicodeobject.h:451:61: warning: ‘Py_ssize_t 
_PyUnicode_get_wstr_length(PyObject*)’ is deprecated [-Wdeprecated-declarations]
  451 | #define PyUnicode_WSTR_LENGTH(op) 
_PyUnicode_get_wstr_length((PyObject*)op)
  |   
~~^~~
/usr/include/python3.10/cpython/unicodeobject.h:264:8: note: in expansion of 
macro ‘PyUnicode_WSTR_LENGTH’
  264 |PyUnicode_WSTR_LENGTH(op)))
  |^
skfmm/pheap.cpp:1598:22: note: in expansion of macro ‘PyUnicode_GET_SIZE’
 1598 | (PyUnicode_GET_SIZE(**name) != 
PyUnicode_GET_SIZE(key)) ? 1 :
  |  ^~
/usr/include/python3.10/cpython/unicodeobject.h:446:26: note: declared here
  446 | static inline Py_ssize_t _PyUnicode_get_wstr_length(PyObject *op) {
  |  ^~
/usr/include/python3.10/cpython/unicodeobject.h:451:61: warning: ‘Py_ssize_t 
_PyUnicode_get_wstr_length(PyObject*)’ is deprecated [-Wdeprecated-declarations]
  451 | #define PyUnicode_WSTR_LENGTH(op) 
_PyUnicode_get_wstr_length((PyObject*)op)
  |   
~~^~~
/usr/include/python3.10/cpython/unicodeobject.h:261:7: note: in expansion of 
macro ‘PyUnicode_WSTR_LENGTH’
  261 |   PyUnicode_WSTR_LENGTH(op) :\
  |   ^
skfmm/pheap.cpp:1598:52: note: in expansion of macro ‘PyUnicode_GET_SIZE’
 1598 | (PyUnicode_GET_SIZE(**name) != 
PyUnicode_GET_SIZE(key)) ? 1 :
  |^~~~

Bug#1008639: libsigrokdecode: FTBFS: ./.libs/libsigrokdecode.so: undefined reference to `PyList_Insert'

[Sebastian Ramacher]

Source: libsigrokdecode
Version: 0.5.3-2
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)

libsigrokdecode FTBFS:

/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyList_Insert'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyModule_AddObject'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PySys_GetObject'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyDict_SetItemString'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyType_GenericNew'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyImport_Import'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyList_GetItem'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyBytes_AsStringAndSize'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyObject_CallMethod'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyGILState_Release'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyBytes_Size'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyBool_FromLong'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyUnicode_FromString'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyObject_CallFunctionObjArgs'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyExc_TypeError'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`Py_InitializeEx'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyExc_Exception'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyObject_Str'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyDict_Next'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyLong_AsLong'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyModule_AddIntConstant'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyErr_Format'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyFloat_FromDouble'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyArg_ParseTuple'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyErr_Occurred'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PySet_Pop'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyObject_IsSubclass'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyArg_ParseTupleAndKeywords'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyFloat_Type'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyExc_IndexError'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyEval_InitThreads'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`_Py_FalseStruct'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyEval_RestoreThread'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyBytes_AsString'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyType_FromSpec'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `_Py_TrueStruct'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyEval_SaveThread'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyDict_Size'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PySequence_GetItem'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyDict_GetItem'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PySequence_Size'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyList_Size'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyType_IsSubtype'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `Py_DecRef'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyGILState_Ensure'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyErr_NormalizeException'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyObject_CallObject'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyType_GetFlags'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyErr_Fetch'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyFloat_AsDouble'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PySequence_Check'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyLong_AsSize_t'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PySet_Add'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `Py_BuildValue'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyObject_GetAttrString'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to `PyLong_Type'
/usr/bin/ld: ./.libs/libsigrokdecode.so: undefined reference to 
`PyObject_SetAttrString'
/usr/bin/ld: ./.libs/libsigrokdecode.so: 

Bug#1008638: ldns: FTBFS: checking for the distutils Python package... no

[Sebastian Ramacher]

Source: ldns
Version: 1.7.1-2
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)

ldns FTBFS:

checking for the distutils Python package... no
configure: error: cannot import Python module "distutils".
Please check your Python installation. The error was:
:1: DeprecationWarning: The distutils package is deprecated and slated 
for removal in Python 3.12. Use setuptools or check PEP 632 for potential 
alternatives


See
https://buildd.debian.org/status/fetch.php?pkg=ldns&arch=amd64&ver=1.7.1-2%2Bb2&stamp=1648456911&raw=0

Cheers
-- 
Sebastian Ramacher

Bug#1003078: network-manager-gnome: Can't disable Networking/Wi-Fi, can't remove/edit connections (No polkit authorization)

[Michael Biebl]

Control: tags -1 + moreinfo

Which desktop environment is this?
Can you provide steps how this can be reproduced?


On Mon, 03 Jan 2022 19:36:59 +0100 Ivan Vilata i Balaguer 
 wrote:

Package: network-manager-gnome
Version: 1.24.0-1
Severity: normal

Dear Maintainer,

After updating `network-manager-gnome`, the toggles "Enable Networking" and
"Enable Wi-Fi" that show on right-click over the `nm-applet` appear active but
grayed out and not responsive.  Also, if I choose "Edit Connections...", and
choose a connection in the "Network Connections" list, the "-" and gears
buttons in the bottom remain grayed out and a tooltip shows up with
"No polkit authorization to perform the action".

Since I'm not running the whole GNOME, I installed `policykit-1-gnome`, ran
`/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1` and restarted
`nm-applet` with same results.  As my user belongs to `netdev`, I also tried
the `/etc/polkit-1/localauthority/50-local.d/WHATEVER.pkla` config mentioned
in #642136 to no avail (after restarting polkit and NetworkManager):

[Adding or changing system-wide NetworkManager connections]
Identity=unix-group:netdev
Action=org.freedesktop.NetworkManager.settings.modify.system
ResultAny=no
ResultInactive=no
ResultActive=yes

Other applets like `nm-tray` allow me to disable Networking/Wi-Fi without
issues, and `nmtui-*` tools allow me to edit connections just fine, so it
seems specific to this package and not `network-manager`.

Thanks a lot, and cheers!

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE=ca:es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-3
ii  dbus-x11 [dbus-session-bus]   1.12.20-3
ii  libatk1.0-0   2.36.0-3
ii  libayatana-appindicator3-10.5.90-5
ii  libc6 2.33-1
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.70.2-1
ii  libgtk-3-03.24.31-1
ii  libjansson4   2.13.1-1.1
ii  libmm-glib0   1.18.4-1
ii  libnm01.32.12-1
ii  libnma0   1.8.32-1


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008281: iputils-ping: Move from capabilities to non-raw ICMP sockets

[Petr Vorel]

> Correct term is "ICMP_PROTO sockets".

No, the correct term is non-raw ICMP socket.
Sorry for a confusion.

Kind regards,
Petr

Bug#1008637: crossfire: cfpython.c:63:10: fatal error: node.h: No such file or directory

[Sebastian Ramacher]

Source: crossfire
Version: 1.75.0-3
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)

crossfire FTBFS:

cfpython.c:63:10: fatal error: node.h: No such file or directory
   63 | #include 
  |  ^~~~
compilation terminated.


See
https://buildd.debian.org/status/fetch.php?pkg=crossfire&arch=amd64&ver=1.75.0-3%2Bb1&stamp=1648451503&raw=0

Cheers
-- 
Sebastian Ramacher

Bug#1008636: cluster3: rebuild with Python 3.10 as default

[Sebastian Ramacher]

Source: cluster3
Version: 1.59+ds-3
Severity: serious

cluster3 is not auto-builddable, so it requires a manual rebuild for the
python3.10-default transition. Please upload a build with Python 3.10 as
default.

Cheers
-- 
Sebastian Ramacher

Bug#1008635: atropos: ImportError: cannot import name 'Iterable' from 'collections' (/usr/lib/python3.10/collections/__init__.py)

[Sebastian Ramacher]

Source: atropos
Version: 1.1.31+dfsg-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)

atropos FTBFS with python 3.10

E   ImportError: cannot import name 'Iterable' from 'collections' 
(/usr/lib/python3.10/collections/__init__.py)
___ ERROR collecting .pybuild/cpython3_3.10/build/tests/test_trim.py ___
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.10/build/tests/test_trim.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/test_trim.py:2: in 
from atropos.adapters import Adapter, ColorspaceAdapter, PREFIX, BACK
atropos/adapters/__init__.py:13: in 
from atropos import align
atropos/align/__init__.py:7: in 
from atropos.util import RandomMatchProbability, reverse_complement
atropos/util/__init__.py:3: in 
from collections import OrderedDict, Iterable, Sequence
E   ImportError: cannot import name 'Iterable' from 'collections' 
(/usr/lib/python3.10/collections/__init__.py)
=== warnings summary ===
tests/test_paired.py:612
  /<>/.pybuild/cpython3_3.10/build/tests/test_paired.py:612: 
PytestUnknownMarkWarning: Unknown pytest.mark.timeout - is this a typo?  You 
can register custom marks to avoid this warning - for details, see 
https://docs.pytest.org/en/stable/mark.html
@pytest.mark.timeout(10)

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info 
ERROR tests/test_adapters.py
ERROR tests/test_align.py
ERROR tests/test_colorspace.py
ERROR tests/test_commands.py
ERROR tests/test_filters.py
ERROR tests/test_modifiers.py
ERROR tests/test_multicore.py
ERROR tests/test_qualtrim.py
ERROR tests/test_seqio.py
ERROR tests/test_trim.py
!!! Interrupted: 10 errors during collection !!!
 1 warning, 10 errors in 1.05s =
E: pybuild pybuild:367: test: plugin distutils failed with: exit code=2: cd 
/<>/.pybuild/cpython3_3.10/build; python3.10 -m pytest tests
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 
"--before-test=ln -s /<>/tests/cut {build_dir}/tests && ln -s 
/<>/tests/data {build_dir}/tests" returned exit code 13

See
https://buildd.debian.org/status/fetch.php?pkg=atropos&arch=amd64&ver=1.1.31%2Bdfsg-1%2Bb1&stamp=1648449686&raw=0

Cheers
-- 
Sebastian Ramacher

Bug#1008611: bambam autopkgtest failure with pygame 2.1

[Marcin Owsiany]

Thanks for the report. Since showing text is proven to still work (as seen
in the screenshots) I suspect the app is no longer receiving the
(simulated) keypresses, because otherwise it should show at least the
colorful "m" letters (even if rendering pictures would stop working for
some reason).

To fix this, I need to figure out a way to interactively run the app
against the new version of the library without messing up my (Debian
stable) system... I'll try running it under xvfb in a container, but other
ideas most welcome :-)

Marcin

Bug#1008634: condor: CVE-2022-26110 / HTCONDOR-2022-0003

[Salvatore Bonaccorso]

Source: condor
Version: 8.6.8~dfsg.1-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for condor.

CVE-2022-26110[0], HTCONDOR-2022-0003

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-2022-26110
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26110
[1] https://htcondor.org/security/vulnerabilities/HTCONDOR-2022-0003

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008633: node-spdx-license-ids: autopkgtest regression: Cannot find module 'fettuccine-class'

[Paul Gevers]

Source: node-spdx-license-ids
Version: 3.0.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, since the start of 
2022, it started to fail in testing. I copied some of the output at the 
bottom of this report.


Failing tests are considered RC bugs by the release team.

Paul

[1] https://ci.debian.net/packages/n/node-spdx-license-ids/

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-spdx-license-ids/20269931/log.gz

autopkgtest [11:24:40]: test pkg-js-autopkgtest-require: 
/usr/share/pkg-js-autopkgtest/runner require
autopkgtest [11:24:40]: test pkg-js-autopkgtest-require: 
[---

# Using ./package.(json|yaml)
# Node module name is spdx-license-ids
# Test: require
#   Testing spdx-license-ids: SKIPPED
#   Testing get-spdx-license-ids: internal/modules/cjs/loader.js:818
  throw err;
  ^

Error: Cannot find module 'fettuccine-class'
Require stack:
- /usr/share/nodejs/get-spdx-license-ids/index.js
- /tmp/autopkgtest-lxc.49dkppxa/downtmp/autopkgtest_tmp/[eval]
at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:815:15)

at Function.Module._load (internal/modules/cjs/loader.js:667:27)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. 
(/usr/share/nodejs/get-spdx-license-ids/index.js:3:19)

at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:1027:10)

at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/usr/share/nodejs/get-spdx-license-ids/index.js',
'/tmp/autopkgtest-lxc.49dkppxa/downtmp/autopkgtest_tmp/[eval]'
  ]
}
not ok
autopkgtest [11:24:42]: test pkg-js-autopkgtest-require: 
---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008172: ffmpeg: Please enable librist

[Sebastian Ramacher]

Control: tags -1 pending

On 2022-03-23 16:24:26, Florian Ernst wrote:
> Source: ffmpeg
> Version: 7:4.4.1-3
> Severity: wishlist
> Tags: patch
> 
> Dear maintainers,
> 
> now that  is available (thanks
> to really quick NEW processing) please enable librist in ffmpeg as per
> the attached patch.
> 
> For reference, quoting from the package description
> | Reliable Internet Stream Transport (RIST) is a transport protocol
> | designed for reliable transmission of video over lossy networks
> | (including the Internet) with low latency and high quality.
> | .
> | RIST is intended as a more reliable successor to Secure Reliable
> | Transport (SRT), and as an open alternative to proprietary commercial
> | options such as Zixi, VideoFlow, QVidium, and DVEO (Dozer).
> 
> And for further elaborating my motivation please see the ITP at
> .
> I just confirmed that with the attached patch ffmpeg still builds fine,
> resulting in the same debdiff as presented in that ITP.

Thanks for the patch, applied on the branch for 5.0.

Cheers

> 
> Cheers,
> Flo

> diff -Nru ffmpeg-4.4.1/debian/control ffmpeg-4.4.1/debian/control
> --- ffmpeg-4.4.1/debian/control   2022-01-15 16:31:36.0 +0100
> +++ ffmpeg-4.4.1/debian/control   2022-03-19 09:49:07.0 +0100
> @@ -109,6 +109,8 @@
>   libpulse-dev,
>  # --enable-librabbitmq
>   librabbitmq-dev,
> +# --enable-librist
> + librist-dev,
>  # --enable-librubberband
>   librubberband-dev,
>  # --enable-librsvg
> diff -Nru ffmpeg-4.4.1/debian/rules ffmpeg-4.4.1/debian/rules
> --- ffmpeg-4.4.1/debian/rules 2021-11-21 18:30:36.0 +0100
> +++ ffmpeg-4.4.1/debian/rules 2022-03-19 09:49:07.0 +0100
> @@ -52,6 +52,7 @@
>   --enable-libopus \
>   --enable-libpulse \
>   --enable-librabbitmq \
> + --enable-librist \
>   --enable-librubberband \
>   --enable-libshine \
>   --enable-libsnappy \




-- 
Sebastian Ramacher

Bug#907029: buici-clock: diff for NMU version 0.4.9.4+nmu2

[Sudip Mukherjee]

Control: tags 907029 + patch
Control: tags 907029 + pending
--

Dear maintainer,

I've prepared an NMU for buici-clock (versioned as 0.4.9.4+nmu2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

--
Regards
Sudip

diff -Nru buici-clock-0.4.9.4+nmu1/clock.cxx buici-clock-0.4.9.4+nmu2/clock.cxx
--- buici-clock-0.4.9.4+nmu1/clock.cxx  2021-01-14 21:27:49.0 +
+++ buici-clock-0.4.9.4+nmu2/clock.cxx  2022-03-29 20:13:18.0 +0100
@@ -106,7 +106,8 @@
 void draw_dial (Display* display, Visual* visual,
Pixmap pixmap, int dx, int dy);
 void draw_hands (Display* display, Visual* visual,
-   Pixmap pixmap, int dx, int dy, int seconds);
+   Pixmap pixmap, int dx, int dy, int seconds,
+   bool showSecondHand);
 void draw_dial_shape (Display* display, Pixmap pixmap, int dx, int dy);
 
 class WTopLevel : public LWindow {
@@ -538,7 +539,7 @@
 _gc, 0, 0, width (), height (), 0, 0);
 
 
-  draw_hands (xdisplay (), xvisual (), pixmap, width (), height (), seconds);
+  draw_hands (xdisplay (), xvisual (), pixmap, width (), height (), seconds, 
m_fSecondHand);
 
 #if 0
// -- Draw hands
diff -Nru buici-clock-0.4.9.4+nmu1/debian/changelog 
buici-clock-0.4.9.4+nmu2/debian/changelog
--- buici-clock-0.4.9.4+nmu1/debian/changelog   2021-01-14 22:05:45.0 
+
+++ buici-clock-0.4.9.4+nmu2/debian/changelog   2022-03-29 20:33:23.0 
+0100
@@ -1,3 +1,11 @@
+buici-clock (0.4.9.4+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix showSecondHand. (Closes: #907029)
+- Thanks Jason for the patch.
+
+ -- Sudip Mukherjee   Tue, 29 Mar 2022 20:33:23 
+0100
+
 buici-clock (0.4.9.4+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru buici-clock-0.4.9.4+nmu1/draw.cc buici-clock-0.4.9.4+nmu2/draw.cc
--- buici-clock-0.4.9.4+nmu1/draw.cc2021-01-14 21:27:49.0 +
+++ buici-clock-0.4.9.4+nmu2/draw.cc2022-03-29 20:13:18.0 +0100
@@ -145,7 +145,8 @@
 
 
 void draw_hands (Display* display, Visual* visual,
-Pixmap pixmap, int dx, int dy, int seconds)
+Pixmap pixmap, int dx, int dy, int seconds,
+bool showSecondHand)
 {
   cairo_surface_t* s = cairo_xlib_surface_create (display, pixmap, visual,
  dx, dy);
@@ -198,16 +199,18 @@
 cairo_path_destroy (path);
 
// Second hand
-cairo_save (cr);
-cairo_rotate (cr, ((2.0*M_PI)*seconds)/60.0);
-cairo_set_line_width (cr, WIDTH_THIN);
-cairo_move_to (cr, 0,  (DY/2.0)*0.20);
-cairo_line_to (cr, 0, -(DY/2.0)*0.64);
-cairo_set_source_rgb (cr, 1.0, 0, 0);
-cairo_stroke (cr);
-cairo_arc (cr, 0, -(DY/2.0)*0.64, DX*0.03, 0, 2*M_PI);
-cairo_fill (cr);
-cairo_restore (cr);
+if (showSecondHand){
+cairo_save (cr);
+cairo_rotate (cr, ((2.0*M_PI)*seconds)/60.0);
+cairo_set_line_width (cr, WIDTH_THIN);
+cairo_move_to (cr, 0,  (DY/2.0)*0.20);
+cairo_line_to (cr, 0, -(DY/2.0)*0.64);
+cairo_set_source_rgb (cr, 1.0, 0, 0);
+cairo_stroke (cr);
+cairo_arc (cr, 0, -(DY/2.0)*0.64, DX*0.03, 0, 2*M_PI);
+cairo_fill (cr);
+cairo_restore (cr);
+}
   }
 
   cairo_destroy (cr);

Bug#1007899: network-manager: L2TP-VPN doesn't work with network-manager version 1.36.2-1 (works with 1.34.0-1)

[Michael Biebl]

Hi Doug

On Tue, 22 Mar 2022 00:38:54 + Douglas Kosovic  wrote:

I suspect this is the same as the following upstream NetworkManager 1.36.2
routing bug:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/946

I assume you have enabled the "Use this connection only for resources on
its network" checkbox in the VPN connection's IPv4 settings? In which
case network-manager 1.36.2 doesn't appear to be adding any routes for
the VPN connection like it does if the checkbox isn't enabled or did
with earlier versions of NetworkManager.


Is there anything to fix on the network-manager package side or can this 
issue be closed?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008632: O: closure-compiler -- JavaScript optimizing compiler

[Thomas Koch]

Package: wnpp
Severity: normal
X-Debbugs-Cc: tho...@koch.ro, s...@debian.org, 733...@bugs.debian.org, 
tmanc...@debian.org, prav...@debian.org
Control: affects -1 src:closure-compiler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the closure-compiler package.

The package description is:
 Closure Compiler is a JavaScript optimizing compiler. It parses your
 JavaScript, analyzes it, removes dead code and rewrites and minimizes
 what's left. It also checks syntax, variable references, and types, and
 warns about common JavaScript pitfalls. It is used in many of Google's
 JavaScript apps, including Gmail, Google Web Search, Google Maps, and
 Google Docs.
 .
 This package contains the /usr/bin wrapper script and manpage.


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmJDXtUACgkQB/xIkQQr
plqvsg/9HrMYaBuwCBUABsIxmJOFywNYq4WhCDpWEBs1s7mS7gT0qHW2LLtj3ZX7
wizH0zvRrJqIfw8EiBpQeUnVUHKzjDjXaM5BrBe/mLPTT5TOS0iqIwCCrMcIvJUS
0rSl8u/aLsiaD42KpUa7gJmt/KFRVKh0TgwceclPl3vSbMT1Hk+Jy25d/aK+s3VB
tUdkDwfZ+EGz7uZlYlEZ4eSaf1sDK5y/HoRpitNFazsJ44IT6GtvJgY34VEm/ocz
XptncbgTLUufOzSNyTgaODaDHiDX9VuVbotZ2sXIpYEyfZPVyrLgTv0xcGk/9iSF
HyRUaBgg044dYr3zUK++wQ6MJXtIx6vqv2KYSc2o2mK42JwwbhkiiLmRuz/GIvJs
p80kMdykfAfseSEB815MyVg4HPPf4lB1tC4vEJN7NwrJC7LcDBxLtZpdTPVQ/Ear
uTpo2CVV4IxfiY8ynobR+2A1ShOZtHkCE4FxzRe2ZtCDWPBMOsV1YNyMDol69RNm
flTfQa7Ya/7IrOk4xGRZh5SO2nNJlKEKxsGUYPob3C8m6VEsqEwxv1Z07wjXxkge
vZEUjLh9A0VpRJefUwZzqlv1Ef5DpJ/5XL5isSdCuhYY2I5a3k+8G1/6xRSj5b7Z
XA/IrIgnx3hScgZ/xGBRWA0nTpOP+wpKgURnag0E9ZrSJewiBUI=
=tftf
-END PGP SIGNATURE-

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

[Lucas Nussbaum]

Hi Sean,

On 28/03/22 at 16:21 -0700, Sean Whitton wrote:
> Hello Lucas,
> 
> Many thanks for providing this summary of your position.  Let me just
> note a point of disagreement:
> 
> On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote:
> 
> > A point that I find important is the following: as a project, I think
> > that we care about facilitating the review of changes we make to
> > upstream source.
> 
> Certainly we do.
> 
> > I think that the preferred method (and widely accepted method) for
> > that is currently to use the 3.0 (quilt) format with DEP-3-documented
> > patches, on top of a tarball that contains the pristine upstream
> > source.
> >
> > The git packaging workflows that generate source packages using either
> > 1.0 native packages, or 1.0 non-native packages without patches, make it
> > harder to identify and review those changes, as they require browsing
> > the git repository, which sometimes is not properly documented using
> > Vcs-*.
> 
> I don't think it's the preferred method.  I believe most of the project
> sees git histories are the preferred tool for achieving the goal you
> state.
> 
> If we had only source packages for this purpose, then yes, 3.0 (quilt)
> plus DEP-3 would be preferred.  But we have git, too, and indeed dgit.
> Repositories for packages contain both upstream history and Debian
> packaging history, and we have powerful git subcommands for extracting
> information.  In many cases there is a good argument to be made that the
> git history is part of the preferred form of modification.

I think there are three different use cases to consider:

  A. preferred form for regular contributions to the package (typically
  by the package maintainer)

  B. preferred form for occasional contributions to the package (typically
  by an NMUer, or by the security team)

  C. preferred form for reviewing the packaging and Debian-specific
  changes.


I fully agree that the git repository is the preferred form for A.
However, for B and C, I think that our lingua franca is the source
package, and thus a source package that doesn't make it hard to
understand things such as Debian-specific patches. Of course that
could change if we were able to standardize on a git workflow (or
a small set of git workflows), but I don't see this happenning anytime
soon.

Lucas

Bug#1008628: gnome-online-accounts: Online accounts disappeared from gnome-control-center

[Paolo Redaelli]

Il 29/03/22 21:24, Simon McVittie ha scritto:

Control: tags -1 + moreinfo unreproducible

On Tue, 29 Mar 2022 at 20:40:03 +0200, Paolo Redaelli wrote:

the Online Account section of gnome control center disappered.

I tried to explicitly invoke it with "gnome-control-center online-accounts" and 
all I got is this error:

(gnome-control-center:49141): cc-window-WARNING **: 20:37:31.872: Could not find settings 
panel "online-accounts"

This works for me, with gnome-control-center 1:41.4-2, but I can't find any
changes between 1:41.4-1 and 1:41.4-2 that look related...


I have skipped some versions; I don't know when this issue started.

I went through 3.38.0-3 → 3.38.1-2 → 3.40.0-2 → 3.40.1-2 → 3.43.1-1

I noticed it now but I can't say when it began

Bug#1008628: gnome-online-accounts: Online accounts disappeared from gnome-control-center

[Paolo Redaelli]

Il 29/03/22 21:24, Simon McVittie ha scritto:

Control: tags -1 + moreinfo unreproducible

On Tue, 29 Mar 2022 at 20:40:03 +0200, Paolo Redaelli wrote:

the Online Account section of gnome control center disappered.

I tried to explicitly invoke it with "gnome-control-center online-accounts" and 
all I got is this error:

(gnome-control-center:49141): cc-window-WARNING **: 20:37:31.872: Could not find settings 
panel "online-accounts"

This works for me, with gnome-control-center 1:41.4-2, but I can't find any
changes between 1:41.4-1 and 1:41.4-2 that look related...

Does

 debsums -c gnome-control-center

report any changes?


No, it doesn't, even after issuing:

sudo apt install --reinstall gnome-control-center gnome-online-accounts

Bug#1006836: transition: python3.10 as default

[Graham Inggs]

Hi Markus

On Mon, 28 Mar 2022 at 20:01, Graham Inggs  wrote:
> I don't think anything is needed right now, thanks.  I will schedule a
> rebuild of opm-common once graphviz has built, and then retry
> opm-simulators.

It seems opm-simulators FTBFS in much the same way now after
opm-common has been rebuilt.

Regards
Graham

Bug#1008631: RFS: git-revise/0.7.0-1 -- handy git tool for doing efficient in-memory commit rebases

[Nicolas Schier]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "git-revise":

 * Package name: git-revise
   Version : 0.7.0-1
   Upstream Author : Nika Layzell 
 * URL : https://mystor.github.io/git-revise.html
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/git-revise
   Section : vcs

The source builds the following binary packages:

  git-revise - handy git tool for doing efficient in-memory commit rebases & 
fixups

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

  https://mentors.debian.net/package/git-revise/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-revise/git-revise_0.7.0-1.dsc

Changes since the last upload:

 git-revise (0.7.0-1) unstable; urgency=medium
 .
   * Fix package section to "vcs" (Closes: #1002543);
 thanks to Jonas Smedegaard
   * debian/gbp.conf: Add basic git-buildpackage configuration
   * New upstream version 0.7.0
   * Remove obsolete patches
   * d/tests/control: Add test dependencies gpg, gpg-agent

Kind regards,
Nicolas


signature.asc
Description: PGP signature

Bug#733586: closure-compiler: new upstream version available

[Nicholas D Steeves]

Hello Thomas and Tony,

CCing Javascript team (JS Team, please see below for why), and fixing
threading, since top-posting is confusing.  Reply follows inline:

Thomas Koch  writes:
>> tony mancill  hat am 29.03.2022 07:26 geschrieben:
>> > On Mon, Mar 28, 2022 at 03:27:17PM -0400, Nicholas D Steeves wrote:
>> > 
>> > This package came to my attention via #975505, where it was noted that
>> > MathJax2 has had to disable functionality because of too ancient of a
>> > closure-compiler, and at this time it appears that MathJax3 will have to
>> > do the same.
>> > 
>> > Closure-compiler is a candidate for salvaging:
>> > 
>> >   https://wiki.debian.org/PackageSalvaging
>> >   
>> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
>> > 
>> > The ideal resolution would be for one of the listed Uploaders to resume
>> > maintenance of the package, but orphaning is of course also an option :-)
>> 
>> The closure-compiler package is officially a team-maintained package by
>> the Java Team, so you or anyone else who is interested in joining Java
>> Team and maintaining the package is welcome to do so.  That is, please
>> feel free to add yourself to Uploaders.
>> 
>> That said, it's more of a JavaScript tool than a Java package, and so
>> the package could also be moved to another team if that's preferable.
>> 
>> I will gladly help with either of those options, or with reviewing and
>> sponsoring an upload of a newer version if one is made available.
>> 
>> Finally, I have never been a user of closure-compiler - my packaging
>> work on it has been under the Java Team umbrella - and I have
>> (obviously) been unable to devote sufficient time to it.  I will remove
>> myself from Uploaders to avoid any future confusion.
>>
>
> Hello,
>
> sorry, I was under the wrong impression that closure-compiler would be
> abandoned upstream and that it would eventually die of age and be
> removed.  I packaged closure-compiler as a dependency of the code
> review system Gerrit which however couldn't be packaged at the time
> due to GWT.
>
> Whoever does another upload to closure-compiler please also remove me
> from uploaders.
>
> Thank you!
>

Thank you both for your quick reply!  Your clarification and context is
much appreciated :-)  While closure-compiler is currently under the Java
Team umbrella, removing both human uploaders will create a Policy §3.3
violation (the need for a human Maintainer/Uploader is unfulfilled):

  https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer

Closure-compiler must be formally orphaned for this reason.

There is additionally a practical reason to orphan it: The maintainers
of all packages that depend on it will receive a Package Tracker
notification that it is unmaintained; This includes transitive
dependencies via MathJax2 (sigil, pandoc, etc).  Furthermore, it will
show up on the list of packages that prospective DMs and DDs investigate
as part of their process.  If I remember correctly the orphan bug will
also appear for developers who have the "how-can-i-help" package
installed.

Thus, please file the wnpp Orphan bug, because it's clearly the correct
avenue forward, and because it maximises the chance of finding a new
maintainer.

Cheers!
Nicholas


signature.asc
Description: PGP signature

Bug#1008628: gnome-online-accounts: Online accounts disappeared from gnome-control-center

[Simon McVittie]

Control: tags -1 + moreinfo unreproducible

On Tue, 29 Mar 2022 at 20:40:03 +0200, Paolo Redaelli wrote:
> the Online Account section of gnome control center disappered.
> 
> I tried to explicitly invoke it with "gnome-control-center online-accounts" 
> and all I got is this error:
> 
> (gnome-control-center:49141): cc-window-WARNING **: 20:37:31.872: Could not 
> find settings panel "online-accounts"

This works for me, with gnome-control-center 1:41.4-2, but I can't find any
changes between 1:41.4-1 and 1:41.4-2 that look related...

Does

debsums -c gnome-control-center

report any changes?

smcv

Bug#950182: [Pkg-puppet-devel] Bug#950182: Puppet 5.5 EOL in November 2020

[Antoine Beaupré]

On 2022-03-29 21:14:42, Thomas Goirand wrote:
> On 3/29/22 20:58, Antoine Beaupré wrote:
>> On 2020-05-16 21:13:25, Martin Konrad wrote:
>>> Hi,
 The others are related to other operating systems than Debian, so I
 really wonder if we need them (yum, really? zfs and zone are for
 Solaris, and scheduled_task is for windows...).
>>> If we want to make transitioning from Puppet 5 to Puppet 6 as easy as
>>> possible I think there is no way around packaging _all_ modules that
>>> were bundled with Puppet 5. Keep in mind that some users might run their
>>> Puppet master on Debian while having agents running on different
>>> operating systems that might use yum, zfs etc.
>> 
>> Given how late we are to this party (Puppet 5 has been EOL over a year
>> now, and Puppet 6 is still not in testing), I don't think that should be
>> a blocker.
>> 
>> It's kind of expected that major upgrades in Debian somewhat throw a
>> wrench in your manifests and you need to run around like a chicken with
>> your head cut off to plug all those leaks. That's an upstream issue, and
>> not one we should try to fix ourselves.
>> 
>> IMHO.
>> 
>> The focus here should be to provide a working Puppet 6 agent, and not
>> fight with the server-side stuff, which, BTW, is in an even worse shape
>> because the puppetserver code is not packaged *at all* in Debian
>> still. See:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904
>> https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html
>> 
>> Having Puppet agent 6 in Debian would at least allow us to migrate
>> fleets to an eventually Puppetserver 7 package in Debian bookworm, or at
>> least use the upstream Puppetserver 6/7 packages.
>> 
>> A.
>
> Hi,
>
> I don't agree with this view.

Sorry, could you clarify which part you disagree with?

> The main issue remains jruby.

For the Puppet agent, from what I understand, jruby is not an
issue. jruby is an issue for puppetserver, on the other side. I think
the work here should focus on the agent since the two components are
effectively separate code bases upstream now.

> A lot of the other work has been mostly done.

I know! It's kind of amazing how hard that packaging is. :)

> At this time, maybe we should giveup on having jruby work with Ruby 3,
> and accept the parts of it which are embedded (like the ruby
> interpreter).

Yeah, that would make sense I think. But maybe that conversation would
be better to have on the jruby side of things (e.g. #972230) or in the
puppetserver ITP (#830904).

Again, I'm coming at this a little from the outside and I'm just trying
to see what the way forward is right now. Just today I had to downgrade
jetty9 after the buster point upgrade for some obscure reason, and I
can't help but think those kind of issues would go away if we kept up
with upstream a little better.

(And yes, that's an issue I should probably file somewhere... for now
that's https://gitlab.torproject.org/tpo/tpa/team/-/issues/40699 )

a.

-- 
The destiny of Earthseed is to take root among the stars.
- Octavia Butler

Bug#950182: [Pkg-puppet-devel] Bug#950182: Puppet 5.5 EOL in November 2020

[Thomas Goirand]

On 3/29/22 20:58, Antoine Beaupré wrote:

On 2020-05-16 21:13:25, Martin Konrad wrote:

Hi,

The others are related to other operating systems than Debian, so I
really wonder if we need them (yum, really? zfs and zone are for
Solaris, and scheduled_task is for windows...).

If we want to make transitioning from Puppet 5 to Puppet 6 as easy as
possible I think there is no way around packaging _all_ modules that
were bundled with Puppet 5. Keep in mind that some users might run their
Puppet master on Debian while having agents running on different
operating systems that might use yum, zfs etc.


Given how late we are to this party (Puppet 5 has been EOL over a year
now, and Puppet 6 is still not in testing), I don't think that should be
a blocker.

It's kind of expected that major upgrades in Debian somewhat throw a
wrench in your manifests and you need to run around like a chicken with
your head cut off to plug all those leaks. That's an upstream issue, and
not one we should try to fix ourselves.

IMHO.

The focus here should be to provide a working Puppet 6 agent, and not
fight with the server-side stuff, which, BTW, is in an even worse shape
because the puppetserver code is not packaged *at all* in Debian
still. See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904
https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html

Having Puppet agent 6 in Debian would at least allow us to migrate
fleets to an eventually Puppetserver 7 package in Debian bookworm, or at
least use the upstream Puppetserver 6/7 packages.

A.


Hi,

I don't agree with this view.

The main issue remains jruby. A lot of the other work has been mostly 
done. At this time, maybe we should giveup on having jruby work with 
Ruby 3, and accept the parts of it which are embedded (like the ruby 
interpreter).


Cheers,

Thomas Goirand (zigo)

Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020

[Antoine Beaupré]

On 2020-02-02 13:06:42, Thomas Goirand wrote:

[...]

> FYI, I packaged and uploaded the first 2 so far, but can't push to Git.
> Please set me as maintainer or owner, so I can do that.
>
> Note that I'm doing a git based workflow, packaging upstream tags,
> rather than using pristine-tar. If this bothers anyone, please let me
> know (but please only complain about the workflow if you really have the
> intention to contribute to the packaging, otherwise you're just getting
> on my way to be efficient for no reason).

Not sure I'm picking the right message to reply to here, but here we go.

I see that you uploaded 6.16.0-1 to experimental back in December 2020:

https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/

Is that package in any shape to ship with bookworm? It would be great to
start this transition to get the package down into testing soon...

Note that we're likely to miss the February 2023 deadline for the Puppet
6 EOL anyways:

https://puppet.com/docs/puppet/6/platform_lifecycle.html

... so maybe we don't even want to do that? or maybe we should focus on
packaging Puppet 7?

I was hoping for a moment we could ship bookworm with the Puppet 6 agent
which would allow us work with a puppetserver 7, but it seems even that
won't keep us from shipping an EOL component (puppet agent 6)...

a.
-- 
La mer, cette grande unificatrice, est l'unique espoir de l'homme.
Aujourd'hui plus que jamais auparavant, ce vieux dicton dit
littéralement ceci: nous sommes tous dans le même bateau.
- Jacques Yves Cousteau - Océanographe

Bug#1008572: ITP: xgboost-predictor-java -- Java implementation of XGBoost predictor for online prediction tasks

[Pierre Gruet]

Hi Mo,

Le 28/03/2022 à 22:39, M. Zhou a écrit :

Hi Pierre,

The original C++/Python implementation xgboost is maintained
by deep learning team:
https://salsa.debian.org/deeplearning-team/xgboost

I have assigned the whole debian science team with
maintainer access (max role) to deep learning team.
You may choose to maintain the package there
if you like.


Thanks for reading my bug report and taking time to write this; yes, I 
think it is a relevant place to maintain xgboost-predictor-java.

I will take this into account while packaging!



This team is dedicated to hardware acceleration,
machine learning, and deep learning. See
debian...@lists.debian.org



Now subscribed!

By the way, does the team have some policy? Or does it inherit its 
policy from Debian Science or whatever?


Best regards,

--
Pierre

Bug#1008628: gnome-online-accounts: Online accounts disappeared from gnome-control-center

[Paolo Redaelli]

Package: gnome-online-accounts
Version: 3.43.1-1
Severity: important

Dear Maintainer,

the Online Account section of gnome control center disappered.

I tried to explicitly invoke it with "gnome-control-center online-accounts" and 
all I got is this error:

(gnome-control-center:49141): cc-window-WARNING **: 20:37:31.872: Could not 
find settings panel "online-accounts"

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-online-accounts depends on:
ii  libatk1.0-0   2.36.0-3
ii  libc6 2.33-7
ii  libcairo-gobject2 1.16.0-5
ii  libcairo2 1.16.0-5
ii  libcom-err2   1.46.5-2
ii  libgck-1-03.40.0-4
ii  libgcr-base-3-1   3.40.0-4
ii  libgcr-ui-3-1 3.40.0-4
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.72.0-1
ii  libgoa-1.0-0b 3.43.1-1
ii  libgoa-backend-1.0-1  3.43.1-1
ii  libgtk-3-03.24.33-1
ii  libharfbuzz0b 2.7.4-1
ii  libk5crypto3  1.19.2-2+b1
ii  libkrb5-3 1.19.2-2+b1
ii  libp11-kit0   0.24.0-6
ii  libpango-1.0-01.50.6+ds-1
ii  libpangocairo-1.0-0   1.50.6+ds-1
ii  librest-0.7-0 0.8.1-1.1
ii  libsoup2.4-1  2.74.2-3
ii  libwebkit2gtk-4.0-37  2.36.0-1
ii  libxml2   2.9.13+dfsg-1

Versions of packages gnome-online-accounts recommends:
ii  gnome-control-center  1:41.4-1

gnome-online-accounts suggests no packages.

-- no debconf information

Bug#1008625: RFH: qiskit-terra

[Diego M. Rodriguez]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: affects -1 src:qiskit-terra

Hello,

I request help with maintaining this package. With upstream moving faster than 
originally anticipated and with my co-maintainer and mentor retiring from 
Debian, I no longer have the bandwidth and skills to realistically maintain the 
packaging effort on par with the latest upstream releases by myself.

One of the challenges in order to bring back the package to speed is packaging 
additional dependencies (~3 required, some of them not pure Python) into 
Debian. The package also has a strong relationship with (also RFH-ed) 
qiskit-aer, and ideally help would also be needed with the latter (potentially 
expanding to other future qiskit-related packages).

Best,
---
Diego M. Rodriguez

Bug#1008627: RFA: qiskit-ibmq-provider

[Diego M. Rodriguez]

Package: wnpp
Severity: normal
Control: affects -1 src:qiskit-ibmq-provider

Hello,

I request adoption (or likely removal) of this package. Upstream is phasing out 
this package [1] in favor of similar alternatives, and I no longer have the 
bandwidth and energy to maintain the packaging effort.

One of the new packages that will replace the current one 
("qiskit-ibm-provider") shares many similarities with the current package - 
ideally, the new maintainer would be able to reuse most of the current effort. 
Please note that this package has a strong relationship with (RFH-ed) 
qiskit-terra, and help/coordination would be encouraged/needed.

Best,

[1] https://github.com/Qiskit/qiskit-ibmq-provider/issues/1042
---
Diego M. Rodriguez

Bug#1008626: RFH: qiskit-aer

[Diego M. Rodriguez]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: affects -1 src:qiskit-aer

Hello,

I request help with maintaining this package. With upstream moving faster than 
originally anticipated and with my co-maintainer and mentor retiring from 
Debian, I no longer have the bandwidth and skills to realistically maintain the 
packaging effort on par with the latest upstream releases by myself.

Since the version currently packaged in Debian, upstream has included usage of 
conan along with a number of dependencies and changes. The package also has a 
strong relationship with (also RFH-ed) qiskit-terra, and ideally help would 
also be needed with the latter (potentially expanding to other qiskit-related 
packages).

Best,
---
Diego M. Rodriguez

Bug#950182: Puppet 5.5 EOL in November 2020

[Antoine Beaupré]

On 2020-05-16 21:13:25, Martin Konrad wrote:
> Hi,
>> The others are related to other operating systems than Debian, so I 
>> really wonder if we need them (yum, really? zfs and zone are for
>> Solaris, and scheduled_task is for windows...).
> If we want to make transitioning from Puppet 5 to Puppet 6 as easy as
> possible I think there is no way around packaging _all_ modules that
> were bundled with Puppet 5. Keep in mind that some users might run their
> Puppet master on Debian while having agents running on different
> operating systems that might use yum, zfs etc.

Given how late we are to this party (Puppet 5 has been EOL over a year
now, and Puppet 6 is still not in testing), I don't think that should be
a blocker.

It's kind of expected that major upgrades in Debian somewhat throw a
wrench in your manifests and you need to run around like a chicken with
your head cut off to plug all those leaks. That's an upstream issue, and
not one we should try to fix ourselves.

IMHO.

The focus here should be to provide a working Puppet 6 agent, and not
fight with the server-side stuff, which, BTW, is in an even worse shape
because the puppetserver code is not packaged *at all* in Debian
still. See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904
https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html

Having Puppet agent 6 in Debian would at least allow us to migrate
fleets to an eventually Puppetserver 7 package in Debian bookworm, or at
least use the upstream Puppetserver 6/7 packages.

A.

-- 
Instead of worrying about what somebody else is going to do, which is
not under your control, the important thing is, what are you going to
decide about what is under your control?
 - Richard Stallman

Bug#1001001: closed by Salvatore Bonaccorso (Re: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!)

[Paul Gevers]

Hi all,

On 20-02-2022 13:44, Paul Gevers wrote:

Sad to say, but this week we had two hangs again.


And this week another two.

 ci-worker-arm64-07 ==

Mar 26 10:15:55 ci-worker-arm64-07 kernel: kernel BUG at 
include/linux/swapops.h:204!
Mar 26 10:15:55 ci-worker-arm64-07 kernel: Internal error: Oops - BUG: 0 
[#1] SMP


Linux kernel from before the last point release:
Linux version 5.10.0-12-arm64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2>


 ci-worker-arm64-08 ==
Mar 25 22:13:44 ci-worker-arm64-08 kernel: kernel BUG at 
include/linux/swapops.h:204!
Mar 25 22:13:44 ci-worker-arm64-08 kernel: Internal error: Oops - BUG: 0 
[#1] SMP


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003204: set the sticky bit on some InRelease files

[Jakub Wilk]

I'm affected too. It's not just InRelease files:

  # find /var/cache/apt-cacher-ng -type f | wc -l
  185505

  # find /var/cache/apt-cacher-ng -type f -perm /1000 | wc -l
  16447

I've never had FilePerms set in my config.

--
Jakub Wilk

Bug#1008603: geopy: python3-geographiclib no longer built from src:geographiclib

[Sebastiaan Couwenberg]

On 3/29/22 18:39, Sebastiaan Couwenberg wrote:

On 3/29/22 18:29, Daniele Tricoli wrote:

Many thanks for this early notice! If I read correctly the readme here:
https://sourceforge.net/projects/geographiclib/files/distrib/


I read that too, but did not find the code repos or release tarballs for 
the Python bindings, nor the matlab, js, java, and dotnet ones which are 
all removed from the 2.0 source tree.


The distrib-Fortran directory appeared on SourceForge:

 https://sourceforge.net/projects/geographiclib/files/distrib-Fortran/

It links to the repo on GitHub where there is also one for Python:

 https://github.com/geographiclib/geographiclib-python

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1008623: gnuradio cannot be installed in sid: failed dependency python3 (<< 3.10)

[Renzo Davoli]

Package: gnuradio
Version: 3.10.1.1-1
Severity: normal
X-Debbugs-Cc: re...@cs.unibo.it

Dear Maintainer,

   * What led up to the situation?
 python update to 3.10

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

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

Versions of packages gnuradio depends on:
ii  libboost-program-options1.74.0  1.74.0-14
ii  libboost-thread1.74.0   1.74.0-14
ii  libc6   2.33-7
ii  libfmt8 8.1.1+ds1-2
ii  libgcc-s1   12-20220319-1
ii  libgmp102:6.2.1+dfsg-3
pn  libgnuradio-analog3.10.1
pn  libgnuradio-audio3.10.1 
pn  libgnuradio-blocks3.10.1
pn  libgnuradio-channels3.10.1  
pn  libgnuradio-digital3.10.1   
pn  libgnuradio-dtv3.10.1   
pn  libgnuradio-fec3.10.1   
pn  libgnuradio-fft3.10.1   
pn  libgnuradio-filter3.10.1
pn  libgnuradio-iio3.10.1   
pn  libgnuradio-network3.10.1   
pn  libgnuradio-pdu3.10.1   
pn  libgnuradio-pmt3.10.1   
pn  libgnuradio-qtgui3.10.1 
pn  libgnuradio-runtime3.10.1   
pn  libgnuradio-soapy3.10.1 
pn  libgnuradio-trellis3.10.1   
pn  libgnuradio-uhd3.10.1   
pn  libgnuradio-video-sdl3.10.1 
pn  libgnuradio-vocoder3.10.1   
pn  libgnuradio-wavelet3.10.1   
pn  libgnuradio-zeromq3.10.1
ii  libjs-mathjax   2.7.9+dfsg-1
ii  libqt5core5a5.15.2+dfsg-15
ii  libqt5widgets5  5.15.2+dfsg-15
ii  libsoapysdr0.8  0.8.1-2+b1
pn  libspdlog1-fmt8 
ii  libstdc++6  12-20220319-1
ii  libuhd4.1.0 4.1.0.5-3
pn  libvolk2-bin
pn  libvolk2.5  
ii  python3 3.10.4-1
pn  python3-click   
pn  python3-click-plugins   
ii  python3-gi  3.42.0-3
ii  python3-gi-cairo3.42.0-3
ii  python3-lxml4.8.0-1
pn  python3-mako
ii  python3-numpy [python3-numpy-abi9]  1:1.21.5-1
pn  python3-opengl  
ii  python3-packaging   21.3-1
pn  python3-pygccxml
ii  python3-pyqt5   5.15.6+dfsg-1+b2
pn  python3-pyqtgraph   
pn  python3-sip 
pn  python3-thrift  
ii  python3-yaml5.4.1-1+b1
pn  python3-zmq 

Versions of packages gnuradio recommends:
pn  gnuradio-dev
pn  python3-matplotlib  
pn  python3-networkx
pn  python3-pygccxml
pn  python3-pyqt5.qwt   
ii  python3-scipy   1.7.3-2
pn  soapysdr-tools  

Versions of packages gnuradio suggests:
pn  gqrx-sdr
pn  gr-fosphor  
pn  gr-osmosdr  
pn  rtl-sdr 
pn  uhd-host

Bug#901595: reaver: Watch file is broken and generating errors

[Samuel Henrique]

Hello Bartosz,

Are you still interested in maintaining reaver?

I'd like to have the package co-maintained under the pkg-security
team, as Raphaël suggested when he created this bug.

Would you be ok with me uploading the latest release, fixing a few
bugs and moving the package to the team? I'm gonna keep you as an
Uploader but I can also remove it if you're not interested in it
anymore.

In case of no replies, I plan on going ahead with the change since
there's a new release which is 2 years old now.

Thanks,


-- 
Samuel Henrique 

Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail

[Simon McVittie]

On Tue, 29 Mar 2022 at 12:44:32 -0400, Daniel Kahn Gillmor wrote:
> If there is no explicit API dependency tracking within GNOME, but
> version numbers of major GNOME components are supposed to advance in
> lockstep, then shouldn't the corresponding packages in debian have
> automated and explicit dependency annotations to enforce that lockstep
> transition?

Major GNOME components are expected to be upgraded together, except for
when that's unnecessary. That is an unsatisfying answer, but unfortunately
it's the only true answer.

GNOME is intended (by upstream) to be upgraded as a suite of packages that
go together, and we should make sure that each released version of Debian
contains packages that are consistent with each other. Interfaces that
are only intended to be used within the group of GNOME core packages,
and are not intended to be "API" to be used by unrelated software,
will sometimes get incompatible changes.

We find out about incompatible changes within core GNOME components by
reading diffs, or by trying it and seeing what works. We try to set up
appropriate versioned Depends/Breaks to make known-broken situations
impossible to achieve, but in the case of gnome-control-center and
gnome-settings-daemon, we could not proceed with this until the ongoing
python3.10 transition got far enough to make gnome-control-center
buildable again (my upload from yesterday only became buildable today,
after Samba libraries were rebuilt).

If we speculatively added versioned Depends/Breaks even without evidence
of a potentially-incompatible change, then we'd be less likely to see
transient brokenness in unstable, but we'd also be making the overall
system more rigid: we'd be unable to get any of the GNOME 42 core
components into testing until *all* of them were ready to migrate,
which seems like a recipe for making the migration not actually happen
because there's always something blocking it.

I think we need to strike a balance between, at one extreme, having
unstable be so unusable that it is not useful to test, and at the
other extreme, being so conservative about transitions that everything
happens months too late, by which time upstream won't take our patches
or bug reports because they already moved on to the next release cycle
(for example GNOME 40, which didn't reach unstable until GNOME 41 was
already in hard freeze upstream).

The 41 -> 42 transition is more partial than most because Ubuntu want
to ship a mixture of 41 and 42 in their 22.04 LTS release (I'm not 100%
clear on why, I think they want to keep some components on GTK 3 that
would be GTK 4 upstream), and we're being nice to Ubuntu by not upgrading
the components they don't want to upgrade until after their freeze has
reached a sufficiently frozen stage.

> GNOME typically does a good job in handling a novice user's behaviors
> well without hassling them with confusing technical arcana, but that
> means that silent and complete crashes like the one observed here just
> look like unrecoverable breakage to the normal user who doesn't know
> anything about stderr or how to launch settings from the terminal.

Sorry, but that normal user probably should not be using unstable.

smcv

Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye

[Mark Brown]

On Tue, Mar 29, 2022 at 01:02:34AM +0100, Mark Brown wrote:
> On Sun, Sep 05, 2021 at 05:01:18PM +0100, Steve McIntyre wrote:

> I bisected this to
> 
> commit 7a8b64d17e35810dc3176fe61208b45c15d25402
> 
> of/address: use range parser for of_dma_get_range
> 
> on what appears to have been a DT system with a built in DT from
> the firmware, using upstream's defconfig.  I dimly recall seeing

Oh, and probably worth pointing out that current mainline handles
the failures with ATA a lot more gracefully, still failing to
bring up ATA but just printing:

[2.652674] ahci :02:00.0: SSS flag set, parallel bus scan disabled
[2.659364] ahci :02:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 
impl SATA mode
[2.667474] ahci :02:00.0: flags: 64bit ncq sntf stag led clo pmp pio 
slum part ccc sxs 
[2.676825] ahci :02:00.0: failed to start port 0 (errno=-12)
[2.682955] ahci: probe of :02:00.0 failed with error -12

and MMC still also fails but this time with an identified oops
rather than just timeouts:

[2.987953] [ cut here ]
[2.994834] usbcore: registered new interface driver usbhid
[2.998370] f_sdh30 5230.sdhci: swiotlb addr 0x+65536 
overflow (mask , bus limit 0).
[2.998395] WARNING: CPU: 2 PID: 8 at kernel/dma/swiotlb.c:740 
swiotlb_map+0x1e4/0x1f8
[3.003981] usbhid: USB HID core driver
[3.014149] Modules linked in:
[3.014159] CPU: 2 PID: 8 Comm: kworker/u48:0 Not tainted 
5.17.0-11137-gb953c6822375 #1
[3.026681] NET: Registered PF_PACKET protocol family
[3.028964] Hardware name: Socionext SynQuacer E-series DeveloperBox, BIOS 
build #54 Mar  6 2019
[3.028973] Workqueue: events_unbound async_run_entry_fn
[3.028987] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[3.037169] 9pnet: Installing 9P2000 support
[3.042056] pc : swiotlb_map+0x1e4/0x1f8
[3.042068] lr : swiotlb_map+0x1e4/0x1f8
[3.042078] sp : 8818bb80
[3.050930] Key type dns_resolver registered
[3.056180] x29: 8818bb80 x28:  x27: 
[3.063504] registered taskstats version 1
[3.067423] 
[3.067427] x26: 0001 x25: 0080 x24: 000801787010
[3.067439] x23:  x22: 
[3.071388] Loading compiled-in X.509 certificates
[3.075292]  x21: 0001
[3.075299] x20: 898c3998 x19: 000801787010
[3.079127] pstore: Using crash dump compression: deflate
[3.082890]  x18: 0020
[3.082897] x17:  x16: 206f74206b636162 x15: 
[3.082909] x14: 0001
[3.097298] OF: translation of DMA address(0) to CPU address failed node()
[3.102762]  x13: 000f7bf76556 x12: 000f7bf76551
[3.102773] x11: 0720072007200720 x10: 000a x9 : 8818bb80
[3.102785] x8 : 8a331198 x7 : 8818b980
[3.108037] gpio-keys gpio-keys: Invalid size 0x1 for dma-range(s)
[3.112816]  x6 : 000f7bf3ef80
[3.112823] x5 :  x4 : 
[3.116564] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[3.121457]  x3 : 
[3.121464] x2 : 8a0125a0 x1 : fbd95b9fae668f00 x0 : 
[3.197275] Call trace:
[3.199721]  swiotlb_map+0x1e4/0x1f8
[3.203305]  dma_map_page_attrs+0xec/0x228
[3.207408]  sdhci_setup_host+0x8f0/0xd30
[3.211430]  sdhci_add_host+0x18/0x50
[3.215098]  sdhci_f_sdh30_probe+0x2a0/0x378
[3.219373]  platform_probe+0x68/0xd8
[3.223043]  really_probe+0xb8/0x300
[3.226622]  __driver_probe_device+0x78/0xe0
[3.230896]  driver_probe_device+0x3c/0xe8
[3.234997]  __driver_attach_async_helper+0x2c/0x50
[3.239880]  async_run_entry_fn+0x34/0xd0
[3.243896]  process_one_work+0x1ec/0x330
[3.247912]  worker_thread+0x44/0x420
[3.251579]  kthread+0x110/0x120
[3.254815]  ret_from_fork+0x10/0x20
[3.258397] ---[ end trace  ]---

followed by more in sdhci_send_command().

[   23.661522] WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:1151 
sdhci_send_command+0x954/0xde8

I'm guessing these are going to be the same underlying issue with the
firmware but manifesting a bit differently, the network device
does still complain about the 1 byte dma-range.  The system gets
to a ramdisk but has no useful I/O.


signature.asc
Description: PGP signature

Bug#1007915: [Pkg-javascript-devel] Bug#1007915: Bug#1007915: node-wikibase-cli: incompatible with node-commander >= 8

[Yadd]

Le 29 mars 2022 18:21:22 GMT+02:00, Andrius Merkys  a écrit :
>Hi Yadd,
>
>On 2022-03-29 19:17, Yadd wrote:
>> On 29/03/2022 17:44, Yadd wrote:
>>> Hi Andrius,
>>>
>>> you fix is enough for commander 8, I'm currently writing commander 9
>>> patch
>> 
>> Fixed and pushed. However package looks unusable because all bin/*
>> commands are not in $PATH. You could either:
>>  * install all commands in /usr/bin
>>  * or change path in /usr/bin/wd and /usr/bin/wb
>
>Thanks a lot for taking care of this! I will check why the executables
>do not end in /usr/bin/. Once I am done, I will upload.
>
>Thanks once more,
>Andrius

After that, please remove my workaround in debian/tests/pkg-js/test

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#1008459: qiskit-terra: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13

[Nilesh Patra]

control: reassign -1 src:nbconvert
control: forcemerge -1 1008376
control: affects -1 src:qiskit-terra

Hi,

>  ERRORS 
> 
> _ ERROR collecting 
> .pybuild/cpython3_3.9/build/test/python/tools/jupyter/test_notebooks.py _
> ImportError while importing test module 
> '/<>/.pybuild/cpython3_3.9/build/test/python/tools/jupyter/test_notebooks.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> /usr/lib/python3.9/importlib/__init__.py:127: in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
> test/python/tools/jupyter/test_notebooks.py:22: in 
> from nbconvert.preprocessors import ExecutePreprocessor
> /usr/lib/python3/dist-packages/nbconvert/__init__.py:4: in 
> from .exporters import *
> /usr/lib/python3/dist-packages/nbconvert/exporters/__init__.py:4: in 
> from .slides import SlidesExporter
> /usr/lib/python3/dist-packages/nbconvert/exporters/slides.py:12: in 
> from ..preprocessors.base import Preprocessor
> /usr/lib/python3/dist-packages/nbconvert/preprocessors/__init__.py:10: in 
> 
> from .execute import ExecutePreprocessor
> /usr/lib/python3/dist-packages/nbconvert/preprocessors/execute.py:8: in 
> 
> from nbclient import NotebookClient, execute as _execute
> /usr/lib/python3/dist-packages/nbclient/__init__.py:5: in 
> from .client import NotebookClient, execute  # noqa: F401
> /usr/lib/python3/dist-packages/nbclient/client.py:35: in 
> from .output_widget import OutputWidget
> /usr/lib/python3/dist-packages/nbclient/output_widget.py:6: in 
> from .jsonutil import json_clean
> /usr/lib/python3/dist-packages/nbclient/jsonutil.py:16: in 
> from ipython_genutils import py3compat
> E   ModuleNotFoundError: No module named 'ipython_genutils'

Clearly this is due to nbclient instead. Re-assigning and merging with another 
BR(#1008376)
which says the same thing

Nilesh


signature.asc
Description: PGP signature

Bug#945139: pipenv: update to latest pipenv

[Eldon Koyle]

Package: pipenv
Version: 11.9.0-1.1
Followup-For: Bug #945139

Dear Maintainer,

The version of pipenv currently in Debian is now over four years and 20
versions out-of-date.  The old version is incompatible with python 3.10,
so the package is no longer usable.

-- 
Eldon

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC,
TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 pipenv depends on:
ii  python3   3.10.4-1
ii  python3-certifi   2020.6.20-1
ii  python3-pip   22.0.2+dfsg-1
ii  python3-pkg-resources 59.6.0-1.2
ii  python3-virtualenv20.13.0+ds-2
ii  python3-virtualenv-clone  0.3.0-2

pipenv recommends no packages.

pipenv suggests no packages.

-- debconf-show failed

-- 
Eldon Koyle

Bug#1008621: nvidia-driver: Please create the nvidia-legacy-470xxx driver

[Andreas Beckmann]

Control: tag -1 wontfix

On 29/03/2022 18.41, Eric Valette wrote:

See https://forums.developer.nvidia.com/t/current-graphics-driver-releases/28500
It highlights that 470 is legacy although the legacy driver page is pending 
update
already queue for 470.


Please use the Tesla 470 driver for legacy cards only supported up to 
the 470 series.



Andreas

Bug#1003038: mkfs.hfs does not respect the -v option when creating an HFS volume

[John Paul Adrian Glaubitz]

Hi Glenn!

On 1/5/22 11:23, John Paul Adrian Glaubitz wrote:
> Thanks for debugging and reporting this. I will have a look at this bug and
> fix it hopefully soon. Also, thanks for fixing so many issues in GRUB, I'm
> on the GRUB mailing list as well and I'm seeing your regular influx of
> patches there!

So, I just had a look at the code again and compared it with the original code
from the last version of the diskdev_cmds which supported legacy HFS [1].

The original code contains an embedded function to map UTF-8 into Mac encoding,
search for "Map UTF-8 input into a Mac encoding.". I didn't reimplement that
code back then because it uses some string code from Apple's CoreFoundation
libraries. I assumed no one would bother if we just hardwire the volume label
to "untitled" and moved on.

However, since you now reported this bug, I think it's reasonable to fix
this issue and I think it should be possible with the help of the sources
of version 332.25-11.

Looking at the corresponding patch [2], you can see that the patch implements
a similar approach of what you suggested, see:

+   mdbp->drVN[0] = strlen(defaults->volumeName);
+   bcopy(defaults->volumeName,&mdbp->drVN[1],mdbp->drVN[0]);

I'll think a bit over it to decide what approach we use. Reimplementing Apple's
code as close as possible without using the CoreFoundation stuff would be my
preferred solution.

Maybe you have a suggestion on how to reimplement Apple's UTF-8-to-Mac 
conversion
code from [1].

Adrian

> [1] 
> https://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-491/newfs_hfs.tproj/makehfs.c.auto.html
> [2] 
> https://sources.debian.org/src/hfsprogs/332.25-11/debian/patches/0002-Add-exclude-Darwin-specific-code.patch/#L993

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1006925: acgntool: abort on maintanance

[gregor herrmann]

On Tue, 08 Mar 2022 11:31:10 +0100, Christian Göttsche wrote:

> It seems to crash once a week:
> 
> Feb 28 07:01:08 rpi3 systemd[1]: apt-cacher-ng-maint.service: Main
> process exited, code=killed, status=6/ABRT
> Feb 28 07:01:08 rpi3 systemd[1]: apt-cacher-ng-maint.service: Failed
> with result 'signal'.
> Feb 28 07:01:08 rpi3 systemd[1]: Failed to start Daily apt-cacher-ng
> maintenance.

I just noticed a full file system, which was caused by the acng
directory getting huge.

Calling the maint helper manually resulted in:

# /usr/lib/apt-cacher-ng/acngtool maint -c /etc/apt-cacher-ng 
SocketPath=/var/run/apt-cacher-ng/socket
Aborted
# echo $?
134

I'm wondering is this is fallout from
https://salsa.debian.org/blade/apt-cacher-ng/-/commit/1a9d214d7f00b55f5436a2f66de4daa4240c3ee7
(hard-coded 10 minute timeout)

On my 10 year old Raspberry Pi 2 the maint job will never finish in
10 minutes, which is a bit of a problem …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: JBO: Mir sta'dd'n etz die Feier


signature.asc
Description: Digital Signature

Bug#940398: RFA: golang-github-nats-io-go-nats

[Dominik George]

Hi,

On Sun, Sep 15, 2019 at 06:38:01PM -0400, Alexandre Viau wrote:
> I'd like to find new maintainers for some of my packages because I have
> had less time for Debian. I'd like to focus the small amount of time
> that I have for Debian on other things.
> 
> For now, I intend to do my best to keep maintaining this package.
> However, I will probably retitle this bug with the 'O:' prefix at some
> point, indicating that I have orphaned it.
> 
> Feel free to upload a new version of the package and remove me from the
> uploaders in debian/control.

On Mon, Jun 22, 2020 at 01:53:45PM +0200, Badreddin Aboubakr wrote:
> I would like to take the maintainership for the NATS packages.


I am currently working on packaging nextcloud-spreed-signaling, which
depends on NATS.

It seems the pckage has by now been renamed to nats.go and has go.mod
support. SO I would package the new package in the Go packaging team
under the new name, and then file a removal request for this package.

Any objections?

Cheers,
Nik


signature.asc
Description: PGP signature

Bug#1008622: ITP: python-pdbfixer -- Fix problems in Protein Data Bank files

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: python-pdbfixer
  Version : 1.8.1
  Upstream Author : Stanford University and Peter Eastman
* URL : https://github.com/openmm/pdbfixer
* License : Expat
  Programming Lang: Python
  Description : Fix problems in Protein Data Bank files (Python 3)

PDBFixer is an application for fixing problems in Protein Data Bank
files in preparation for simulating them. It can automatically fix the
following problems:

  - Add missing heavy atoms.
  - Add missing hydrogen atoms.
  - Build missing loops.
  - Convert non-standard residues to their standard equivalents.
  - Select a single position for atoms with multiple alternate positions
listed.
  - Delete unwanted chains from the model.
  - Delete unwanted heterogens.
  - Build a water box for explicit solvent simulations.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-pdbfixer

Bug#1008603: geopy: python3-geographiclib no longer built from src:geographiclib

[Sebastiaan Couwenberg]

On 3/29/22 18:29, Daniele Tricoli wrote:

On Tue, Mar 29, 2022 at 02:28:36PM +0200, Bas Couwenberg wrote:

GeographicLib 2.0 has been released and removed the language bindings from its 
source tree.

The python3-geographiclib and node-geographiclib binary packages are no longer 
built from the geographiclib source package.

At time of writing there is no distrib directory for the Python nor Node.js 
bindings like there is for C:

  https://sourceforge.net/projects/geographiclib/files/

I'm not aware what upstreams plans are with the other language implementations, 
they'll need to be packaged separately if they haven't been deprecated.


Many thanks for this early notice! If I read correctly the readme here:
https://sourceforge.net/projects/geographiclib/files/distrib/


I read that too, but did not find the code repos or release tarballs for 
the Python bindings, nor the matlab, js, java, and dotnet ones which are 
all removed from the 2.0 source tree.



  NOTE: Starting with version 2.0 of GeographicLib (to be announced) the
source code distribution will be split into separate packages for each
programming language.


So maybe we have only to wait. Do you plan to package
python3-geographiclib if it hasn't been deprecated and it will show up
later? I can help if needed.


No, I already maintain too many packages I don't actually use myself.

You're welcome to maintain python-geographiclib in the GIS team, but 
you're likely better off in the Python team to not have to deal with a 
different team policy:


 https://debian-gis-team.pages.debian.net/policy/

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail

[Daniel Kahn Gillmor]

On Mon 2022-03-28 21:26:16 -0400, Jeremy Bicha wrote:
> This fix is pending

Thanks for the pending fix, Jeremy.  I can't help noticing that this
failure looks like a classic backward-incompatible API change.  The API
happens to be across a gsettings schema instead of a C library,
language-specific module, or network service, but it's still the same
thing.

As a community, we have decades of hard-won experience in reasoning
about and handling API changes: thinking about what kinds of changes are
backward-compatible (adding interfaces) or backward-incompatible
(removing or changing interfaces), how to signal them (SONAMEs for C
shared objects, libtool's current/revision/age, semver in many of the
modern language ecosystems, URL prefixes for HTTP REST, etc), and how to
declare dependencies on them in ways that are not hard to propagate into
downstream package managers.

How does GNOME track these API changes across its constitutent projects?
I'm too much of a newbie in GNOME to know how that's done, but if there
is some sort of API version tracking within gnome, then it seems like
either gnome-settings-daemon should have marked a backward-incompatible
API bump when it removed the "screenshot" key from the schema or
gnome-control-center didn't accurately specify its particular API needs
from gnome-settings-daemon.  If that signalling is present, and either
of those were fixed upstream, that knowledge should be propagated to the
debian packaging.

If there is no explicit API dependency tracking within GNOME, but
version numbers of major GNOME components are supposed to advance in
lockstep, then shouldn't the corresponding packages in debian have
automated and explicit dependency annotations to enforce that lockstep
transition?

There are other options too, of course, including:

 - gnome-settings-daemon could declare that any given key in its schema
   could go away, and expect callers to deal with such an outage.  In
   that case, gnome-control-center is at fault for aborting when the
   'screenshot' key was not found.

 - gnome-settings-daemon could avoid a backward-incompatible API change
   by retaining the "screenshot" key, possibly emitting deprecation
   warnings somewhere when the deprecated key is accessed.  Some future
   version could bundle a collection of schema removals into a larger
   backward-incompatible API change after a suitable deprecation window.

This is a larger general concern about the health of GNOME in Debian
going forward: i don't expect the GNOME interdependencies to get simpler
over time (what user-facing software does?), so i would like to
understand how GNOME and the Debian GNOME team think about handling them
in general.

GNOME typically does a good job in handling a novice user's behaviors
well without hassling them with confusing technical arcana, but that
means that silent and complete crashes like the one observed here just
look like unrecoverable breakage to the normal user who doesn't know
anything about stderr or how to launch settings from the terminal.

If you think this is an upstream GNOME issue and no debian-specific at
all, I'm happy to move this off the Debian BTS, just tell me where you
think the appropriate venue is.

Thanks for your work maintaining GNOME in debian!

--dkg


signature.asc
Description: PGP signature

Bug#1007832: seg-fault in mesa-vulkan-driver when connected to a remote headless machine.

[Alois Schlögl]

Further investigation shows that part of the issue is package 
"mesa-vulkan-drivers"

and also on machines without nvidia-gpus.


When uninstalling  nvidia-drivers, and mesa-vulkan-drivers, vulkan-tools 
reports correctly an error that no vulkan device is found
When installing mesa-vulkan-driver, and having the nvidia-driver in 
place, "gdb vulkaninfo" results in this backtrace



Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
ERROR: [Loader Message] Code 0 : loader_scanned_icd_add: Could not get 
'vkCreateInstance' via 'vk_icdGetInstanceProcAddr' for ICD 
libGLX_nvidia.so.0
ERROR: [Loader Message] Code 0 : 
/usr/lib/i386-linux-gnu/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : 
/usr/lib/i386-linux-gnu/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : 
/usr/lib/i386-linux-gnu/libvulkan_lvp.so: wrong ELF class: ELFCLASS32


Program received signal SIGSEGV, Segmentation fault.
0x15554aa4d3fc in ?? () from 
/usr/lib/x86_64-linux-gnu/libvulkan_intel.so

(gdb) bt
#0  0x15554aa4d3fc in ?? () from 
/usr/lib/x86_64-linux-gnu/libvulkan_intel.so
#1  0x15554aa4ea65 in ?? () from 
/usr/lib/x86_64-linux-gnu/libvulkan_intel.so
#2  0x14bef7e7 in ?? () from 
/usr/lib/x86_64-linux-gnu/libvulkan.so.1
#3  0x14befc22 in ?? () from 
/usr/lib/x86_64-linux-gnu/libvulkan.so.1
#4  0x15554a96fde4 in ?? () from 
/usr/lib/x86_64-linux-gnu/libVkLayer_MESA_device_select.so
#5  0x14bef2a3 in ?? () from 
/usr/lib/x86_64-linux-gnu/libvulkan.so.1
#6  0x14bf1e05 in vkEnumeratePhysicalDevices () from 
/usr/lib/x86_64-linux-gnu/libvulkan.so.1

#7  0x555b5639 in ?? ()
#8  0x555638b6 in ?? ()
#9  0x14fead0a in __libc_start_main (main=0x55563670, 
argc=1, argv=0x7fffe458, init=, fini=,
    rtld_fini=, stack_end=0x7fffe448) at 
../csu/libc-start.c:308

#10 0x5556580a in ?? ()



When having mesa-vulkan-drivers installed, and nvidia drivers are 
disabled (e.g. with "rmmod nvidia-drm nvidia-settings"), or on machines 
without nvidia-gpu's,
vulkan-tools shows a lot of properties, but fails also with a 
segmentation fault.


Running "gdb vulkaninfo", I get this backtrace:

Thread 1 "vulkaninfo" received signal SIGSEGV, Segmentation fault.
0x7fffcd2f52bc in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
(gdb) bt
#0  0x7fffcd2f52bc in ?? () from 
/usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#1  0x7fffcd2f57f1 in ?? () from 
/usr/lib/x86_64-linux-gnu/libvulkan_lvp.so

#2  0x555a7140 in ?? ()
#3  0x555a123e in ?? ()
#4  0x55564565 in ?? ()
#5  0x7fffd6fa2d0a in __libc_start_main (main=0x55563670, 
argc=1, argv=0x7fffda98, init=, fini=,
    rtld_fini=, stack_end=0x7fffda88) at 
../csu/libc-start.c:308

#6  0x5556580a in ?? ()


Though the behavior is slightly different, both libraries 
libvulkan_intel.so and libvulkan_lvp.so, are part of the 
mesa-vulkan-drivers package.


So this indicates that this is a bug in package mesa-vulkan-drivers.

Bug#1008620: hplip: Please make hplip compatible with Python 3.10 transition

[Eric Valette]

Package: hplip
Version: 3.21.12+dfsg0-1
Severity: important

Hplip is not mentionned in the python 3.10-add transition but is still not 
installable with
python3.10 default.


-- Package-specific info:

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

Kernel: Linux 5.10.108 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages hplip depends on:
ii  adduser3.121
ii  cups   2.4.1op1-2
ii  hplip-data 3.21.12+dfsg0-1
ii  libc6  2.34-0experimental3
ii  libcups2   2.4.1op1-2
ii  libdbus-1-31.14.0-1
ii  libhpmud0  3.21.12+dfsg0-1
ii  libpython3.9   3.9.12-1
ii  libsane-hpaio  3.21.12+dfsg0-1
ii  libsane1   1.1.1-5
ii  lsb-base   11.1.0
ii  printer-driver-hpcups  3.21.12+dfsg0-1
ii  python33.9.8-1
ii  python3-dbus   1.2.18-3+b1
ii  python3-gi 3.42.0-3
ii  python3-pexpect4.8.0-2
ii  python3-pil9.0.1-1
ii  python3-reportlab  3.6.8-1
ii  wget   1.21.2-2+b1
ii  xz-utils   5.2.5-2

Versions of packages hplip recommends:
ii  avahi-daemon  0.8-5
ii  policykit-1   0.120-6
ii  printer-driver-postscript-hp  3.21.12+dfsg0-1
ii  sane-utils1.1.1-5

Versions of packages hplip suggests:
ii  hplip-doc  3.21.12+dfsg0-1
ii  hplip-gui  3.21.12+dfsg0-1
ii  python3-notify20.3-4
ii  system-config-printer  1.5.16-1

-- no debconf information

Bug#1008603: geopy: python3-geographiclib no longer built from src:geographiclib

[Daniele Tricoli]

Hello Bas,

On Tue, Mar 29, 2022 at 02:28:36PM +0200, Bas Couwenberg wrote:
> GeographicLib 2.0 has been released and removed the language bindings from 
> its source tree.
> 
> The python3-geographiclib and node-geographiclib binary packages are no 
> longer built from the geographiclib source package.
> 
> At time of writing there is no distrib directory for the Python nor Node.js 
> bindings like there is for C:
> 
>  https://sourceforge.net/projects/geographiclib/files/
> 
> I'm not aware what upstreams plans are with the other language 
> implementations, they'll need to be packaged separately if they haven't been 
> deprecated.

Many thanks for this early notice! If I read correctly the readme here:
https://sourceforge.net/projects/geographiclib/files/distrib/

>  NOTE: Starting with version 2.0 of GeographicLib (to be announced) the
> source code distribution will be split into separate packages for each
> programming language.

So maybe we have only to wait. Do you plan to package
python3-geographiclib if it hasn't been deprecated and it will show up
later? I can help if needed.

Thanks,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org


signature.asc
Description: PGP signature

Bug#990334: sbuild: Make usage of zfs snapshot/rollback and clone

[Florian Ernst]

Hello there,

On Sat, Jun 26, 2021 at 06:54:16AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Juri Grabowski (2021-06-25 23:00:39)
> > overlayfs doesn't work with ZFS right now.  I mean, that through zfs
> > snapshot/rollback and clone features we can achieve better performance in
> > spawning and destroying new schroots.
> 
> Possibly. But if so, then that's something that schroot has to offer. Not
> sbuild.

JFTR, schroot already supports ZFS datasets with snapshotting and
cloning to create new sessions. For reference, I put a description of my
personal setup into
.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1008612: closed by Sebastiaan Couwenberg (Re: Bug#1008612: libspatialite7: erroneous geometry conversion using ST_Transform)

[Sebastiaan Couwenberg]

On 3/29/22 17:35, Brian Miles wrote:

I apologize that I mis-stated my original description of the bug. It is not 
that the results for 26910 transforms are the same as for 32610 transforms, but 
that transforms to 26910 are simply incorrect for Debian/Ubuntu.


I'm no projection specialist, I cannot judge whether a transformation is 
correct or not. The experts for that frequent the proj mailinglist.



As this is only happening on Debian/Ubuntu, it is not clear to me that bringing 
this upstream will result in resolution. Are there any other option to 
addressing this?


Things that may affect the transformation result:

 * libspatialite version
 * proj version
 * whether proj-data grids are installed / PROJ_NETWORK=ON is set

proj-data is not packaged in Debian (#952459), it is packaged in Alpine.

Datumgrid availabilty makes better transformations possible:

$ spatialite /tmp/test.db "SELECT AsText(point), 
AsText(ST_Transform(point, 26910)) FROM test;"

SpatiaLite version ..: 5.0.1Supported Extensions:
- 'VirtualShape'[direct Shapefile access]
- 'VirtualDbf'  [direct DBF access]
- 'VirtualText' [direct CSV/TXT access]
- 'VirtualGeoJSON'  [direct GeoJSON access]
- 'VirtualXL'   [direct XLS access]
- 'VirtualNetwork'  [Dijkstra shortest path - obsolete]
- 'RTree'   [Spatial Index - R*Tree]
- 'MbrCache'[Spatial Index - MBR cache]
- 'VirtualFDO'  [FDO-OGR interoperability]
- 'VirtualBBox' [BoundingBox tables]
- 'VirtualSpatialIndex' [R*Tree metahandler]
- 'VirtualElementary'   [ElemGeoms metahandler]
- 'VirtualRouting'  [Dijkstra shortest path - advanced]
- 'VirtualKNN'  [K-Nearest Neighbors metahandler]
- 'VirtualGPKG' [OGC GeoPackage interoperability]
- 'VirtualXPath'[XML Path Language - XPath]
- 'SpatiaLite'  [Spatial SQL - OGC]
PROJ version : Rel. 9.0.0, March 1st, 2022
GEOS version : 3.10.2-CAPI-1.16.0
RTTOPO version ..: 1.1.0
TARGET CPU ..: x86_64-linux-gnu
POINT(-122.338928 47.629273)|POINT(549665.158879 5275308.47686)
POINT(-122.338923 47.62927)|POINT(549665.537361 5275308.146648)
POINT(-122.33895 47.629253)|POINT(549663.525012 5275306.240011)
POINT(-122.392051 47.62888)|POINT(545674.479273 5275232.14496)
POINT(-122.392038 47.62888)|POINT(545675.455944 5275232.152617)

$ PROJ_NETWORK=ON spatialite /tmp/test.db "SELECT AsText(point), 
AsText(ST_Transform(point, 26910)) FROM test;"

SpatiaLite version ..: 5.0.1Supported Extensions:
- 'VirtualShape'[direct Shapefile access]
- 'VirtualDbf'  [direct DBF access]
- 'VirtualText' [direct CSV/TXT access]
- 'VirtualGeoJSON'  [direct GeoJSON access]
- 'VirtualXL'   [direct XLS access]
- 'VirtualNetwork'  [Dijkstra shortest path - obsolete]
- 'RTree'   [Spatial Index - R*Tree]
- 'MbrCache'[Spatial Index - MBR cache]
- 'VirtualFDO'  [FDO-OGR interoperability]
- 'VirtualBBox' [BoundingBox tables]
- 'VirtualSpatialIndex' [R*Tree metahandler]
- 'VirtualElementary'   [ElemGeoms metahandler]
- 'VirtualRouting'  [Dijkstra shortest path - advanced]
- 'VirtualKNN'  [K-Nearest Neighbors metahandler]
- 'VirtualGPKG' [OGC GeoPackage interoperability]
- 'VirtualXPath'[XML Path Language - XPath]
- 'SpatiaLite'  [Spatial SQL - OGC]
PROJ version : Rel. 9.0.0, March 1st, 2022
GEOS version : 3.10.2-CAPI-1.16.0
RTTOPO version ..: 1.1.0
TARGET CPU ..: x86_64-linux-gnu
POINT(-122.338928 47.629273)|POINT(549665.036792 5275308.276363)
POINT(-122.338923 47.62927)|POINT(549665.415273 5275307.94615)
POINT(-122.33895 47.629253)|POINT(549663.402919 5275306.039517)
POINT(-122.392051 47.62888)|POINT(545674.35684 5275231.954471)
POINT(-122.392038 47.62888)|POINT(545675.333511 5275231.962125)

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1007915: [Pkg-javascript-devel] Bug#1007915: node-wikibase-cli: incompatible with node-commander >= 8

[Andrius Merkys]

Hi Yadd,

On 2022-03-29 19:17, Yadd wrote:
> On 29/03/2022 17:44, Yadd wrote:
>> Hi Andrius,
>>
>> you fix is enough for commander 8, I'm currently writing commander 9
>> patch
> 
> Fixed and pushed. However package looks unusable because all bin/*
> commands are not in $PATH. You could either:
>  * install all commands in /usr/bin
>  * or change path in /usr/bin/wd and /usr/bin/wb

Thanks a lot for taking care of this! I will check why the executables
do not end in /usr/bin/. Once I am done, I will upload.

Thanks once more,
Andrius

Bug#1008619: ITP: mdurl -- Python port of the JavaScript mdurl pacakge

[Emmanuel Arias]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias 
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: mdurl
  Version : 0.1.0
  Upstream Author : Taneli Hukkinen 
* URL : https://github.com/executablebooks/mdurl
* License : expat
  Programming Lang: Python
  Description : Python port of the JavaScript mdurl pacakge

The JavaScript mdurl package is a set of URL utilities for markdown-it.
This package is a Python port needed for markdown-it-py package.

mdurl is need for markdown-it-py from v2.0.0. I plan maintain
mdurl under Debian Python Team umbrella.

Bug#1007915: [Pkg-javascript-devel] Bug#1007915: node-wikibase-cli: incompatible with node-commander >= 8

[Yadd]

On 29/03/2022 17:44, Yadd wrote:

Hi Andrius,

you fix is enough for commander 8, I'm currently writing commander 9 patch


Fixed and pushed. However package looks unusable because all bin/* 
commands are not in $PATH. You could either:

 * install all commands in /usr/bin
 * or change path in /usr/bin/wd and /usr/bin/wb

Cheers,
Yadd

Bug#988354: schroot: fails to enter zfs source chroots

[Florian Ernst]

Hello there,

On Tue, May 11, 2021 at 10:48:00AM +0200, Sebastian Ramacher wrote:
> Thanks for adding zfs support to schroot. While entering a zfs-backed
> chroot works fine, i.e., schroot -c unstable-amd64-sbuild, trying to
> enter the source chroot fails:
> [...]

FWIW, this works for me, so it might simply be that some additional
configuration is required. Thus the following just for reference:

My bash history tells me that I actually applied

# zfs set mountpoint=legacy zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild

when migrating to a ZFS-based schroot setup as per

# cat /etc/schroot/chroot.d/unstable-amd64-sbuild-*
[unstable-amd64-sbuild]
description=Debian unstable/amd64 autobuilder
groups=root,sbuild
root-groups=root,sbuild
profile=sbuild
type=zfs-snapshot
zfs-dataset=zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild
mount-options=-o relatime,async
command-prefix=/var/cache/pbuilder/ccache/sbuild-setup,eatmydata
aliases=UNRELEASED,sid,rc-buggy,experimental

and indeed it just works for me, cf. for illustration

$ schroot -c unstable-amd64-sbuild # normal access
(unstable-amd64-sbuild)fernst@fernst:~$ df -hT
Filesystem  
   Type   Size  Used Avail Use% Mounted on
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-caeca563-8016-4209-a022-77f59f5d4058
 zfs 65G  359M   64G   1% /
tmpfs   
   tmpfs   16G 0   16G   0% /dev/shm
zfspool/SYSTEM/var  
   zfs 50G   33G   18G  65% /build
zfspool/SYSTEM/home/fernst  
   zfs264G  201G   64G  76% 
/home/fernst/debian
/dev/mapper/lvmpool-root
   ext415G   11G  4.0G  73% 
/etc/sudoers.d/local-reprotest
(unstable-amd64-sbuild)fernst@fernst:~$ # CTRL+D here
exit
$ schroot -c source:unstable-amd64-sbuild # accessing the source chroot as a 
normal user
E: Access not authorised
I: You do not have permission to access the schroot service.
I: This failure will be reported.
$ sudo schroot -c source:unstable-amd64-sbuil # accessing the source chroot via 
sudo
(unstable-amd64-sbuild)root@fernst:/home/fernst# touch /blubber # apply some 
change
(unstable-amd64-sbuild)root@fernst:/home/fernst# # CTRL+D here
exit
$ schroot -c unstable-amd64-sbuild
(unstable-amd64-sbuild)fernst@fernst:~$ ls -al /blubber # check whether the 
above change persisted
-rw-r--r-- 1 root root 0 Mar 29 16:09 /blubber
(unstable-amd64-sbuild)fernst@fernst:~$ # CTRL+D here
exit

The only glitch I had so far with ZFS-based schroot I just reported in
, and there is a simple fix available.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1008618: fish: /usr/share/fish/functions/fish_title.fish (line 7): $(...) is not supported

[xiscu]

Package: fish
Version: 3.4.0+ds-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
apt-get update && apt-get dist-upgrade

/usr/share/fish/functions/fish_title.fish (line 7): $(...) is not supported. In 
fish, please use '(prompt_hostname)'.
and set ssh "[$(prompt_hostname | string sub -l 10)]"
  ^
from sourcing file /usr/share/fish/functions/fish_title.fish


   * What outcome did you expect instead?
No warnings and no errors

Thanks in advance,
xiscu


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

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

Versions of packages fish depends on:
ii  bsdextrautils  2.37.3-1+b1
ii  chromium [www-browser] 99.0.4844.84-1
ii  firefox [www-browser]  95.0.1-1
ii  firefox-esr [www-browser]  91.7.0esr-1
ii  fish-common3.4.0+ds-1
ii  groff-base 1.22.4-8
ii  libc6  2.33-7
ii  libpcre2-32-0  10.39-3
ii  libstdc++6 12-20220319-1
ii  libtinfo6  6.3-2
ii  lynx [www-browser] 2.9.0dev.10-1
ii  man-db 2.10.2-1
ii  python33.9.8-1
ii  surf [www-browser] 2.1+git20210719-2

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
ii  doc-base  0.11.1

-- no debconf information

Bug#1008614: parted: Updated Indonesian translation

[Colin Watson]

On Tue, Mar 29, 2022 at 10:25:15PM +0700, Andika Triwidada wrote:
> Attached is updated Indonesian translation for parted.

This looks like program translations, which are maintained upstream.
Could you send them upstream instead via the Translation Project?

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1008617: git add -p emits perl errors with very long files

[Mikko Rasa]

Package: git
Version: 1:2.35.1+next.20220211-1
Severity: minor
Tags: patch

I'm working on a large Unity project where some of out scene and prefab
files reach six digit line numbers.  When using git add -p on such a file
and selecting the go to hunk option, these errors appear:

Negative repeat count does nothing at /usr/lib/git-core/git-add--interactive 
line 1399,  line 1.

It seems to be due to the summary of the hunks exceeding 20 characters.
The error appears once per such a hunk and makes the list of hunks
difficult to read.  It can be avoided by simply wrapping the offending
line in an if (see attached patch).

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

Kernel: Linux 5.15.4-k8 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages git depends on:
ii  git-man  1:2.35.1+next.20220211-1
ii  libc62.33-7
ii  libcurl3-gnutls  7.81.0-1
ii  liberror-perl0.17029-1
ii  libexpat12.4.6-1
ii  libpcre2-8-0 10.39-3
ii  perl 5.34.0-3
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages git recommends:
ii  ca-certificates  20211016
ii  less 590-1
ii  openssh-client [ssh-client]  1:8.9p1-3
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-4
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/git-core/git-add--interactive (from git package)
--- git-add--interactive.orig   2022-03-29 18:30:14.787905260 +0300
+++ /usr/lib/git-core/git-add--interactive  2022-03-29 18:25:28.990785877 
+0300
@@ -1396,7 +1396,9 @@
 
# Keep the line numbers, discard extra context.
$summary =~ s/@@(.*?)@@.*/$1 /s;
-   $summary .= " " x (20 - length $summary);
+   if (length $summary < 20) {
+   $summary .= " " x (20 - length $summary);
+   }
 
# Add some user context.
for my $line (@{$rhunk->{TEXT}}) {

Bug#1008616: /etc/schroot/setup.d/05zfs: make ZFS snapshot removal more robust

[Florian Ernst]

Package: schroot
Version: 1.6.10-12
Severity: minor
File: /etc/schroot/setup.d/05zfs
Tags: patch

Dear maintainer,

thank you for enabling ZFS usage.

Please consider the following patch to make clone removal a little more
robust:

| diff --git a/schroot/setup.d/05zfs b/schroot/setup.d/05zfs
| index 6ecc0196..785aee5f 100755
| --- a/schroot/setup.d/05zfs
| +++ b/schroot/setup.d/05zfs
| @@ -49,10 +49,10 @@ if [ "$CHROOT_TYPE" = "zfs-snapshot" ] && [ -n 
"$CHROOT_ZFS_CLONE_NAME" ]; then
|  if zfs list "$CHROOT_ZFS_CLONE_NAME" >/dev/null 2>&1
|  then
|  if [ "$VERBOSE" = "verbose" ]; then
| -zfs destroy "$CHROOT_ZFS_CLONE_NAME"
| +zfs destroy -r "$CHROOT_ZFS_CLONE_NAME"
|  zfs destroy "$CHROOT_ZFS_SNAPSHOT_NAME"
|  else
| -zfs destroy "$CHROOT_ZFS_CLONE_NAME" > /dev/null
| +zfs destroy -r "$CHROOT_ZFS_CLONE_NAME" > /dev/null
|  zfs destroy "$CHROOT_ZFS_SNAPSHOT_NAME" > /dev/null
|  fi
|  else

I.e. recursively destroy all children of that clone via the "-r" option.
Otherwise I can all too easily happen that such children exist in the
form of snapshots, e.g. when using zfsnap or any such tool that might
automatically create a snapshot of a ZFS dataset while it is in use.

For illustration, let's consider the following sequence of actions:

1. a user enters a ZFS-based chroot via
   $ schroot -c unstable-amd64-sbuild
2. schroot creates a snapshot of the base dataset and then a clone of
   that snapshot, e.g.
   $ zfs list -t all
   [...]
   
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild@unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18
 0B  -  359M  -
   
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18
 8K  62.2G  359M  legacy
3. some tool - here done manually - creates a snapshot of that clone
   $ sudo zfs snapshot 
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18@test
4. the user exits their schroot session and schroot complains
   E: 05zfs: cannot destroy 
'zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18':
 filesystem has children
   E: 05zfs: use '-r' to destroy the following datasets:
   E: 05zfs: 
zfspool/SYSTEM/srv/chroot/unstable-amd64-sbuild/schroot-unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18@test
   E: unstable-amd64-sbuild-44e762df-cab6-4cf3-99dd-15f0fd018d18: Chroot setup 
failed: stage=setup-stop
5. $CHROOT_ZFS_CLONE_NAME and $CHROOT_ZFS_SNAPSHOT_NAME must be cleaned
   up manually

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1007915: node-wikibase-cli: incompatible with node-commander >= 8

[Yadd]

Hi Andrius,

you fix is enough for commander 8, I'm currently writing commander 9 patch

Bug#1008612: closed by Sebastiaan Couwenberg (Re: Bug#1008612: libspatialite7: erroneous geometry conversion using ST_Transform)

[Brian Miles]

Hi Bas,

I apologize that I mis-stated my original description of the bug. It is not 
that the results for 26910 transforms are the same as for 32610 transforms, but 
that transforms to 26910 are simply incorrect for Debian/Ubuntu.

As this is only happening on Debian/Ubuntu, it is not clear to me that bringing 
this upstream will result in resolution. Are there any other option to 
addressing this?

I am happy to help with testing/debugging if that helps.

Thanks,

Brian

> On Mar 29, 2022, at 11:18 AM, Debian Bug Tracking System 
>  wrote:
> 
> This is an automatic notification regarding your Bug report
> which was filed against the libspatialite7 package:
> 
> #1008612: libspatialite7: erroneous geometry conversion using ST_Transform
> 
> It has been closed by Sebastiaan Couwenberg .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Sebastiaan Couwenberg 
>  by
> replying to this email.
> 
> 
> -- 
> 1008612: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008612
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 
> From: Sebastiaan Couwenberg 
> Subject: Re: Bug#1008612: libspatialite7: erroneous geometry conversion using 
> ST_Transform
> Date: March 29, 2022 at 11:05:11 AM EDT
> To: Brian Miles , 1008612-d...@bugs.debian.org
> 
> 
> Hi Brian,
> 
> I'm not in a position to address this issue, please take it upstream. Either 
> the mailing list:
> 
> https://groups.google.com/g/spatialite-users
> 
> Or the issue tracker:
> 
> https://www.gaia-gis.it/fossil/libspatialite/index
> 
> Be aware that upstream development is very slow, don't get your hopes up for 
> a quick fix.
> 
> Kind Regards,
> 
> Bas
> 
> -- 
> GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> 
> 
> From: Brian Miles 
> Subject: libspatialite7: erroneous geometry conversion using ST_Transform
> Date: March 29, 2022 at 10:47:18 AM EDT
> To: sub...@bugs.debian.org
> 
> 
> Package: libspatialite7
> Version: 5.0.1-2
> 
> Hello,
> 
> I have discovered a bug in libspatialite7’s ST_Transform() function where 
> transforms from WGS84 geographic coordinates (EPSG:4326) to NAD83 UTM 10N 
> (26910) returns the result for WGS84 UTM 10N (32610).  This appears to only 
> be occurring on Debian 11 (and perhaps other versions, as well as Ubuntu 
> 20.04, and perhaps other versions). The behavior on macOS and Alpine Linux 
> appears to be correct. Here are the steps to reproduce:
> 
> # DB Setup
> 
> CREATE TABLE IF NOT EXISTS test(id INTEGER PRIMARY KEY);
> SELECT AddGeometryColumn ('test', 'point', 4326, 'POINT', 'XY', 1);
> 
> INSERT INTO test (point) VALUES (GeomFromText('POINT(-122.338928 47.629273)', 
> 4326));
> INSERT INTO test (point) VALUES (GeomFromText('POINT(-122.338923 47.62927)', 
> 4326));
> INSERT INTO test (point) VALUES (GeomFromText('POINT(-122.33895 47.629253)', 
> 4326));
> INSERT INTO test (point) VALUES (GeomFromText('POINT(-122.392051 47.62888)', 
> 4326));
> INSERT INTO test (point) VALUES (GeomFromText('POINT(-122.392038 47.62888)', 
> 4326));
> 
> 
> # Results from Debian 11 (ARM64 and x86_64) and Ubuntu 22.04 (ARM64):
> 
> spatialite> SELECT AsText(point), AsText(ST_Transform(point, 26910)) FROM 
> test;
> POINT(-122.338928 47.629273)|POINT(549665.036792 5275308.276363)
> POINT(-122.338923 47.62927)|POINT(549665.415273 5275307.94615)
> POINT(-122.33895 47.629253)|POINT(549663.402919 5275306.039517)
> POINT(-122.392051 47.62888)|POINT(545674.35684 5275231.954471)
> POINT(-122.392038 47.62888)|POINT(545675.333511 5275231.962125)
> 
> spatialite> SELECT AsText(point), AsText(ST_Transform(point, 32610)) FROM 
> test;
> POINT(-122.338928 47.629273)|POINT(549665.158878 5275308.476981)
> POINT(-122.338923 47.62927)|POINT(549665.53736 5275308.14677)
> POINT(-122.33895 47.629253)|POINT(549663.525012 5275306.240133)
> POINT(-122.392051 47.62888)|POINT(545674.479273 5275232.145082)
> POINT(-122.392038 47.62888)|POINT(545675.455944 5275232.152738)
> spatialite> 
> 
> 
> # Results from macOS 12 (Homebrew or MacPorts; ARM64 and x86_64):
> 
> spatialite> SELECT AsText(point), AsText(ST_Transform(point, 26910)) FROM 
> test;
> AsText(point) AsText(ST_Transform(point, 26910))
>   --
> POINT(-122.338928 47.629273)  POINT(549665.158879 5275308.47686)
> POINT(-122.338923 47.62927)   POINT(549665.537361 5275308.146648)
> POINT(-122.33895 47.629253)   POINT(549663.525012 5275306.240011)
> POINT(-122.392051 47.62888)   POINT(545674.479273 5275232.14496)
> POINT(-122.392038 47.62888)   POINT(545675.455944 5275232.152617)
> 
> spatialite> SELECT AsText(point), AsText(ST_Transform(point, 32610)) FROM 
> test;
> AsText(point) AsText(ST_Transform(point, 32610)) 
>   ---
> POINT(

Bug#1008614: attachment

[Andika Triwidada]

parted_3.4-2_id.po
Description: application/po

Bug#1008614: parted: Updated Indonesian translation

[Andika Triwidada]

Package: parted
Version: 3.4-2
Severity: wishlist
Tags: l10n

Dear Maintainer,

Attached is updated Indonesian translation for parted.

Regards,
Andika

Bug#1007804: amfora: AppArmor policy

[Nilesh Patra]

Hi,

On Thu, 17 Mar 2022 04:46:05 + Jo Coscia  wrote:
> I would like to contribute an AppArmor policy for amfora. I asked the
> folks in #apparmor about this, and they recommended going to the Debian
> bug tracker.
> 
> I tested amfora with the following policy, and all features appear to
> work correctly.

Thanks for your patch. Admittedly I do not know much about apparmor profiles
myself; but I suppose it'd be good if you could submit your patch upstream[1]
I even saw this in our wiki too[2], that the better place to do this is 
upstream itself.

[1]: https://github.com/makeworld-the-better-one/amfora
[2]: 
https://wiki.debian.org/AppArmor/Contribute#Debian_.2F_Upstream_relationship

Regards,
Nilesh


signature.asc
Description: PGP signature