Bug#985292: materia-gtk-theme: unhandled symlink to directory conversion: /usr/share/themes/Materia-compact/gtk-3.0/assets -> ../gtk-assets

[Leandro Cunha]

Hi,

Can you test the version I pushed for Salsa and confirm that the problem
has been fixed?

[1] https://salsa.debian.org/leandrocunha/materia-gtk-theme
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985292

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#986320: Stronger advice on when to use native packages

[Russ Allbery]

Package: debian-policy
Version: 4.5.1.0
Severity: wishlist

Currently, Debian Policy is silent on when it's appropriate to use a
native package, but there may be a project consensus aganist using
native packages when the software has an existence outside of Debian.

Even if that consensus does not exist, there is probably consensus
that native packages are a poor match for large packages (because of
the inefficiency of making small updates to the packaging of native
packages), and there may be other cases where we can give stronger
guidance.

Probe the project consensus here and see if Policy should say something
stronger.

(See #542288 for some of this discussion.)

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  3.4.3-2

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

Bug#986129: unblock: sendmail/8.15.2-22

[Paul Gevers]

Control: reassign -1 -2 release-notes
Control: retitle -2 sendmail is stopped during upgrades
Control: tag -2 patch
Control: close -1

Hi Andreas,

On 30-03-2021 09:05, Andreas Beckmann wrote:
> Please unblock package sendmail

Unblocked.

> sendmail does not cleanly restart after upgrading from buster because
> the binaries were moved from /usr/lib/sm.bin to /usr/libexec/sendmail.
> So let's stop sendmail in preinst if upgrading from a version with the
> old layout. (To minimize downtime sendmail is usually not stopped before
> the new version gets unpacked, but only restarted in postinst.)

If I understand you correctly, users don't expect this historically. So,
do you think this warrants a comment in the release notes? We already
have a section about "prepare for downtime" [1], but if this went more
smoothly in the past, it may me still smart. Something like:

"""
In contrast to normal upgrades of sendmail, during the upgrade of buster
to bullseye sendmail will be stopped, causing more downtime to the
service than other sendmail upgrades. Please read [1] for generic advice
on reducing downtime.
"""

Paul

[1]
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#services-downtime



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986319: towncrier: incorrect Homepage URL

[Paul Wise]

Package: towncrier
Severity: minor
Usertags: homepage

The web page at the URL in the current Homepage field says that the
homepage for towncrier is elsewhere.

   $ apt-cache show towncrier | grep -i homepage
   Homepage: https://pypi.org/project/towncrier/
   
   $ curl -s https://pypi.org/project/towncrier/ | html2markdown | grep -i 
homepage | sort -u
 * [ __Homepage](https://github.com/hawkowl/towncrier)
   
-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages towncrier depends on:
ii  python3  3.9.2-2
ii  python3-click7.1.2-1
ii  python3-incremental  17.5.0-1
ii  python3-jinja2   2.11.3-1
ii  python3-toml 0.10.1-1

towncrier recommends no packages.

towncrier suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#986317: inform6-compiler: New upstream available

[Nathanael Nerode]

Package: inform6-compiler
Version: 6.33-2+b1
Severity: normal
X-Debbugs-Cc: ncn_flos...@fastmail.fm

Dear Maintainer,

Inform 6.34 was released in mid-2020.

https://github.com/DavidKinder/Inform6/releases/tag/v6.34

There are several reasons to update to this.  It fixes several bugs and is 
usable with the (not in Debian) package Inform 7, which verion 6.33 is not.

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

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

Versions of packages inform6-compiler depends on:
ii  libc6  2.31-9

Versions of packages inform6-compiler recommends:
ii  frotz [zcode-interpreter]  2.53+dfsg-1
ii  gargoyle-free [zcode-interpreter]  2019.1.1-2
ii  inform6-library6.12.2+dfsg.1-1.1
ii  sdlfrotz [zcode-interpreter]   2.53+dfsg-1

Versions of packages inform6-compiler suggests:
pn  inform-mode  
pn  inform6-doc  

-- no debconf information

Bug#986318: inform6-compiler: inform6 would run twice as fast if compiled with -flto

[Nathanael Nerode]

Package: inform6-compiler
Version: 6.33-2+b1
Severity: wishlist
X-Debbugs-Cc: ncn_flos...@fastmail.fm

Dear Maintainer,

I have tested and Inform 6 runs twice as fast if compiled with the -flto option 
(which is over 10 years old and highly stable) and any level of optimization 
(-O2, -O1, -Og.)  I strongly suggest that this be done as the standard compile 
for the Debian package.

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

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

Versions of packages inform6-compiler depends on:
ii  libc6  2.31-9

Versions of packages inform6-compiler recommends:
ii  frotz [zcode-interpreter]  2.53+dfsg-1
ii  gargoyle-free [zcode-interpreter]  2019.1.1-2
ii  inform6-library6.12.2+dfsg.1-1.1
ii  sdlfrotz [zcode-interpreter]   2.53+dfsg-1

Versions of packages inform6-compiler suggests:
pn  inform-mode  
pn  inform6-doc  

-- no debconf information

Bug#417411: readpst: Need to address encoding differences

[Paul Wise]

Hi Osamu,

On Tue, 3 Apr 2007 01:47:28 +0900 Osamu Aoki wrote:

> Thanks for interesting tool.  This is helping me to move my wife's old
> Windows mail to a diifferent platform.
> 
> I realized that old windows (95,98,Me) versions used non-utf-8 encodings
> for different countries.  So when one extracts the content of pst file,
> filenames are encoded in traditional non-utf-8 format (Names like Inbox
> are translated into each language in pst).

I recently adopted readpst and I am now triaging the bug reports.

Would it be possible for you to attach an example PST file with
non-UTF-8 content, without any private information? 

The two scripts that you attached to the bug report have some coding
issues. I have fixed the issues reported by shellcheck, fixed some
other issues and attached the new versions to this email.

Would it be possible for you to discuss the scripts with the upstream
maintainer? They don't have time to maintain the project but are
willing to accept patches to the Mercurial repository.

Carl Byington 
https://www.five-ten-sg.com/libpst/
http://hg.five-ten-sg.com/libpst/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


pst_fix_filename
Description: application/shellscript


script-recode
Description: application/shellscript


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

Bug#986316: poke: incorrect homepage URL

[Paul Wise]

On Fri, 2021-04-02 at 21:08 -0400, Sergio Durigan Junior wrote:

> The decision to use the gnu.org URL was made consciously: poke is a GNU
> official project, and as such I think it is more correct to direct the
> user to the GNU project's home page.  Having said that, I agree that
> ideally that page should contain everything related to poke without
> redirecting the user to another URL.

Understandable and agreed. However, right now the page on author's
website is much more useful to Debian users than the GNU web page.

> I have contacted upstream and asked them which homepage they would like
> the Debian package to point users to.  My understanding is that they
> want to make the gnu.org page the official one, but I may be wrong.

Getting input from upstream is a good idea, I expect they are waiting
on someone in the FSF/GNU to be able to update the GNU web page.

Perhaps for the next upload you could use the page on the author's
website and switch it over to the GNU one when that gets updated?

PS: I noticed this because of the recent (now closed) ITP for GNU poke:

https://bugs.debian.org/986288

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#986316: poke: incorrect homepage URL

[Sergio Durigan Junior]

On Friday, April 02 2021, Paul Wise wrote:

> The web page at the URL in the current Homepage field says that the
> homepage for GNU poke is elsewhere.
>
>$ apt-cache show poke | grep Homepage
>Homepage: https://www.gnu.org/software/poke/
>
>$ w3m -dump https://www.gnu.org/software/poke/ | grep -i homepage
>The poke homepage is at http://www.jemarch.net/poke.
>
> The URL being suggested doesn't use https but does support https:
>
>$ diff -u <(curl -s http://www.jemarch.net/poke) <(curl -s 
> https://www.jemarch.net/poke)

Thank you for the bug report.

The decision to use the gnu.org URL was made consciously: poke is a GNU
official project, and as such I think it is more correct to direct the
user to the GNU project's home page.  Having said that, I agree that
ideally that page should contain everything related to poke without
redirecting the user to another URL.

I have contacted upstream and asked them which homepage they would like
the Debian package to point users to.  My understanding is that they
want to make the gnu.org page the official one, but I may be wrong.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#986314: RFS: gsimplecal/2.1-2 [QA] -- lightweight GUI calendar application

[Hugo Torres de Lima]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gsimplecal":

 * Package name: gsimplecal
   Version : 2.1-2
   Upstream Author : https://github.com/dmedvinsky/gsimplecal/issues
 * URL : https://dmedvinsky.github.io/gsimplecal
 * License : BSD-3-Clause
 * Vcs : http://anonscm.debian.org/cgit/collab-maint/gsimplecal.git
   Section : misc

It builds those binary packages:

  gsimplecal - lightweight GUI calendar application

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

  https://mentors.debian.net/package/gsimplecal/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gsimplecal/gsimplecal_2.1-2.dsc

Changes since the last upload:

 gsimplecal (2.1-2) experimental; urgency=medium
 .
   * QA upload.
   * Using new DH level format. Consequently:
   - debian/compat: Removed.
   - debian/control: Changed from 'debhelper' to 'debhelper-compat' in
 Build-Depends field and bumped level to 13.
   * debian/control:
   - Added 'Rules-Requires-Root: no' to source stanza.
   - Bumped Standards-Version to 4.5.1.
   - Changed priority to optional.
   - Removed the dh-autoreconf from Build-Depends field.
   - Updated homepage.
   * debian/copyright:
   - Added Upstream-Contact.
   - Updated upstream and packaging copyright years.
   - Using a secure URI in Format field.
   * debian/docs: Added document README.rst.
   * debian/rules: Added the DEB_CXXFLAGS_MAINT_APPEND and
   DEB_LDFLAGS_MAINT_APPEND variable to improve the GCC
   hardening.
   * debian/upstream/metadata: Created.
   * debian/watch:
   - Bumped to version 4.
   - Updated the source address.

Regards,
-- 
  Hugo Torres de Lima

Bug#986316: poke: incorrect homepage URL

[Paul Wise]

Package: poke
Version: 1.1+dfsg-2
Severity: minor

The web page at the URL in the current Homepage field says that the
homepage for GNU poke is elsewhere.

   $ apt-cache show poke | grep Homepage
   Homepage: https://www.gnu.org/software/poke/
   
   $ w3m -dump https://www.gnu.org/software/poke/ | grep -i homepage
   The poke homepage is at http://www.jemarch.net/poke.
   
The URL being suggested doesn't use https but does support https:
   
   $ diff -u <(curl -s http://www.jemarch.net/poke) <(curl -s 
https://www.jemarch.net/poke)

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages poke depends on:
ii  libc6   2.31-10
ii  libjson-c5  0.15-2
ii  libpoke01.1+dfsg-2
ii  libreadline88.1-1
ii  sensible-utils  0.0.14

poke recommends no packages.

poke suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#976050: mailutils: FTBFS on amd64 with current unstable

[Chris Hofstaedtler]

Control: severity -1 important

* Rob Browning  [210403 00:45]:
> Andreas Henriksson  writes:
> 
> > Thanks for this info, it made it much easier to know where to look for
> > the problem which is caused by having emacs installed in the build
> > environment (which it isn't in a clean buildd chroot).
> 
> Ahh, sorry, clearly forgot to mention that I'd also run "apt install
> emacs-nox" to do some editing.  Glad you figured it out.

Given building mailutils works in a clean environment, this bug is
not really severity: serious AFAICT.

Should still be fixed, obviously.

Chris

Bug#568834: First stab at functionality for copying files

[Benj. Mako Hill]

Greetings!


> It's been quite a while since I've written Perl and I'm not 100% sure
> that I've thought the logic through completely so as to avoid all
> possible corner cases (e.g., related to every way one would swap
> filenames and/or copy things repeatedly).

I'm attaching an updated and better version of the patch. It's
stylistically more consistent and fixes at least one bug/corner case.

It's obviously still be good to have someone look at it and think
through through this a little before it's applied.

In any case, I'm using it now and will try to stress test it and
figure out what the corner cases are.

Later,
Mako


-- 
Benjamin Mako Hill
https://mako.cc/
--- /home/mako/bin/vidir	2021-04-02 17:24:01.718977602 -0700
+++ /usr/bin/vidir	2019-08-18 06:27:38.0 -0700
@@ -81,7 +81,6 @@
 use File::Path qw(make_path);
 use File::Spec;
 use File::Temp;
-use File::Copy;
 use Getopt::Long;
 
 my $error=0;
@@ -144,7 +143,6 @@
 	die "@editor exited nonzero, aborting\n";
 }
 
-my %finished_item;
 open (IN, $tmp->filename) || die "$0: cannot read ".$tmp->filename.": $!\n";
 while () {
 	chomp;
@@ -152,26 +150,7 @@
 		my $num=int($1);
 		my $name=$2;
 		if (! exists $item{$num}) {
-			# attempt to copy files if a duplicate of a number we've already seen before
-			if (exists $finished_item{$num}) {
-if ($name eq $finished_item{$num}) {
-	print STDERR "$0: cannot copy because source ($finished_item{$num}) and destination ($name) are the same\n";
-} 
-elsif (-e $name || -l $name) {
-	print STDERR "$0: cannot copy because destination ($name) already exists\n";
-}
-elsif (! (-e $finished_item{$num} || -l $finished_item{$num})) {
-	print STDERR "$0: cannot copy because source ($finished_item{$num}) does not exist\n";
-}
-elsif (! copy($finished_item{$num}, $name)) {
-	print STDERR "$0: failed to copy $finished_item{$num} to $name: $!\n";
-	$error=1;
-}
-next;
-			}
-			else {
-die "$0: unknown item number $num\n";
-			}
+			die "$0: unknown item number $num\n";
 		}
 		elsif ($name ne $item{$num}) {
 			next unless length $name;
@@ -227,7 +206,6 @@
 }
 			}
 		}
-		$finished_item{$num} = $name;
 		delete $item{$num};
 	}
 	elsif (/^\s*$/) {


signature.asc
Description: PGP signature

Bug#983203: your mail

[Chris Hofstaedtler]

Control: severity -1 important

* Lyndon Brown  [210308 22:09]:
> # set severity to grave since it appears that the package is completely
> # broken currently.
> severity 983203 grave

"completely broken" appears to be a gross overstatement. The
firewalld integration might be broken - and I agree it should be
fixed - but sshguard supports other firewall tools as well.

Chris

Bug#882872: First stab at functionality for copying files

[Benj. Mako Hill]

tags 882872 patch
thanks

Greetings!

Thanks for maintaining moreutils! It's one of the packages I love most
in Debian!

I'm attaching a first stab a patch to add copying file support to
vidir (i.e., #882872) which is something I've wanted for a very long
time and just broke down and did today.

It's been quite a while since I've written Perl and I'm not 100% sure
that I've thought the logic through completely so as to avoid all
possible corner cases (e.g., related to every way one would swap
filenames and/or copy things repeatedly).

The way it works is much simpler than the model suggested in #568834,
(which, BTW, sounds very nice): If a line number shows up twice in the
vidir output—and if the two filenames associated with the lines
numbers—are different, the file gets copied. That's it. :)

Regards,
Mako


-- 
Benjamin Mako Hill
https://mako.cc/
--- /home/mako/bin/vidir	2021-04-02 16:48:20.646390946 -0700
+++ /usr/bin/vidir	2019-08-18 06:27:38.0 -0700
@@ -81,7 +81,6 @@
 use File::Path qw(make_path);
 use File::Spec;
 use File::Temp;
-use File::Copy;
 use Getopt::Long;
 
 my $error=0;
@@ -144,7 +143,6 @@
 	die "@editor exited nonzero, aborting\n";
 }
 
-my %finished_item;
 open (IN, $tmp->filename) || die "$0: cannot read ".$tmp->filename.": $!\n";
 while () {
 	chomp;
@@ -152,24 +150,7 @@
 		my $num=int($1);
 		my $name=$2;
 		if (! exists $item{$num}) {
-			# copy files if a dupliate of a number we've already seen before
-			if (exists $finished_item{$num}) {
-if ($name eq $finished_item{$num}) {
-	print STDERR "$0: cannot copy because source ($finished_item{$num}) and destination ($name) are the same\n";
-	delete $item{$num};
-} elsif (-e $name || -l $name) {
-	print STDERR "$0: cannot copy because destination ($name) already exists\n";
-	delete $item{$num};
-} elsif (! (-e $finished_item{$num} || -l $finished_item{$num})) {
-	print STDERR "$0: cannot copy because $finished_item{$num} does not exist\n";
-	delete $item{$num};
-} elsif (! copy($finished_item{$num}, $name)) {
-	print STDERR "$0: failed to copy $finished_item{$num} to $name: $!\n";
-	$error=1;
-}
-			} else {
-die "$0: unknown item number $num\n";
-			}
+			die "$0: unknown item number $num\n";
 		}
 		elsif ($name ne $item{$num}) {
 			next unless length $name;
@@ -225,7 +206,6 @@
 }
 			}
 		}
-		$finished_item{$num} = $name;
 		delete $item{$num};
 	}
 	elsif (/^\s*$/) {


signature.asc
Description: PGP signature

Bug#678437: Still valid

[Edmund Christian Herenz]

This bug is nine years old, but still valid in Debian Buster.

Bug#963210: qa.debian.org: DDPO still using old name

[Raúl Benencia]

On Sat, Jun 20, 2020 at 05:07:43PM +0100, Martina Ferrari wrote:
> In the past months, I have been gradually switching all my online identities 
> to
> my new name (Martina) and uid/nick (Tina). I have changed emails, GPG keys, 
> and
> finally my Debian LDAP uid.

Hola Martina! Long time. :-)

I did some research to get to the bottom of this issue. I'll be verbose
describing what I found in hopes of it being useful for similar issues in the
future.

The source of your deadname is in a database that DDPO uses under the hood
called carnivore[1]. I think your case might be very similar to #706260. In your
case, names are being merged[2] because there are still some packages that use
your deadname.

In quants, qa.debian.org, if you check the file
/srv/qa.debian.org/carnivore/uids you might see something like this:

| martina ferrari : email:t...@debian.org
| martina ferrari : email:t...@debian.org
| martín ferrari : email:t...@debian.org

I haven't confirmed this—I don't have access to quants—but I tried it locally
after running extract_data myself.

You can explicitly state[3] that you don't want your name to be merged with your
deadname, at the cost of unlinking the two uids. If you add[3] "Martina
Ferrari", then the result will be:

| martina ferrari : email:t...@debian.org
|
| martina ferrari : email:tin...@debian.org
| martín ferrari : email:tin...@debian.org

This approach has the disadvantage that you'll stop seeing all packages in a
single page; probably not what you want, so I kept digging.

The developer.wml[4] file shows that it chooses the first name of all the
indexed names. A possible solution is to somehow set your name at the beginning
of that list. Another solution can be to state that you prefer a single name on
the DB.

I wrote a patch that implements this last solution, allowing you to state a
preferred name. I'm still testing it, but I'll try to submit it for review on
the weekend.

nota bene: it's the first time I'm interacting with this codebase so I might be
entirely wrong. \o/

[1] https://salsa.debian.org/qa/qa/-/blob/c850ab59/carnivore/README#L12-13
[2] https://salsa.debian.org/qa/qa/-/blob/c850ab59/carnivore/extract_data#L85
[3] https://salsa.debian.org/qa/qa/-/blob/c850ab59/carnivore/extract_data#L82
[4] https://salsa.debian.org/qa/qa/-/blob/c850ab59/wml/developer.wml#L1654


signature.asc
Description: PGP signature

Bug#986315: Pychess requires psutil

[Tamás Bajusz]

Unfortunately official Debian packages are updated rarely.
Try the latest release from https://github.com/pychess/pychess/releases

Bug#985629: Bug#981405: unblock (pre-approval): cryptsetup/2:2.3.5-1

[Guilhem Moulin]

Control: tag -1 - moreinfo

Hi Paul,

On Fri, 02 Apr 2021 at 22:33:05 +0200, Paul Gevers wrote:
> I'm not overly enthusiastic about the size of the diff, but indeed this
> seems like something we'd want.
> 
> Please go ahead and remove the moreinfo tag once the upload has happened.

Done, many thanks and apologies for the extra work!  (And also sorry
carnil for typoing your name in msg#10.)

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#986315: pychess: Pychess requires psutil

[André Caldas]

Package: pychess
Version: 1.0.0-1.1
Severity: important
X-Debbugs-Cc: andre.em.cal...@gmail.com

Dear Maintainer,

When executed, exits with error:
ERROR: PyChess requires psutil to be installed

Executed from console:
$ pychess

To fix the problem, I just installed python3-psutil.


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

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

Versions of packages pychess depends on:
ii  gaviotatb0.4-2.1
ii  gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gst-plugins-base-1.0  1.18.3-1
ii  gir1.2-gstreamer-1.0 1.18.3-1
ii  gir1.2-gtk-3.0   3.24.24-1
ii  gir1.2-gtksource-3.0 3.24.11-2
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-rsvg-2.0  2.50.2+dfsg-1
ii  gnome-icon-theme 3.12.0-3
ii  gobject-introspection1.66.1-1+b1
ii  libgaviotatb10.4-2.1
ii  python3  3.9.1-1
ii  python3-cairo1.16.2-4+b2
ii  python3-gi   3.38.0-1+b2
ii  python3-gi-cairo 3.38.0-1+b2
ii  python3-websockets   8.1-1

pychess recommends no packages.

pychess suggests no packages.

-- no debconf information

Bug#986309: surf: Please update embedded copy of the AppArmor gstreamer abstraction

[Reiner Herrmann]

Hi intrigeri,

On Fri, Apr 02, 2021 at 09:39:32PM +0200, intrig...@debian.org wrote:
> This autopkgtest:
> 
>   Test-Command: cmp /etc/apparmor.d/abstractions/surf-gstreamer 
> /etc/apparmor.d/abstractions/gstreamer
> 
> … fails since I've uploaded apparmor-profiles-extra 1.32,
> which modifies /etc/apparmor.d/abstractions/gstreamer.
> 
> This blocks the migration of apparmor-profiles-extra to testing.
> 
> Could you please update your copy of that file?

Thanks for the notice. I just uploaded a new revision which includes
your updated file.

> (Longer term, this makes me less convinced that the strategy chosen in
> #901416 and #912026 a few years back is ideal. If you'd like to
> re-consider this, e.g. to replace the copied abstraction with
> a dependency on apparmor-profiles-extra at some point, let me know if
> there's anything you need from me.)

I don't really want to add a dependency, as surf is perfectly usable
without AppArmor. I also think the current solution is not ideal,
but so far the updates to the gstreamer abstraction were rare,
and thanks to autopkgtest quickly detectable. Let's keep the current
state for now. :-)

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#986288: ITP: poke -- GNU poke, an interactive, extensible binary editor

[Peter Pentchev]

On Fri, Apr 02, 2021 at 03:18:40PM +0200, Hilko Bengen wrote:
> Package: wnpp
> Owner: Hilko Bengen 
> Severity: wishlist
> 
> * Package name: poke
>   Version : 1.1
>   Upstream Author : Jose E. Marchesi
> * URL or Web page : https://www.jemarch.net/poke
> * License : GPL-3+
>   Description : GNU poke, an interactive, extensible binary editor

This seems to be in experimental already, albeit with a different
upstream site:

  https://tracker.debian.org/pkg/poke

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#986312: NVRM: request_mem_region failed for 0M @ 0x0.

[PICCA Frederic-Emmanuel]

I have also this information in the syslog

Mar 29 08:01:51 re-grades-01 kernel: [1.762583] pci :42:04.0: BAR 15: 
no space for [mem size 0x13800 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762584] pci :42:04.0: BAR 15: 
failed to assign [mem size 0x13800 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762586] pci :42:08.0: BAR 15: 
no space for [mem size 0x13800 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762587] pci :42:08.0: BAR 15: 
failed to assign [mem size 0x13800 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762589] pci :42:0c.0: BAR 15: 
no space for [mem size 0x13800 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762590] pci :42:0c.0: BAR 15: 
failed to assign [mem size 0x13800 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762592] pci :43:00.0: BAR 1: no 
space for [mem size 0x1000 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762593] pci :43:00.0: BAR 1: 
trying firmware assignment [mem 0x2e08000-0x2e08fff 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762594] pci :43:00.0: BAR 1: 
[mem 0x2e08000-0x2e08fff 64bit pref] conflicts with PCI Bus :40 
[mem 0x260c020-0x2e0c01\
f window]
Mar 29 08:01:51 re-grades-01 kernel: [1.762595] pci :43:00.0: BAR 1: 
failed to assign [mem size 0x1000 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762596] pci :43:00.0: BAR 8: no 
space for [mem size 0x1 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762597] pci :43:00.0: BAR 8: 
trying firmware assignment [mem 0x2df8000-0x2e07fff 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762598] pci :43:00.0: BAR 8: 
[mem 0x2df8000-0x2e07fff 64bit pref] conflicts with PCI Bus :40 
[mem 0x260c020-0x2e0c01\
f window]
Mar 29 08:01:51 re-grades-01 kernel: [1.762599] pci :43:00.0: BAR 8: 
failed to assign [mem size 0x1 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762600] pci :43:00.0: BAR 3: no 
space for [mem size 0x0200 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762601] pci :43:00.0: BAR 3: 
trying firmware assignment [mem 0x2e0b000-0x2e0b1ff 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762602] pci :43:00.0: BAR 3: 
[mem 0x2e0b000-0x2e0b1ff 64bit pref] conflicts with PCI Bus :40 
[mem 0x260c020-0x2e0c01\
f window]
Mar 29 08:01:51 re-grades-01 kernel: [1.762603] pci :43:00.0: BAR 3: 
failed to assign [mem size 0x0200 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762604] pci :43:00.0: BAR 10: 
no space for [mem size 0x2000 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762604] pci :43:00.0: BAR 10: 
trying firmware assignment [mem 0x2e09000-0x2e0afff 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762606] pci :43:00.0: BAR 10: 
[mem 0x2e09000-0x2e0afff 64bit pref] conflicts with PCI Bus :40 
[mem 0x260c020-0x2e0c01fff\
ff window]
Mar 29 08:01:51 re-grades-01 kernel: [1.762606] pci :43:00.0: BAR 10: 
failed to assign [mem size 0x2000 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762607] pci :42:04.0: PCI 
bridge to [bus 43]
Mar 29 08:01:51 re-grades-01 kernel: [1.762611] pci :42:04.0:   bridge 
window [mem 0xca00-0xcb3f]
Mar 29 08:01:51 re-grades-01 kernel: [1.762619] pci :44:00.0: BAR 1: no 
space for [mem size 0x1000 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762620] pci :44:00.0: BAR 1: 
trying firmware assignment [mem 0x2df4000-0x2df4fff 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762621] pci :44:00.0: BAR 1: 
[mem 0x2df4000-0x2df4fff 64bit pref] conflicts with PCI Bus :40 
[mem 0x260c020-0x2e0c01\
f window]
Mar 29 08:01:51 re-grades-01 kernel: [1.762622] pci :44:00.0: BAR 1: 
failed to assign [mem size 0x1000 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762622] pci :44:00.0: BAR 8: no 
space for [mem size 0x1 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762623] pci :44:00.0: BAR 8: 
trying firmware assignment [mem 0x2de4000-0x2df3fff 64bit pref]
Mar 29 08:01:51 re-grades-01 kernel: [1.762624] pci :44:00.0: BAR 8: 
[mem 0x2de4000-0x2df3fff 64bit pref] conflicts with PCI Bus :40 
[mem 0x260c020-0x2e0c01\


Maybe the conflict is responsible of this issue.

Do you have an idea of what should cause this conflict ?

Bug#986312: NVRM: request_mem_region failed for 0M @ 0x0.

[PICCA Frederic-Emmanuel]

Hello andreas

> what's the NUMA layout of the machine? what cpus do you have in there?

I attached the lstopo output.

> Great. Half of the bus ids are in hex, half in decimal.

> How many cards do you have in there? And how many pci devices are there
> per card?

the list is in the reportbug :)

3 x RTX 3090 and 6 x T4

> Have you tried different drivers? (tesla-450, tesla-460)

only the 460

> Have you tried with only one kind of cards (Tesla or Geforce) in there?

no

> Have you tried with only a single card in there?

no


Fred

re-grades-01.pdf
Description: re-grades-01.pdf

Bug#986312: NVRM: request_mem_region failed for 0M @ 0x0.

[Andreas Beckmann]

On 02/04/2021 22.06, PICCA Frederic-Emmanuel wrote:

All the graphical cards on the numa node 0 are not available on my computer.


what's the NUMA layout of the machine? what cpus do you have in there?


We are using this computer in order to do data treatment in a scientific 
facility.

During the boot we have these error messages

Mar 29 13:08:12 re-grades-01 kernel: [6.726771] NVRM: request_mem_region 
failed for 0M @ 0x0. This can
Mar 29 13:08:12 re-grades-01 kernel: [6.726771] NVRM: occur when a driver 
such as rivatv is loaded and claims
Mar 29 13:08:12 re-grades-01 kernel: [6.726771] NVRM: ownership of the 
device's registers.
Mar 29 13:08:12 re-grades-01 kernel: [6.726792] nvidia: probe of 
:43:00.0 failed with error -1

...

I would like to help debug this issue, but I do not know where to start.

thanks for considering




[22.870] (--) PCI: (67@0:0:0) 10de:1eb8:10de:12a2 rev 161, Mem @ 
0x260d000/268435456, 0x261e000/33554432
[22.870] (--) PCI: (68@0:0:0) 10de:1eb8:10de:12a2 rev 161, Mem @ 
0x2633000/268435456, 0x2644000/33554432
[22.870] (--) PCI: (69@0:0:0) 10de:1eb8:10de:12a2 rev 161, Mem @ 
0x2659000/268435456, 0x266a000/33554432
[22.870] (--) PCI: (70@0:0:0) 10de:2204:1043:87d5 rev 161, Mem @ 
0x267f000/268435456, 0x268/33554432, I/O @ 0x6000/128
[22.870] (--) PCI:*(101@0:0:0) 1a03:2000:1458:1000 rev 65, Mem @ 
0xd200/33554432, 0xd400/131072, I/O @ 0x7000/128, BIOS @ 
0x/131072
[22.870] (--) PCI: (131@0:0:0) 10de:1eb8:10de:12a2 rev 161, Mem @ 
0x9600/16777216, 0x6616000/268435456, 0x6619000/33554432
[22.871] (--) PCI: (132@0:0:0) 10de:1eb8:10de:12a2 rev 161, Mem @ 
0x9400/16777216, 0x6602000/268435456, 0x6605000/33554432
[22.871] (--) PCI: (133@0:0:0) 10de:2204:1043:87d5 rev 161, Mem @ 
0x9a00/16777216, 0x661c000/268435456, 0x661d000/33554432, I/O @ 
0xd000/128, BIOS @ 0x/524288
[22.871] (--) PCI: (134@0:0:0) 10de:2204:1043:87d5 rev 161, Mem @ 
0x9800/16777216, 0x661a000/268435456, 0x661b000/33554432, I/O @ 
0xc000/128, BIOS @ 0x/524288
[22.871] (--) PCI: (135@0:0:0) 10de:1eb8:10de:12a2 rev 161, Mem @ 
0x9200/16777216, 0x65ee000/268435456, 0x65f1000/33554432


Great. Half of the bus ids are in hex, half in decimal.

How many cards do you have in there? And how many pci devices are there 
per card?


Have you tried different drivers? (tesla-450, tesla-460)
Have you tried with only one kind of cards (Tesla or Geforce) in there?
Have you tried with only a single card in there?

Andreas

Bug#985958: [pre-approval] unblock: spip/3.2.11-2

[Paul Gevers]

Control: tags -1 moreinfo

Hi David,

On 26-03-2021 20:53, David Prévot wrote:
> Please unblock package spip

This package does have a bit of a track record for security issues.

> [ Reason ]
> Upstream just released a new minor version to improve PHP 7.4 compat
> (latest version already improved PHP 7.3 compat). Since Bullseye ship
> with PHP 7.4, including those fixes should avoid future issues (I had
> to backport a PHP 7.3 compatibility issue with a buster-security upload
> already to fix a serious issue with plugins handling).

If I read the upstream CHANGELOG correctly, it seems that this was all
put together in a short time (days). Are you aware of any tests in the
package (I didn't spot them)? Does upstream have any testing infra?

I'm seriously doubting if we'd not introduce more issues than we solve here.

> [ Impact ]
> On top of fixing possible problems, this update avoids filling the
> web server error.log due to multiple warnings and deprecation notices.

Ack. Are those fixes cherry-pickable?

> [ Tests ]
> I only tested the package manually, but I’m keeping an eye on upstream
> issues that may arise about this new release.

See above. This doesn't sound great.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985629: Bug#981405: unblock (pre-approval): cryptsetup/2:2.3.5-1

[Paul Gevers]

Control: tags -1 moreinfo confirmed

Hi Guilhem,

On 21-03-2021 14:55, Guilhem Moulin wrote:
> On Sun, 21 Mar 2021 at 00:51:06 +0100, Guilhem Moulin wrote:
>> I'm seeking pre-approval to upload cryptsetup/2:2.3.5-1 to unstable.
>> Hopefully the attached debdiff is not too large/intrusive for inclusion
>> in Bullseye.  For convenience I'm also attaching a diff with the ‘tests’
>> and ‘po’ directories (which arguably add a lot of clutter), as well as a
>> diff with only upstream's ‘lib’ and ‘src’ directories (given it's really
>> what this is about).

I'm not overly enthusiastic about the size of the diff, but indeed this
seems like something we'd want.

Please go ahead and remove the moreinfo tag once the upload has happened.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986139: offlineimap3 crashes with encoding error

[Sudip Mukherjee]

Control: forwarded -1 https://github.com/OfflineIMAP/offlineimap3/issues/62
--

On Fri, Apr 2, 2021 at 11:18 AM Nehalenniæ Oudin  wrote:
>
> Hi,
>
> I have the same problem.
> If I have some time, I'll have a look at it.

Thanks. You might like to raise a PR in upstream repo also.


-- 
Regards
Sudip

Bug#985661: linker flags

[Valerio Messina]

in my current project I had to manually add:
 -lzip -lboost_system -lboost_filesystem -lboost_locale -lpthread
(discovered by try and errors) to linker flags to build the binary.

I'm expect those dependencies come from pkg-config

--
Valerio

Bug#953947: debci: arm64 autopkgtest regularly times out

[Chris Hofstaedtler]

* Paul Gevers  [210402 20:11]:
> Source: debci
> Version: 2.6
> User: debian...@lists.debian.org
> Usertags: timeout
> 
> Dear Antonio, myself and all,
> 
> Debci fails its own autopkgtest on arm64. Moreover, it regularly times out.
> 
> Can we please investigate the situation?
> 
> To avoid wasting lots of time on the ci.debian.net infrastructure, I
> have add our own package to the ignore list for arm64.

This can also be seen on armhf, and amd64:

https://ci.debian.net/data/autopkgtest/testing/armhf/d/debci/11403517/log.gz
https://ci.debian.net/data/autopkgtest/testing/amd64/d/debci/11311391/log.gz

Might make sense to disable this test for bullseye if it cannot be fixed?

Chris

Bug#986030: manpages.debian.org: Content does no match shipped (deb) version: testing/manpages-de/journalctl.1.de.html

[Paul Gevers]

Hi,

On 28-03-2021 11:21, Helge Kreutzmann wrote:
> So this text is in Unstable since version 4.9.1-1 (February 7th) and
> Testing since March 2nd.
> 
> So my assumption is that the update mechanism of 
> manpages.debian.org does not work correctly.

Interestingly enough both unstable and testing claim to be extracted from:
 Source file:   journalctl.1.de.gz (from manpages-de 4.9.3-4)

and following the link to the raw man page shows the new content.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986311: unblock: debian-cloud-images/0.0.4

[Noah Meyerhans]

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

Please unblock package debian-cloud-images

Primarily I'm requesting this because this source package provides the
debian-cloud-images-packages package that is a key package (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929214) and updating the
package in bullseye will update the Depends list to match what is actually
required to build cloud images today.

This package contains a snapshot of the code and configuration used by the
cloud team to generate the images for azure, aws, and openstack.  The cloud
team does not build directly from the packages in the archive, but rather
from the salsa repository.  So there is no risk of impact to the cloud
images we generate if this package is updated.  Keeping the archive package
closer to what's actually used by the cloud team is beneficial to any users
who might be generating their own images based on our configuration.

Thanks
noah

unblock debian-cloud-images/0.0.4

Bug#985473: slic3r: symbol lookup error after gcode export

[Bernhard Übelacker]

Dear Maintainer,
tried to export the example files delivered with prusa-slicer
e.g. AK_Bed.stl, but could  not  reproduce the fault inside
a minimal qemu VM.

My resulting process has /usr/lib/slic3r/auto/Slic3r/XS/XS.so
mapped, the function _ZN5boost6nowide6setenvEPKcS2_i
would be printed by gdb as this:
"boost::nowide::setenv(char const*, char const*, int)@plt"
But I could not see gdb trapping at this breakpoint.
Maybe I have not a good input file for this.

Kind regards,
Bernhard

Bug#892842: kotlin progress

[Phil Morrell]

On Sat, Oct 17, 2020 at 03:36:35PM +0100, Phil Morrell wrote:
> The latest packaging can be found on salsa. It is capable of building
> itself but doesn't yet include all the required jars in the final
> package. Instructions are also on salsa and discussion happens in
> #debian-android-tools and monthly Jitsi/IRC calls.
> 
> https://salsa.debian.org/samyak-jn/kotlin
> https://salsa.debian.org/android-tools-team/admin/-/issues/27
> https://lists.debian.org/debian-android-tools/2020/09/msg0.html

With huge thanks to Sunil, a major blocker open since October has now
been cleared (see commit for gory details). The repo will be moved to
java-team in salsa, but until then the issue tracker has next steps:

https://salsa.debian.org/android-tools-team/admin/-/issues
https://lists.debian.org/debian-android-tools/2021/03/msg00013.html
https://salsa.debian.org/samyak-jn/kotlin/-/commit/04274d619e65e474b4cd730d07107dd319f760ab


signature.asc
Description: PGP signature

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[Paul Gevers]

Hi

On 02-04-2021 18:54, intrigeri wrote:
> Paul Gevers (2021-04-02):
>> On 02-04-2021 14:00, intrigeri wrote:
>>> I would like to see the same 1-line change in Bullseye, in the hope
>>> that it's enough to allow you folks to remove src:apparmor from
>>> the blocklist.
>>
>> Shall we test first if it helps?
> 
> Sure :)
> 
> I understand I can't do this myself.

If I counted right, I ran 23 tests with the package from experimental
(22 on arm64 and 1 on amd64). There was one tmpfail for a different
reason. So indeed, this trick seems to work.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986309: surf: Please update embedded copy of the AppArmor gstreamer abstraction

[intrigeri]

Package: surf
Severity: serious
Version: 2.0+git20201107-1

Hi Reiner!

This autopkgtest:

  Test-Command: cmp /etc/apparmor.d/abstractions/surf-gstreamer 
/etc/apparmor.d/abstractions/gstreamer

… fails since I've uploaded apparmor-profiles-extra 1.32,
which modifies /etc/apparmor.d/abstractions/gstreamer.

This blocks the migration of apparmor-profiles-extra to testing.

Could you please update your copy of that file?

(Longer term, this makes me less convinced that the strategy chosen in
#901416 and #912026 a few years back is ideal. If you'd like to
re-consider this, e.g. to replace the copied abstraction with
a dependency on apparmor-profiles-extra at some point, let me know if
there's anything you need from me.)

Cheers,
-- 
intrigeri

Bug#986310: surf: autopkgtest needs update for new version of apparmor-profiles-extra

[Paul Gevers]

Source: surf
Version: 2.0+git20201107-1
Severity: important
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:apparmor-profiles-extra

[X-Debbugs-CC: debian...@lists.debian.org,
apparmor-profiles-ex...@packages.debian.org]

Dear maintainer(s),

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

 passfail
apparmor-profiles-extra  from testing1.33
surf from testing2.0+git20201107-1
all others   from testingfrom testing

I copied some of the output at the bottom of this report. Indeed, the
/etc/apparmor.d/abstractions/gstreamer file received an updated. If you
update your apparmor template, please also make sure that the right
version to your TEST dependencies in debian/tests/control, or neither
surf nor apparmor-profiles-extra will ever migrate without intervention
from the Release Team or the maintainers of apparmor-profiles-extra.

Currently this regression is blocking the migration of
apparmor-profiles-extra to testing [1]. Of course,
apparmor-profiles-extra shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in
apparmor-profiles-extra was intended and your package needs to update to
the new situation.

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

Paul
PS: normally I file these bugs at severity serious, but as we're in the
freeze, I deemed important high enough as apparmor-profiles-extra
doesn't fix any bug at RC severity.

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
apparmor-profiles-extra/1.33. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=apparmor-profiles-extra

https://ci.debian.net/data/autopkgtest/testing/amd64/s/surf/11413642/log.gz

autopkgtest [15:10:09]: test command1: cmp
/etc/apparmor.d/abstractions/surf-gstreamer
/etc/apparmor.d/abstractions/gstreamer
autopkgtest [15:10:09]: test command1: [---
/etc/apparmor.d/abstractions/surf-gstreamer
/etc/apparmor.d/abstractions/gstreamer differ: byte 1084, line 41
autopkgtest [15:10:10]: test command1: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986291: virtualbox-guest-dkms: Installing virtualbox-guest-dkms causes kernel panic on next VM startup

[James Valleroy]

Package: virtualbox-guest-dkms
Version: 6.1.18-dfsg-3
Severity: important
X-Debbugs-Cc: jvalle...@mailbox.org

Dear Maintainer,

Installing virtualbox-guest-dkms in this VM causes it to not be able
to restart. Virtualbox window shows a kernel panic, I can get a
screenshot, but have not figured out how to get the logs out from the
VM in this state.

Steps to reproduce:

1. Host system has virtualbox 6.1.18-dfsg-3 and vagrant 2.2.14+dfsg-1.

2. Bring up vagrant box "freedombox/plinth-dev" v21.4 with virtualbox provider.
https://app.vagrantup.com/freedombox/boxes/plinth-dev/versions/21.4

A Vagrantfile is available here:
https://salsa.debian.org/freedombox-team/freedombox/-/blob/master/Vagrantfile

3. In VM, edit /etc/apt/sources.list to switch to unstable, and add contrib 
component.

4. In VM, install "linux-headers-$(uname -r)" and "virtualbox-guest-dkms".

5. Reboot the VM.


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

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

Versions of packages virtualbox-guest-dkms depends on:
pn  dkms  

virtualbox-guest-dkms recommends no packages.

virtualbox-guest-dkms suggests no packages.

Bug#986308: acpica-unix: remove alternatives

[Chris Hofstaedtler]

Source: acpica-unix
Priority: wishlist

A long time ago, acpixtract and acpidump were provided by more than
one packages. Those alternate versions have long gone away.

Please remove the alternatives setup from acpica-unix, to reduce
overall complexity.

Thanks,
Chris

Bug#986307: scrappie: flaky armhf autopkgtest: Invalid control character at: line 1 column 91 (char 90)

[Paul Gevers]

Source: scrappie
Version: 1.4.2-4
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed the it fails regularly
on armhf, while sporadically a rerun passes. I copied some of the output
at the bottom of this report. It seems there's regularly a non-printable
character at the end of the UUID of the first two tests too, including
in this case.

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

Paul

[1] https://ci.debian.net/packages/s/scrappie/testing/armhf/

https://ci.debian.net/data/autopkgtest/testing/armhf/s/scrappie/11240539/log.gz

autopkgtest [22:23:14]: test run-unit-test: [---
Test functionality
Test 1
>read_ch228_file118.fast5  { "filename" : "read_ch228_file118.fast5",
"uuid" : "e47468bf-12e3-4208-a866-babdd780e9c0", "normalised_score" :
0.479833,  "nblock" : 5778,  "sequence_length" : 2448,
"blocks_per_base" : 2.360294, "nsample" : 29150, "trim" : [ 200, 29090 ] }
PASS
Test 2
>read_ch228_file118.fast5  { "filename" : "read_ch228_file118.fast5",
"uuid" : "e47468bf-12e3-4208-a866-babdd780e9c0%", "normalised_score" :
0.459902,  "nevent" : 5787,  "sequence_length" : 1695,
"events_per_base" : 3.414159 }
PASS
Test 3
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.5zv20404/downtmp/autopkgtest_tmp/misc/json_to_tsv.py",
line 5, in 
first_entry = json.loads(stdin.readline())
  File "/usr/lib/python3.9/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python3.9/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.9/json/decoder.py", line 353, in raw_decode
obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Invalid control character at: line 1
column 91 (char 90)
autopkgtest [22:24:01]: test run-unit-test: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985524: iso2mesh-tools: broken symlink: /usr/bin/tetgen1.5 -> tetgen

[Qianqian Fang]

On 4/2/21 9:26 AM, Sébastien Villemot wrote:
>
> Thanks for looking at this issue.
>
> I don’t think that creating those symlinks in iso2mesh-tools is the
> right solution. Such symlinks should only be created by the tetgen
> package, otherwise this only creates confusion over package boundaries.
>
> I think the right solution is to drop the symlinks, and rather to
> create a Debian-specific patch that replaces “tetgen1.5” with “tetgen”
> in brain2mesh.m.


understood. I agree patching brain2mesh and other related demo scripts
is a better solution than the symbolic link, however, iso2mesh has been
used by other widely distributed tools, like brainstorm, fieldtrip etc,
and I am afraid that dropping this link can lead to broken scripts
(unless all upstream codes are patched).

can we upload this temporary fix for now, and I will add a fall-back
mechanism (in mcpath.m
) in the next
release of iso2mesh? once that is added, I will remove the symbolic link.

let me know what you think. thanks

Qianqian

Bug#985137: Segfault plotting wind data

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce the issue inside a minimal stable VM.
It crashes with following backtrace [1].

This crash does not show up with the same input in current testing.
The resulting png file shows a "mesh" on top of a map.
The method GribDecoder::visit changed a bit [2].

Kind regards,
Bernhard


[1]
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f4f07840dce in magics::GribDecoder::visit (this=0x1b1f5e0, 
transformation=...) at ./src/decoders/GribDecoder.cc:371
371transformation.setMinMaxX(matrix_->minX(), matrix_->maxX());
(gdb) bt
#0  0x7f4f07840dce in magics::GribDecoder::visit (this=0x1b1f5e0, 
transformation=...) at ./src/decoders/GribDecoder.cc:371
#1  0x7f4f0755a4f2 in magics::VisualAction::visit (this=0x1b1f440, 
transformation=...) at /usr/include/c++/8/bits/locale_facets.h:877
#2  0x7f4f07553cd4 in 
magics::BasicSceneObject::dispatch (visitor=..., 
this=0x1b1d900) at /usr/include/c++/8/bits/stl_iterator.h:783
#3  magics::BasicSceneObject::visit (transformation=..., this=0x1b1d900) at 
./src/basic/BasicSceneObject.h:135
#4  magics::ViewNode::visit (this=0x1b1d900, tree=...) at 
./src/basic/ViewNode.cc:286
#5  0x7f4f0753a92c in 
magics::BasicSceneObject::dispatch (visitor=..., 
this=0x1b1d560) at ./src/common/Layout.h:237
#6  magics::FortranSceneNode::visit (this=0x1b1d560, tree=...) at 
./src/basic/SceneNode.cc:134
#7  0x7f4f07536e6b in 
magics::BasicSceneObject::dispatch (visitor=..., 
this=0x16e3c40) at /usr/include/c++/8/bits/stl_iterator.h:783
#8  magics::RootScenePage::visualise (this=0x16e3c40) at 
./src/basic/RootSceneNode.cc:346
#9  0x7f4f0753707a in magics::RootSceneNode::visualise (this=0x1a43240) 
at ./src/basic/RootSceneNode.cc:331
#10 0x7f4f075065d5 in magics::FortranMagics::dispatch 
(this=this@entry=0x1b15740) at ./src/basic/FortranMagics.cc:509
#11 0x7f4f075098c0 in magics::FortranMagics::pclose (this=0x1b15740) at 
./src/basic/FortranMagics.cc:144
#12 0x7f4f0747a27d in pclose_ () at ./src/common/MagicsCalls.cc:1085
...
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3/dist-packages/Magics/Magics.py", line 181, in 
finalize
return dll.mag_close()
  File "/usr/lib/python3/dist-packages/Magics/Magics.py", line 149, in 
wrapped
err = fn(*args)
  File "/usr/lib/python3/dist-packages/Magics/macro.py", line 523, in _plot
Magics.finalize()
  File "wflags-segfault.py", line 29, in 
(gdb) print this->matrix_
$4 = (magics::Matrix *) 0x0


https://sources.debian.org/src/magics++/3.3.1-1/src/decoders/GribDecoder.cc/#L371

[2]

https://sources.debian.org/src/magics++/4.6.0-2/src/decoders/GribDecoder.cc/#L406

# single-use Buster/stable amd64 qemu VM 2021-03-31

apt update

apt dist-upgrade
apt install systemd-coredump lightdm xserver-xorg openbox xterm mc gdb xygrib 
magics++ python3-magics++ libeccodes-tools \
libeccodes0-dbgsym libmagplus3v5-dbgsym libffi6-dbg pyhton3-dbg
apt build-dep libeccodes0



mkdir /home/benutzer/source/eccodes/orig -p
cd/home/benutzer/source/eccodes/orig
apt source eccodes
cd




wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=985137;filename=wflags-segfault.tar.gz;msg=5;
 -O wflags-segfault.tar.gz
tar -zxf wflags-segfault.tar.gz




benutzer@debian:~$ python3 wflags-segfault.py
Magics :--
Magics :
Magics :  Magics 3.3.1 (64 bit)
Magics :
Magics : Meteorological Applications Graphics Integrated Colour System
Magics :
Magics :Developed By
Magics :
Magics :   The European Centre for Medium-Range Weather Forecasts
Magics :
Magics :
Magics :--
Speicherzugriffsfehler (Speicherabzug geschrieben)




root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2021-04-01 18:26:33 CEST  21049  1000  1000  11 present   /usr/bin/python3.7




root@debian:~# coredumpctl gdb 21049
   PID: 21049 (python3)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Thu 2021-04-01 18:26:32 CEST (39s ago)
  Command Line: python3 wflags-segfault.py
Executable: /usr/bin/python3.7
 Control Group: /user.slice/user-1000.slice/session-5.scope
  Unit: session-5.scope
 Slice: user-1000.slice
   Session: 5
 Owner UID: 1000 (benutzer)
   Boot ID: 13704ca5860b4e1ca1d50c521516559a
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.python3.1000.13704ca5860b4e1ca1d50c521516559a.21049.161729439200.lz4
   Message: Process 21049 (python3) of user 1000 dumped core.

Stack trace of thread 21049:
#0  

Bug#986306: FTBFS: certificate in testdata has expired

[Shengjing Zhu]

Source: golang-github-docker-go-connections
Version: 0.4.0-2
Severity: serious
X-Debbugs-Cc: z...@debian.org


=== RUN   TestConfigServerExclusiveRootPools
config_test.go:241: Unable to verify certificate 1: x509: certificate has 
expired or is not yet valid: current time 2021-04-02T18:04:40Z is after 
2021-03-17T16:40:46Z
--- FAIL: TestConfigServerExclusiveRootPools (0.00s)

=== RUN   TestConfigClientExclusiveRootPools
config_test.go:595: Unable to verify certificate 1: x509: certificate has 
expired or is not yet valid: current time 2021-04-02T18:04:40Z is after 
2021-03-17T16:40:46Z
--- FAIL: TestConfigClientExclusiveRootPools (0.00s)

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[Paul Gevers]

Hi,

On 02-04-2021 18:54, intrigeri wrote:
> Paul Gevers (2021-04-02):
>> On 02-04-2021 14:00, intrigeri wrote:
>>> I would like to see the same 1-line change in Bullseye, in the hope
>>> that it's enough to allow you folks to remove src:apparmor from
>>> the blocklist.
>>
>> Shall we test first if it helps?
> 
> Sure :)
> 
> I understand I can't do this myself.

I just confirmed there's a bug in our infrastructure and you can
actually do this (I already did; scheduled 10 runs after the first two
succeeded). Apparently the retry api *doesn't* check for the rejectlist.
I'll file a bug against debci shortly.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986305: FTBFS without internet access

[Shengjing Zhu]

Source: nomad
Version: 0.12.10+dfsg1-1
Severity: important
X-Debbugs-Cc: z...@debian.org


--- FAIL: TestAutopilot_RollingUpdate (7.09s)
nomad-338 2021-04-02T17:49:27.482Z [ERROR] nomad/serf.go:164: nomad: failed to 
confirm peer status: peer=nomad-340.regionFoo error="rpc error: failed to get 
conn: dial tcp 127.0.0.1:9383: connect: connection refused" retry=32s
nomad-340 2021-04-02T17:49:27.484Z [ERROR] nomad/serf.go:164: nomad: failed to 
confirm peer status: peer=nomad-339.regionFoo error="rpc error: failed to get 
conn: dial tcp 127.0.0.1:9391: connect: connection refused" retry=32s
nomad-335 2021-04-02T17:49:53.244Z [WARN]  nomad/vault.go:490: nomad.vault: 
failed to contact Vault API: retry=30s error="Get 
"https://vault.service.consul:8200/v1/sys/health?drsecondarycode=299=299=299=299=299":
 dial tcp: lookup vault.service.consul on 127.0.0.53:53: no such host"

Bug#971953: linux-image-5.8: Intel Bay Trail PMIC, laptop screen backlight cannot be adjusted

[/dev/fra]

Dear Maintainer,

This problem has been fixed in linux-image-5.10.0-4 (source-version 
5.10.19-1), see bug report #982808[1].

This bug report can be closed.

Cheers

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

Bug#986257: RFS: age/1.0.0~rc1-2 -- simple, modern and secure encryption tool

[Shengjing Zhu]

On Fri, Apr 2, 2021 at 3:33 AM Johan Fleury  wrote:
>
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "age":
>
>  * Package name: age
>Version : 1.0.0~rc1-2
>Upstream Author : Filippo Valsorda 
>  * URL : https://github.com/FiloSottile/age
>  * License : BSD-3-clause, Expat, ISC
>  * Vcs : https://salsa.debian.org/go-team/packages/age
>Section : utils
>
> It builds those binary packages:
>
>   age - simple, modern and secure encryption tool
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/age/
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/a/age/age_1.0.0~rc1-2.dsc
>
> Changes since the last upload:
>
>  age (1.0.0~rc1-2) unstable; urgency=medium
>  .
>* Set main.Version at build time to ease debuging (Closes: #986144)
>

Uploaded.

I just fixed one minor issue directly.
https://salsa.debian.org/go-team/packages/age/-/commit/af6d87964882bd8dfe6590767e2b80fdeb0e4276

-- 
Shengjing Zhu

Bug#986231: [util-linux] lsblk doesn't report FSTYPE for mirrored volumes

[Chris Hofstaedtler]

Hi Alex,

Thank you for your report.

* Alex Volkov  [210402 17:53]:
> Package: util-linux
> Version: 2.33.1-0.1
> 
> lsblk doesn't report FSTYPE for mirrored volumes.

Is this reproducible with util-linux from testing/bullseye?

If so, could you attach instructions on how to arrive at your
specific setup (starting from a plain Debian install without any
mirrored stuff)?

Chris

Bug#957397: kannel-sqlbox: ftbfs with GCC-10

[Logan Rosen]

Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/1005_gcc_10.patch: Fix FTBFS with GCC 10 by unconditionally marking
variable as extern in header files.

Thanks for considering the patch.

Logan
diff -Nru kannel-sqlbox-0.7.2/debian/patches/1005_gcc_10.patch 
kannel-sqlbox-0.7.2/debian/patches/1005_gcc_10.patch
--- kannel-sqlbox-0.7.2/debian/patches/1005_gcc_10.patch1969-12-31 
19:00:00.0 -0500
+++ kannel-sqlbox-0.7.2/debian/patches/1005_gcc_10.patch2021-04-02 
13:43:20.0 -0400
@@ -0,0 +1,72 @@
+--- a/gw/sqlbox_mssql.h
 b/gw/sqlbox_mssql.h
+@@ -47,8 +47,5 @@
+ Msg *mssql_fetch_msg();
+ void sql_shutdown();
+ struct server_type *sqlbox_init_mssql(Cfg *cfg);
+-#ifndef sqlbox_mssql_c
+-extern
+-#endif
+-Octstr *sqlbox_id;
++extern Octstr *sqlbox_id;
+ #endif
+--- a/gw/sqlbox_mysql.h
 b/gw/sqlbox_mysql.h
+@@ -49,8 +49,5 @@
+ Msg *mysql_fetch_msg();
+ void sql_shutdown();
+ struct server_type *sqlbox_init_mysql(Cfg *cfg);
+-#ifndef sqlbox_mysql_c
+-extern
+-#endif
+-Octstr *sqlbox_id;
++extern Octstr *sqlbox_id;
+ #endif
+--- a/gw/sqlbox_pgsql.h
 b/gw/sqlbox_pgsql.h
+@@ -46,8 +46,5 @@
+ void sql_shutdown();
+ struct server_type *sqlbox_init_pgsql(Cfg *cfg);
+ void sqlbox_configure_pgsql(Cfg* cfg);
+-#ifndef sqlbox_pgsql_c
+-extern
+-#endif
+-Octstr *sqlbox_id;
++extern Octstr *sqlbox_id;
+ #endif
+--- a/gw/sqlbox_sdb.h
 b/gw/sqlbox_sdb.h
+@@ -22,8 +22,5 @@
+ Msg *sdb_fetch_msg();
+ void sql_shutdown();
+ struct server_type *sqlbox_init_sdb(Cfg *cfg);
+-#ifndef sqlbox_sdb_c
+-extern
+-#endif
+-Octstr *sqlbox_id;
++extern Octstr *sqlbox_id;
+ #endif
+--- a/gw/sqlbox_sqlite.h
 b/gw/sqlbox_sqlite.h
+@@ -42,8 +42,5 @@
+ Msg *sqlite_fetch_msg();
+ void sql_shutdown();
+ struct server_type *sqlbox_init_sqlite(Cfg *cfg);
+-#ifndef sqlbox_sqlite_c
+-extern
+-#endif
+-Octstr *sqlbox_id;
++extern Octstr *sqlbox_id;
+ #endif
+--- a/gw/sqlbox_sqlite3.h
 b/gw/sqlbox_sqlite3.h
+@@ -42,8 +42,5 @@
+ Msg *sqlite3_fetch_msg();
+ void sql_shutdown();
+ struct server_type *sqlbox_init_sqlite3(Cfg *cfg);
+-#ifndef sqlbox_sqlite3_c
+-extern
+-#endif
+-Octstr *sqlbox_id;
++extern Octstr *sqlbox_id;
+ #endif
diff -Nru kannel-sqlbox-0.7.2/debian/patches/series 
kannel-sqlbox-0.7.2/debian/patches/series
--- kannel-sqlbox-0.7.2/debian/patches/series   2018-10-07 18:37:08.0 
-0400
+++ kannel-sqlbox-0.7.2/debian/patches/series   2021-04-02 13:39:55.0 
-0400
@@ -2,3 +2,4 @@
 1002_gwlib_autoonf.patch
 1003_clang_FTBFS_Wreturn-type.patch
 1004_allow_changing_db_type.patch
+1005_gcc_10.patch

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Holger Levsen]

On Fri, Apr 02, 2021 at 10:26:47AM -0700, Russ Allbery wrote:
> I'll therefore propose that we move the discussion of whether to give
> stronger advice on when to use native packages to a separate bug.  Once
> this is merged, there will be some text in Policy defining native
> packages, so it will be easier to work on that.
> 
> Sound good?

sounds good, thanks!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#875531: "editor +42 filename" -- accept or reject?

[Russ Allbery]

Adam Borowski  writes:

> Now that you folks are dealing with the "editor" virtual package, and,
> what interests me here, the alternative for /usr/bin/editor -- could you
> please process this proposal as well, and either accept or close it?

> My point is that, all but one (e3) current alternatives allow
> positioning the cursor on a given line, and various users take
> inconsistent approach as to when this feature can be used.

Thank you for doing the research to confirm this is supported by all the
editor alternatives!  That makes this fairly easy.  Attached is a proposed
diff.  This is on top of the diff for #682347; it's separable, but I'd
prefer to get that seconded and merged first.

Note that, based on your research, this will make e3 RC-buggy.  (Obviously
this wouldn't be RC for this upcoming release.)

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

diff --git a/policy/ch-customized-programs.rst b/policy/ch-customized-programs.rst
index 27abebd..d58e297 100644
--- a/policy/ch-customized-programs.rst
+++ b/policy/ch-customized-programs.rst
@@ -93,6 +93,14 @@ alternative should have a slave alternative for
 ``/usr/share/man/man1/pager.1.gz`` pointing to the corresponding manual
 page.
 
+Packages that register as an alternative for ``/usr/bin/editor`` must
+support the following features:
+
+- When invoked as ``editor ``, they open  for
+  editing.
+- When invoked as ``editor +N ``, they open  for
+  editing and position the cursor or equivalent at line ``N`` of the file.
+
 Packages that register as an alternative for ``/usr/bin/editor`` should
 also provide the virtual package ``editor`` by including it in the
 ``Provides`` control field. The package providing the current default

Bug#986301: [Pkg-zfsonlinux-devel] Bug#986301: README.Debian: zfs-initramfs is stable now

[Aron Xu]

Hi,

On Sat, Apr 3, 2021 at 1:03 AM наб  wrote:
>
> Source: zfs-linux
> Version: 2.0.3-4
> Severity: normal
>
> Dear Maintainer,
>
> d/README.Debian says this:
> -- >8 --
> 2. Use zfs-initramfs with caution.
> --
>
> Debian Installer's root installation support is being worked on,
> and zfs-initramfs is included here but still needs to be tested
> in detail. Since faulty operation on filesystem can lead to major
> loss of data, please use zfs-initramfs with caution.
>
>  -- Aron Xu   Sat, 3 Aug 2013 03:23:11 +0800
> -- >8 --
>
> d-i doesn't support root-on-ZFS installations (and I doubt it ever
> will, considering the licensing), but that's beside the point:
> zfs-initramfs is stable now (i.e. 2.0.x and forward, after I got my
> hands on it, though even in 8.4.x it wasn't /too/ bad),
> as is zfs-dracut.
>
> It's probably best to remove outdated information like this.
>

Although it's supporting many use cases very well, I still want to
keep this warning for Debian, well maybe the wording could be updated
slightly to be not so scary - when the installer cannot help users
create a proper pool and dataset layout, users who're not very
experienced with ZFS might get bitten by the set up.

Cheers,
Aron

Bug#986161: no upload is possible in droopy

[Chris Hofstaedtler]

Control: tags -1 + confirmed
Control: severity -1 + grave

Hi,

please submit bugs to the Debian BTS in English; it would help with
them getting fixed.

Anyway, I've reproduced this problem and would say it makes droopy
completely unusable in bullseye.

Log:

% mkdir foo
% droopy -m "Hi, this is Bob. You can send me a file." -d foo
 _
| \..-.-.-.--.--.
|  --  |   _|  _  |  _  |  _  |  |  |
|_/|__| |_|_|   __|___  |
|__|  |_|

No configuration file found
Files will be uploaded to /home/ch/foo

HTTP server starting... Check it out at http://localhost:8000
172.16.172.186 - - [02/Apr/2021 17:32:39] "GET / HTTP/1.1" 200 -
172.16.172.186 - - [02/Apr/2021 17:32:39] "GET /favicon.ico HTTP/1.1" 200 -
172.16.172.186 - - [02/Apr/2021 17:32:43] Started file transfer
172.16.172.186 - - [02/Apr/2021 17:32:43] TypeError('__init__() takes from 1 to 
11 positional arguments but 12 were given')
172.16.172.186 - - [02/Apr/2021 17:32:43] "POST / HTTP/1.1" 200 -


It appears the cgi.FieldStorage subclassing needs to be updated for Python 3.9.

Chris

Bug#986304: pipewire-audio-client-libraries: this package only concerns ALSA and JACK

[Patrice Duroux]

Package: pipewire-audio-client-libraries
Version: 0.3.24-3
Severity: wishlist

Dear Maintainer,

The PulseAudio replacement server is already part of the pipewire-bin packages
with the systemd example files in the pipewire one.

Maybe one of them could also provide a README.Debian file that addresses its
configuration, then cites the affiliate to ALSA and JACK using the pipewire-
audio-client-library. Because currently a README.Debian file is provided by
pipewire-audio-client-libraries with a symlink as examples/README.audio.

In addition the last paragraph of its package description is:

 This package contains client libraries allowing programs designed for
 the ALSA, JACK and PulseAudio APIs to use a PipeWire server for audio
 playback and recording. They are not used by default, and are currently
 considered to be experimental.

I suggest to change it to:

 This package contains client libraries allowing programs designed for
 the ALSA and JACK APIs to use a PipeWire server for audio playback and
 recording. They are not used by default, and are currently considered
 to be experimental.

Thanks,
Patrice

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

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

Versions of packages pipewire-audio-client-libraries depends on:
ii  libasound2 1.2.4-1.1
ii  libc6  2.31-11
ii  libpipewire-0.3-0  0.3.24-3
ii  pipewire   0.3.24-3

pipewire-audio-client-libraries recommends no packages.

pipewire-audio-client-libraries suggests no packages.

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Holger Levsen  writes:

> I'm not sure if in this regard I would have liked the previous version
> better, as the paragraph about native packages is the only one which I
> would like to see extended to explain that it has been observed that
> packages we thought were native to Debian were not really native to
> Debian at all and require modifications in Debian downstream
> distributions, which are harder to do when the packages are native (eg
> modified orig.tar's despite no upstream changes).

This is generally my opinion as well, but I know there are other folks who
disagree, and I'm therefore not sure whether this has consensus.  (Native
packages are a lot simpler.)  I decided to take the easy way out and note
that this bug was originally about documenting NMU and stable upload
version conventions, so setting policy for when people should use native
packages is a bit out of scope.

I'll therefore propose that we move the discussion of whether to give
stronger advice on when to use native packages to a separate bug.  Once
this is merged, there will be some text in Policy defining native
packages, so it will be easier to work on that.

Sound good?

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

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Russ Allbery]

Simon McVittie  writes:

> The other way is to repackage the new upstream release from first
> principles, either because it's a new release from an upstream branch
> that's older than the one in testing/unstable (like src:flatpak in
> Debian 10), or because testing/unstable already has packaging changes
> that aren't suitable for stable (like src:dbus in Debian 10). In this
> case it would be misleading to use a version number like
> flatpak_1.2.5-1~deb10u1 (because 1.2.5-1 never existed) or
> dbus_1.12.20-1~deb10u1 (because 1.12.20-1 did exist, but the version of
> dbus in stable was not based on it, and does not have the downstream
> changes from that version). Instead, the convention that has emerged is
> to use 0+deb10u1, by analogy with the convention that an NMU introducing
> a new upstream release has revision number 0.1.

Ah, thanks for this.  I wasn't aware this convention existed.

Here's a new draft, which is unfortunately quite a bit longer because it's
hard to make this clear.  I also added the +really convention explicitly,
since it's mentioned immediately above, and noted that the stable update
and backport conventions can, in rare circumstances, stack.

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

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index a21a510..2fd6868 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -582,20 +582,17 @@ The three components here are:
 alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
 tilde) and is compared in the same way as the ``upstream_version`` is.
 
-It is optional; if it isn't present then the ``upstream_version``
-may not contain a hyphen. This format represents the case where a
-piece of software was written specifically to be a Debian package,
-where the Debian package source must always be identical to the
-pristine source and therefore no revision indication is required.
+It is conventional to restart the ``debian_revision`` at ``1`` each
+time the ``upstream_version`` is increased.
 
-It is conventional to restart the ``debian_revision`` at ``1``
-each time the ``upstream_version`` is increased.
+The package management system will break the version number apart at
+the last hyphen in the string (if there is one) to determine the
+``upstream_version`` and ``debian_revision``. The absence of a
+``debian_revision`` is equivalent to a ``debian_revision`` of ``0``.
 
-The package management system will break the version number apart
-at the last hyphen in the string (if there is one) to determine
-the ``upstream_version`` and ``debian_revision``. The absence of a
-``debian_revision`` is equivalent to a ``debian_revision`` of
-``0``.
+Presence of the ``debian_revision`` part indicates this package is a
+non-native package (see :ref:`s-source-packages`).  Absence indicates
+the package is a native package.
 
 When comparing two version numbers, first the epoch of each are
 compared, then the ``upstream_version`` if epoch is equal, and then
@@ -625,6 +622,8 @@ These two steps (comparing and removing initial non-digit strings and
 initial digit strings) are repeated until a difference is found or both
 strings are exhausted.
 
+.. _s-avoid-epochs:
+
 Epochs should be used sparingly
 ^^^
 
@@ -639,13 +638,132 @@ Epochs should not be used when a package needs to be rolled back.
 In that case, use the ``+really`` convention: for example, if you
 uploaded ``2.3-3`` and now you need to go backwards to upstream 2.2,
 call your reverting upload something like ``2.3+really2.2-1``.
-Eventually, when we upload upstream 2.4, the +really part can go away.
+Eventually, when we upload upstream 2.4, the ``+really`` part can go away.
 
 Epochs are also not intended to cope with version
 numbers containing strings of letters which the package management
 system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
 orderings.  [#]_
 
+Special version conventions
+^^^
+
+The following special version numbering conventions are used in the Debian
+archive:
+
+- The absence of ``debian_revision``, and therefore of a hyphen in the
+  version number, indicates that the package is native.
+
+- The presence of ``+really`` in the ``upstream_version`` component
+  indicates that a newer upstream version has been rolled back to an older
+  upstream version.  The part of the ``upstream_version`` component
+  following ``+really`` is the true upstream version.  See
+  :ref:`s-avoid-epochs` for an example of when this is used.
+
+Non-maintainer uploads:
+
+- ``debian_revision`` components ending in ``.`` (period) followed by a
+  number indicate this version of the non-native package was uploaded by
+  someone other than the maintainer (an NMU or non-maintainer upload).
+  This is used for a source package upload; for uploads 

Bug#986303: openssh-client: tries to place known_hosts in parent directory when .ssh is a symlink

[Calum McConnell]

Package: openssh-client
Version: 1:8.4p1-5
Severity: minor
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I try to track all configuration seperately, which means
symlinking dotfiles in $HOME to a seperate folder, that is
a git repositiory.  SSH doesnt yet support the XDG spec for
home folders (AFAIK), which is fine, but it stubbornly
refuses to use the correct known_hosts file.

SSH will instead ignore the $HOME/.ssh/known-hosts file, which
is actually stored at $GIT-REPO-OF-DOTFILES/.ssh/known-hosts.
It tries to use $GIT-REPO/known-hosts instead, creating the file
as needed, and prompting that previously-connected hosts are
unknown.

I solved this issue simply by hard linking the proper file
and the one SSH thinks it needs.  I'd appreciate it if this
could be fixed longer-term, however.


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

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.20.7.1
ii  libc6 2.31-10
ii  libedit2  3.1-20191231-2+b1
ii  libfido2-11.6.0-2
ii  libgssapi-krb5-2  1.18.3-4
ii  libselinux1   3.1-3
ii  libssl1.1 1.1.1k-1
ii  passwd1:4.8.1-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages openssh-client recommends:
ii  xauth  1:1.1-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
ii  monkeysphere  0.43-3.1
ii  ssh-askpass   1:1.2.4.1-10+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAmBnUz4dHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzKYyxAA2d+4xly0rt2Ixl/Y
A77cScYWoI2wo8I+XimZb6rm4HaHNGhDL19wNBZCYf8R+F2cZSRQKsPHXhBimiYE
ysTxqrwnPyk6c2USvA8sWJiOqM8Pb74+1WDEfo2WjVbk95xxEAacYk5zIfuAN4q1
7Qf9qIwJKbBNxU5ZKCBVWTlSHQMT3554wjXLixPVFF0WgmNWTGdVOSO1ADmjaXNO
I/vPmPvEkxFpxELIPEgJOc3lXGD4fRrGz+xRMGbWI9zC+fzDMEAZPZ705bwWzPSL
Mx4V/PkZOh4oXm2YuhFU45IAUcumCfOoKXZHdNwApEpyOvGaGjYaQ9cQFTYVPOCW
/mmHf6jPc+sO+2gYAS2IqP1OTzUIZwX7YwNMvJmke95MdDzAYhA/kcx6peJao6vJ
Ya+N6jwSG5kHQu38BhEdynfHq639soFW3v0ZA1xrNdCyObsUIOCIU/Uyj6CEaomI
eYy8MayZO5jEghxsnTXNbFgOZxj09hZ4UJwqzmIosd8ZuPF0mvC53jL56HkJH3Jj
oZ7RKPwYDFUfwEvZ4hdN6KmCbwXSLniR+tEgUmahymMk3oNWC/AsEKJTBRtXdtYN
hKuaPDevqMQK5s20VxzAypRV4t24FDtrxmN6pNBd18anTpXuLoV0JOIViXb9umeC
P1DBfJ9hPmAF2NsI0AJmp8vL1a8=
=z2Ei
-END PGP SIGNATURE-

Bug#986302: systemd: malformed LoadCredential= in a unit triggers a crash

[Luca Boccassi]

Package: systemd
Version: 247.3-3
Severity: important
Tags: patch upstream

Dear Maintainer(s),

A malformed LoadCredential setting such as:

LoadCredential=foobar

will cause systemd v247/v248 to crash when parsing the unit.

Upstream issue: https://github.com/systemd/systemd/issues/19178

MR on Salsa to fix the issue:

https://salsa.debian.org/systemd-team/systemd/-/merge_requests/126

Kind regards,
Luca Boccassi

Bug#986300: RM: librpcsecgss -- RoQA; orphaned leaf library, upstream dead

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

librpcsecgss was a library written by the NFS4 on Linux project. It is
however, now unused in Debian, and the current upstream NFS4 (userland)
implementation also does not need/ship it anymore. Therefore it will
also not be reintroduced when updating Debians NFS code.

The library is currently orphaned, has no r-deps, and has not seen an
upload since 2012.

Please remove it.

Chris

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[intrigeri]

Paul Gevers (2021-04-02):
> On 02-04-2021 14:00, intrigeri wrote:
>> I would like to see the same 1-line change in Bullseye, in the hope
>> that it's enough to allow you folks to remove src:apparmor from
>> the blocklist.
>
> Shall we test first if it helps?

Sure :)

I understand I can't do this myself.

Bug#984760: grub-pc: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Stefan Nitz]

Package: grub-pc
Followup-For: Bug #984760

Dear Maintainer,


* Install / update to grub-common grub-pc grub-pc-bin grub2 grub2-common - 
version: 2.02+dfsg1-20+deb10u4
* Install 2.02+dfsg1-20+deb10u3 - system works again
* can not boot: ... grub_register_command_lockdown not found ...
* boot system




-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sdb2 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sdb1 /boot ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/_dev_dm_1 /home/nitz ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-SAMSUNG_HN-M101MBB_S2R8J1MBA04065
(hd1)   /dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_172843424862
#(hd2)  /dev/disk/by-id/lvm-pv-uuid-Vty9C5-u24G-nx3B-Appj-UhSr-wQZj-LtfXc7
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="Debian GNU/Linux, mit Xen-Hypervisor"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd1,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos2 
--hint-efi=hd1,msdos2 --hint-baremetal=ahci1,msdos2  
31010fdb-7e31-49df-bbce-b9fc3d11930d
else
  search --no-floppy --fs-uuid --set=root 31010fdb-7e31-49df-bbce-b9fc3d11930d
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=C
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd1,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos2 
--hint-efi=hd1,msdos2 --hint-baremetal=ahci1,msdos2  
31010fdb-7e31-49df-bbce-b9fc3d11930d
else
  search --no-floppy --fs-uuid --set=root 31010fdb-7e31-49df-bbce-b9fc3d11930d
fi
insmod png
if background_image 
/usr/share/desktop-base/futureprototype-theme/grub/grub-4x3.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-31010fdb-7e31-49df-bbce-b9fc3d11930d' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  
21ec0055-1c79-4010-a7b8-421818b40973
else
  search --no-floppy --fs-uuid --set=root 
21ec0055-1c79-4010-a7b8-421818b40973
fi
echo'Linux 4.19.0-16-amd64 wird geladen …'
linux   /vmlinuz-4.19.0-16-amd64 
root=UUID=31010fdb-7e31-49df-bbce-b9fc3d11930d ro  quiet
echo'Initiale Ramdisk wird geladen …'
initrd  /initrd.img-4.19.0-16-amd64
}
submenu 'Erweiterte Optionen für Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-31010fdb-7e31-49df-bbce-b9fc3d11930d' {
menuentry 'Debian GNU/Linux, mit Linux 4.19.0-16-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 

Bug#985509: openrc: diff for NMU version 0.42-2.1

[Mark Hindley]

Control: tags 985509 + patch
Control: tags 985509 + pending

Dear openrc maintainers,

I've prepared an NMU for openrc (versioned as 0.42-2.1) to address #985509 and
uploaded it to DELAYED/2. Please feel free to tell me if I should delay it
longer.

Regards.

Mark

diff -Nru openrc-0.42/debian/changelog openrc-0.42/debian/changelog
--- openrc-0.42/debian/changelog2020-11-27 08:48:35.0 +
+++ openrc-0.42/debian/changelog2021-04-02 11:16:00.0 +0100
@@ -1,3 +1,11 @@
+openrc (0.42-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make -dev package symlinks in /usr/lib target shared libraries in
+/lib.  (Closes: #985509).
+
+ -- Mark Hindley   Fri, 02 Apr 2021 11:16:00 +0100
+
 openrc (0.42-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru openrc-0.42/debian/libeinfo-dev.links.in 
openrc-0.42/debian/libeinfo-dev.links.in
--- openrc-0.42/debian/libeinfo-dev.links.in1970-01-01 01:00:00.0 
+0100
+++ openrc-0.42/debian/libeinfo-dev.links.in2021-04-02 11:16:00.0 
+0100
@@ -0,0 +1 @@
+@SHLIBDIR@/libeinfo.so.1 @LIBDIR@/libeinfo.so
diff -Nru openrc-0.42/debian/librc-dev.install.in 
openrc-0.42/debian/librc-dev.install.in
--- openrc-0.42/debian/librc-dev.install.in 2020-11-27 08:48:35.0 
+
+++ openrc-0.42/debian/librc-dev.install.in 2021-04-02 11:16:00.0 
+0100
@@ -1,4 +1,3 @@
-debian/tmp@SHLIBDIR@/librc.so   /usr@SHLIBDIR@
 debian/tmp/usr/include/rc.h /usr/include
 debian/tmp@LIBDIR@/pkgconfig/openrc.pc  @LIBDIR@/pkgconfig
 debian/tmp/usr/share/man/man3/r*/usr/share/man/man3
diff -Nru openrc-0.42/debian/librc-dev.links.in 
openrc-0.42/debian/librc-dev.links.in
--- openrc-0.42/debian/librc-dev.links.in   1970-01-01 01:00:00.0 
+0100
+++ openrc-0.42/debian/librc-dev.links.in   2021-04-02 11:16:00.0 
+0100
@@ -0,0 +1 @@
+@SHLIBDIR@/librc.so.1 @LIBDIR@/librc.so
diff -Nru openrc-0.42/debian/rules openrc-0.42/debian/rules
--- openrc-0.42/debian/rules2020-11-27 08:48:35.0 +
+++ openrc-0.42/debian/rules2021-04-02 11:16:00.0 +0100
@@ -15,7 +15,7 @@
 DEB_HOST_ARCH_OS   ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
-DH_INSTALL_FILES = $(basename $(wildcard debian/*.install.in))
+DH_INSTALL_FILES = $(basename $(wildcard debian/*.install.in) $(wildcard 
debian/*.links.in))
 
 export LIBDIR = /usr/lib/$(DEB_HOST_MULTIARCH)
 export SHLIBDIR = /lib/$(DEB_HOST_MULTIARCH)
@@ -35,6 +35,9 @@
 %.install: %.install.in
sed -e 's;@SHLIBDIR@;$(SHLIBDIR);g' -e 's;@LIBDIR@;$(LIBDIR);g' <$< >$@
 
+%.links: %.links.in
+   sed -e 's;@SHLIBDIR@;$(SHLIBDIR);g' -e 's;@LIBDIR@;$(LIBDIR);g' <$< >$@
+
 override_dh_auto_clean:
dh_auto_clean
rm -f $(DH_INSTALL_FILES)

Bug#986298: 2.02+dfsg1-20+deb10u4: kernel boot fail.

[Stefan Nitz]

Package: 2.02+dfsg1-20+deb10u4
Version: 2.02+dfsg1-20+deb10u4
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), 
(102, 'experimental'), (50, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

* Install / update to grub-common grub-pc grub-pc-bin grub2 grub2-common - 
version: 2.02+dfsg1-20+deb10u4
* Install 2.02+dfsg1-20+deb10u3 - system works again
* can not boot: ... grub_register_command_lockdown not found ...
* boot system

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[Paul Gevers]

Hi intrigeri,

On 02-04-2021 14:00, intrigeri wrote:
> I would like to see the same 1-line change in Bullseye, in the hope
> that it's enough to allow you folks to remove src:apparmor from
> the blocklist.

Shall we test first if it helps?

> Would you like to pre-approve this here, or do you prefer that
> I request pre-approval via the regular release team process?

If it works, and if all you do is change that one line and a changelog
entry, then I'll unblock it, yes. But first, let's see if it does what
you hope, no?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985766: closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#985766: fixed in plocate 1.1.6-1)

[Calum McConnell]

Thank you!


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

Bug#986296: i7z generates two kernel messages per second while running

[Andreas Beckmann]

On 02/04/2021 17.53, Dennis Boone wrote:

While i7z is running, the syslog receives 60 messages every 30 seconds:

Apr  2 11:47:58 ozymandias kernel: [319599.175688] msr: Write to unrecognized 
MSR 0x38f by i7z (pid: 180370). Please report to x...@kernel.org.



i9-10900K processor, W430 chipset, Supermicro X12SCA-F motherboard.


I don't think that i7z properly supports anything newer than haswell. 
Some bits may work on newer generations, but some obviously don't.


Upstream seems to be dead ...

Andreas

Bug#986297: ITP: gsocket -- Allows two users behind NAT/Firewall to establish a TCP connection with each other. Securely.

[Daniel Echeverri]

Package: wnpp
Owner: Daniel Echeverri 
Severity: wishlist

* Package name: gsocket
* Version : 1.4.28
* Upstream Author : skyper
* URL or Web page : https://github.com/hackerschoice/gsocket
* License : BSD-2-Clause
* Description : Allows two users behind NAT/Firewall to establish a TCP
connection with each other. Securely.

Abandon the thought of IP Addresses and Port Numbers. Instead start
thinking that two programs should be able to communicate with each other as
long as they know the same secret (rather than each other's IP Address and
Port Number). The Global Socket library facilitates this: It locally
derives temporary session keys and IDs and connects two programs through
the Global Socket Relay Network (GSRN) regardless and independent of the
local IP Address or geographical location. Once connected the library then
negotiates a secure TLS connection(End-2-End). The secret never leaves your
workstation. The GSRN sees only the encrypted traffic.

The GSRN is a free cloud service and is free to use by anyone.

The Global Socket Toolkit comes with a set of tools:

gsocket - Makes an existing program (behind firewall or NAT) accessible
from anywhere in the world. It does so by analyzing the program and
replacing the IP-Layer with its own Gsocket-Layer. A client connection to a
hostname ending in '*.gsocket' then gets automatically redirected (via the
GSRN) to this program.
gs-netcat - Netcat on steroids. Turn gs-netcat into an AES-256 encrypted
reverse backdoor via TOR (optional) with a true PTY/interactive command
shell (gs-netcat -s MySecret -i), integrated file-transfer, spawn a
Socks4/4a/5 proxy or forward TCP connections or give somebody temporary
shell access.
gs-sftp - sftp server & client between two firewalled workstations (gs-sftp
-s MySecret)
gs-mount - Access and mount a remote file system (gs-mount -s MySecret
~/mnt/warez)
blitz - Copy data from workstation to workstation (blitz -s MySecret
/usr/share/*)
...many more examples and tools.

Regards!

-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#986296: i7z generates two kernel messages per second while running

[Dennis Boone]

Package: i7z
Version: 0.27.2+git2013.10.12-g5023138-7
Severity: important

While i7z is running, the syslog receives 60 messages every 30 seconds:

Apr  2 11:47:58 ozymandias kernel: [319599.175688] msr: Write to unrecognized 
MSR 0x38f by i7z (pid: 180370). Please report to x...@kernel.org.
Apr  2 11:48:32 ozymandias kernel: [319633.641731] filter_write: 59 callbacks 
suppressed
Apr  2 11:48:32 ozymandias kernel: [319633.641732] msr: Write to unrecognized 
MSR 0x38f by i7z (pid: 180370). Please report to x...@kernel.org.
Apr  2 11:49:07 ozymandias kernel: [319668.104971] filter_write: 59 callbacks 
suppressed

Obviously the log traffic alone is undesirable.

i9-10900K processor, W430 chipset, Supermicro X12SCA-F motherboard.


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

Kernel: Linux 5.10.0-5-amd64 (SMP w/20 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages i7z depends on:
ii  libc6 2.31-10
ii  libncurses6   6.2+20201114-2
ii  libtinfo6 6.2+20201114-2
ii  msr-tools 1.3-3+b1
ii  ruby  1:2.7+2
ii  ruby1.8 [ruby-interpreter]1.8.7.358-7.1
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.194-8.2

i7z recommends no packages.

i7z suggests no packages.

-- no debconf information

Bug#986288: poke in Debian

[Hilko Bengen]

* Sudip Mukherjee:

> poke has already been packaged. Is it something different?
> https://tracker.debian.org/pkg/poke

Oh, I hadn't noticed because it was only uploaded to experimental. Will
contact the packager.

Cheers,
-Hilko

Bug#986295: ITP: r-bioc-ballgown -- Flexible, isoform-level differential expression analysis

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-de...@lists.debian.org, nil...@debian.org

* Package name: r-bioc-ballgown
  Version : 2.22.0+dfsg
  Upstream Author : Jack Fu 
* URL : https://bioconductor.org/packages/ballgown
* License : Artistic-2.0
  Programming Lang: R
  Description : Flexible, isoform-level differential expression analysis
  Tools for statistical analysis of assembled transcriptomes,
  including flexible differential expression analysis, visualization of
  transcript structures, and matching of assembled transcripts to annotation.
  
  I shall maintain this package

Bug#986256: simka: flaky amd64 autopkgtest: regularly times out after 2:47 h

[Paul Gevers]

Hi Nilesh,

On 02-04-2021 13:40, Nilesh Patra wrote:
> Hi,
> 
> On Thu, 1 Apr 2021 20:53:00 +0200 Paul Gevers  wrote:
>  
>> Your package has an autopkgtest, great. However, I looked into
>> the history of your autopkgtest [1] and I noticed version 1.5.3-2 fails
>> regularly on amd64, while sporadically a rerun passes. I copied some of
>> the output at the bottom of this report. It hits the autopkgtest time
>> out after 2hours and 47 minutes. Successful runs pass in less than a minute.
>>
>> Because the unstable-to-testing migration software now blocks on
>> regressions in testing, flaky tests, i.e. tests that flip between
>> passing and failing without changes to the list of installed packages,
>> are causing people unrelated to your package to spend time on these
>> tests.
> 
> That makes sense  - do you think marking this test as flaky can be
> solution?

No, because when a test times out, that restriction doesn't work. You'll
need to keep the test below 2:47, and as it normally takes less than a
minute, it may point at something seriously hanging.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986294: New upstream 0.45 available

[Yuri D'Elia]

Package: rlwrap
Version: 0.43-1+b2
Severity: wishlist

Dear maintainer, upstream has released 0.45. It would be nice to update
due to several bug fixes affecting the current package.

Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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)

Versions of packages rlwrap depends on:
ii  libc6 2.31-11
ii  libreadline8  8.1-1
ii  libtinfo6 6.2+20201114-2
ii  perl  5.32.1-3
ii  python3   3.9.2-2

rlwrap recommends no packages.

rlwrap suggests no packages.

Bug#951988: libplacebo: FTBFS: (.text+0x8ee): undefined reference to `spvContextCreate'

[Chris Hofstaedtler]

Hello Timo,

* Paul Gevers :
> On Thu, 18 Feb 2021 10:26:44 + Simon McVittie  wrote:
> > On Mon, 18 Jan 2021 at 11:27:35 +, Simon McVittie wrote:
> > https://salsa.debian.org/xorg-team/vulkan/glslang/-/merge_requests/4
> > 
> > (Updated patches attached, if you prefer the BTS.)
> 
> Can we move this issue forward somehow? What are the risks of the
> proposed patch? Without having knowledge of how pkg-config works, the
> patch looks rather harmless to me if it fixes the issue at stake.

You have merged the mentioned MR on salsa. Do you plan on uploading
a package with this change (soon)?

Chris

Bug#986293: libvirtuoso5.5-cil: fails to upgrade from 'buster': The type initializer for 'Sys' threw an exception.

[Andreas Beckmann]

Package: libvirtuoso5.5-cil
Version: 7.2.5.1+dfsg-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails.

This may be related to a similar error in libglib3.0-cil (#986275).

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

  Preparing to unpack .../54-libvirtuoso5.5-cil_7.2.5.1+dfsg-3_amd64.deb ...
  Removing libvirtuoso5.5-cil from Mono
  
  Unhandled Exception:
  System.TypeInitializationException: The type initializer for 'Sys' threw an 
exception. ---> System.DllNotFoundException: 
/usr/lib/../lib/libmono-system-native.so assembly: 
type: member:(null)
at (wrapper managed-to-native) Interop+Sys.LChflagsCanSetHiddenFlag()
at Interop+Sys..cctor () [0x0] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 
 --- End of inner exception stack trace ---
at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath, 
System.Int32 fileType, Interop+ErrorInfo& errorInfo) [0xf] in 
<12b418a7818c4ca0893feeaaf67f1e7f>:0 
at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath) 
[0x6] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 
at System.IO.File.Exists (System.String path) [0x00058] in 
<12b418a7818c4ca0893feeaaf67f1e7f>:0 
at Mono.Tools.Driver.LoadConfig (System.Boolean quiet) [0x00031] in 
<3a4d36ecef0a47439a72108fe400486f>:0 
at Mono.Tools.Driver.Main (System.String[] args) [0x00347] in 
<3a4d36ecef0a47439a72108fe400486f>:0 
  [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The 
type initializer for 'Sys' threw an exception. ---> 
System.DllNotFoundException: /usr/lib/../lib/libmono-system-native.so 
assembly: type: member:(null)
at (wrapper managed-to-native) Interop+Sys.LChflagsCanSetHiddenFlag()
at Interop+Sys..cctor () [0x0] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 
 --- End of inner exception stack trace ---
at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath, 
System.Int32 fileType, Interop+ErrorInfo& errorInfo) [0xf] in 
<12b418a7818c4ca0893feeaaf67f1e7f>:0 
at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath) 
[0x6] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 
at System.IO.File.Exists (System.String path) [0x00058] in 
<12b418a7818c4ca0893feeaaf67f1e7f>:0 
at Mono.Tools.Driver.LoadConfig (System.Boolean quiet) [0x00031] in 
<3a4d36ecef0a47439a72108fe400486f>:0 
at Mono.Tools.Driver.Main (System.String[] args) [0x00347] in 
<3a4d36ecef0a47439a72108fe400486f>:0 
  W: removing assembly: OpenLink.Data.Virtuoso, Version=6.2.3128.1, 
Culture=neutral, PublicKeyToken=6654f6917d07cb95 failed!
  Unpacking libvirtuoso5.5-cil (7.2.5.1+dfsg-3) over (6.1.6+dfsg2-4+b2) ...
  Setting up libexpat1:amd64 (2.2.10-2) ...
  Setting up libpixman-1-0:amd64 (0.40.0-1) ...
  Setting up libxau6:amd64 (1:1.0.9-1) ...
  Setting up libxcb1:amd64 (1.14-3) ...
  Setting up libxcb-render0:amd64 (1.14-3) ...
  Setting up libglib2.0-0:amd64 (2.66.8-1) ...
  No schema files found: doing nothing.
  Setting up libvirtuoso5.5-cil (7.2.5.1+dfsg-3) ...
  * Installing 1 assembly from libvirtuoso5.5-cil into Mono
  
  Unhandled Exception:
  System.TypeInitializationException: The type initializer for 'Sys' threw an 
exception. ---> System.DllNotFoundException: 
/usr/lib/../lib/libmono-system-native.so assembly: 
type: member:(null)
at (wrapper managed-to-native) Interop+Sys.LChflagsCanSetHiddenFlag()
at Interop+Sys..cctor () [0x0] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 
 --- End of inner exception stack trace ---
at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath, 
System.Int32 fileType, Interop+ErrorInfo& errorInfo) [0xf] in 
<12b418a7818c4ca0893feeaaf67f1e7f>:0 
at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath) 
[0x6] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 
at System.IO.File.Exists (System.String path) [0x00058] in 
<12b418a7818c4ca0893feeaaf67f1e7f>:0 
at Mono.Tools.Driver.LoadConfig (System.Boolean quiet) [0x00031] in 
<3a4d36ecef0a47439a72108fe400486f>:0 
at Mono.Tools.Driver.Main (System.String[] args) [0x00347] in 
<3a4d36ecef0a47439a72108fe400486f>:0 
  [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The 
type initializer for 'Sys' threw an exception. ---> 
System.DllNotFoundException: /usr/lib/../lib/libmono-system-native.so 
assembly: type: member:(null)
at (wrapper managed-to-native) Interop+Sys.LChflagsCanSetHiddenFlag()
at Interop+Sys..cctor () [0x0] in <12b418a7818c4ca0893feeaaf67f1e7f>:0 
 --- End of inner exception stack trace ---
at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath, 
System.Int32 fileType, Interop+ErrorInfo& errorInfo) [0xf] in 
<12b418a7818c4ca0893feeaaf67f1e7f>:0 
at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath) 

Bug#986292: general: sqlite3 problem when a command is not available

[m]

Package: general
Severity: normal
X-Debbugs-Cc: noadr...@hotmail.com

Everytime a command is not available, this comes up.


command-not-found version: 0.3
Python version: 3.9.1 final 0
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2021.1
Codename:   kali-rolling
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir)
  File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
79, in __init__
self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
__init__
self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file

Bug#984630: python3-waitress: leaves alternatives after upgrade: /etc/alternatives/waitress-serve -> /usr/bin/waitress-serve-python3

[Andreas Beckmann]

Followup-For: Bug #984630
Control: tag -1 patch
diff -Nru waitress-1.4.4/debian/changelog waitress-1.4.4/debian/changelog
--- waitress-1.4.4/debian/changelog 2021-01-09 10:16:20.0 +0100
+++ waitress-1.4.4/debian/changelog 2021-04-02 15:03:03.0 +0200
@@ -1,3 +1,9 @@
+waitress (1.4.4-2) UNRELEASED; urgency=medium
+
+  * Fix cleanup of the waitress-serve alternative.  (Closes: #984630)
+
+ -- Andreas Beckmann   Fri, 02 Apr 2021 15:03:03 +0200
+
 waitress (1.4.4-1) unstable; urgency=medium
 
   [ Andrej Shadura ]
diff -Nru waitress-1.4.4/debian/python3-waitress.preinst 
waitress-1.4.4/debian/python3-waitress.preinst
--- waitress-1.4.4/debian/python3-waitress.preinst  2021-01-09 
10:16:20.0 +0100
+++ waitress-1.4.4/debian/python3-waitress.preinst  2021-04-02 
15:03:03.0 +0200
@@ -2,7 +2,7 @@
 
 set -e
 
-if [ "$1" = "configure" ]
+if [ "$1" = "upgrade" ]
 then
 if update-alternatives --list waitress-serve >/dev/null 2>&1
 then

Bug#986290: libags-audio3: wrong ref-count in ags_fx_factory.c

[Joël Krähemann]

Package: libags-audio3
Version: 3.7.44-3
Severity: normal
Tags: patch

Dear Maintainer,

Upstream discovered wrong ref-count in ags/audio/ags_fx_factory.c affecting
libags_audio.so and the gsequencer binary.

Without patching memory corruptions could occur. As AgsChannel implementation
might be finalize while in use.

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/24 CPU threads)
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

Versions of packages libags-audio3 depends on:
ii  gstreamer1.0-plugins-bad  1.18.2-1+b1
ii  gstreamer1.0-plugins-base 1.18.3-1
ii  gstreamer1.0-plugins-good 1.18.3-1
pn  libags3   
ii  libasound21.2.4-1.1
ii  libc6 2.31-10
ii  libfftw3-double3  3.3.8-2
ii  libglib2.0-0  2.66.8-1
ii  libgstreamer-plugins-base1.0-01.18.3-1
ii  libgstreamer1.0-0 1.18.3-1
ii  libinstpatch-1.0-21.1.6-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libpulse0 14.2-2
ii  libsamplerate00.2.1+ds0-1
ii  libsndfile1   1.0.31-1
ii  libsoup2.4-1  2.72.0-2
ii  libxml2   2.9.10+dfsg-6.3+b1

libags-audio3 recommends no packages.

libags-audio3 suggests no packages.
diff --git a/ags/audio/ags_fx_factory.c b/ags/audio/ags_fx_factory.c
index 2f904c133..dd2e78fb0 100644
--- a/ags/audio/ags_fx_factory.c
+++ b/ags/audio/ags_fx_factory.c
@@ -788,10 +788,6 @@ ags_fx_factory_create_playback(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -1236,10 +1232,6 @@ ags_fx_factory_create_buffer(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -1657,6 +1649,10 @@ ags_fx_factory_create_volume(AgsAudio *audio,
 }
   }  
 
+  if(channel != NULL){
+g_object_unref(channel);
+  }
+
   if((AGS_FX_FACTORY_REMAP & (create_flags)) != 0){
 if(fx_volume_audio != NULL){
   g_object_unref(fx_volume_audio);
@@ -1683,10 +1679,6 @@ ags_fx_factory_create_volume(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -2131,10 +2123,6 @@ ags_fx_factory_create_peak(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -2589,10 +2577,6 @@ ags_fx_factory_create_eq10(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -3047,10 +3031,6 @@ ags_fx_factory_create_analyse(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -3505,10 +3485,6 @@ ags_fx_factory_create_envelope(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -3934,10 +3910,6 @@ ags_fx_factory_create_pattern(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -4381,10 +4353,6 @@ ags_fx_factory_create_notation(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -4892,10 +4860,6 @@ ags_fx_factory_create_ladspa(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -5407,10 +5371,6 @@ ags_fx_factory_create_dssi(AgsAudio *audio,
 g_object_unref(input);
   }
 
-  if(channel != NULL){
-g_object_unref(channel);
-  }
-
   return(start_recall);
 }
 
@@ -6025,10 +5985,6 @@ ags_fx_factory_create_lv2(AgsAudio *audio,
   if(input != NULL){
 g_object_unref(input);
   }
-
-  if(channel != NULL){
-g_object_unref(channel);
-  }
   
   return(start_recall);
 }

Bug#986281: bmake: please ship bsd.*.mk symlinks for bmake mk files

[Lauri Tirkkonen]

Package: bmake
Version: 20200710-11
Severity: normal

Dear Maintainer,

in the current default configuration of the Debian package, upstream
bmake files are used, but unlike installation of bmake from source,
symlinks from bsd.*.mk to *.mk are not present in the default mk-files
directory.

My use case is simple programs using bsd.prog.mk, which are meant to
succeed building with the same Makefile on different BSDs as well as
non-BSD systems with bmake, and those programs don't care much about
which brand of mk-files are used as long as the simple use case is
supported. Since the symlinks are not present, .include 
with 'bmake' fails.

Please ship the bsd.*.mk symlinks in /usr/share/bmake/mk-bmake.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/32 CPU threads)
Locale: LANG=C, 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 bmake depends on:
ii  libc6  2.31-11

bmake recommends no packages.

bmake suggests no packages.

-- no debconf information

-- 
Lauri Tirkkonen | lotheac @ IRCnet

Bug#984931: marking as a bug in git-el

[David Bremner]

Control: reassign -1 git-el

I'm reassigning this bug to (only) git-el since it hasn't been confirmed
that there is actually a problem with elpa-magit. IMHO it doesn't
benefit anyone to drop elpa-magit (and it's rdeps) from bullseye because
of a problem with a transitional package.


signature.asc
Description: PGP signature

Bug#986288: poke in Debian

[Sudip Mukherjee]

Hi Hilko,

poke has already been packaged. Is it something different?
https://tracker.debian.org/pkg/poke



-- 
Regards
Sudip

Bug#985524: iso2mesh-tools: broken symlink: /usr/bin/tetgen1.5 -> tetgen

[Sébastien Villemot]

Le vendredi 02 avril 2021 à 09:16 -0400, Qianqian Fang a écrit :
> On 4/2/21 5:19 AM, Sébastien Villemot wrote:
> 
> > But are those symlinks really needed in the first place? I could not find a 
> > place in the package where “tetgen1.5” is called (with the version number 
> > as a suffix). Only “tetgen” seems to be called. But maybe am I missing 
> > something.
> 
> 
> we noticed that the mesh output are not reproducible across different
> versions of tetgen. They also behave differently - some crash for
> certain input, some don't. therefore, in iso2mesh, we embedded different
> versions of iso2mesh and allow users to specifically choose using a flag
> in several core functions.
> 
> Because debian only provides tetgen1.5 as tetgen, to allow some existing
> scripts/demos to run (at least), for example, in the octave-brain2mesh
> package
> 
> https://salsa.debian.org/pkg-octave-team/octave-brain2mesh/-/blob/master/brain2mesh.m#L205
> 
> 
> I need to create the tetgen1.5 link.
> 
> let me know if there is a better solution.

Thanks for looking at this issue.

I don’t think that creating those symlinks in iso2mesh-tools is the
right solution. Such symlinks should only be created by the tetgen
package, otherwise this only creates confusion over package boundaries.

I think the right solution is to drop the symlinks, and rather to
create a Debian-specific patch that replaces “tetgen1.5” with “tetgen”
in brain2mesh.m.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#986289: libcache-fastmmap-perl: autopkgtest fails on t/21.t if a large tmpfs is present

[Sebastien Delafond]

Source: libcache-fastmmap-perl
Version: 1.56-1
Severity: normal
User: de...@kali.org
Usertags: origin-kali

t/21.t is executed only if a tmpfs larger than 8G is found on the
system:

```
my $fs;
BEGIN {
my @fs = map { { /(\w+)="([^"]*)"/g } } split /\n/, `findmnt -t tmpfs -P -b 
-o TARGET,AVAIL | grep /tmp`;
($fs) = grep { $_->{AVAIL} > 2**33 } @fs;
if (!$fs) {
  plan skip_all => 'Large file tests need tmpfs with at least 8G';
}
}
```

When that condition is met, the creation of a cache file will be
attempted on that tmpfs, and in an autopkgtest testbed including a user
with a uid greater than 1000 this call will fail as there is no
`Restrictions: need-root` annotation.

Here's a short sequence of calls exhibiting the issue:

  $ debci setup --suite sid --arch amd64 --backend lxc
  $ mkdir -p /srv/tmpfs
  $ mount -t tmpfs -o size=9G,rw tmpfs /srv/tmpfs
  $ TMPDIR=/srv/tmpfs autopkgtest -U -B libcache-fastmmap-perl -- lxc 
autopkgtest-sid-amd64
  [...]
  t/21.t .. 

  1..6  
  
  ok 1 - use Cache::FastMmap;   

  Create of share file /srv/tmpfs/autopkgtest-lxc.2sfvvv_r/largecachetest.cache 
failed: Permission denied at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Cache/FastMmap.pm line 762.
  [...]
  autodep8-perl-build-deps FAIL non-zero exit status 1
  [...]
  $ TMPDIR=/srv/tmpfs autopkgtest -u root -U -B libcache-fastmmap-perl -- lxc 
autopkgtest-sid-amd64
  [...]
  $ echo $?
  0

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

Kernel: Linux 5.10.0-4-amd64 (SMP w/36 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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

Bug#985524: iso2mesh-tools: broken symlink: /usr/bin/tetgen1.5 -> tetgen

[Qianqian Fang]

On 4/2/21 5:19 AM, Sébastien Villemot wrote:
>
> Can you please clarify the situation regarding the above bug?
>
> As I understand it, /usr/bin/tetgen and its corresponding manpage are 
> provided by the tetgen package, which is *not* a dependency of 
> iso2mesh-tools. So there are installation scenarios where those symlinks may 
> be dangling. Hence the release critical bug.


hi Sébastien

sorry, I was only able to see this bug today.

the issue was caused by incorrect dependency, and it is now fixed in salsa

https://salsa.debian.org/pkg-octave-team/octave-iso2mesh/-/commit/e2c128a60496d79de92cf41647d1b9f18a887860

Rafael, would you be able to review this change and upload? I assume we
also need to update changelog.


> But are those symlinks really needed in the first place? I could not find a 
> place in the package where “tetgen1.5” is called (with the version number as 
> a suffix). Only “tetgen” seems to be called. But maybe am I missing something.


we noticed that the mesh output are not reproducible across different
versions of tetgen. They also behave differently - some crash for
certain input, some don't. therefore, in iso2mesh, we embedded different
versions of iso2mesh and allow users to specifically choose using a flag
in several core functions.

Because debian only provides tetgen1.5 as tetgen, to allow some existing
scripts/demos to run (at least), for example, in the octave-brain2mesh
package

https://salsa.debian.org/pkg-octave-team/octave-brain2mesh/-/blob/master/brain2mesh.m#L205

I need to create the tetgen1.5 link.

let me know if there is a better solution.

thanks


Qianqian

>
> Thanks,
>

Bug#986288: ITP: poke -- GNU poke, an interactive, extensible binary editor

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: poke
  Version : 1.1
  Upstream Author : Jose E. Marchesi
* URL or Web page : https://www.jemarch.net/poke
* License : GPL-3+
  Description : GNU poke, an interactive, extensible binary editor

Bug#986287: unblock: os-autoinst/4.6.1604525166.912dfbd-0.3

[Frédéric Bonnard]

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

Please unblock package os-autoinst

The version in testing has bug #977990 which is a FTBFS on i386 because
of flaky tests.
I initially wanted to be stricter than upstream and run all tests as it
worked on my builders, but I've decided to stick to the tests upstream
feels confident to run.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977990#44

Build now works right away on i386 :
https://buildd.debian.org/status/package.php?p=os-autoinst

See attached the debdiff for the changes I did.

unblock os-autoinst/4.6.1604525166.912dfbd-0.3


Thanks!
Regards

F. 

diff -Nru os-autoinst-4.6.1604525166.912dfbd/debian/changelog 
os-autoinst-4.6.1604525166.912dfbd/debian/changelog
--- os-autoinst-4.6.1604525166.912dfbd/debian/changelog 2020-12-22 
15:00:29.0 +0100
+++ os-autoinst-4.6.1604525166.912dfbd/debian/changelog 2021-04-01 
12:50:51.0 +0200
@@ -1,3 +1,10 @@
+os-autoinst (4.6.1604525166.912dfbd-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Stick to tests that upstream runs (Closes: #977990)
+
+ -- Frédéric Bonnard   Thu, 01 Apr 2021 12:50:51 +0200
+
 os-autoinst (4.6.1604525166.912dfbd-0.2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru os-autoinst-4.6.1604525166.912dfbd/debian/rules 
os-autoinst-4.6.1604525166.912dfbd/debian/rules
--- os-autoinst-4.6.1604525166.912dfbd/debian/rules 2020-12-22 
14:55:47.0 +0100
+++ os-autoinst-4.6.1604525166.912dfbd/debian/rules 2021-04-01 
12:48:06.0 +0200
@@ -8,6 +8,8 @@
 override_dh_auto_configure:
cp -a $(CURDIR)/isotovideo $(CURDIR)/isotovideo.orig
sed -i 's/my $$thisversion =.*/my $$thisversion = "$(DEB_VERSION)";/' 
$(CURDIR)/isotovideo
+   # Following opensuse .spec : don't require qemu and exclude known flaky 
tests
+   cd t && rm -f 07-commands.t 13-osutils.t 14-isotovideo.t 
18-qemu-options.t 18-backend-qemu.t 99-full-stack.t
dh_auto_configure -- -DOS_AUTOINST_DOC_DIR=/usr/share/doc/$(DEB_SOURCE) 
\
-DSYSTEMD_SERVICE_DIR=/lib/systemd/system 
-DCMAKE_BUILD_TYPE=RelWithDebInfo
 


signature.asc
Description: PGP signature

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Guillem Jover]

Hi!

On Sun, 2021-03-21 at 14:03:32 +0100, Stephen Kitt wrote:
> Control: retitle -1 ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility 
> library wrapping SDL 2.0
> Control: owner -1 !
> 
> On Sun, 21 Mar 2021 11:17:32 +, Simon McVittie  wrote:
> > On Sat, 13 Mar 2021 at 23:47:30 +0100, Guillem Jover wrote:
> > > I've recently retried switching to Wayland and I think I'm sticking
> > > with it. But while checking for toolkits support, noticed that SDL 1.2
> > > does not have native Wayland support, but SDL 2.0 does.  
> > 
> > Note that SDL 2.0 currently defaults to using X11 if available, and will
> > currently only use Wayland if X11 is unavailable, so in environments where
> > Xwayland is either always run (such as GNOME 3.38) or started automatically
> > on-demand (such as GNOME 40), SDL 2.0 games will normally be using X11.
> > I think typical desktop environments like GNOME and KDE Plasma are
> > likely to want Xwayland available by default for quite a long time,
> > even if it's only started on-demand.

Sure, in my case sway, but all the same. My goal is to be able to
disable Xwayland completely though. :)

> > You can override this with with environment variable
> > SDL_VIDEODRIVER=wayland.

Yes, the problem though is that this cannot be set unconditionally in
one's environment, as any SDL-1 program will then fail to start
completely (some might even segfault if they are not checking the SDL
initialization function return codes, as I found out with hex-a-hop,
which should now be fixed upstream :).

> Right, I’ll make sure to document this in the package.

Please, document that setting this unconditionally is currently not a
good idea.

> > On Sun, 14 Mar 2021 at 02:07:34 +0100, Haelwenn (lanodan) Monnier wrote:
> > > As seen in [1] regarding the headers, sdl12-compat isn't a full
> > > replacement yet.
> > > 
> > > It could work for pure binary-compatibility but you can't build anything
> > > against it yet so it should be a Provide+Replace rather than something
> > > like a newer version.
> > > 
> > > 1: https://github.com/libsdl-org/sdl12-compat/issues/34  
> > 
> > Yes, I'd come to that conclusion too.
> 
> Yup, for the time being it’s really only a runtime replacement, it’s not
> ready as a build-time SDL2 shim for SDL1.2 projects.

Right, sorry should have made this more clear in the RFP.

There was also , which seems might
have been more complete, but given that it does not seem to be active
anymore and not maintained by upstream SDL, it was not worth pursuing.

Thanks,
Guillem

Bug#986185: closed by Debian FTP Masters (reply to Mo Zhou ) (Bug#986185: fixed in zfs-linux 2.0.3-3)

[наб]

On Fri, Apr 02, 2021 at 12:05:16PM +, M. Zhou wrote:
> [1] instead of NEWS, in order to avoid being too abruptive.

I do think this is definitely NEWS-worthy ‒ you're affecting existing
set-ups in ways that are hard to notice and could potentially lead
to premature media failure or, at the very least, significant
performance degradation.

I mean, I'm a maniac and I do read all changelogs, but the /vast/
majority of people don't, and this feels like the prime use of NEWS.

But I agree, having this in README.Debian would be good as well.

Best,
наб


signature.asc
Description: PGP signature

Bug#875531: "editor +42 filename" -- accept or reject?

[Adam Borowski]

Hi!
Now that you folks are dealing with the "editor" virtual package, and,
what interests me here, the alternative for /usr/bin/editor -- could you
please process this proposal as well, and either accept or close it?

My point is that, all but one (e3) current alternatives allow positioning
the cursor on a given line, and various users take inconsistent approach
as to when this feature can be used.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋⠀ by a hacker".  So what's the problem?
⠈⠳⣄

Bug#986286: diaspora-installer: fails to install: Your bundle is locked to mimemagic (0.3.5), but that version could not be found

[Andreas Beckmann]

Package: diaspora-installer
Version: 0.7.14.0+debian2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up diaspora-installer (0.7.14.0+debian2) ...
  Download diaspora tarball version 0.7.14.0 from github.com...
  --2021-04-02 11:03:54--  
https://github.com/diaspora/diaspora/archive/v0.7.14.0.tar.gz
  Resolving github.com (github.com)... 140.82.121.4
  Connecting to github.com (github.com)|140.82.121.4|:443... connected.
  HTTP request sent, awaiting response... 302 Found
  Location: https://codeload.github.com/diaspora/diaspora/tar.gz/v0.7.14.0 
[following]
  --2021-04-02 11:03:54--  
https://codeload.github.com/diaspora/diaspora/tar.gz/v0.7.14.0
  Resolving codeload.github.com (codeload.github.com)... 140.82.121.9
  Connecting to codeload.github.com (codeload.github.com)|140.82.121.9|:443... 
connected.
  HTTP request sent, awaiting response... 200 OK
  Length: unspecified [application/x-gzip]
  Saving to: '/var/cache/diaspora-installer/diaspora-0.7.14.0.tar.gz'
  
  
  /var/cach [<=> ]   0  --.-KB/s   
 /var/cache [ <=>]   1.45M  7.11MB/s   
/var/cache/ [  <=>   ]   3.79M  9.36MB/s   
   /var/cache/d [   <=>  ]   8.59M  14.2MB/s   
/var/cache/diaspora [<=> ]   9.45M  14.0MB/sin 0.7s
  
  2021-04-02 11:03:55 (14.0 MB/s) - 
'/var/cache/diaspora-installer/diaspora-0.7.14.0.tar.gz' saved [9911008]
  
  Checking integrity of download...
  /var/cache/diaspora-installer/diaspora-0.7.14.0.tar.gz: OK
  Extracting files...
  Copying files to /usr/share/diaspora...
  diaspora archive to copy: diaspora-0.7.14.0
  Copying source tarball to /var/lib/diaspora/public...
  Setting up environment varibales...
  Using /etc/diaspora/diaspora.conf...
  DB_NAME=diaspora_production
  Using system bundler...
  Installing gems with rubygems ...
  [ESC][33m[DEPRECATED] The `--frozen` flag is deprecated because it relies on 
being remembered across bundler invocations, which bundler will no longer do in 
future versions. Instead please use `bundle config set --local frozen 'true'`, 
and stop using this flag[ESC][0m
  [ESC][33m[DEPRECATED] The `--path` flag is deprecated because it relies on 
being remembered across bundler invocations, which bundler will no longer do in 
future versions. Instead please use `bundle config set --local path 
'vendor/bundle'`, and stop using this flag[ESC][0m
  [ESC][33m[DEPRECATED] The `--without` flag is deprecated because it relies on 
being remembered across bundler invocations, which bundler will no longer do in 
future versions. Instead please use `bundle config set --local without 
'development test'`, and stop using this flag[ESC][0m
  [ESC][33m[DEPRECATED] The `--with` flag is deprecated because it relies on 
being remembered across bundler invocations, which bundler will no longer do in 
future versions. Instead please use `bundle config set --local with 
'postgresql'`, and stop using this flag[ESC][0m
  Fetching gem metadata from https://gems.diasporafoundation.org/..
  Fetching gem metadata from https://rubygems.org/..
  [ESC][31mYour bundle is locked to mimemagic (0.3.5), but that version could 
not be found
  in any of the sources listed in your Gemfile. If you haven't changed sources,
  that means the author of mimemagic (0.3.5) has removed it. You'll need to 
update
  your bundle to a version other than mimemagic (0.3.5) that hasn't been removed
  in order to install.[ESC][0m
  dpkg: error processing package diaspora-installer (--configure):
   installed diaspora-installer package post-installation script subprocess 
returned error exit status 7
  Processing triggers for libc-bin (2.31-11) ...
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Processing triggers for libgdk-pixbuf-2.0-0:amd64 (2.42.2+dfsg-1) ...
  Errors were encountered while processing:
   diaspora-installer


cheers,

Andreas


diaspora-installer_0.7.14.0+debian2.log.gz
Description: application/gzip

Bug#984439: Maybe related issue ...

[Gianfranco Costamagna]

control: tags -1 patch pending

Hello, a proper upstream fix is in deferred/2 (and attached)

G.

On Thu, 1 Apr 2021 08:34:32 +0200 Gianfranco Costamagna 
 wrote:
> Hello,
> In Ubuntu I uploaded this ugly workaround for armhf
> 
> diff -pruN 6.2.2006+really6.2.1905+dfsg-2/debian/changelog 
> 6.2.2006+really6.2.1905+dfsg-2ubuntu1/debian/changelog
> --- 6.2.2006+really6.2.1905+dfsg-2/debian/changelog   2020-12-21 
> 20:21:12.0 +
> +++ 6.2.2006+really6.2.1905+dfsg-2ubuntu1/debian/changelog2021-03-17 
> 09:27:28.0 +
> @@ -1,3 +1,12 @@
> +netgen (6.2.2006+really6.2.1905+dfsg-2ubuntu1) hirsute; urgency=medium
> +
> +  * Ignore test results on armhf. They failed since the begin, but testsuite
> +was not ran, and they are already being worked/looked by upstream and
> +Debian. They fail when armhf is ran on arm64 kernel, leading to unaligned
> +accesses. See Debian bug #984439 and LP bug: #1919335
> +
> + -- Gianfranco Costamagna   Wed, 17 Mar 2021 
> 10:27:28 +0100
> +
>  netgen (6.2.2006+really6.2.1905+dfsg-2) unstable; urgency=medium
>  
>[ Christophe Trophime ]
> diff -pruN 6.2.2006+really6.2.1905+dfsg-2/debian/rules 
> 6.2.2006+really6.2.1905+dfsg-2ubuntu1/debian/rules
> --- 6.2.2006+really6.2.1905+dfsg-2/debian/rules   2020-12-21 
> 20:21:06.0 +
> +++ 6.2.2006+really6.2.1905+dfsg-2ubuntu1/debian/rules2021-03-17 
> 09:27:28.0 +
> @@ -44,10 +44,17 @@ override_dh_auto_configure:
>  
>  override_dh_auto_test:
>   dh_auto_install
> +ifeq ($(DEB_HOST_ARCH),armhf)
> + cd tests/pytest && \
> +  PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages \
> +  LD_LIBRARY_PATH=$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH) 
> \
> +  python3 -m pytest || true
> +else
>   cd tests/pytest && \
>PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages \
>LD_LIBRARY_PATH=$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH) 
> \
>python3 -m pytest
> +endif
>  
>  override_dh_shlibdeps:
>   dh_shlibdeps -l/usr/lib/${DEB_HOST_MULTIARCH}/netgen
> 
> Do you think its worth a Debian upload too?
> 
> Gianfranco
> 
> 
diff -Nru netgen-6.2.2006+really6.2.1905+dfsg/debian/changelog 
netgen-6.2.2006+really6.2.1905+dfsg/debian/changelog
--- netgen-6.2.2006+really6.2.1905+dfsg/debian/changelog2020-12-21 
21:21:12.0 +0100
+++ netgen-6.2.2006+really6.2.1905+dfsg/debian/changelog2021-04-02 
14:05:03.0 +0200
@@ -1,3 +1,11 @@
+netgen (6.2.2006+really6.2.1905+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/4fad6e0631718a4bb574d67505e0ebfef1f171ce.patch:
+- upstream fix for armhf build failure (Closes: #984439)
+
+ -- Gianfranco Costamagna   Fri, 02 Apr 2021 
14:05:03 +0200
+
 netgen (6.2.2006+really6.2.1905+dfsg-2) unstable; urgency=medium
 
   [ Christophe Trophime ]
diff -Nru 
netgen-6.2.2006+really6.2.1905+dfsg/debian/patches/4fad6e0631718a4bb574d67505e0ebfef1f171ce.patch
 
netgen-6.2.2006+really6.2.1905+dfsg/debian/patches/4fad6e0631718a4bb574d67505e0ebfef1f171ce.patch
--- 
netgen-6.2.2006+really6.2.1905+dfsg/debian/patches/4fad6e0631718a4bb574d67505e0ebfef1f171ce.patch
   1970-01-01 01:00:00.0 +0100
+++ 
netgen-6.2.2006+really6.2.1905+dfsg/debian/patches/4fad6e0631718a4bb574d67505e0ebfef1f171ce.patch
   2021-04-02 14:04:14.0 +0200
@@ -0,0 +1,58 @@
+From 4fad6e0631718a4bb574d67505e0ebfef1f171ce Mon Sep 17 00:00:00 2001
+From: Christopher Lackner 
+Date: Thu, 1 Apr 2021 10:48:13 +0200
+Subject: [PATCH] fix pickling on arm, store long type platform independent
+
+---
+ libsrc/core/archive.hpp | 20 ++--
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+diff --git a/libsrc/core/archive.hpp b/libsrc/core/archive.hpp
+index 430262bf..decf8718 100644
+--- a/libsrc/core/archive.hpp
 b/libsrc/core/archive.hpp
+@@ -684,7 +684,11 @@ namespace ngcore
+ Archive & operator & (short & i) override
+ { return Write(i); }
+ Archive & operator & (long & i) override
+-{ return Write(i); }
++{
++  // for platform independence
++  int64_t tmp = i;
++  return Write(tmp);
++}
+ Archive & operator & (size_t & i) override
+ { return Write(i); }
+ Archive & operator & (unsigned char & i) override
+@@ -722,14 +726,13 @@ namespace ngcore
+ template 
+ Archive & Write (T x)
+ {
++  static_assert(sizeof(T) < BUFFERSIZE, "Cannot write large types with 
this function!");
+   if (unlikely(ptr > BUFFERSIZE-sizeof(T)))
+ {
+   stream->write([0], ptr);
+-  *reinterpret_cast([0]) = x; // NOLINT
+-  ptr = sizeof(T);
+-  return *this;
++  ptr = 0;
+ }
+-  *reinterpret_cast([ptr]) = x; // NOLINT
++  memcpy([ptr], , sizeof(T));
+   ptr += sizeof(T);
+   return *this;
+ }
+@@ -755,7 +758,12 @@ namespace ngcore
+ Archive & operator & (short & i) override
+ { 

Bug#986185: closed by Debian FTP Masters (reply to Mo Zhou ) (Bug#986185: fixed in zfs-linux 2.0.3-3)

[M. Zhou]

Hi,

Thanks for the super awesome feedback!

I indeed forgot to write a README.Debian [1] recording this
change and its usage. Let me prepare a revision and upload shortly.

[1] instead of NEWS, in order to avoid being too abruptive.

On Fri, 2021-04-02 at 12:20 +0200, наб wrote:
> This looks great, thanks! You've definitely taken the right approach
> here.
> 
> Just a few nitpicks, see diff:
>   * no need to call modprobe, just check sysfs directly
>     (this is what modprobe does anyway)
>   * the proper name for this is "periodic-{scrub,trim}" ‒
>     "periodical" really doesn't work here in modern use
>   * get_property() was overly complex ‒
>     if the pool doesn't exist, zfs-get already exits with 1,
> so just bubble it up through "|| return 1" to appease -e;
> if the property isn't set, it just returns 0 and prints "-",
> which we already check
>   * I also touched the comment up and linked to the zpool userprops
> PR
> 
> Also, please add note of this to the NEWS file, something like
> -- >8 --
>   Starting with this version, the auto-scrub and auto-trim jobs will
> use
>   the "org.debian:periodic-{scrub,trim}" user properties on the
> pool's
>   root dataset to determine if they should do anything; accepted
> values
>   are:
>     * "auto" ‒ same as unset, use default checks
> * "enable" ‒ always scrub/trim automatically
> * "disable" ‒ never scrub/trim automatically
>   .
>   The default for auto-scrub is to scrub, as before,
>   but the default for auto-trim has changed: it will now only trim
>   if the pool consists of /only/ NVMe drives, since some SATA 2
>   and SATA 3.0 SSDs will hang or crash during large TRIMs (#983086) ‒
>   if your pools with SATA SSDs had no problems trimming before,
>   you will need to run
>     zfs set org.debian:periodic-trim=enable sata-pool
>   to restore previous behaviour.
> -- >8 --
> would be great, feel free to just steal this.
> 
> Best,
> наб
> diff --git a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
> b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
> index 91631cb18..cb4e3c07e 100755
> --- a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
> +++ b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
> @@ -1,27 +1,19 @@
>  #!/bin/sh -eu
>  
>  # directly exit successfully when zfs module is not loaded
> -if modprobe -n -q --first-time zfs; then
> +if ! [ -d /sys/module/zfs ]; then
> exit 0
>  fi
>  
>  # [auto] / enable / disable
> -PROPERTY_NAME="org.debian:periodical-scrub"
> +PROPERTY_NAME="org.debian:periodic-scrub"
>  
>  get_property () {
> -   # Detect the ${PROPERTY_NAME} property from a given zpool
> -   # Note, we are abusing user-defined property on zpool root
> dataset
> -   # as "zpool user-defined property".
> +   # Detect the ${PROPERTY_NAME} property on a given pool
> +   # We are abusing user-defined properties on the root dataset,
> +   # since they're not available on pools
> https://github.com/openzfs/zfs/pull/11680
> pool=$1
> -   if ! zfs list -H -o name "${pool}" 1>/dev/null 2>/dev/null;
> then
> -   return 1  # failed to find the root dataset
> -   fi
> -   if ! zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
> 1>/dev/null 2>/dev/null; then
> -   return 1  # no such property
> -   else
> -   # has such property
> -   zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
> -   fi
> +   zfs get -H -o value "${PROPERTY_NAME}" "${pool}" 2>/dev/null
> || return 1
>  }
>  
>  scrub_if_not_scrub_in_progress () {
> diff --git a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
> b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
> index 585a58baf..5a0216507 100755
> --- a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
> +++ b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
> @@ -1,27 +1,19 @@
> -#!/bin/sh -e
> +#!/bin/sh -eu
>  
>  # directly exit successfully when zfs module is not loaded
> -if modprobe -n -q --first-time zfs; then
> +if ! [ -d /sys/module/zfs ]; then
> exit 0
>  fi
>  
>  # [auto] / enable / disable
> -PROPERTY_NAME="org.debian:periodical-trim"
> +PROPERTY_NAME="org.debian:periodic-trim"
>  
>  get_property () {
> -   # Detect the ${PROPERTY_NAME} property from a given zpool
> -   # Note, we are abusing user-defined property on zpool root
> dataset
> -   # as "zpool user-defined property".
> -   pool=$1
> -   if ! zfs list -H -o name "${pool}" 1>/dev/null 2>/dev/null;
> then
> -   return 1  # failed to find the root dataset
> -   fi
> -   if ! zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
> 1>/dev/null 2>/dev/null; then
> -   return 1  # no such property
> -   else
> -   # has such property
> -   zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
> -   fi
> +    # Detect the ${PROPERTY_NAME} property on a given pool
> +    # We are abusing user-defined properties 

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[intrigeri]

Hi Paul,

Paul Gevers (2021-02-18):
> Hi intrigeri,
>
> On 18-02-2021 10:34, intrigeri wrote:
>>>   # Dummy test so that changes to linux-image-amd64 trigger our other 
>>> autopkgtests
>>>   # on ci.debian.net
>
> By the way, we have the "hint-testsuite-triggers" for this.
>
>> Actually, apparmor-profiles-extra has the exact same test, and AFAICT
>> it seems to run pretty reliably there, so I now have doubts about the
>> hypothesis I quoted above.
>> 
>> Still, perhaps it's worth trying to add isolation-machine to that
>> test, remove src:apparmor from the blocklist, and see what happens?
>
> If you add that restriction (instead of the current ones), the test
> isn't run anywhere (and can't cause any issues).

Thanks!

In 3.0.1-6 (experimental) I've replaced the current restrictions with
hint-testsuite-triggers, i.e.:

   Test-Command: /bin/true
   Depends: linux-image-amd64 [amd64] | linux-image-generic [ amd64 ]
  -Restrictions: superficial, skip-not-installable
  +Restrictions: hint-testsuite-triggers

I've verified that the resulting .dsc has the same
Testsuite-Triggers field.

I would like to see the same 1-line change in Bullseye, in the hope
that it's enough to allow you folks to remove src:apparmor from
the blocklist.

Would you like to pre-approve this here, or do you prefer that
I request pre-approval via the regular release team process?

Cheers,
-- 
intrigeri

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Simon McVittie]

On Thu, 01 Apr 2021 at 18:17:59 -0700, Russ Allbery wrote:
> +- ``upstream_version`` components in native packages or
> +  ``debian_revision`` components in non-native packages ending in
> +  ``~debNuX`` also indicate a stable update, but of a different type.
> +  This version convention indicates that the stable version of the package
> +  was updated to a new upstream release, as distinct from the ``+debNuX``
> +  convention that indicates additional changes were applied to the
> +  existing stable release.  ``N`` and ``X`` mean the same as with
> +  ``+debNuX``.

I don't think this is quite it.

For me, ~debNu1 implies that a stable update was made by taking a newer
Debian package (typically from unstable) - not necessarily a new upstream
release! - and backporting it in its entirety, mechanically equivalent to
a ~bpo version but released to all users of stable rather than just those
who have opted-in to backports.

src:pango1.0 in Debian 10 is an example of this: we fixed CVE-2019-1010238
in testing/unstable by applying a patch (1.42.4-6 was vulnerable,
1.42.4-7 was fixed). We could have continued by fixing CVE-2019-1010238
in stable as 1.42.4-6+deb10u1, but the result would have been functionally
equivalent to 1.42.4-7, so it seemed clearer to just take 1.42.4-7 and
rebuild it for Debian 10 as 1.42.4-7~deb10u1. We later repeated the
process for 1.42.4-8 with some non-security fixes.

If the stable version of the package was updated to a new upstream release
instead, there are two ways that can happen. One way is to take the version
from testing/unstable and rebuild it in stable, like src:openjdk-11 in
Debian 10: 11.0.9.1+1-1 was uploaded to unstable first, then rebuilt
in Debian 10 as 11.0.9.1+1-1~deb10u1.

The other way is to repackage the new upstream release from first
principles, either because it's a new release from an upstream branch
that's older than the one in testing/unstable (like src:flatpak in Debian
10), or because testing/unstable already has packaging changes that aren't
suitable for stable (like src:dbus in Debian 10). In this case it would be
misleading to use a version number like flatpak_1.2.5-1~deb10u1 (because
1.2.5-1 never existed) or dbus_1.12.20-1~deb10u1 (because 1.12.20-1 did
exist, but the version of dbus in stable was not based on it, and does
not have the downstream changes from that version). Instead, the convention
that has emerged is to use 0+deb10u1, by analogy with the convention that
an NMU introducing a new upstream release has revision number 0.1.

~debNuX for X > 1 indicates subsequent stable-specific changes applied
on top of to a ~debNu1 version.

(Sorry, I'm not sure how to express all this in a paragraph or two...)

smcv

Bug#986284: update InRelease files in place and changes owner and mode in the process

[Marc Haber]

Package: apt
Version: 2.2.2
Severity: minor

Hi,

when doing apt update, InRelease files seem to be downloaded and
upgraded in place. While this happens, the file's owner/mode changes
from root:root 644 to _apt:root 640 and back after a few seconds.

A simultaneously running aide (https://tracker.debian.org/pkg/aide)
process might pick this up and put it in a report. This has actually
happened (I have a black thumb for software).

While the file is still identical after the download, triggering this
behavior is somewhat unlikely, but I would still prefer if apt
downloaded InRelease files to a temporary file name and then rename the
new file in place iff the new contents differs fromt the old one
(keeping even the inode number the same in the 'did not change' case).

I did a few tests and have only found this behavior for InRelease files.
But of course, I'd love to have this behavior for all flies that apt
downloads and keeps around during its operation.

This is by no means somthing that needs to be fixed before the bullseye
release. Thanks for your consideration!

Greetings
Marc



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

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

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

Versions of packages apt recommends:
ii  ca-certificates  20210119

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

-- no debconf information

Bug#986256: simka: flaky amd64 autopkgtest: regularly times out after 2:47 h

[Nilesh Patra]

Hi,

On Thu, 1 Apr 2021 20:53:00 +0200 Paul Gevers  wrote:
 
> Your package has an autopkgtest, great. However, I looked into
> the history of your autopkgtest [1] and I noticed version 1.5.3-2 fails
> regularly on amd64, while sporadically a rerun passes. I copied some of
> the output at the bottom of this report. It hits the autopkgtest time
> out after 2hours and 47 minutes. Successful runs pass in less than a minute.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.

That makes sense  - do you think marking this test as flaky can be
solution?

Nilesh


signature.asc
Description: PGP signature

Bug#986152: Offer of help

[Jeremy Sowden]

I'd be happy to help.  I've been a Shorewall user for many years, and
I've recently been lending a hand to the Netfilter Packaging Team.

J.


signature.asc
Description: PGP signature

Bug#986283: claws-mail-vcalendar-plugin: Recurring event time incorrectly shifted due to DST

[Vilius Panevėžys]

Package: claws-mail-vcalendar-plugin
Version: 3.17.3-2
Severity: normal
Tags: upstream

Today I noticed a recurring meeting time was shifted ahead by 1 hour: the 
actual start time is 11:00, vCalendar plug-in displayed start time - 12:00. 
This is likely due to the fact daylight saving time came into effect on 03-28 
this year.

The invitation includes a "VTIMEZONE" block that seems right, except for the 
strange year (1601) in "DTSTART". Blocks indented for readability.

BEGIN:VTIMEZONE
TZID:FLE Standard Time
BEGIN:STANDARD
DTSTART:16010101T04
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE

A quick grep through the source does not return any matches for "DAYLIGHT" in 
neither the source of the package currently in stable, nor upstream, which 
suggests the property is not supported, hence the upstream tag.

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

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

Versions of packages claws-mail-vcalendar-plugin depends on:
ii  claws-mail   3.17.3-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4+deb10u1
ii  libcurl3-gnutls  7.64.0-4+deb10u2
ii  libdb5.3 5.3.28+dfsg1-0.5
ii  libetpan20   1.9.3-2
ii  libexpat12.2.6-2+deb10u1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgnutls30  3.6.7-4+deb10u6
ii  libgtk2.0-0  2.24.32-3
ii  libical3 3.0.4-3
ii  liblockfile1 1.14-1.1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libsasl2-2   2.1.27+dfsg-1+deb10u1

claws-mail-vcalendar-plugin recommends no packages.

claws-mail-vcalendar-plugin suggests no packages.

-- no debconf information

Bug#986282: unblock: rust-compiler-builtins/0.1.26-3

[plugwash]

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

Please unblock package rust-compiler-builtins

rust-compiler-builtins 0.1.26-2 FTBFS on armhf (and presumablly also armel
but I did not test that).

Rust upstream have renamed the old assembler support from asm! to llvm_asm!
in preperation for the introduction of a new assembler syntax. This breaks
the build of rust-compiler-builtins on arm (tested on armhf but presumablly
also affects armel).

rust-compiler-builtins uses inline asm in the arm implementations. There is also
some inline asm in the x86 and x86-64 implementations, but said asm is not
used when building for linux.

Upstream fixed this some time ago,
https://github.com/rust-lang/compiler-builtins/commit/cde22bc180391e75de1c189fe29f442ada86ccde
but unfortunately the new version was never uploaded to Debian and given that
it's a key package, it's too late for new upstream versions now. The upstream
commit also included some unrelated changes.

I therefore took the upstream commit, removed changes unrelated to the asm
change and applied it to the Debian package. I left in the changes to the
non-linux asm blocks figuring it was sensible to treat the asm change
as one unit.

unblock rust-compiler-builtins/0.1.26-3

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

Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru rust-compiler-builtins-0.1.26/debian/cargo-checksum.json 
rust-compiler-builtins-0.1.26/debian/cargo-checksum.json
--- rust-compiler-builtins-0.1.26/debian/cargo-checksum.json2020-04-12 
21:42:44.0 +
+++ rust-compiler-builtins-0.1.26/debian/cargo-checksum.json2021-04-01 
11:34:12.0 +
@@ -1 +1 @@
-{"package":"036b035e9ebcd705affece16319223d19f229e2358be6e3b7b094e57193312e6","files":{}}
+{"package":"Could not get crate checksum","files":{}}
diff -Nru rust-compiler-builtins-0.1.26/debian/changelog 
rust-compiler-builtins-0.1.26/debian/changelog
--- rust-compiler-builtins-0.1.26/debian/changelog  2020-04-12 
21:42:44.0 +
+++ rust-compiler-builtins-0.1.26/debian/changelog  2021-04-01 
11:34:12.0 +
@@ -1,3 +1,12 @@
+rust-compiler-builtins (0.1.26-3) unstable; urgency=medium
+
+  * Team upload.
+  * Package compiler_builtins 0.1.26 from crates.io using debcargo 2.4.2
+  * Apply upstream changes to replace asm with llvm_asm and hence
+fix FTBFS on arm (Closes: 985810).
+
+ -- Peter Michael Green   Thu, 01 Apr 2021 11:34:12 +
+
 rust-compiler-builtins (0.1.26-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-compiler-builtins-0.1.26/debian/copyright 
rust-compiler-builtins-0.1.26/debian/copyright
--- rust-compiler-builtins-0.1.26/debian/copyright  2020-04-12 
21:42:44.0 +
+++ rust-compiler-builtins-0.1.26/debian/copyright  2021-04-01 
11:34:12.0 +
@@ -57,7 +57,7 @@
 
 Files: debian/*
 Copyright:
- 2019 Debian Rust Maintainers 
+ 2019-2021 Debian Rust Maintainers 

  2019 kpcyrd 
 License: MIT or Apache-2.0
 
diff -Nru rust-compiler-builtins-0.1.26/debian/copyright.debcargo.hint 
rust-compiler-builtins-0.1.26/debian/copyright.debcargo.hint
--- rust-compiler-builtins-0.1.26/debian/copyright.debcargo.hint
2020-04-12 21:42:44.0 +
+++ rust-compiler-builtins-0.1.26/debian/copyright.debcargo.hint
2021-04-01 11:34:12.0 +
@@ -413,8 +413,8 @@
 
 Files: debian/*
 Copyright:
- 2020 Debian Rust Maintainers 
- 2020 kpcyrd 
+ 2020-2021 Debian Rust Maintainers 

+ 2020-2021 kpcyrd 
 License: MIT or Apache-2.0
 
 License: Apache-2.0
diff -Nru rust-compiler-builtins-0.1.26/debian/patches/series 
rust-compiler-builtins-0.1.26/debian/patches/series
--- rust-compiler-builtins-0.1.26/debian/patches/series 1970-01-01 
00:00:00.0 +
+++ rust-compiler-builtins-0.1.26/debian/patches/series 2021-04-01 
11:34:12.0 +
@@ -0,0 +1 @@
+use-llvm_asm.patch
\ No newline at end of file
diff -Nru rust-compiler-builtins-0.1.26/debian/patches/use-llvm_asm.patch 
rust-compiler-builtins-0.1.26/debian/patches/use-llvm_asm.patch
--- rust-compiler-builtins-0.1.26/debian/patches/use-llvm_asm.patch 
1970-01-01 00:00:00.0 +
+++ rust-compiler-builtins-0.1.26/debian/patches/use-llvm_asm.patch 
2021-04-01 11:34:12.0 +
@@ -0,0 +1,305 @@
+Patch to fix asm related FTBFS by switching from asm! to llvm_asm!
+
+This patch is Based on the upstream commit referenced below with
+non-asm related changes removed.
+
+commit cde22bc180391e75de1c189fe29f442ada86ccde
+Author: Alex 

Bug#986185: closed by Debian FTP Masters (reply to Mo Zhou ) (Bug#986185: fixed in zfs-linux 2.0.3-3)

[наб]

This looks great, thanks! You've definitely taken the right approach here.

Just a few nitpicks, see diff:
  * no need to call modprobe, just check sysfs directly
(this is what modprobe does anyway)
  * the proper name for this is "periodic-{scrub,trim}" ‒
"periodical" really doesn't work here in modern use
  * get_property() was overly complex ‒
if the pool doesn't exist, zfs-get already exits with 1,
so just bubble it up through "|| return 1" to appease -e;
if the property isn't set, it just returns 0 and prints "-",
which we already check
  * I also touched the comment up and linked to the zpool userprops PR

Also, please add note of this to the NEWS file, something like
-- >8 --
  Starting with this version, the auto-scrub and auto-trim jobs will use
  the "org.debian:periodic-{scrub,trim}" user properties on the pool's
  root dataset to determine if they should do anything; accepted values
  are:
* "auto" ‒ same as unset, use default checks
* "enable" ‒ always scrub/trim automatically
* "disable" ‒ never scrub/trim automatically
  .
  The default for auto-scrub is to scrub, as before,
  but the default for auto-trim has changed: it will now only trim
  if the pool consists of /only/ NVMe drives, since some SATA 2
  and SATA 3.0 SSDs will hang or crash during large TRIMs (#983086) ‒
  if your pools with SATA SSDs had no problems trimming before,
  you will need to run
zfs set org.debian:periodic-trim=enable sata-pool
  to restore previous behaviour.
-- >8 --
would be great, feel free to just steal this.

Best,
наб
diff --git a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub 
b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
index 91631cb18..cb4e3c07e 100755
--- a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
+++ b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/scrub
@@ -1,27 +1,19 @@
 #!/bin/sh -eu
 
 # directly exit successfully when zfs module is not loaded
-if modprobe -n -q --first-time zfs; then
+if ! [ -d /sys/module/zfs ]; then
exit 0
 fi
 
 # [auto] / enable / disable
-PROPERTY_NAME="org.debian:periodical-scrub"
+PROPERTY_NAME="org.debian:periodic-scrub"
 
 get_property () {
-   # Detect the ${PROPERTY_NAME} property from a given zpool
-   # Note, we are abusing user-defined property on zpool root dataset
-   # as "zpool user-defined property".
+   # Detect the ${PROPERTY_NAME} property on a given pool
+   # We are abusing user-defined properties on the root dataset,
+   # since they're not available on pools 
https://github.com/openzfs/zfs/pull/11680
pool=$1
-   if ! zfs list -H -o name "${pool}" 1>/dev/null 2>/dev/null; then
-   return 1  # failed to find the root dataset
-   fi
-   if ! zfs get -H -o value "${PROPERTY_NAME}" "${pool}" 1>/dev/null 
2>/dev/null; then
-   return 1  # no such property
-   else
-   # has such property
-   zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
-   fi
+   zfs get -H -o value "${PROPERTY_NAME}" "${pool}" 2>/dev/null || return 1
 }
 
 scrub_if_not_scrub_in_progress () {
diff --git a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim 
b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
index 585a58baf..5a0216507 100755
--- a/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
+++ b/debian/tree/zfsutils-linux/usr/lib/zfs-linux/trim
@@ -1,27 +1,19 @@
-#!/bin/sh -e
+#!/bin/sh -eu
 
 # directly exit successfully when zfs module is not loaded
-if modprobe -n -q --first-time zfs; then
+if ! [ -d /sys/module/zfs ]; then
exit 0
 fi
 
 # [auto] / enable / disable
-PROPERTY_NAME="org.debian:periodical-trim"
+PROPERTY_NAME="org.debian:periodic-trim"
 
 get_property () {
-   # Detect the ${PROPERTY_NAME} property from a given zpool
-   # Note, we are abusing user-defined property on zpool root dataset
-   # as "zpool user-defined property".
-   pool=$1
-   if ! zfs list -H -o name "${pool}" 1>/dev/null 2>/dev/null; then
-   return 1  # failed to find the root dataset
-   fi
-   if ! zfs get -H -o value "${PROPERTY_NAME}" "${pool}" 1>/dev/null 
2>/dev/null; then
-   return 1  # no such property
-   else
-   # has such property
-   zfs get -H -o value "${PROPERTY_NAME}" "${pool}"
-   fi
+# Detect the ${PROPERTY_NAME} property on a given pool
+# We are abusing user-defined properties on the root dataset,
+# since they're not available on pools 
https://github.com/openzfs/zfs/pull/11680
+pool=$1
+zfs get -H -o value "${PROPERTY_NAME}" "${pool}" 2>/dev/null || return 1
 }
 
 trim_if_not_already_trimming () {


signature.asc
Description: PGP signature

Bug#986280: ITP: libfdeep -- Header-only library for using Keras models in C++

[Filippo Rusconi]

Package: wnpp
Severity: wishlist
Owner: Filippo Rusconi 
X-Debbugs-Cc: debian-de...@lists.debian.org, lopi...@debian.org

* Package name: libfdeep
  Version : 0.15.2
  Upstream Author : Tobias Hermann (https://github.com/Dobiasd)
* URL : /https://github.com/Dobiasd
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: C++
  Description : Header-only library for using Keras models in C++.

 Would you like to build/train a model using Keras/Python? And would you like
 to run the prediction (forward pass) on your model in C++ without linking your
 application against TensorFlow? Then frugally-deep is exactly for you.
 . 
 frugally-deep:
 .
   - is a small header-only library written in modern and pure C++.  is very
 easy to integrate and use.

   - depends only on FunctionalPlus, Eigen and json - also header-only
 libraries.

   - supports inference (model.predict) not only for sequential models but also
 for computational graphs with a more complex topology, created with the
   functional API.

   - re-implements a (small) subset of TensorFlow, i.e., the operations needed
 to support prediction.

   - results in a much smaller binary size than linking against TensorFlow.

   - works out-of-the-box also when compiled into a 32-bit executable. (Of
 course, 64 bit is fine too.)

   - utterly ignores even the most powerful GPU in your system and uses only
 one CPU core per prediction.

   - but is quite fast on one CPU core compared to TensorFlow, and you can run
 multiple predictions in parallel, thus utilizing as many CPUs as you like
 to improve the overall prediction throughput of your application/pipeline.

This library is a dependency for the new version of the toppic package that I
maintain and that is part of the tools I use in my own lab research.

Sincerely,
Filippo

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org