Bug#988302: ITP: molotov -- create a bootable media from a Windows 10 iso image

[Andrei POPESCU]

Control: reassign -1 wnpp

On Lu, 10 mai 21, 01:15:21, Cézar wrote:
> Package: molotov
> Severity: wishlist
> 
> Molotov is a command-line program that aims to make it easy to create 
> bootable flash drives on a Linux machine from a Windows 10 iso image. 
> It is licensed under the GPL and the source package can be found here:
> 
> https://mentors.debian.net/package/molotov/
> 
> This package also comes with two manpages currently translated to 
> English and Portuguese and is extremely lightweight and by lightweight 
> I mean that this program only depends on other programs that are 
> already installed on most distributions, that is, the grub bootloader 
> and the tools required for partitioning flash drives. That's it.
> 
> However it's not all roses, Molotov depends on a Windows image to 
> work, it doesn't do anything by itself, the user is required to 
> download the image from the Microsoft's website and then use Molotov 
> for making the ISO bootable and that is why I recommend putting 
> Molotov in the **contrib** section of the Debian because it depends on 
> non-free software to work.
> 
> So that's about it, I intend to package this program and make it 
> available for all the users in Debian.

Reassigning to correct (pseudo-)package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#988304: exim4: rsyslog log files not getting any new info

[GSR]

Package: exim4
Version: 4.94.2-2
Severity: normal

After updating from 4.94.2-1 any info stopped appearing in rsyslog
(8.2102.0-2) files like /var/log/mail.log. Mail can be sent and
received, and /var/log/exim4/mainlog gets new lines. So it seems to be
something about talking with syslog.

Cheers,
GSR
 

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

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

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.76
ii  exim4-base 4.94.2-2
ii  exim4-daemon-light 4.94.2-2

exim4 recommends no packages.

exim4 suggests no packages.

Bug#988302: ITP: molotov -- create a bootable media from a Windows 10 iso image

[Cézar]

Package: molotov
Severity: wishlist

Molotov is a command-line program that aims to make it easy to create bootable 
flash drives on a Linux machine from a Windows 10 iso image. It is licensed 
under the GPL and the source package can be found here:

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

This package also comes with two manpages currently translated to English and 
Portuguese and is extremely lightweight and by lightweight I mean that this 
program only depends on other programs that are already installed on most 
distributions, that is, the grub bootloader and the tools required for 
partitioning flash drives. That's it.

However it's not all roses, Molotov depends on a Windows image to work, it 
doesn't do anything by itself, the user is required to download the image from 
the Microsoft's website and then use Molotov for making the ISO bootable and 
that is why I recommend putting Molotov in the **contrib** section of the 
Debian because it depends on non-free software to work.

So that's about it, I intend to package this program and make it available for 
all the users in Debian.

Bug#937234: pam-python: Python2 removal in sid/bullseye

[Mike Gabriel]

Hi,

On  Mo 10 Mai 2021 01:03:47 CEST, Russell Stuart wrote:


On 9/5/21 6:08 am, Mike Gabriel wrote:

Furthermore, I agree with Nik, that AGPL for a non-web project (as  
that's where AGPL really makes sense) is disputable and you don't

loose anything if you switch over to GPL-3+ instead of AGPL-3+.


That's correct.  It's just laziness on my part.  It's easier to copy &
paste the same licence into all my projects.  As the exception clause
illustrates I put some thought into choosing one that seemed to fit
best.  I guess I could add another exception that changes "prominent
notice" to something like "easily discoverable notice", if people have
an issue with the word prominent.

The reason I use the AGPL is it seems to me software as a service
reduces copyleft licences to something about of strong as MIT licences.
If I was happy with a MIT licence that is what I would have used, but
I'm not.


Hmmm... defaulting to AGPL with all your projects seems questionable.  
I personally prefer to consider the overall use case and target  
audience of a software project and then choose wisely out of the pool  
of licenses available. Copyleft preferred whereever possible. Amending  
original license texts with exception clauses sounds awkward. AFAIK,  
the exception clauses are not for changing the license content, but  
for mentioning code projects that are allowed to be combined with your  
software code, e.g. like the OpenSSL exception in GPL-2+/3+ license  
often seen around with code that is GPL, but links against OpenSSL  
(which is license with a GPL incompatible license afair, I forgot  
which one it was/is).


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp9jgDpiwK6R.pgp
Description: Digitale PGP-Signatur

Bug#986267: xfce4-appfinder: Application Finder doesn't show up xfce4's "Add New Items" window

[Ron Murray]

Never mind. I thought I'd point out a deficiency, but you seem to be
more interested in how I found it than the deficiency itself.


On Sun, 2021-04-18 at 18:32 +0200, Yves-Alexis Perez wrote:
> On Fri, 2021-04-02 at 00:57 -0400, Ron Murray wrote:
> > 
> >    I noticed "Application Finder" in a Debian Live build I'd made,
> > and
> > wondered why I'd never seen it on my normal Debian box. So I tried
> > to
> > add it with xfce4's "Add New Items" option, but it doesn't show up
> > there.
> > 
> Hi Ron,
> 
> sorry but it's unclear to me what you mean when you say “I noticed …”
> where
> exactly you noticed and what exactly you tried to do next. What is
> this “Add
> new items” menu you're talking about ? If it is the panel plugin
> menu, then
> there is no “application finder plugin”, but you should be able to
> add a
> launcher, and then use the application finder as the application to
> be
> launched.
> 
> Regards,

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761



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

Bug#988078: release-notes: add information regarding exim4 and 'tainted data' issue

[Justin B Rye]

Andreas Metzler wrote:
> The text has been slightly updated with one oof the latest uploads, it
> now reads

That's the last sentence changed.  We also need a title text; maybe

Exim 4.94

(The upstream "brand name" usually seems to be capitalised, whereas the
Debian (meta)package name is "exim4".)

> -
>   Please consider exim 4.93/4.94 a *major* exim upgrade. It introduces the

We don't really need to mention 4.93 here and below, and if we put
4.94 in the title we can just say "the version of Exim in bullseye"
everywhere else.

>   concept of tainted data read from untrusted sources, like e.g. message
>   sender or recipient. This tainted data (e.g. $local_part or $domain)
>   cannot be used among other things as a file or directory name or command
>   name.
> 
>   This WILL BREAK configurations which are not updated accordingly.
>   Old Debian exim configuration files also will not work unmodified, the new

(Pedantically, needs a semicolon or suchlike rather than a comma.)

>   configuration needs to be installed with local modifications merged in.
> 
>   Typical nonworking examples include:
>   * Delivery to /var/mail/$local_part. Use $local_part_data in combination
> with check_local_user.
>   * Using
> data = ${lookup{$local_part}lsearch{/some/path/$domain/aliases}}
> instead of
> data = ${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
> for a virtual domain alias file.
> 
>   The basic strategy for dealing with this change is to use the result of a
>   lookup in further processing instead of the original (remote provided)
>   value.

(Is it possible we could shorten this by pointing to some external
reference here?)

> 
>   To ease upgrading there is a new main configuration option to temporarily
>   downgrade taint errors to warnings, letting the old configuration work with
>   the newer exim. To make use of this feature add
>   .ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
>allow_insecure_tainted_data = yes
>   .endif
>   to the exim configuration (e.g. to /etc/exim4/exim4.conf.localmacros)
>   *before* upgrading to exim 4.93/4.94 and check the logfile for taint
>   warnings. This is a temporary workaround which is already marked for
>   removal on introduction.
> -

So if I'm getting this formatting right it would be:

  
Exim 4.94

  Please consider the version of Exim in bullseye a
  major Exim upgrade. It introduces the
  concept of tainted data read from untrusted sources, like e.g.
  message sender or recipient. This tainted data (e.g.
  $local_part or $domain)
  cannot be used among other things as a file or directory name or
  command name.
 

  This will break configurations which are not
  updated accordingly. Old Debian Exim configuration files also
  will not work unmodified; the new configuration needs to be
  installed with local modifications merged in.
 

  Typical nonworking examples include:


  

  Delivery to /var/mail/$local_part. Use
  $local_part_data in combination with
  check_local_user.

  
  

  Using


 data = ${lookup{$local_part}lsearch{/some/path/$domain/aliases}}


  instead of


 data = ${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}


  for a virtual domain alias file.

  


  The basic strategy for dealing with this change is to use the
  result of a lookup in further processing instead of the original
  (remote provided) value.


  To ease upgrading there is a new main configuration option to
  temporarily downgrade taint errors to warnings, letting the old
  configuration work with the newer Exim. To make use of this
  feature add
 
 
.ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
 allow_insecure_tainted_data = yes
.endif
 
 
  to the Exim configuration (e.g. to
  /etc/exim4/exim4.conf.localmacros)
  before upgrading and check the logfile for
  taint warnings. This is a temporary workaround which is already
  marked for removal on introduction.

  

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#976147: MariaDB upgrade issues from Debian 10 to Debian 11

[Otto Kekäläinen]

Thanks for running the debug commands. Would you like to also read and
analyze them and try to find out what is going on and thus what the
solution would be?

And maybe submit a Merge Request on what should be changed in the
debian/control file maybe?

In this message I describe how I tested a new debian/control file
without having to rebuild the whole package:
https://lists.debian.org/debian-devel/2021/03/msg00206.html


On Sun, May 9, 2021 at 1:30 AM Olaf van der Spek  wrote:
>
> Op zo 9 mei 2021 om 08:40 schreef Otto Kekäläinen :
> > Here is a debian-devel thread where I learnt new ways to run apt in
> > debug mode to better see why it chooses to upgrade/remove certain
> > packages, it might be helpful here too:
> > https://lists.debian.org/debian-devel/2021/03/msg00139.html
> > https://lists.debian.org/debian-devel/2021/03/msg00131.html
>
> # apt upgrade -o Debug::pkgDepCache::AutoInstall=1 -o
> Debug::pkgDepCache::Marker=1 -o Debug::pkgProblemResolver=1
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
>   MarkInstall mariadb-server:amd64 < 1:10.3.27-0+deb10u1 -> 1:10.5.9-1
> @ii umU Ib > FU=0
>   Installing mariadb-server-10.5:amd64 as Depends of mariadb-server:amd64
>  Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not an
> option for mariadb-server-10.5:amd64 (1:10.5.9-1)
>  Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not an
> option for mariadb-server-10.5:amd64 (1:10.5.9-1)
> MarkInstall mariadb-server-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > 
> FU=0
> Installing galera-4:amd64 as Depends of mariadb-server-10.5:amd64
>Delayed Removing: galera-3:amd64 as upgrade is not an option
> for galera-4:amd64 (26.4.7-3)
>Delayed Removing: galera-3:amd64 as upgrade is not an option
> for galera-4:amd64 (26.4.7-3)
>   MarkInstall galera-4:amd64 < none -> 26.4.7-3 @un uN Ib > FU=0
>   MarkDelete galera-3:amd64 < 25.3.31-2+b1 @ii mK Ib > FU=0
> Installing mariadb-client-10.5:amd64 as Depends of 
> mariadb-server-10.5:amd64
>Delayed Removing: mariadb-client-10.3:amd64 as upgrade is not
> an option for mariadb-client-10.5:amd64 (1:10.5.9-1)
>Delayed Removing: mariadb-client-10.3:amd64 as upgrade is not
> an option for mariadb-client-10.5:amd64 (1:10.5.9-1)
>Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade is
> not an option for mariadb-client-10.5:amd64 (1:10.5.9-1)
>   MarkInstall mariadb-client-10.5:amd64 < none -> 1:10.5.9-1 @un
> uN Ib > FU=0
>   Installing mariadb-client-core-10.5:amd64 as Depends of
> mariadb-client-10.5:amd64
>  Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade
> is not an option for mariadb-client-core-10.5:amd64 (1:10.5.9-1)
>  Delayed Removing: mariadb-client-core-10.3:amd64 as upgrade
> is not an option for mariadb-client-core-10.5:amd64 (1:10.5.9-1)
> MarkInstall mariadb-client-core-10.5:amd64 < none ->
> 1:10.5.9-1 @un uN Ib > FU=0
> MarkDelete mariadb-client-core-10.3:amd64 <
> 1:10.3.27-0+deb10u1 @ii mK Ib > FU=0
>   MarkDelete mariadb-client-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii
> mK Ib > FU=0
> Installing mariadb-server-core-10.5:amd64 as Depends of
> mariadb-server-10.5:amd64
>Delayed Removing: mariadb-server-core-10.3:amd64 as upgrade is
> not an option for mariadb-server-core-10.5:amd64 (1:10.5.9-1)
>Delayed Removing: mariadb-server-10.3:amd64 as upgrade is not
> an option for mariadb-server-core-10.5:amd64 (1:10.5.9-1)
>Delayed Removing: mariadb-server-core-10.3:amd64 as upgrade is
> not an option for mariadb-server-core-10.5:amd64 (1:10.5.9-1)
>   MarkInstall mariadb-server-core-10.5:amd64 < none -> 1:10.5.9-1
> @un uN Ib > FU=0
>   MarkDelete mariadb-server-core-10.3:amd64 < 1:10.3.27-0+deb10u1
> @ii mK Ib > FU=0
>   MarkDelete mariadb-server-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii
> mK Ib > FU=0
>   MarkKeep galera-3:amd64 < 25.3.31-2+b1 @ii mR > FU=0
>   MarkKeep mariadb-server-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mR > FU=0
>   MarkKeep mariadb-client-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mR > FU=0
>   MarkKeep mariadb-server-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mR > FU=0
>   MarkKeep mariadb-client-core-10.3:amd64 < 1:10.3.27-0+deb10u1 @ii mR > FU=0
> Entering ResolveByKeep
>   Dependencies are not satisfied for galera-4:amd64 < none -> 26.4.7-3
> @un uN Ib >
> Keeping package galera-4:amd64
>   MarkKeep galera-4:amd64 < none -> 26.4.7-3 @un uN Ib > FU=0
>   Dependencies are not satisfied for mariadb-client-core-10.5:amd64 <
> none -> 1:10.5.9-1 @un uN Ib >
> Keeping package mariadb-client-core-10.5:amd64
>   MarkKeep mariadb-client-core-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > 
> FU=0
>   Dependencies are not satisfied for mariadb-client-10.5:amd64 < none
> -> 1:10.5.9-1 @un uN Ib >
> Keeping package mariadb-client-10.5:amd64
>   MarkKeep mariadb-client-10.5:amd64 < none -> 1:10.5.9-1 @un uN Ib > FU=0
>   

Bug#987643: ne10 FTBFS with gcc 10

[Wookey]

Wookey wrote::

> Testing it now.

Nope, that doesn't actually fix the problem, although it appears to
have reduced the number of instances of complaint (that may just be an artifact 
of parallel=1)

Not totally clear what's going on here (the function and prototype
seems to match to me). I'll have to have a proper look yet. Does it think they 
are both definitions?

seatest.h:
void (*seatest_simple_test_result)(int passed, char* reason, const char* 
function, unsigned int line);

seatest.c:
void (*seatest_simple_test_result)(int passed, char* reason, const char* 
function, unsigned int line) = seatest_simple_test_result_log;

void seatest_simple_test_result_log(int passed, char* reason, const char* 
function, unsigned int line)
{
  ...
}

[ 86%] Linking CXX executable NE10_imgproc_unit_test_smoke
cd /home/wookey/packages/ne10/ne10-1.2.1/obj-aarch64-linux-gnu/test && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/NE10_imgp\
roc_unit_test_static.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/home/wookey/packages/ne10/ne10-1.2.1=. 
-fstack-protector-strong -Wformat -Werror=format-\
security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -O2 -DNDEBUG 
-Wl,-z,relro -rdynamic CMakeFiles/NE10_imgproc_unit_\
test_static.dir/__/modules/imgproc/test/test_main.c.o 
CMakeFiles/NE10_imgproc_unit_test_static.dir/__/modules/imgproc/test/test\
_suite_resize.c.o 
CMakeFiles/NE10_imgproc_unit_test_static.dir/__/modules/imgproc/test/test_suite_rotate.c.o
 CMakeFiles/NE10_im\
gproc_unit_test_static.dir/__/modules/imgproc/test/test_suite_boxfilter.c.o 
CMakeFiles/NE10_imgproc_unit_test_static.dir/src/se\
atest.c.o CMakeFiles/NE10_imgproc_unit_test_static.dir/src/unit_test_common.c.o 
CMakeFiles/NE10_imgproc_unit_test_static.dir/sr\
c/NE10_random.c.o -o NE10_imgproc_unit_test_smoke  ../modules/libNE10.a -lm 
-lrt -lstdc++
/usr/bin/ld: 
CMakeFiles/NE10_imgproc_unit_test_static.dir/__/modules/imgproc/test/test_suite_resize.c.o:./obj-aarch64-linux-gnu\
/test/./test/include/seatest.h:23: multiple definition of 
`seatest_simple_test_result'; CMakeFiles/NE10_imgproc_unit_test_stati\
c.dir/__/modules/imgproc/test/test_main.c.o:./obj-aarch64-linux-gnu/test/./test/include/seatest.h:23:
 first defined here
/usr/bin/ld: 
CMakeFiles/NE10_imgproc_unit_test_static.dir/__/modules/imgproc/test/test_suite_rotate.c.o:./obj-aarch64-linux-gnu\
/test/./test/include/seatest.h:23: multiple definition of 
`seatest_simple_test_result'; CMakeFiles/NE10_imgproc_unit_test_stati\
c.dir/__/modules/imgproc/test/test_main.c.o:./obj-aarch64-linux-gnu/test/./test/include/seatest.h:23:
 first defined here
/usr/bin/ld: 
CMakeFiles/NE10_imgproc_unit_test_static.dir/__/modules/imgproc/test/test_suite_boxfilter.c.o:./obj-aarch64-linux-\
gnu/test/./test/include/seatest.h:23: multiple definition of 
`seatest_simple_test_result'; CMakeFiles/NE10_imgproc_unit_test_st\
atic.dir/__/modules/imgproc/test/test_main.c.o:./obj-aarch64-linux-gnu/test/./test/include/seatest.h:23:
 first defined here
/usr/bin/ld: 
CMakeFiles/NE10_imgproc_unit_test_static.dir/src/seatest.c.o:./obj-aarch64-linux-gnu/test/./test/include/seatest.h\
:23: multiple definition of `seatest_simple_test_result'; 
CMakeFiles/NE10_imgproc_unit_test_static.dir/__/modules/imgproc/test/\
test_main.c.o:./obj-aarch64-linux-gnu/test/./test/include/seatest.h:23: first 
defined here
collect2: error: ld returned 1 exit status
make[3]: *** [test/CMakeFiles/NE10_imgproc_unit_test_static.dir/build.make:197: 
test/NE10_imgproc_unit_test_smoke] Error 1
make[3]: Leaving directory 
'/home/wookey/packages/ne10/ne10-1.2.1/obj-aarch64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:281: 
test/CMakeFiles/NE10_imgproc_unit_test_static.dir/all] Error 2
make[2]: Leaving directory 
'/home/wookey/packages/ne10/ne10-1.2.1/obj-aarch64-linux-gnu'
make[1]: *** [Makefile:152: all] Error 2
make[1]: Leaving directory 
'/home/wookey/packages/ne10/ne10-1.2.1/obj-aarch64-linux-gnu'
dh_auto_build: error: cd obj-aarch64-linux-gnu && make -j1 VERBOSE=1 returned 
exit code 2
make: *** [debian/rules:17: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


There are also some complaints about printf format types too which should 
probably be fixed..
home/wookey/packages/ne10/ne10-1.2.1/modules/imgproc/test/test_suite_boxfilter.c:163:41:
 warning: format '%d' expects argument\
 of type 'int', but argument 2 has type 'long unsigned int' [-Wformat=]
  163 | printf ("**ERROR**: allocating %d bytes memory for kernels 
fails!\n",
  |~^
  | |
  | int
  |%ld
  164 | sizeof (ne10_size_t) * (*size));
  | ~~
  |  |
  |  long unsigned int


Wookey
-- 
Principal hats:  

Bug#988256: Acknowledgement (RM: mariadb-10.3/experimental -- RoM; obsoleted by mariadb-10.5)

[Otto Kekäläinen]

Actually package was removed from experimental in
https://tracker.debian.org/news/1226586/removed-110327-1exp1-from-experimental/

Closed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975548 now.

I am still a bit confused on why mariadb-10.1 and mariadb-10.3 show up
in the security tracker for Debian unstable. Please advice.

Bug#988303: RFP: firefox-decrypt -- A tool to extract passwords from profiles of Mozilla (Fire/Water)fox, Thunderbird, SeaMonkey and derivates

[Paul Wise]

On Mon, 10 May 2021 03:37:30 +0200 Christoph Anton Mitterer wrote:

> * Package name: firefox-decrypt
>   Description : A tool to extract passwords from profiles of Mozilla 
> (Fire/Water)fox, Thunderbird, SeaMonkey and derivates

For a package already in Debian that can do this, see nss-passwords.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#898109: fixed in openbsc 1.4.0+dfsg1-1

[Logan Rosen]

On Sun, May 9, 2021 at 9:53 PM Logan Rosen  wrote:
> This does not appear to be the case. I synced this version into Ubuntu just 
> now, and the package failed to build on both s390x and ppc64el with -O3 due 
> to potential null pointer dereference errors. [1]

Sorry, to clarify, the ppc64el build was with -O3, and the s390x build
was with -O2. They both failed.

Bug#898109: fixed in openbsc 1.4.0+dfsg1-1

[Logan Rosen]

control: reopen -1

Hi,

On Thu, 07 Jan 2021 10:49:18 + Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:
> Source: openbsc
> Source-Version: 1.4.0+dfsg1-1
> Done: Thorsten Alteholz 
>
> We believe that the bug you reported is fixed in the latest version of
> openbsc, which is due to be installed in the Debian FTP archive.

This does not appear to be the case. I synced this version into Ubuntu just
now, and the package failed to build on both s390x and ppc64el with -O3 due
to potential null pointer dereference errors. [1]

Thanks,
Logan

[1] https://launchpad.net/ubuntu/+source/openbsc/1.4.0+dfsg1-1

Bug#988303: RFP: firefox-decrypt -- A tool to extract passwords from profiles of Mozilla (Fire/Water)fox, Thunderbird, SeaMonkey and derivates

[Christoph Anton Mitterer]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+pkg-mozi...@tracker.debian.org

* Package name: firefox-decrypt
  Version : 1.0.0-rc1
  Upstream Author : Renato Alves
* URL : https://github.com/unode/firefox_decrypt
* License : GPL 3+
  Programming Lang: Python
  Description : A tool to extract passwords from profiles of Mozilla 
(Fire/Water)fox, Thunderbird, SeaMonkey and derivates

CC'in Firefox maintainers in case they have interest or want to comment.


Firefox Decrypt is a tool to extract passwords from profiles of Mozilla
(Fire/Water)fox™, Thunderbird®, SeaMonkey® and derivates.

It can be used to recover passwords from a profile protected by a Master
Password as long as the latter is known. If a profile is not protected by
a Master Password, passwords are displayed without prompt.

This tool does not try to crack or brute-force the Master Password in any
way. If the Master Password is not known it will simply fail to recover
any data.

Bug#792580: LMH

[Fernando Castillo Valdebenito (Alumno)]

Good morning, I am emailing to enquire about my previous email, did you receive 
it?

Bug#988301: exim :include: not working after jessie

[Josip Rodin]

Package: exim4
Version: 4.89-2+deb9u8

Hi,

After an upgrade to stretch, and likewise buster, the :include:
functionality of the redirect router seems to be broken.

I have include_directory set to /etc/exim4, and a subdirectory with
files containing alias content, an an aliases file containing e.g.:

priprema: :include:/etc/exim4/dynaliases/priprema

This worked perfectly up to jessie, but after the upgrade, deliveries
started choking with messages like:

R=aliases defer (-17): error in redirect data: failed to open
/etc/exim4/dynaliases/priprema (component of included file); could
be symbolic link

strace shows:

openat(AT_FDCWD, "/etc/exim4/dynaliases", O_RDONLY|O_LARGEFILE) = 7
openat(7, "/priprema", O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = -1 ENOENT (No such 
file or directory)

Obviously it's supposed to continue to find the file in that directory,
because the file hasn't been touched...

Am I missing something here?

A diff between 4.84 and 4.89 sources shows that this code was changed
inbetween, with a block of new code using EXIM_HAVE_OPENAT replacing
the old logic...?

Please fix it. TIA.

-- 
Josip Rodin

Bug#987244: RFS: nbsdgames/4.0-1 [ITP] -- text based mini games for your terminal

[Hossein Bakhtiari]

On Sun, 25 Apr 2021 21:17:44 -0400 The Wanderer  wrote:
> On 2021-04-25 at 20:45, Phil Morrell wrote:
> > Given all this, I suggest you adopt a universal prefix for all the
> > games, perhaps "nb-"? On the other hand, it might be worth
> > preserving tab completion with a suffix instead, in which case no
> > harm with a full "-nbsdgames".
> 
> I was going to suggest a 'nbsd-' prefix, for reasons of consistency with
> the collection name, but if 'nb-' is considered acceptable it would at
> least have the advantage of being faster and easier to type.

I suggest using the prefix 'nb' (without the -). 

This prefix is shorter, more shift-efficient and already used in the Arch 
package. Also you can type 'nb' and press tab and see all the games.

Bug#988300: linux-kbuild-5.10: can not build nvidia-kernel-340xx-dkms

[Hans-J. Ullrich]

Package: linux-kbuild-5.10
Version: 5.10.28-1
Severity: important

Dear Maintainer,

I am not quite sure, but I believe, there is a problem with either 
linux-kbuild-5.10 or the nvidia-kernel-340xx-dkms.

The problem is, that the build of the kernel module stops and the make.log says 
the following:

--- snip ---

make[3]: Verzeichnis „/usr/src/linux-headers-5.10.0-6-amd64“ wird betreten
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are 
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix 
it.";  \
echo >&2 ;  \
/bin/false)
make -f /usr/src/linux-headers-5.10.0-6-common/scripts/Makefile.build obj=.. \
single-build= \
need-builtin=1 need-modorder=1
/usr/src/linux-headers-5.10.0-6-common/scripts/Makefile.build:44: 
/usr/src/linux-headers-5.10.0-6-common/../Makefile: Datei oder Verzeichnis 
nicht gefunden
make[4]: *** Keine Regel, um 
„/usr/src/linux-headers-5.10.0-6-common/../Makefile“ zu erstellen.  Schluss.
make[3]: *** [/usr/src/linux-headers-5.10.0-6-common/Makefile:1822: ..] Fehler 2
make[3]: Verzeichnis „/usr/src/linux-headers-5.10.0-6-amd64“ wird verlassen
make[2]: *** [Makefile:185: __sub-make] Fehler 2
make[2]: Verzeichnis „/usr/src/linux-headers-5.10.0-6-common“ wird verlassen
make[1]: *** [Makefile:205: nvidia.ko] Fehler 2
make[1]: Verzeichnis „/var/lib/dkms/nvidia-legacy-340xx/340.108/build“ wird 
verlassen
make: *** [Makefile:221: ../Module.symvers] Fehler 2
make: Verzeichnis „/var/lib/dkms/nvidia-legacy-340xx/340.108/build/uvm“ wird 
verlassen
  
1124,1  
--- snap 

This issue happened, when I deinstalled and reinstalled all the nvidia-packages.

Please note: It was possible before to build the nvidia-module for a 
5.10-version, but this was a prior version before 5.10.0-6-amd64 (maybe 
5.10.0-4-amd64 or similar).

On kernel version 4.19.0-16-amd64 the module can be build, but this is another 
linux-kbuild-version!

Thus and because of the make.log I believe, linux-kbuild-5.10 might be buggy.

Thank you for reading this and any help.

Best regards

Hans
 

 





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

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

Versions of packages linux-kbuild-5.10 depends on:
ii  libc6  2.31-11
ii  libelf10.183-1
ii  libssl1.1  1.1.1k-1

linux-kbuild-5.10 recommends no packages.

linux-kbuild-5.10 suggests no packages.

-- debconf-show failed

Bug#988298: ITP: fidi -- (φίδι) service mock system for testing infrastructure

[Nicholas D Steeves]

Hi Manoj,

Manoj Srivastava  writes:

> Package: wnpp
> Owner: Manoj Srivastava 
> Severity: wishlist
>
> * Package name: fidi
>   Version : 1.0.1
>   Upstream Author : Manoj Srivastava 
> * URL or Web page : https://github.com/google/fidi
> * License : Apache-2.0
>   Description : (φίδι) service mock system for testing infrastructure
>
>  The goal of φίδι (fidi) is to model some aspects of arbitrarily
>  complex services, and simulate the behaviour of the service business
>  logic (without actually containing any real business logic or
>  complexity) in presence of external stimuli. Each instance of the
>  φίδι (fidi) application can mock a node in the complex, client
>  serfver service that it is mocking. Different instances of φίδι
>  (fidi) talk to other instanceds of themselves, like a snake (φίδι)
>  eating its tail.
>
>  φίδι (fidi) also simulates fault injection symptoms, which allows the
>  simulation of normal behaviour as well as incidents and recovery. The
>  motivation is to test the behaviour of the infrastructure,
>  monitoring, alerting and logging systems, while mocking an actual
>  service.
>

This seems like useful software :-)  Would you please consider noting in
the long description what language the word φίδι is from?  I'm guessing
other people will be curious.  Is it Greek, by the way?  Feel free to
disregard this message if the intent is to force people to manually look
up the word online ;-)

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#978656: RFA: zenburn-emacs -- low contrast color theme for Emacs

[Raúl Benencia]

Hello Sean, :-)

On Sun, May 09, 2021 at 01:46:29PM -0700, Sean Whitton wrote:
> Thanks for taking it over!  I've granted salsa access but would prefer
> to sponsor a few more Emacs-related uploads by you before granting DM.

Thanks so much for your prompt upload, and for granting me access to
the team! Much appreciated.

Also, thanks for mentioning that you would prefer to sponsor a few
more uploads first before granting me DM permissions. I understand
that and, if you don't mind, I'll CC you on future Emacs-related
contributions that requires sponsoring.

Best,
--
Raúl Benencia


signature.asc
Description: PGP signature

Bug#988299: shim-signed: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: shim-signed
Version: 1.34~1+deb10u1+15.4-2~deb10u1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  buster -> buster-proposed-updates

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


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

0m27.4s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/shim-signed/NEWS.Debian.gz (shim-signed:amd64) != 
/usr/share/doc/shim-signed-common/NEWS.Debian.gz (?)
/usr/share/doc/shim-signed -> shim-signed-common
  /usr/share/doc/shim-signed/changelog.gz (shim-signed:amd64) != 
/usr/share/doc/shim-signed-common/changelog.gz (shim-signed-common)
/usr/share/doc/shim-signed -> shim-signed-common
  /usr/share/doc/shim-signed/copyright (shim-signed:amd64) != 
/usr/share/doc/shim-signed-common/copyright (shim-signed-common)
/usr/share/doc/shim-signed -> shim-signed-common


cheers,

Andreas


shim-signed_1.34~1+deb10u1+15.4-2~deb10u1.log.gz
Description: application/gzip

Bug#937234: pam-python: Python2 removal in sid/bullseye

[Russell Stuart]

On 9/5/21 6:08 am, Mike Gabriel wrote:


That is not the point. E.g., if we spot a security issue with a
package, maybe you as the maintainer / upstream developer (afaik, you
are upstream and downstream for pam-python, Russel, right?) but also
maybe someone in the security team (or any other third person) might
apply a fix to the package and do an e.g. stable-security upload.


Yes, OK.  I hadn't thought of that perspective.  So far pam-python's
one security release was done by myself, and it was done upstream 
beforehand.


No, see my previous mail for more details. Debian offers a very 
standardized way of obtaining the exact source code that the 
libpam-python bin:pkg has been built from. Period. Done. License 
compliance accomplished.


It's pretty clear Debian does an exemplary job of source distribution.
It was just the "prominent notice" bit.

Commercial products (eg, the phones), in some ways do this better(!)
than Debian does.  They collect them all in an About page, which is easy
to find.  If the commercial products added a "and you can download the
source from here..." link, it would be job done for the AGPL.

Debian does a much better job of all the hard parts: collecting those
licences, organising them into a database and ensuring they always
present on the machine, providing working downloads links - but making
it all findable by a normal GUI user - not so good.  It needs an easily
findable GUI clicky thingy that displays them.  Having that would put 
the "AGPL prominent notice" requirement to bed for good.


Even just adding a copyright and download pages to Synaptic might
suffice.  For a CLI user a "apt-get licence" would do the job.

Furthermore, I agree with Nik, that AGPL for a non-web project (as 
that's where AGPL really makes sense) is disputable and you don't

loose anything if you switch over to GPL-3+ instead of AGPL-3+.


That's correct.  It's just laziness on my part.  It's easier to copy &
paste the same licence into all my projects.  As the exception clause
illustrates I put some thought into choosing one that seemed to fit
best.  I guess I could add another exception that changes "prominent
notice" to something like "easily discoverable notice", if people have
an issue with the word prominent.

The reason I use the AGPL is it seems to me software as a service
reduces copyleft licences to something about of strong as MIT licences.
If I was happy with a MIT licence that is what I would have used, but
I'm not.

Bug#988298: ITP: fidi -- (φίδι) service mock system for testing infrastructure

[Manoj Srivastava]

Package: wnpp
Owner: Manoj Srivastava 
Severity: wishlist

* Package name: fidi
  Version : 1.0.1
  Upstream Author : Manoj Srivastava 
* URL or Web page : https://github.com/google/fidi
* License : Apache-2.0
  Description : (φίδι) service mock system for testing infrastructure

 The goal of φίδι (fidi) is to model some aspects of arbitrarily
 complex services, and simulate the behaviour of the service business
 logic (without actually containing any real business logic or
 complexity) in presence of external stimuli. Each instance of the
 φίδι (fidi) application can mock a node in the complex, client
 serfver service that it is mocking. Different instances of φίδι
 (fidi) talk to other instanceds of themselves, like a snake (φίδι)
 eating its tail.

 φίδι (fidi) also simulates fault injection symptoms, which allows the
 simulation of normal behaviour as well as incidents and recovery. The
 motivation is to test the behaviour of the infrastructure,
 monitoring, alerting and logging systems, while mocking an actual
 service.

Manoj
-- 
Win95 is not a virus; a virus does something.  -- unknown source
Manoj Srivastava  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

Bug#795013: Closing this bug (BTS maintenance for src:linux bugs)

[A. M.]

reopen 795013
thanks

# Dear Salvatore:
# I have not said anything for a long time, but not because the bug
# didn't occur, but because I didn't know what to do when the startup
# failed the described way, and because the failure was infrequent.  I
# always simply restarted the laptop.  The machine always runs the
# current Debian stable, whichever it may be.  The call stacks have
# already been given in the bug report if it helps.  I would kindly ask
# you to tell me how/what to debug next.
# Alex

Bug#988297: README.Debian contains instructions that result in RC bugs in other packages

[Nicholas D Steeves]

Source: zenburn-emacs
Version: 2.6-3
Severity: important

README.Debian contains the obsolete and now harmful requirement to run
(package-initialize) in init.el.  Package-initialize is now executed
automatically in between early-init.el and init.el, and continuing to
call it from init.el (or one of the many alternative '~/.emacs'
locations) results in RC bugs like #987683 (see bug for discussion
about the bug type).  This bug in zenburn-emacs docs is arguably
release critical.

On the upside, if it's RC then ftpmasters may approve an unblock :-)

And on the topic of unblocks, I see that zenburn-emacs doesn't have
autopkgtests, which are an automatic migration requirement.  As this
package does not appear to contain tests of any kind, it may be
advantageous to Raúl if this bug was RC, because an RC bug that
justifies an unblock will allow his work to be included in Bullseye.

I'm also wondering if src:emacs should also do something like provide
a NEWS file and/or check user config for 'package-initialize' and warn
in the modeline.

Cheers,
Nicholas

Bug#988296: [pre-approval] unblock: linbox/1.6.3-3

[Doug Torrance]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: dtorra...@piedmont.edu, debian-scie...@lists.debian.org, 
987...@bugs.debian.org

Please unblock package linbox

[ Reason ]
linbox is scheduled to be removed from testing on June 15 due to RC bug 
#987921.  The package FTBFS on i386 when compiling with gcc 10 due to an 
ambiguous overload error.  A fix has been proposed upstream 
(https://github.com/linbox-team/linbox/pull/274) and a patch has been written 
for the Debian package 
(https://salsa.debian.org/science-team/linbox/-/commit/f630fb1).  It should 
arrive in unstable soon, pending review and sponsorship.

[ Impact ]
The change between the version of the package currently in testing and the 
proposed version is minimal (one patch affecting two lines of code) and also 
prevents FTBFS on i386.

[ Tests ]
The affected code is covered in test-qlub from the upstream test suite, which 
is run during build.

[ Risks ]
Minimal risk -- patch is trivial.

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

[ Other info ]
Thank you!

unblock linbox/1.6.3-3
diff -Nru linbox-1.6.3/debian/changelog linbox-1.6.3/debian/changelog
--- linbox-1.6.3/debian/changelog   2020-02-01 15:09:26.0 -0500
+++ linbox-1.6.3/debian/changelog   2021-05-09 12:28:04.0 -0400
@@ -1,3 +1,11 @@
+linbox (1.6.3-3) unstable; urgency=medium
+
+  * debian/patches/iterator-difference-type.patch
+- New patch; use std::ptrdiff_t for vector iterator difference
+  type (Closes: #987921).
+
+ -- Doug Torrance   Sun, 09 May 2021 12:28:04 -0400
+
 linbox (1.6.3-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru linbox-1.6.3/debian/patches/iterator-difference-type.patch 
linbox-1.6.3/debian/patches/iterator-difference-type.patch
--- linbox-1.6.3/debian/patches/iterator-difference-type.patch  1969-12-31 
19:00:00.0 -0500
+++ linbox-1.6.3/debian/patches/iterator-difference-type.patch  2021-05-09 
12:26:48.0 -0400
@@ -0,0 +1,27 @@
+Description: Use std::ptrdiff_t for vector iterator difference type
+Bug: https://github.com/linbox-team/linbox/issues/273
+Bug-Debian: https://bugs.debian.org/987921
+Origin: https://github.com/linbox-team/linbox/pull/274
+Author: Doug Torrance 
+Last-Update: 2021-05-09
+
+--- a/linbox/vector/bit-vector.inl
 b/linbox/vector/bit-vector.inl
+@@ -46,7 +46,7 @@
+   typedef LinBox::BitVector::reference reference;
+   typedef bool *pointer;
+   typedef bool value_type;
+-  typedef long difference_type;
++  typedef std::ptrdiff_t difference_type;
+   };
+ 
+   template <>
+@@ -56,7 +56,7 @@
+   typedef LinBox::BitVector::const_reference reference;
+   typedef const bool *pointer;
+   typedef bool value_type;
+-  typedef long difference_type;
++  typedef std::ptrdiff_t difference_type;
+   };
+ }
+ 
diff -Nru linbox-1.6.3/debian/patches/series linbox-1.6.3/debian/patches/series
--- linbox-1.6.3/debian/patches/series  2020-02-01 15:06:40.0 -0500
+++ linbox-1.6.3/debian/patches/series  2021-05-09 12:24:55.0 -0400
@@ -4,3 +4,4 @@
 fix-RR-RecCounter.patch
 pkgconfig.patch
 replace-dangerous-pointer-casts-with-memcpy.patch
+iterator-difference-type.patch

Bug#987968: Acknowledgement (flash-kernel: Tinkered a new DTB to make my version of Olimex A64-Olinuxino-eMMC boot)

[Régis Etourmy]

Hello,

Finally, I have only commented out a single line 

vcc-pb-supply = <_dcdc1>;

from the file sun50i-a64-olinuxino.dts (which is included in the file
sun50i-a64-olinuxino-emmc.dts), to be able to get  a DTB that allows 
the system to boot on my 1Ge16GW version of the A64-Olinuxino-eMMC
card.


 Message initial 
De: Debian Bug Tracking System 
Répondre à: 987...@bugs.debian.org
À: Regis Etourmy 
Objet: Bug#987968: Acknowledgement (flash-kernel: Tinkered a new DTB to
make my version of Olimex A64-Olinuxino-eMMC boot)
Date: Sun, 02 May 2021 22:57:03 +

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 987968:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987968.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Install System Team 

If you wish to submit further information on this problem, please
send it to 987...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#785419: Bug#855203: hwclock-set: Synchronize from hwclock despite systemd presence

[Rick Thomas]

On Sat, May 8, 2021, at 12:02 PM, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> Ist this still an issue or has been fixed in meanwhile? I'm going
> through some older src:linux associated buts and noticed that it was
> considered here to reassign it to util-linux.
> 
> Is the problem still present?
> 
> Further:
> 
> On Fri, Mar 17, 2017 at 07:55:31PM +0100, Lukas Wunner wrote:
> [...]
> > @Rick Thomas: Could you verify if the attached patch solves this issue
> > for you?
> 
> Were you able to test the proposed patch?
> 
> Regards,
> Salvatore

Thanks for following up on this!

No, I got side-tracked by a family medical issue (now all resolved and OK) and 
never was able to test the patches.  Sorry!

Nevertheless, I can verify that the problem _is_ still with us.  I'm running

rbthomas@cube:~$ uname -a
Linux cube 4.19.0-16-armmp #1 SMP Debian 4.19.181-1 (2021-03-19) armv7l 
GNU/Linux
rbthomas@cube:~$ cat /etc/debian_version 
10.9

on a Cubox-i4Pro.   It still shows as having two RealTime clocks.  The one 
named /dev/rtc0 still looses it's time when I unplug/replug the device, while 
/dev/rtc1 still does manage to carry-over.  Unfortunately, the kernel still 
uses rtc0 to set system time when rebooting.

The workaround I use (such as it is) is to run ntpsec with the "-g" option, 
which allows the first system clock adjustment to be more than 1000 seconds. ( 
I also have to remember to reset rtc0 after a power outage.)

Along the same lines, I recently got a Raspberry Pi4B 4GB, and was somewhat 
surprised to find that it did not have a RT clock at all unless you buy an 
add-on hat for it.  So we not only have to deal with devices with two RT 
clocks, but also devices with zero RT clocks.

I'm not much of a software developer, so if you want me to test something, 
please provide it in the form of a ".deb" that I can install,  rather than a 
set of patches I have to apply.

Thanks!
Rick

Bug#931003: Fixing rust package FTBFS in buster

[peter green]

On 08/05/2021 17:36, Adrian Bunk wrote:

On Wed, May 05, 2021 at 08:01:13AM +0100, peter green wrote:

On 04/05/2021 12:28, Santiago Vila wrote:

On Tue, May 04, 2021 at 11:48:09AM +0100, peter green wrote:

This was automatically closed by ftpmaster because the package was
removed from unstable, but this still does not fix the FTBFS problem
in stable.


Unfortunately I don't think a proper fix will be forthcoming, upstream
has abandoned the crate in question.


It does not need to be a perfect fix. It is enough that dpkg-buildpackage
exits with status 0. If the tests are no longer valid, disabling them
should be much better than nothing, because packages in stable must
build in stable.


I'm prepared prepare such uploads if the stable release managers
are prepared to accept them.


Usually they are receptive for reasonable FTBFS fixes,
and my rust-rustyline bug was part of me doing a find+fix round.


...
rust-simd: abandoned upstream, not in testing/unstable probably not properly 
fixible, could disable test build during package build to fix FTBFS.
rust-coresimd: abandoned upstream, not in testing/unstable probably not 
properly fixible, could disable test build during package build to fix FTBFS.
rust-nodrop-union: abandoned upstream, not in testing, broken in unstable 
probably not properly fixible, could disable test build during package build to 
fix FTBFS.


Is it only the test that is broken?
Or is the test due to some minor functionality breakage?
In that case, ignoring test problems would be the correct action.

But if the packages are just completely broken with current rustc,
then RM bugs against release.debian.org asking for removal in the
next buster point release would be the correct action for such
leaf packages.


As best I can tell they are just completely broken with current rustc.

They are not leaf packages (though naive search tools may
think they are because most dependencies between rust packages
go via virtual packages).

The reverse dependency graphs look like

librust-simd-dev -> librust-encoding-rs+simd-accel-dev, 
librust-encoding-rs+simd-dev
librust-coresimd-dev -> librust-packed-simd+coresimd-dev
librust-nodrop-union-dev -> librust-nodrop+nodrop-union-dev, 
librust-nodrop+use-union-dev

So before rust-simd, rust-coresimd and rust-nodrop-union could
be dropped it would be nessacery to modify rust-encoding-rs, rust-packed-simd
and rust-nodrop to drop the binary packages that depend on them.

I'm quite prepared to do this if there is consensus to do so
but I'm not going to make unilateral moves here.

Bug#987921: [RFS] Re: Bug#987921: linbox FTBFS on 32bit with gcc 10

[Anton Gladky]

Hi Doug,

I will review/upload the package tomorrow,
Please file a pre-approval request against release.debian.org. Thanks

Regards

Anton


Am So., 9. Mai 2021 um 22:48 Uhr schrieb Torrance, Douglas <
dtorra...@piedmont.edu>:

> Control: tags -1 pending
>
> On Sun 02 May 2021 12:46:50 AM EDT, Adrian Bunk wrote:
> > Source: linbox
> > Version: 1.6.3-2
> > Severity: serious
> > Tags: ftbfs
> >
> >
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/i386/linbox.html
>
> I've fixed this RC bug in git:
> https://salsa.debian.org/science-team/linbox
>
> Would anyone be willing to review/sponsor?  I'm hoping that linbox won't
> get removed before the bullseye release.
>
> Thanks!
> Doug
>

Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script

[Kurt Fitzner]

If you're not convinced try to...


You are correct.  It is indeed very difficult to get the client to even 
use TCP/IP on a local machine any more, which I could only do by setting 
the host to 127.0.0.1.  The word "localhost" now seems to exclusively 
mean unix socket for mysql.


Thank-you, that not only turns this into a non-bug, but it means I can 
relax a bit on my configurations for mysql/mariadb in the future and not 
worry about ensuring they are explicitly set to unix sockets across the 
board.

Bug#978656: RFA: zenburn-emacs -- low contrast color theme for Emacs

[Sean Whitton]

Hello,

On Sun 09 May 2021 at 10:39AM -07, Raúl Benencia wrote:

> Hello Sean,
>
> On Tue, Dec 29, 2020 at 12:38:10PM -0700, Sean Whitton wrote:
>> I request an adoptor for the zenburn-emacs package, which I haven't used
>> for some months now.
>
> I've prepared[0] a merge request with the newest version of
> zenburn-emacs. Will you be willing to sponsor it?
>
>   [0] https://salsa.debian.org/emacsen-team/zenburn-emacs/-/merge_requests/1
>
> Additionally, it would ease my future uploads if I get added into the
> Debian Maintainer ACL for this package, and also if I'm given
> Maintainer permissions on the current Emacsen-owned git repository, as
> I'm planning on keeping it team-maintained.

Thanks for taking it over!  I've granted salsa access but would prefer
to sponsor a few more Emacs-related uploads by you before granting DM.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#978656: RFA: zenburn-emacs -- low contrast color theme for Emacs

[Sean Whitton]

Hello,

On Sun 09 May 2021 at 01:46PM -07, Sean Whitton wrote:

> Hello,
>
> On Sun 09 May 2021 at 10:39AM -07, Raúl Benencia wrote:
>
>> Hello Sean,
>>
>> On Tue, Dec 29, 2020 at 12:38:10PM -0700, Sean Whitton wrote:
>>> I request an adoptor for the zenburn-emacs package, which I haven't used
>>> for some months now.
>>
>> I've prepared[0] a merge request with the newest version of
>> zenburn-emacs. Will you be willing to sponsor it?
>>
>>   [0] https://salsa.debian.org/emacsen-team/zenburn-emacs/-/merge_requests/1
>>
>> Additionally, it would ease my future uploads if I get added into the
>> Debian Maintainer ACL for this package, and also if I'm given
>> Maintainer permissions on the current Emacsen-owned git repository, as
>> I'm planning on keeping it team-maintained.
>
> Thanks for taking it over!  I've granted salsa access but would prefer
> to sponsor a few more Emacs-related uploads by you before granting DM.

Aaaand I uploaded to unstable during the freeze.  Let us hope
zenburn-emacs does not need any last minute RC bug fixes.  My apologies.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#988295: glabels: Maintainer email is not reachable

[Baptiste Beauplat]

Source: glabels
Severity: serious
Justification: Policy 3.3

Dear Maintainer,

The maintainer email ubuntu-devel-disc...@lists.ubuntu.com is a
moderated mailing list. Mail sent from the BTS and submitters are not
guaranteed to be delivered. (See the attached notification)

Please use another reachable email as maintainer.

Best,

-- 
Baptiste Beauplat - lyknode
--- Begin Message ---
Bug#986512: libunity: FTBFS: dh_auto_test: error: make -j4 check
VERBOSE=1 returned exit code 2

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


https://lists.ubuntu.com/mailman/confirm/ubuntu-devel-discuss/7a82633fb9b2d298ac25c2c751cb765f617d0a22

--- End Message ---


signature.asc
Description: PGP signature

Bug#988294: libunity: Maintainer email is not reachable

[Baptiste Beauplat]

Source: libunity
Severity: serious
Justification: Policy 3.3

Dear Maintainer,

The maintainer email ubuntu-devel-disc...@lists.ubuntu.com is a
moderated mailing list. Mail sent from the BTS and submitters are not
guaranteed to be delivered. (See the attached notification)

Please use another reachable email as maintainer.

Best,

-- 
Baptiste Beauplat - lyknode
--- Begin Message ---
Bug#986512: libunity: FTBFS: dh_auto_test: error: make -j4 check
VERBOSE=1 returned exit code 2

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


https://lists.ubuntu.com/mailman/confirm/ubuntu-devel-discuss/7a82633fb9b2d298ac25c2c751cb765f617d0a22

--- End Message ---


signature.asc
Description: PGP signature

Bug#837907: stat() hangs on a particular file

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Thu, Sep 15, 2016 at 01:12:42PM +0200, Sergio Gelato wrote:
> Package: linux-image-3.16.0-4-amd64
> Version: 3.16.36-1+deb8u1
> 
> One of our systems is suddenly unable to stat() a particular file
> (cookies.sqlite-wal in a user's Firefox profile). Any attempt to
> do so hangs in the system call, as shown by strace. The file resides
> on an NFSv4 share (sec=krb5p). Other files in the same directory on
> the same share remain accessible. The affected file is normally accessible
> on the NFS server and from other NFS clients running the same kernel.
> 
> The user has reported a similar incident yesterday on some directories
> on a different NFS share (also sec=krb5p, but hosted on a different
> server). He rebooted to clear up the problem.
> 
> I'd like advice on how to troubleshoot this effectively. I've tried
> rpcdebug -m {nfs,rpc,nlm} -s all but didn't see any smoking gun; maybe
> some information cached by the kernel is suppressing NFS activity
> associated with the stat() calls. The log entries I do see say
> NFS: nfs_lookup_revalidate(cookies.sqlite-wal) is valid
> 
> Some related kernel traces from this system's logs (in chronological order,
> with an intervening reboot; the first trace is associated with yesterday's
> incident, the second trace is 2-3 minutes newer than the timestamp on
> cookies.sqlite-wal):
> 
> [97483.663949] INFO: task ls:23767 blocked for more than 120 seconds.
> [97483.663951]   Tainted: PW  O  3.16.0-4-amd64 #1
> [97483.663952] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [97483.663954] ls  D 8800afd3b808 0 23767  1 
> 0x0004
> [97483.663957]  8800afd3b3b0 0086 00012f40 
> 88039a057fd8
> [97483.663960]  00012f40 8800afd3b3b0 88041ea137f0 
> 88041edcd128
> [97483.663962]  0002 8113eb50 88039a057d60 
> 88039a057e40
> [97483.663965] Call Trace:
> [97483.663968]  [] ? wait_on_page_read+0x60/0x60
> [97483.663971]  [] ? io_schedule+0x99/0x120
> [97483.663974]  [] ? sleep_on_page+0xa/0x10
> [97483.663977]  [] ? __wait_on_bit+0x5c/0x90
> [97483.663980]  [] ? wait_on_page_bit+0xc6/0xd0
> [97483.663983]  [] ? autoremove_wake_function+0x30/0x30
> [97483.663986]  [] ? pagevec_lookup_tag+0x1d/0x30
> [97483.663989]  [] ? filemap_fdatawait_range+0xd0/0x160
> [97483.663993]  [] ? filemap_write_and_wait+0x36/0x50
> [97483.664002]  [] ? nfs_getattr+0x108/0x220 [nfs]
> [97483.664005]  [] ? vfs_fstatat+0x57/0x90
> [97483.664009]  [] ? SYSC_newlstat+0x1d/0x40
> [97483.664013]  [] ? system_call_fast_compare_end+0x10/0x15
> 
> [ 9724.415533] INFO: task mozStorage #5:2748 blocked for more than 120 
> seconds.
> [ 9724.415537]   Tainted: PW  O 3.16.0-4-amd64 #1
> [ 9724.415538] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 9724.415539] mozStorage #5   D 8803ee153a88 0  2748   2323 
> 0x
> [ 9724.415542]  8803ee153630 0082 00012f40 
> 8803ee2cffd8
> [ 9724.415544]  00012f40 8803ee153630 88041ea537f0 
> 88041edaf7a0
> [ 9724.415545]  0002 a0669800 8803ee2cfc30 
> 88040b1152c0
> [ 9724.415547] Call Trace:
> [ 9724.415557]  [] ? nfs_pageio_doio+0x50/0x50 [nfs]
> [ 9724.415560]  [] ? io_schedule+0x99/0x120
> [ 9724.415563]  [] ? nfs_wait_bit_uninterruptible+0xa/0x10 
> [nfs]
> [ 9724.415566]  [] ? __wait_on_bit+0x5c/0x90
> [ 9724.415568]  [] ? internal_add_timer+0x2a/0x70
> [ 9724.415571]  [] ? nfs_pageio_doio+0x50/0x50 [nfs]
> [ 9724.415573]  [] ? out_of_line_wait_on_bit+0x77/0x90
> [ 9724.415575]  [] ? autoremove_wake_function+0x30/0x30
> [ 9724.415578]  [] ? nfs_updatepage+0x15e/0x830 [nfs]
> [ 9724.415582]  [] ? nfs_write_end+0x57/0x320 [nfs]
> [ 9724.415585]  [] ? 
> iov_iter_copy_from_user_atomic+0x75/0x190
> [ 9724.415588]  [] ? generic_perform_write+0x11b/0x1c0
> [ 9724.415590]  [] ? __generic_file_write_iter+0x158/0x340
> [ 9724.415592]  [] ? generic_file_write_iter+0x39/0xa0
> [ 9724.415595]  [] ? nfs_file_write+0x83/0x1a0 [nfs]
> [ 9724.415598]  [] ? new_sync_write+0x74/0xa0
> [ 9724.415600]  [] ? vfs_write+0xb2/0x1f0
> [ 9724.415601]  [] ? SyS_write+0x42/0xa0
> [ 9724.415603]  [] ? SyS_lseek+0x43/0xa0
> [ 9724.415605]  [] ? system_call_fast_compare_end+0x10/0x15

Do you still can reproduce the issue with a recent kernel?

Regards,
Salvatore

Bug#988293: unblock: hamlib/4.0-5

[Christoph Berg]

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

Please unblock package hamlib.

[ Reason ]
The update fixes #988290.

[ Risks ]
debian/control-only change.

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

unblock hamlib/4.0-5

Thanks,
Christoph

Control files: lines which differ (wdiff format)

{+Breaks:+}
{+ libhamlib2-perl (<< 4.0),+}
{+Breaks:+}
{+ libhamlib2-tcl (<< 4.0),+}
{+Breaks:+}
{+ lua-hamlib2 (<< 4.0),+}
{+Breaks:+}
{+ python3-libhamlib2 (<< 4.0),+}

diff -Nru hamlib-4.0/debian/changelog hamlib-4.0/debian/changelog
--- hamlib-4.0/debian/changelog	2021-01-12 10:52:31.0 +0100
+++ hamlib-4.0/debian/changelog	2021-05-09 22:00:33.0 +0200
@@ -1,3 +1,9 @@
+hamlib (4.0-5) unstable; urgency=medium
+
+  * Add Breaks to module packages renamed in 4.0-1. (Closes: #988290)
+
+ -- Christoph Berg   Sun, 09 May 2021 22:00:33 +0200
+
 hamlib (4.0-4) unstable; urgency=medium
 
   * Pull patches from upstream to fix issues with Icom (IC706 in particular)
diff -Nru hamlib-4.0/debian/control hamlib-4.0/debian/control
--- hamlib-4.0/debian/control	2021-01-12 09:48:48.0 +0100
+++ hamlib-4.0/debian/control	2021-05-09 22:00:33.0 +0200
@@ -132,6 +132,8 @@
  libhamlib2-perl,
 Replaces:
  libhamlib2-perl (<< 4.0),
+Breaks:
+ libhamlib2-perl (<< 4.0),
 Description: Run-time perl library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -165,6 +167,8 @@
  libhamlib2-tcl,
 Replaces:
  libhamlib2-tcl (<< 4.0),
+Breaks:
+ libhamlib2-tcl (<< 4.0),
 Description: Run-time Tcl library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -200,6 +204,8 @@
  ${python3:Provides},
 Replaces:
  python3-libhamlib2 (<< 4.0),
+Breaks:
+ python3-libhamlib2 (<< 4.0),
 Description: Run-time Python3 library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their
  functions through a computer interface. Unfortunately, control commands are
@@ -275,6 +281,8 @@
  ${lua:Provides},
 Replaces:
  lua-hamlib2 (<< 4.0),
+Breaks:
+ lua-hamlib2 (<< 4.0),
 XB-Lua-Version: ${lua:Versions}
 Description: Run-time Lua library to control radio transceivers and receivers
  Most recent amateur radio transceivers allow external control of their

Bug#988286: plocate: missing Breaks: mlocate

[Steinar H. Gunderson]

forcemerge 976321 988286
thanks

On Sun, May 09, 2021 at 07:01:07PM +0200, Andreas Beckmann wrote:
> The list of installed files at points (1) and (2) should be identical,
> but the following files have disappeared:
> 
>   /etc/updatedb.conf
>   /usr/share/man/man5/updatedb.conf.5.gz

If so, I believe this is a dpkg issue; I asked #debian-dpkg about this at the
time, and was told sharing conffiles via Replaces: was explicitly allowed,
and unit tested for.

> This is a serious bug violating policy 7.6, see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

I don't see anything in 7.6 that says a Breaks is needed? Only that it is
commonly used.

Note that plocate is meant to be able to be installed alongside mlocate,
so Breaks: is not appropriate. But they share updatedb.conf (they read it
using the same code).

> and also see the footnote that describes this incorrect behavior:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

This link is probably not what you meant; it highlights this footnote:

Build-Depends in the source package is not adequate since it (rightfully)
does not document the exact version used in the build.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#833035: linux-image-3.16.0-4-amd64: Keyspan USB serial adapter USA-49WLC failed to load firmware

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Thu, Oct 19, 2017 at 05:29:41PM -0400, Paul Fox wrote:
> chris wrote:
>  > On 10/16/2017 11:32 AM, Paul Fox wrote:
>  > > ben, chris -- regarding this bug:
>  > >   Bug#833035:  linux-image-3.16.0-4-amd64:  Keyspan USB serial adapter
>  > >   USA-49WLC failed to load firmware
>  > >
>  > > whatever became of the proposed patch.  i'm running ubuntu 16.04.3,
>  > > kernel 4.4.0-97-generic, and the failure is still present there.
>  > >
>  > > paul
>  > > =--
>  > >   paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 50.2 
> degrees)
>  > >
>  > >
>  > > .
>  > >
>  > The patch provided fixed the bug.   I think I responded with the news.
> 
> yes -- sorry for not being clear.  i was wondering whether the fix had
> gone upstream, and if not, why not.

Has the fix been upstreamed or the issue fixed in meanwhile with a
recent kernel?

Regards,
Salvatore

Bug#988282: roundcube-core: Uninstall fails in lighttpd environment

[Kurt Fitzner]

Package: roundcube-core
Version: 1.4.11+dfsg.1-3
Severity: normal

In a lighttpd environment, roundcube-core fails to uninstall/purge.  Comments
to follow apt's output:

# apt-get purge roundcube roundcube-plugins roundcube-plugins-extra 
roundcube-core roundcube-mysql 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  fonts-glyphicons-halflings libjs-bootstrap libjs-jquery-minicolors 
libjs-jstimezonedetect php-auth-sasl php-intl php-mail-mime 
php-masterminds-html5 php-net-sieve php-net-smtp
  php-net-socket php-pspell php7.4-intl php7.4-pspell
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  roundcube* roundcube-core* roundcube-mysql* roundcube-plugins* 
roundcube-plugins-extra*
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
After this operation, 25.6 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 70765 files and directories currently installed.)
Removing roundcube (1.4.11+dfsg.1-3) ...
Removing roundcube-plugins-extra (1.4.10+1-3) ...
Removing roundcube-plugins (1.4.11+dfsg.1-3) ...
Removing roundcube-core (1.4.11+dfsg.1-3) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: dumping mysql database roundcube to 
/var/tmp/roundcube.roundcube.2021-05-09-12.53.mysql.BQZjK8.
dbconfig-common: dropping mysql database roundcube.
dropping database roundcube: success.
verifying database roundcube was dropped: success.
dbconfig-common: revoking privileges for user roundcube on roundcube.
revoking access to database roundcube from roundcube@localhost: success.
Ignoring unknown module: roundcube
Run "service lighttpd force-reload" to enable changes
dpkg: error processing package roundcube-core (--remove):
 installed roundcube-core package post-removal script subprocess returned error 
exit status 2
dpkg: too many errors, stopping
Errors were encountered while processing:
 roundcube-core
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)


It is failing on disabling roundcube's lighttpd config.  This appears to be
happening because the softlink /etc/lighttpd/conf-available/50-roundcube.conf
to /etc/roundcube/lighttpd.conf is being removed before lighttpd-disable-mod
is being run.  For lighttpd-disable-mod to succeed, apparently the file must
occur in both conf-enabled and conf-available.


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 roundcube-core depends on:
ii  dbconfig-common 2.0.19
ii  debconf [debconf-2.0]   1.5.75
ii  dpkg1.20.9
ii  libjs-bootstrap44.5.2+dfsg1-6
ii  libjs-codemirror5.59.2+~cs0.23.109-1
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-minicolors 2.2.6+dfsg-4
ii  libjs-jquery-ui 1.12.1+dfsg-8
ii  libjs-jstimezonedetect  1.0.6-5
ii  libmagic1   1:5.39-3
ii  php 2:7.4+76
ii  php-auth-sasl   1.1.0-1
ii  php-cli 2:7.4+76
ii  php-common  2:76
ii  php-intl2:7.4+76
ii  php-mail-mime   1.10.10-1
ii  php-masterminds-html5   2.7.4+dfsg-2
ii  php-mbstring2:7.4+76
ii  php-net-sieve   1.4.4-2
ii  php-net-smtp1.9.0-1
ii  php-net-socket  1.2.2-2
ii  php-pear1:1.10.12+submodules+notgz+20210212-1
ii  php7.4 [php]7.4.15-5+deb11u1
ii  php7.4-cli [php-cli]7.4.15-5+deb11u1
ii  php7.4-intl [php-intl]  7.4.15-5+deb11u1
ii  php7.4-json [php-json]  7.4.15-5+deb11u1
ii  php7.4-mbstring [php-mbstring]  7.4.15-5+deb11u1
ii  roundcube-mysql 1.4.11+dfsg.1-3
ii  ucf 3.0043

Versions of packages roundcube-core recommends:
ii  lighttpd [httpd-cgi]1.4.59-1
ii  php-fpm 2:7.4+76
ii  php-gd  2:7.4+76
ii  php-pspell  2:7.4+76
ii  php7.4-fpm [php-fpm]7.4.15-5+deb11u1
ii  php7.4-gd [php-gd]  7.4.15-5+deb11u1
ii  php7.4-pspell [php-pspell]  7.4.15-5+deb11u1
ii  spawn-fcgi  1.6.4-2

Versions of packages roundcube-core suggests:
pn  php-crypt-gpg 
pn  php-mkopinsky-zxcvbn-php  
pn  php-net-ldap3 
ic  roundcube-plugins 1.4.11+dfsg.1-3

-- debconf information excluded

Bug#988290: {tcl,lua}-hamlib: missing Breaks: {libhamlib2-tcl,lua-hamlib2} (<< 4.0)

[Christoph Berg]

Re: Andreas Beckmann
> This is caused by using Replaces without corresponding Breaks.

Oops, thanks for spotting! Upload is on the way.

Christoph

Bug#986512: libunity: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Baptiste Beauplat]

I started a bit of digging up on that FTBFS and I found that libunity
build correctly with vala <= 0.48.13-1.

A changed introduced in 0.48.14 must be at the origin of the bug.

(I don't have sufficient knowledge of vala to get to the bottom of this
issue, I just wanted to share this info)

-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#830303: mmc0: Unexpected interrupt 0x04000000.

[Salvatore Bonaccorso]

Contol: tags -1 + moreinfo

On Mon, Feb 18, 2019 at 11:54:23PM +0200, Alexandros Kosiaris wrote:
> Hi,
> 
> For what it's worth, it seems on this specific hardware:
> 
> Broadcom Limited BCM57765/57785 SDXC/MMC Card Reader [14e4:16bc]
> 
> the problem can be resolved by passing:
> 
> debug_quirks2=0x4 to sdhci kernel module.
> 
> Note that there is also the debug_quirks param. I did set some values
> for it but the working one is the default, namely 0
> 
> For more information have a look at
> https://bugzilla.kernel.org/show_bug.cgi?id=73241#c55
> 
> I just tested it on a Macmini7,1Debian having Stretch with
> 4.19+101~bpo9+1 kernel. I 'll be using it for the next few days, I am
> hoping everything will work out ok and I won't have to report more
> stuff

is the issue still reproducible with a recent kernel? If not we might
go ahead and close the bugreport.

Regards,
Salvatore

Bug#827044: linux-image-4.5.0-1-686-pae: Kernel 4.5.0-1 hangs at boot time on VirtualBox with no hardware virtualization (VT-x)

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Camaleón,

On Sat, Dec 09, 2017 at 11:56:00AM +0100, Camaleón wrote:
> This is still a issue.
> 
> Is not that just non-pae kernel boots but the last bootable kernel is 
> 4.9.0-3, I mean, recent non-pae kernels (4.11, 4.12, 4.13) are unable to 
> boot (bad eip value).
> 
> See attached images for full kernel message.

Is this still reproducible with a current kernel?

Regards,
Salvatore

Bug#987945: physlock: Locking does not seem to use current configured keyboard ("dpkg-reconfigure keyboard-configuration")

[xiscu]

Package: physlock
Followup-For: Bug #987945

Dear Maintainer,
I'm currently not able to reproduce the behaviour (hat some updates in between 
and dpkg-reconfigured
again), anyway the context is: X.org, i3, /usr/bin/physlock -sdm, (just using 
the same KB as on the
first message). Disconecting/connecting the external KB doesn't seems to 
trigger the issue either.
Please feel free to close the issue, if somehow happens again I'll try harder 
trying to reproduce.

Thanks for your time!
xiscu


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

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

Versions of packages physlock depends on:
ii  libc62.31-11
ii  libpam0g 1.4.0-7
ii  libsystemd0  247.3-5

physlock recommends no packages.

physlock suggests no packages.

-- no debconf information

Bug#825026: linux-image-4.5.0-2-armmp-lpae: heartbeat triggered LEDs don't come up by default

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Steiner,

On Sun, May 22, 2016 at 09:42:38PM +0200, Steinar H. Gunderson wrote:
> On Sun, May 22, 2016 at 08:10:18PM +0100, Ben Hutchings wrote:
> > We build in code because we have to, not because it's merely useful.
> > And here we're talking about modules that are useful for only a small
> > proportion of armhf systems.
> 
> Well, if you count number of device trees, it's about 110 devices out of
> 741 (having heartbeat or default-on as policy). So it's a minority (at least
> if you don't try to weight by number of sold devices, which would be much
> harder), but not complete obscurity.
> 
> Anyways, I'm not going to try to drive this; my ARM bug reports are already
> being met with deafening silence on the Exynos list, so there's enough
> frustration involved :-) It's far from the most important thing in the big
> picture.

Despite the above involved frustration, do you know if someone else
did report the problem and/or you know the issue is not present
anymore with a recent kernel (from unstable ideally or mainline)?

Regards,
Salvatore

Bug#824790: linux-image-4.5.0-1-amd64: lots of WARNINGs in hfsc_dequeue+0x300/0x320 when using sch_hfsc+sch_codel

[Salvatore Bonaccorso]

Source: linux
Source-Version: 4.18~rc3-1~exp1

On Thu, May 19, 2016 at 09:12:46PM +0200, Mirek Kratochvil wrote:
> Package: src:linux
> Version: 4.5.1-1
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> When attaching a codel or fq_codel qdisc to a leaf hfsc class, sometimes a
> bunch of warnings (dmesg attached) show up. That would not be a problem, but
> the warnings seem to be triggered for each packet for some time, and as a side
> situation the processing renders the system more or less unresponsive for
> several seconds (which may be a problem for QoS machine).
> 
> A bug that is probably related (but concerning hfsc+sfq) is #631945 , my
> configuration is mostly the same, except with codel instead of SFQ. No similar
> fix exists for codel.
> 
> When trying to rule out the causes, I found that the amount of traffic doesn't
> matter (the machine is currently processing around 1Gbit/s). fq_codel shows 
> the
> same behavior, no other qdisc I tested causes the warnings.
> 
> I hope someone could point out what's wrong with codel, if I see the cause I
> can write/send a patch to upstream.

This issue appears to have been fixed in 4.18-rc3 upstream. Closing
accordingly.

Regards,
Salvatore

Bug#962830: libpam-tacplus: CVE-2020-13881

[Andreas Beckmann]

Followup-For: Bug #962830

So far this was only fixed in jessie-lts, causing a version ordering
violation on upgrades:

 libpam-tacplus | 1.3.8-2| jessie  | source
 libpam-tacplus | 1.3.8-2| stretch | source
 libpam-tacplus | 1.3.8-2| buster  | source
 libpam-tacplus | 1.3.8-2| sid | source
 libpam-tacplus | 1.3.8-2+deb8u1 | jessie-security | source


Andreas

Bug#988219: meson: Move package into unstable

[Andrea Pappacoda]

Ok, I didn't knew that, thank you! Il 9 mag 2021 04:28 Jussi Pakkanen 
 ha scritto:
>
> On Sun, 9 May 2021 at 02:17, Andrea Pappacoda  wrote: 
>
> > I may be wrong, but I thought that only testing (bullseye) was under a 
> > freeze, while unstable (sid) is free to receive updates. For example, 
> > looking at the chromium package tracker (tracker.debian.org/pkg/chromium) 
> > the package has been updated to version 90 in unstable a few days ago, 
> > while freezed at version 89 in testing. 
>
> Build systems have a separate, stricter freeze. 

Bug#988289: htmldoc: CVE-2019-19630

[Utkarsh Gupta]

Hello,

That's pretty unfortunate what happened. Since I fixed this in jessie
(back when it was LTS), I'll take care of stretch (now that it's LTS)
and subsequently buster as well. Thanks!

Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script

[Kurt Fitzner]

After running dpkg-reconfigure roundcube-core I find that 
/etc/dbconfig-common/roundcube.conf remains unchanged, with the relevant 
bits as follows:


# dbc_dbserver: database host.
#leave unset to use localhost (or a more efficient local method
#if it exists).
dbc_dbserver='localhost'

# dbc_dbport: remote database port
#leave unset to use the default.  only applicable if you are
#using a remote database.
dbc_dbport='3306'

Procedure:

$ apt-get purge roundcube roundcube-core roundcube-mysql
$ apt-get --purge autoremove
$ apt-get install roundcube
  Installer asks if I want to configure the database with 
dbconfig-common, answer yes

  Installer asks for me to set a password, to which I do
$ dpkg-reconfigure roundcube-core
  Asked for IMAP server (stores answer in config.inc.php)
  Asked for default language, set to en-CA (stores answer in 
config.inc.php)

  Asked if I want to reinstall the database, select YES
  Asked for connection method, select UNIX SOCKET (no apparent effect)
  Asked for authentication plugin, select default
  Asked for database name, select roundcube
  Asked for username, select roundcube
  Asked for password, set it (x 2)
  Asked for configuration account, set to root
  Asked for what http servers to configure, select lighttpd
  Asked if I want to restart lighttpd, select no

Expected behavior: Both debian-db.php and 
/etc/dbconfig-common/roundcube.conf should reflect the selected Unix 
Socket method of connection.


Actual behavior: Both files retain "localhost" as the server and "3306" 
as the port.


I have tried this several times with the same result every time.  I even 
tried using a different password for the roundcube user in the 
reconfigure that I did during the initial install.  The new password 
makes it through to dbconfig-common.  The updated connection method 
setting does not.

Bug#986232: RFP: organicmaps -- offline maps application

[Martin]

Control: retitle -1 RFP: organicmaps -- offline maps application

Programme has been renamed.
New URL: https://organicmaps.app/
Github: https://github.com/organicmaps/organicmaps

Bug#988253: mmdebstrap: Ways to keep apt Packages files

[Johannes Schauer Marin Rodrigues]

Quoting Vagrant Cascadian (2021-05-09 10:40:47)
> >> But then maybe cleanup/apt might someday implement some other feature I
> >> might miss out on by doing this...
> >
> > We can easily add two other skip options:
> >
> >--skip=cleanup/apt/lists
> >--skip=cleanup/apt/cache
> 
> That would be nice!

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/88a031477a96258c1fd95badce217d244d631f45

signature.asc
Description: signature

Bug#988142: pandas FTBFS in buster: test failures

[Rebecca N. Palmer]

This is _probably_ the same issue that 0.23.3+dfsg-3 has had since it 
was new: some tests run in all installed locales, and on 
reproducible-builds (but not buildds without a locales-all dependency) 
this includes a few with no text encoding.


The underlying issue is in Python stdlib, and is an exception (not a 
wrong answer).  The 'fix' in -4 was to ignore the affected tests.

https://salsa.debian.org/science-team/pandas/-/commit/da7f8469cdf96b0da87db87ea1741e180cee7656

Hence, I currently do not intend to attempt a fix in stable, but am open 
to discussion of this.

Bug#988291: aptitude: strange search output when using tabs in --display-format

[Christoph Anton Mitterer]

One addition I just found out:

It seems that the erroneous spaces in the first line are only printed,
when stdout is a terminal, at least when doing:
at  | cat  afterwards, it works fine.

Bug#988292: gnome-sound-recorder: Potential data loss and regression (recordings not saved or unusable)

[Sophie Herold]

Package: gnome-sound-recorder
Version: 3.38.0-3
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: sop...@hemio.de

Dear Maintainer,

as pointed out in an other issue, there exists an important upstream release
for this package. From the 3.38.1 NEWS file:

 Fix recording is lost when using space bar in name input
 Fix ui becomes unusable and recording is lost after stopping a record
 Remove m4a option since using it results in unusable recordings

At least the first two are regressions compare to current stable version. All
three imply data loss.

The relevant patch is very simple

```
diff --git a/src/application.js b/src/application.js
index 24f0aac..d9ab61a 100644
--- a/src/application.js
+++ b/src/application.js
@@ -124,7 +124,8 @@ var Application = GObject.registerClass(class Application
extends Gtk.Applicatio
 'Sam Hewitt '],
 authors: ['Meg Ford ',
 'Bilal Elmoussaoui ',
-'Felipe Borges '],
+'Felipe Borges ',
+'Kavan Mevada '],
 /* Translators: Replace "translator-credits" with your names, one
name per line */
 translator_credits: _('translator-credits'),
 program_name: GLib.get_application_name(),
diff --git a/src/recorderWidget.js b/src/recorderWidget.js
index 8b01278..2ba4d0d 100644
--- a/src/recorderWidget.js
+++ b/src/recorderWidget.js
@@ -155,6 +155,8 @@ var RecorderWidget = GObject.registerClass({
 case RecorderState.STOPPED:
 this.actionsGroup.lookup('start').enabled = true;
 this.actionsGroup.lookup('stop').enabled = false;
+this.actionsGroup.lookup('pause').enabled = false;
+this.actionsGroup.lookup('resume').enabled = false;
 break;
 }
 }
```

Bug#988291: aptitude: strange search output when using tabs in --display-format

[Christoph Anton Mitterer]

Package: aptitude
Version: 0.8.13-3
Severity: normal



Hi.


When using tabs in --display-format, then output is kinda strange.

E.g.:

$ aptitude --disable-columns --display-format $'%c%M\t%p' search '?obsolete'
iA  libdvdcss2   
iA  libqb0
iA  usbguard-applet-qt

has spacces in the first line (between iA and libdvdcss2 and also *after* 
libdvdcss2,
but results are fine for the other two, that is \t between iA and libqb0 
respectively
usbguard-applet-qt and no spaces after the package names.


It seems to be always the first line, though I could have sworn that last night
when first stumbling over this, I found that the addittion of ? and/or # to the
% fields solved the problem (despite having --disable-columns) ... but I 
cannot
reproduce this now.



Cheers,
Chris.

Bug#987640: zsnes FTBFS with gcc 10

[Baptiste Beauplat]

Control: tags -1 + patch

Dear maintainer,

The following patch fixes the FTBFS. I've tested it and I can run the
program and load a rom successfully.

Without feedback, I'll NMU the package and request an unblock in a
couple of days.

Best,

-- 
Baptiste Beauplat - lyknode
From: Baptiste Beauplat 
Date: Wed, 5 May 2021 23:18:27 +0200
Subject: Fix FTBFS with gcc 10 (Closes: #987640)

Declare HacksDisable as external unsigned char in initc.c.
Declaration and assignation is done in cfg.c. This file is generated at
build time by parsegen from cfg.psr. The generated variable is an
unsigned char.
---
 src/initc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/initc.c b/src/initc.c
index 3096240..56b02bc 100644
--- a/src/initc.c
+++ b/src/initc.c
@@ -1496,7 +1496,7 @@ Would be nice to trash this section in the future
 extern unsigned char ENVDisable, cycpb268, cycpb358, cycpbl2, cycpblt2, cycpbl;
 extern unsigned char cycpblt, opexec268, opexec358, opexec268b, opexec358b;
 extern unsigned char opexec268cph, opexec358cph, opexec268cphb, opexec358cphb;
-bool HacksDisable;
+extern unsigned char HacksDisable;
 
 void headerhack()
 {


signature.asc
Description: PGP signature

Bug#987013: Release goal proposal: Remove Berkeley DB

[Adrian Bunk]

On Fri, Apr 16, 2021 at 10:36:57PM +0200, Marco d'Itri wrote:
> On Apr 16, Bastian Blank  wrote:
> 
> > postfix is easy.  Would inn2 be license compliant with a AGPL licensed
> > BDB, aka able to provide the source to it's users, or what is the plan
> > anyway?
> The plan is to continue using 5.3, not upgrading.
> 
> >  slapd defaults to LMDB since several years and you need to
> > explicitely specify the bdb or hdb backend.
> Sure, but the point was how to convert existing systems.

As far as I can see, the realistic best case would be to drop
Berkeley DB *after* bookworm.

For usages that are not just build-time tests or temporary caches,
we need at least one release for migrating the data of our users.

apt-listchanges is using Berkeley DB through Python (#988090).
This is one global database, and the user-friendly way of migration 
would be either in the maintainer scripts during the upgrade to bookworm 
or at runtime when the version in bookworm discovers a legacy Berkeley 
DB database.

If Python in bookworm would not be able to read legacy Berkeley DB 
databases, we would be screwing our users by not being able to offer
them automatic migrations in packages like apt-listchanges.

I maintain bogofilter (a spam filter). It would be feasible to implement 
a transparent migration from Berkeley DB to a different format in 
bookworm, but this requires a bogofilter tool compiled against libdb5.3 
in bookworm.

Which would not be possible without libdb5.3 in bookworm.

> ciao,
> Marco

cu
Adrian

Bug#978656: RFA: zenburn-emacs -- low contrast color theme for Emacs

[Raúl Benencia]

Hello Sean,

On Tue, Dec 29, 2020 at 12:38:10PM -0700, Sean Whitton wrote:
> I request an adoptor for the zenburn-emacs package, which I haven't used
> for some months now.

I've prepared[0] a merge request with the newest version of
zenburn-emacs. Will you be willing to sponsor it?

  [0] https://salsa.debian.org/emacsen-team/zenburn-emacs/-/merge_requests/1

Additionally, it would ease my future uploads if I get added into the
Debian Maintainer ACL for this package, and also if I'm given
Maintainer permissions on the current Emacsen-owned git repository, as
I'm planning on keeping it team-maintained.

Many thanks in advance.
--
Raúl Benencia


signature.asc
Description: PGP signature

Bug#988280: gftp: FTBFS on hurd-i386: fatal error: stropts.h: No such file or directory

[Jessica Clarke]

On 9 May 2021, at 14:56, hahawang  wrote:
> 
> Package: gftp
> Severity: important
> Version: 2.7.0b-1
> Tags: ftbfs,patch
> User:hahawang
> Usertags: hurd,hurd-i386
> X-Debbugs-CC:debian-h...@lists.debian.org,bug-h...@gnu.org
> 
> I decide to fix a broken package found at the recommended 
> page(https://people.debian.org/~sthibault/out_of_date.txt)named `gftp`.
> 
> After I download the package source and try to build without any 
> modifications under the debian hurd running in qemu 
> (debian-hurd-20210219.img),  I got the following error.
> 
> ```
> 
> pty.c:64:10: fatal error: stropts.h: No such file or directory
>64 | #include 
>   |  ^~~
> compilation terminated.
> 
> ```
> 
> So that I decide to check the source code and find the following line:
> 
> 
> ```
> 
> #if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) || 
> defined(__linux__))
> #include 
> #endif
> 
> ```
> 
> Obviously, the GNU Hurd also haven't the `stropt.h`, so It is better to add a 
> check of GNU-hurd at this line. By following the document available at 
> https://sourceforge.net/p/predef/wiki/OperatingSystems/,
> 
> I have fixed the build failure, patches avaiable at the end of this email.
> 
> Although, IMHO it's trivial, so I decide to report this bug along with a 
> patch directly to the debian bug tracking system, but also hopes for your 
> advises and reviews!
> 
> Thank you!
> 
> ---
> 
> hahawang
> 
> 
> --- a/lib/pty.c
> +++ b/lib/pty.c
> @@ -60,7 +60,7 @@
> 
>  #elif HAVE_GRANTPT
> 
> -#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) || 
> defined(__linux__))
> +#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) || 
> defined(__linux__) || defined(__gnu_hurd__))
>  #include 
>  #endif

Why is this not just #ifdef __sun upstream? AFAIK Solaris is the only OS that
implements that mess. Or, better yet, if it’s optional, just delete the code
that needs this header? Or make it an autoconf check. This is hands down the
worst way upstream could write this code.

Jess

Bug#988290: {tcl,lua}-hamlib: missing Breaks: {libhamlib2-tcl,lua-hamlib2} (<< 4.0)

[Andreas Beckmann]

Package: tcl-hamlib,lua-hamlib
Version: 4.0-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install libhamlib2-tcl/buster
  # (1)
  apt-get install tcl-hamlib/bullseye
  apt-get remove tcl-hamlib
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:


This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The tcl-hamlib package has the following relationships with libhamlib2-tcl:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  libhamlib2-tcl (<< 4.0)
  Provides:  libhamlib2-tcl

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

1m39.3s ERROR: FAIL: After purging files have disappeared:
  /usr/lib/x86_64-linux-gnu/tcl8.6/Hamlib/hamlibtcl.so -> hamlibtcl-3.3.so  
 owned by: tcl-hamlib
  /usr/lib/x86_64-linux-gnu/tcl8.6/Hamlib/pkgIndex.tcl   owned by: tcl-hamlib

1m39.3s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/libhamlib2-tcl.list not owned

1m24.3s ERROR: FAIL: After purging files have disappeared:
  /usr/lib/x86_64-linux-gnu/lua/5.2/Hamliblua.so -> 
../../liblua5.2-hamlib2.so.0.0.0 owned by: lua-hamlib:amd64
  /usr/lib/x86_64-linux-gnu/lua/5.3/Hamliblua.so -> 
../../liblua5.3-hamlib2.so.0.0.0 owned by: lua-hamlib:amd64

1m24.3s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/lua-hamlib2:amd64.list  not owned


cheers,

Andreas


libhamlib2-tcl=3.3-5_tcl-hamlib=4.0-4.log.gz
Description: application/gzip

Bug#988289: htmldoc: CVE-2019-19630

[Andreas Beckmann]

Source: htmldoc
Version: 1.8.27-8
Severity: serious
Tags: security
User: debian...@lists.debian.org
Usertags: piuparts
Control: fixed -1 1.8.27-8+deb8u1
Control: fixed -1 1.9.7-1

Hi,

CVE-2019-19630 is fixed in jessie-lts but not stretch-lts, making
upgrades difficult since jessie-security has a newer version than
stretch(-security).
Please upload the fix to stretch-lts, too.
And as it looks, this is also unfixed in buster.

 htmldoc | 1.8.27-8| jessie  | source
 htmldoc | 1.8.27-8| stretch | source
 htmldoc | 1.8.27-8+deb8u1 | jessie-security | source
 htmldoc | 1.9.3-1 | buster  | source
 htmldoc | 1.9.11-2| bullseye| source
 htmldoc | 1.9.11-2| sid | source


Andreas

Bug#988280: gftp: FTBFS on hurd-i386: fatal error: stropts.h: No such file or directory

[Svante Signell]

On Sun, 2021-05-09 at 21:56 +0800, hahawang wrote:
> Package: gftp
> Severity: important
> Version: 2.7.0b-1
> Tags: ftbfs,patch
> User:hahawang
> Usertags: hurd,hurd-i386
> X-Debbugs-CC:debian-h...@lists.debian.org,bug-h...@gnu.org
> 
> +#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) 
> > > defined(__linux__) || defined(__gnu_hurd__))

Normally defined(__GNU__) is the most common way to indicate GNU/Hurd.

Bug#988288: /usr/bin/pimdataexporter: I can't import file zip configuration

[Davide Lombardo]

Package: pim-data-exporter
Version: 4:20.08.3-1
Severity: important
File: /usr/bin/pimdataexporter

Today I have exported my kmail configuration with pimdataexporter tool. The 
progam generated a zip file of the selected configuration but every time 
I try to import such configuration file either in the same machine or another 
one the $ pimdataexporter --import whatever.zip command fails.
It opens a window selection dialog which should shows the configuration entries 
of the configurations you would like to restore or not, but instead it shows an 
empty list and you can't restore anything.
I have alredy tried to regenerate the zip file with $ pimdataexporter --export 
many times and to import the configuration again with the same unsucessful 
outcome.


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

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

Versions of packages pim-data-exporter depends on:
ii  kinit5.78.0-2
ii  kio  5.78.0-4
ii  libc62.31-11
ii  libgcc-s110.2.1-6
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-20.08]4:20.08.3-3
ii  libkf5akonadimime5 [libkf5akonadimime5-20.08]4:20.08.3-1
ii  libkf5akonadinotes5 [libkf5akonadinotes5-20.08]  4:20.08.3-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08]  4:20.08.3-3
ii  libkf5archive5   5.78.0-2
ii  libkf5calendarcore5abi2  5:5.78.0-2
ii  libkf5configcore55.78.0-4
ii  libkf5configgui5 5.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5contacts5  5:5.78.0-2
ii  libkf5coreaddons55.78.0-4
ii  libkf5crash5 5.78.0-3
ii  libkf5dbusaddons55.78.0-2
ii  libkf5i18n5  5.78.0-2
ii  libkf5identitymanagement5 [libkf5identitymanagement5-20.08]  20.08.3-1
ii  libkf5itemviews5 5.78.0-2
ii  libkf5kiofilewidgets55.78.0-4
ii  libkf5kiogui55.78.0-4
ii  libkf5kiowidgets55.78.0-4
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-20.08]  4:20.08.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-20.08]20.08.3-1
ii  libkf5mime5abi1 [libkf5mime5-20.08]  20.08.3-1
ii  libkf5notifications5 5.78.0-2
ii  libkf5pimcommon5abi2 [libkf5pimcommon5-20.08]4:20.08.3-1
ii  libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-20.08]  4:20.08.3-1
ii  libkf5pimtextedit5abi2 [libkf5pimtextedit5-20.08]20.08.3-1
ii  libkf5widgetsaddons5 5.78.0-2
ii  libkf5xmlgui55.78.0-2
ii  libkuserfeedbackcore11.0.0-3
ii  libkuserfeedbackwidgets1 1.0.0-3
ii  libqt5core5a 5.15.2+dfsg-5
ii  libqt5gui5   5.15.2+dfsg-5
ii  libqt5widgets5   5.15.2+dfsg-5
ii  libstdc++6   10.2.1-6

pim-data-exporter recommends no packages.

pim-data-exporter suggests no packages.

-- no debconf information

Bug#988287: FTBFS due to test failures

[Hans Joachim Desserud]

Source: rally-openstack
Version: 2.0.0-2
Severity: serious
Justification: FTBFS in unstable
Tags: ftbfs

Dear Maintainer,

rally-openstack currently fails to build on Debian Sid with test 
failures:


(...)
ERROR tests/unit/task/scenarios/zaqar/test_utils.py - 
dns.resolver.NoResolver...
ERROR tests/unit/task/ui/charts/test_osprofilerchart.py - 
dns.resolver.NoReso...
ERROR tests/unit/verification/tempest/test_config.py - 
dns.resolver.NoResolve...
ERROR tests/unit/verification/tempest/test_context.py - 
dns.resolver.NoResolv...
ERROR tests/unit/verification/tempest/test_manager.py - 
dns.resolver.NoResolv...
!! Interrupted: 180 errors during collection 
!!!
 180 errors in 61.15s (0:01:01) 


make[1]: *** [debian/rules:25: override_dh_auto_install] Error 2


See also 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rally-openstack.html

for more details.

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#988286: plocate: missing Breaks: mlocate

[Andreas Beckmann]

Package: plocate
Version: 1.1.7-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install mlocate
  # (1)
  apt-get install plocate
  apt-get remove plocate
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /etc/updatedb.conf
  /usr/share/man/man5/updatedb.conf.5.gz

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The plocate package has the following relationships with mlocate:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  mlocate

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

0m33.2s ERROR: FAIL: After purging files have disappeared:
  /etc/updatedb.conf owned by: plocate
  /usr/share/man/man5/updatedb.conf.5.gz owned by: plocate

0m33.2s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/mlocate.listnot owned


cheers,

Andreas


mlocate=0.26-3_plocate=1.1.7-1.log.gz
Description: application/gzip

Bug#987921: [RFS] Re: Bug#987921: linbox FTBFS on 32bit with gcc 10

[Torrance, Douglas]

Control: tags -1 pending

On Sun 02 May 2021 12:46:50 AM EDT, Adrian Bunk wrote:
> Source: linbox
> Version: 1.6.3-2
> Severity: serious
> Tags: ftbfs
>
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/i386/linbox.html

I've fixed this RC bug in git:
https://salsa.debian.org/science-team/linbox

Would anyone be willing to review/sponsor?  I'm hoping that linbox won't get 
removed before the bullseye release.

Thanks!
Doug

Bug#988195: wine-development: starting wine-development failed due to wrong prefix

[gmail]

Dear maintainer,

This message to tell that version 5.9.2 fix actually the issue on my system.

Thank you !

invar

Bug#988285: qpdfview-pdf-poppler-plugin: missing Breaks: qpdfview (<< 0.4.18-3~)

[Andreas Beckmann]

Package: qpdfview-pdf-poppler-plugin
Version: 0.4.18-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install qpdfview/buster
  # (1)
  apt-get install qpdfview-pdf-poppler-plugin/bullseye
  apt-get remove qpdfview-pdf-poppler-plugin
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:


This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The qpdfview-pdf-poppler-plugin package has the following relationships with 
qpdfview:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  qpdfview (<< 0.4.18-3~)

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

0m58.0s ERROR: FAIL: After purging files have disappeared:
  /usr/lib/qpdfview/libqpdfview_pdf.so   owned by: qpdfview-pdf-poppler-plugin

0m58.0s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/qpdfview.list   not owned


cheers,

Andreas


qpdfview=0.4.17~beta1+git20180709-2_qpdfview-pdf-poppler-plugin=0.4.18-4.log.gz
Description: application/gzip

Bug#988284: golang-github-prometheus-procfs-dev: missing Breaks: golang-procfs-dev (<< 0.2.0)

[Andreas Beckmann]

Package: golang-github-prometheus-procfs-dev
Version: 0.3.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install golang-procfs-dev/buster
  # (1)
  apt-get install golang-github-prometheus-procfs-dev/bullseye
  apt-get remove golang-github-prometheus-procfs-dev
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/share/gocode/src/github.com/prometheus/procfs/*/*.go

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The golang-github-prometheus-procfs-dev package has the following relationships 
with golang-procfs-dev:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  golang-procfs-dev (<< 0.2.0)
  Provides:  golang-procfs-dev (= 0.3.0-1)

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

1m19.3s ERROR: FAIL: After purging files have disappeared:
  /usr/share/gocode/src/github.com/prometheus/procfs/bcache/bcache.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/bcache/get.go   owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/bcache/get_test.go  owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/buddyinfo.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/buddyinfo_test.go   owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/doc.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/fs.go   owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/fs_test.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/internal/util/parse.go 
 owned by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/ipvs.go owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/ipvs_test.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/mdstat.go   owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/mdstat_test.go  owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/mountstats.go   owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/mountstats_test.go  owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/net_dev.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/net_dev_test.go owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/nfs.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse_nfs.goowned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse_nfs_test.go  
 owned by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse_nfsd.go   owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/nfs/parse_nfsd_test.go 
 owned by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/proc.go owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/proc_io.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/proc_io_test.go owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/proc_limits.go  owned 
by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/proc_limits_test.go
 owned by: golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/proc_ns.go  owned by: 
golang-github-prometheus-procfs-dev
  /usr/share/gocode/src/github.com/prometheus/procfs/proc_ns_test.go owned 
by: golang-github-prometheus-procfs-dev
  

Bug#988283: libcantorlibs28: missing Breaks: cantor (<< 4:20.12.0-2~)

[Andreas Beckmann]

Package: libcantorlibs28
Version: 4:20.12.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install cantor/buster
  # (1)
  apt-get install libcantorlibs28/bullseye
  apt-get remove libcantorlibs28
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/share/config.kcfg/cantor_libs.kcfg

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The libcantorlibs28 package has the following relationships with cantor:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  cantor (<< 4:20.12.0-2~)

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

4m30.6s ERROR: FAIL: After purging files have disappeared:
  /usr/share/config.kcfg/cantor_libs.kcfgowned by: libcantorlibs28

4m30.6s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/cantor.list not owned


cheers,

Andreas


cantor=4:18.12.0-2_libcantorlibs28=4:20.12.1-4.log.gz
Description: application/gzip

Bug#986769: wireshark: Dropdown menus invisible in Sway

[Balint Reczey]

Control: tags -1 moreinfo unreproducible

Hi Pelle,

On Sun, Apr 11, 2021 at 11:12 PM Pelle  wrote:
>
> Package: wireshark
> Version: 3.4.4-1
> Severity: normal
>
> Dear Maintainer,
>
> Wireshark's dropdown menus are invisible in Sway (the Wayland compositor). The
> invisible dropdown menu entries can't be clicked but they can still be
> activated via keyboard. The dropdown menus in other QT-based apps (VLC, Krita,
> …) work fine in Sway.
>
> A workaround is to run `ssh -X localhost wireshark` in Sway, or to run
> Wireshark inside Weston.
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-5-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_CRAP
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 wireshark depends on:
> ii  wireshark-qt  3.4.4-1

I've tried to reproduce the error, but all menus I could think of
worked under Sway in Ubuntu 21.04 with an intel GPU and in unstable
(today) in Qemu.
Could you please tell which drop-down menus did not work or if you
have some special config that could affect the behaviour?

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#809149: Closing this bug (BTS maintenance for src:linux bugs)

[Vincent Lefevre]

On 2021-05-09 07:21:07 -0700, car...@debian.org wrote:
> This bug was filed for a very old kernel or the bug is old itself
> without resolution.

I confirm that the bug is obsolete. (I'm not sure I could ever
reproduce it.)

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

Bug#988078: release-notes: add information regarding exim4 and 'tainted data' issue

[Andreas Metzler]

On 2021-05-05 Paul Muster  wrote:
> Package: release-notes
> Severity: normal

> Hi,

> please add a new paragraph 5.1.13 (and move existing 5.1.14 to .14) regarding 
> exim and the new 'tainted data' issue.

> Text copied from NEWS.Debian file:
[...]

Thanks, Paul!

The text has been slightly updated with one oof the latest uploads, it
now reads
-
  Please consider exim 4.93/4.94 a *major* exim upgrade. It introduces the
  concept of tainted data read from untrusted sources, like e.g. message
  sender or recipient. This tainted data (e.g. $local_part or $domain)
  cannot be used among other things as a file or directory name or command
  name.

  This WILL BREAK configurations which are not updated accordingly.
  Old Debian exim configuration files also will not work unmodified, the new
  configuration needs to be installed with local modifications merged in.

  Typical nonworking examples include:
  * Delivery to /var/mail/$local_part. Use $local_part_data in combination
with check_local_user.
  * Using
data = ${lookup{$local_part}lsearch{/some/path/$domain/aliases}}
instead of
data = ${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
for a virtual domain alias file.

  The basic strategy for dealing with this change is to use the result of a
  lookup in further processing instead of the original (remote provided)
  value.

  To ease upgrading there is a new main configuration option to temporarily
  downgrade taint errors to warnings, letting the old configuration work with
  the newer exim. To make use of this feature add
  .ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
   allow_insecure_tainted_data = yes
  .endif
  to the exim configuration (e.g. to /etc/exim4/exim4.conf.localmacros)
  *before* upgrading to exim 4.93/4.94 and check the logfile for taint
  warnings. This is a temporary workaround which is already marked for
  removal on introduction.
-

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#988086: Exim delivery process crashes on each mail with NULL-pointer

[Andreas Metzler]

On 2021-05-05 Andreas Metzler  wrote:
[...]
> The breakage is caused by the relevant change in -18/-19 (Pull patches
> to temporarily add an option to turn taint errors into warnings.)

Could you give 4.94.2-2 a spin? It should hit the mirrors in a couple of
hours.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Bug#988236: roundcube-core: Install breaks lighttpd if fastcgi-php-fpm module is active

[Guilhem Moulin]

Control: reassign -1 roundcube-core 1.4.11+dfsg.1-3

On Sat, 08 May 2021 at 09:07:26 -0300, Kurt Fitzner via 
Pkg-roundcube-maintainers wrote:
> On systems with lighttpd, the installer should detect if fastcgi-php-fpm is
> already active and if so, should not subsequently activate fastcgi-php.

Thanks, this is related to #898040.

> I'm not sure this shouldn't have a higher severity, but I'll let you judge.

Like #898040 I don't think this warrants RC severity.  But should a fix
make it in time it's definitely suitable to request an unblock request.

That said I'm not sure to how to fix this.  I'm not really familiar with
lighttpd but I don't see a way to list enabled modules other than
looking in /etc/lighttpd/conf-enabled which I'm not really keen to do.

In fact I'm not sure it's a roundcube-core issue in the first place:
`lighty-enable-mod fastcgi-php` arguably should do some sanity check,
otherwise what's the advantage compared to manually creating symlinks?
In a minimal sid chroot:

$ apt install -y lighttpd php-fpm
[…]
$ service lighttpd start
Starting web server: lighttpd.
$ lighty-enable-mod fastcgi-php-fpm
Met dependency: fastcgi
Enabling fastcgi-php-fpm: ok
Enabling fastcgi: ok
Run "service lighttpd force-reload" to enable changes
$ service lighttpd force-reload
Reloading web server configuration: lighttpd.
$ lighty-enable-mod fastcgi-php
Enabling fastcgi-php: ok
Run "service lighttpd force-reload" to enable changes
$ echo $?
0
$ service lighttpd force-reload
Duplicate array-key '.php'
2021-05-09 12:52:17: configfile.c.1970) source: 
/etc/lighttpd/conf-enabled/15-fastcgi-php.conf line: 21 pos: 1 parser failed 
somehow near here: (EOL)
2021-05-09 12:52:17: configfile.c.1970) source: /etc/lighttpd/lighttpd.conf 
line: 51 pos: 15 parser failed somehow near here: (EOL)

If these modules are incompatible lighty-enable-mod(1) should ideally
give a hint.  I see module snippets have a way to express dependencies,
but unfortunately not conflicts.

lighttpd maintainers (CC'ed): What's the best way to express “enable
fastcgi-php (or fastcgi-php-fpm) unless fastcgi.server already has a
handler for .php”?  Or if that's not possible “enable fastcgi-php unless
fastcgi-php-fpm is already enabled”?  Simply expand
/etc/lighttpd/conf-enabled/*-fastcgi-php-fpm.conf and check for a match,
or is there a more robust way?

Thanks!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#988271: mmdebstrap: Use all cores when compressing with zstd

[Johannes Schauer Marin Rodrigues]

Quoting Vagrant Cascadian (2021-05-09 10:17:42)
> Currently zstd compression, while overall fast, only uses a single thread.
> The attached patch passes the --threads=0 option to zstd (just like in the xz
> case) so that it can take advantage of multiple cores.

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/c51fb24c7b272d42c04d72eb3bd7fe4781baa39d

signature.asc
Description: signature

Bug#800627: linux: fs/isofs/util.c iso_date() will map years >= 2028 to 1970

[Thomas Schmitt]

Hi,

Salvatore Bonaccorso wrote:
> This has been fixed upstream with 34be4dbf87fc ("isofs: fix timestamps
> beyond 2027") which was backported to various table series.
> [committed 2017]

Regrettably it does not suffice, because of the remaining int bottleneck
iso_date(), which is still to see in line 19 of
  https://github.com/torvalds/linux/blob/master/fs/isofs/util.c

For the records and with me duely acknowledging that Debian is not
in charge of fixing this, here is my unposted patch set for the kernel
branch of Jens Axboe as of september 2020.
  git://git.kernel.dk/linux-block

---

From 154a68527351db091e5de60388ba4cfb1fe779fd Mon Sep 17 00:00:00 2001
From: Thomas Schmitt 
Date: Mon, 21 Sep 2020 18:20:14 +0200
Subject: [PATCH 0/1] isofs: prevent file time rollover after year 2038

The time values in struct inode of isofs result from calls to function
iso_date() in isofs/util.c, which returns seconds in the range of signed
int. This will rollover in 2038.
ISO 9660 directory record timestamps are good for up to year 2155.
(ECMA-119 9.1.5: 1900 + 255)

The only callers of iso_date() are in isofs/inode.c and isofs/rock.c
and put the result into struct inode.i_{a,c,m}time.tv_sec which is
of type time64_t.
The time value of iso_date() essentially stems from mktime64().

So return type time64_t is appropriate for iso_date().

--
Demonstration of the problem:

Create an ISO 9660 filesystem with file date in 2040, using file /bin/true
as victim payload:

  xorriso -outdev /tmp/test_date.iso \
  -blank as_needed \
  -map /bin/true /victim \
  -alter_date m 'Oct 01 22:06:12 2040' /victim --

Inspect the current representation by isofs:

  mount /tmp/test_date.iso /mnt/iso
  ls -l /mnt/iso/victim

This yields with int iso_date():

  ... Aug 26  1904 /mnt/iso/victim

After changing the type of iso_date() to time64_t:

  ... Oct  1  2040 /mnt/iso/victim

For completeness i tested the last possible second:

  xorriso ... -alter_date m 'Dec 31 23:59:59 2155' /victim --

and got properly:

  ... Dec 31  2155 /mnt/iso/victim

(When reproducing this it might be to wise to use December 30, to avoid
any potential timezone problems.)

--

Have a nice day :)

Thomas

Thomas Schmitt (1):
  isofs: prevent file time rollover after year 2038

 fs/isofs/isofs.h | 3 ++-
 fs/isofs/util.c  | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

--
2.20.1

---

From 154a68527351db091e5de60388ba4cfb1fe779fd Mon Sep 17 00:00:00 2001
From: Thomas Schmitt 
Date: Mon, 21 Sep 2020 18:20:06 +0200
Subject: [PATCH 1/1] isofs: prevent file time rollover after year 2038

Change the return type of function iso_date() from int to time64_t.

Signed-off-by: Thomas Schmitt 
---
 fs/isofs/isofs.h | 3 ++-
 fs/isofs/util.c  | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/isofs/isofs.h b/fs/isofs/isofs.h
index 055ec6c586f7..527c0db72ff9 100644
--- a/fs/isofs/isofs.h
+++ b/fs/isofs/isofs.h
@@ -107,7 +107,8 @@ static inline unsigned int isonum_733(u8 *p)
/* Ignore bigendian datum due to broken mastering programs */
return get_unaligned_le32(p);
 }
-extern int iso_date(u8 *, int);
+
+time64_t iso_date(u8 *, int);

 struct inode;  /* To make gcc happy */

diff --git a/fs/isofs/util.c b/fs/isofs/util.c
index e88dba721661..348af786a8a4 100644
--- a/fs/isofs/util.c
+++ b/fs/isofs/util.c
@@ -16,10 +16,10 @@
  * to GMT.  Thus  we should always be correct.
  */

-int iso_date(u8 *p, int flag)
+time64_t iso_date(u8 *p, int flag)
 {
int year, month, day, hour, minute, second, tz;
-   int crtime;
+   time64_t crtime;

year = p[0];
month = p[1];
--
2.20.1

---

Have a nice day :)

Thomas

Bug#985786: systemd: should be restartable even with mounted network filesystems

[Marc Lehmann]

On Thu, May 06, 2021 at 11:11:04PM +0200, Michael Biebl  
wrote:
> > This sounds a bit like https://github.com/systemd/systemd/issues/16156
> > Unfortunately your strace log was clipped off.

Pretty much similar, yes, except in my case it's not a race condiiton.

> > Can you try https://github.com/systemd/systemd/pull/19101 ?
> > 
> 
> As I haven't heard back from you, I'm tentatively marking this issue as
> fixed upstream

Sorry, I must have overlooked it, and apologies if my strace was clipped -
marking as fixed upstream sounds like an excellent idea to me - if it it
turns out to be still a problem, and I run into it, I can either re-open
or report again once it happens.

Thanks again for your work!

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#988142: pandas FTBFS in buster: test failures

[Adrian Bunk]

On Sun, May 09, 2021 at 03:11:14PM +0100, Rebecca N. Palmer wrote:
> This is _probably_ the same issue that 0.23.3+dfsg-3 has had since it was
> new: some tests run in all installed locales, and on reproducible-builds
> (but not buildds without a locales-all dependency) this includes a few with
> no text encoding.
> 
> The underlying issue is in Python stdlib, and is an exception (not a wrong
> answer).  The 'fix' in -4 was to ignore the affected tests.
> https://salsa.debian.org/science-team/pandas/-/commit/da7f8469cdf96b0da87db87ea1741e180cee7656
> 
> Hence, I currently do not intend to attempt a fix in stable, but am open to
> discussion of this.

Unless you object to that, I was considering doing a buster-pu update
with the patch for this test fix added.

cu
Adrian

Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script

[Guilhem Moulin]

On Sun, 09 May 2021 at 11:39:16 -0300, Kurt Fitzner wrote:
> After running dpkg-reconfigure roundcube-core I find that
> /etc/dbconfig-common/roundcube.conf remains unchanged, with the relevant
> bits as follows:
> 
> # dbc_dbserver: database host.
> #leave unset to use localhost (or a more efficient local method
> #if it exists).
> dbc_dbserver='localhost'
> 
> # dbc_dbport: remote database port
> #leave unset to use the default.  only applicable if you are
> #using a remote database.
> dbc_dbport='3306'
> […] 
>
> Expected behavior: Both debian-db.php and
> /etc/dbconfig-common/roundcube.conf should reflect the selected Unix Socket
> method of connection.
> 
> Actual behavior: Both files retain "localhost" as the server and "3306" as
> the port.

What makes you think roundcube (and dbconfig) doesn't use the default
UNIX socket with that configuration?  Again the ‘localhost’ hostname is
treated specially, see mysql(1).

If you're not convinced try to remove the mysqld socket path (or change
it to something else) to something else and watch Roundcube fail to
connect.  Or set ‘skip-networking’ and see Roundcube, dbconfig, and even
`mysql -h localhost -P 3306` ignore INADDR_LOOPBACK:3306.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#817049: linux-image-3.16.0-4-amd64: execve() gives EEXIST error under NFS if the file has been regenerated on a different machine

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Mon, Mar 07, 2016 at 04:21:24PM +0100, Vincent Lefevre wrote:
> Package: src:linux
> Version: 3.16.7-ckt20-1+deb8u3
> Severity: normal
> 
> Under NFS, when an executable has been regenerated on a different machine,
> execve() gives me an EEXIST error. To reproduce the bug:
> 
> francine:~> touch bin/tst
> francine:~> cat bin/tst
> 
> cassis:~> cat tst.c
> int main (void)
> { return 0; }
> cassis:~> gcc -O3 tst.c -o tst
> cassis:~> mv tst bin/
> mv: overwrite ‘bin/tst’? y
> 
> At this point, I have to wait for 15 seconds for the "mv" to be
> done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799838
> 
> After that:
> 
> francine:~> strace -f -o tst.out sh -c "exec $HOME/bin/tst"
> sh: 1: exec: /home/vlefevre/bin/tst: File exists
> zsh: exit 2 strace -f -o tst.out sh -c "exec $HOME/bin/tst"
> francine:~[2]> cat tst.out
> 21573 execve("/bin/sh", ["sh", "-c", "exec /home/vlefevre/bin/tst"], [/* 120 
> vars */]) = 0
> 21573 brk(0)= 0x7f4aded7d000
> 21573 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or 
> directory)
> 21573 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = 0x7f4aded46000
> 21573 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or 
> directory)
> 21573 open("/home/vlefevre/debian8/gmp/westmere/lib/tls/x86_64/libc.so.6", 
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/tls/x86_64", 
> 0x7ffec78d5b00) = -1 ENOENT (No such file or directory)
> 21573 open("/home/vlefevre/debian8/gmp/westmere/lib/tls/libc.so.6", 
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/tls", 0x7ffec78d5b00) = 
> -1 ENOENT (No such file or directory)
> 21573 open("/home/vlefevre/debian8/gmp/westmere/lib/x86_64/libc.so.6", 
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/x86_64", 0x7ffec78d5b00) 
> = -1 ENOENT (No such file or directory)
> 21573 open("/home/vlefevre/debian8/gmp/westmere/lib/libc.so.6", 
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 21573 stat("/home/vlefevre/debian8/gmp/westmere/lib", {st_mode=S_IFDIR|0755, 
> st_size=13, ...}) = 0
> 21573 open("/usr/local/lib/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 
> ENOENT (No such file or directory)
> 21573 stat("/usr/local/lib/tls/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such 
> file or directory)
> 21573 open("/usr/local/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
> (No such file or directory)
> 21573 stat("/usr/local/lib/tls", 0x7ffec78d5b00) = -1 ENOENT (No such file or 
> directory)
> 21573 open("/usr/local/lib/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
> (No such file or directory)
> 21573 stat("/usr/local/lib/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file 
> or directory)
> 21573 open("/usr/local/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
> such file or directory)
> 21573 stat("/usr/local/lib", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, 
> ...}) = 0
> 21573 open("/lib64/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
> such file or directory)
> 21573 stat("/lib64/tls/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file or 
> directory)
> 21573 open("/lib64/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
> file or directory)
> 21573 stat("/lib64/tls", 0x7ffec78d5b00) = -1 ENOENT (No such file or 
> directory)
> 21573 open("/lib64/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No 
> such file or directory)
> 21573 stat("/lib64/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file or 
> directory)
> 21573 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> 21573 read(3, 
> "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"..., 832) = 
> 832
> 21573 fstat(3, {st_mode=S_IFREG|0755, st_size=1738176, ...}) = 0
> 21573 mmap(NULL, 3844640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
> 0) = 0x7f4ade55f000
> 21573 mprotect(0x7f4ade701000, 2093056, PROT_NONE) = 0
> 21573 mmap(0x7f4ade90, 24576, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a1000) = 0x7f4ade90
> 21573 mmap(0x7f4ade906000, 14880, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4ade906000
> 21573 close(3)  = 0
> 21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = 0x7f4aded45000
> 21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = 0x7f4aded44000
> 21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = 0x7f4aded43000
> 21573 arch_prctl(ARCH_SET_FS, 0x7f4aded44700) = 0
> 21573 mprotect(0x7f4ade90, 16384, PROT_READ) = 0
> 21573 mprotect(0x7f4aded48000, 12288, PROT_READ) = 0
> 21573 mprotect(0x7f4adeb2a000, 4096, PROT_READ) = 0
> 21573 getpid()  = 21573
> 21573 rt_sigaction(SIGCHLD, 

Bug#798300: linux: fs/isofs/rock.c coarsely truncates file names of 254 or 255 bytes length

[Thomas Schmitt]

Hi,

> if this still should be trackled,

It's still in kernel 5.10, at least.

> please report it upstream

I agree that this bug is not Debain's business.
But i'd need a kernel list member who would be ready to review a patch.


Warning:
From here on it's just whining of a userlander about kernel cruelty.

There is no maintainer for isofs. Nearest is linux-scsi because of the
semi-proximity between cdrom and isofs.
Having had a real test machine last year, i tried to submit patches for
both subsystems [1] [2], but did not get any reaction.

After this experience i did not submit my patch for the name length issues.
It is based on 5.10:
--

From 3d484405f0ad8d10ef490281da157bfdd7450cb6 Mon Sep 17 00:00:00 2001
From: Thomas Schmitt 
Date: Tue, 22 Sep 2020 12:34:50 +0200
Subject: [PATCH 1/1] isofs: truncate oversized Rock Ridge names to 255 bytes

Enlarge the limit for name bytes from 253 to 255.
Do not discard all bytes of the NM field where the overflow occurs, but
rather append them to the accumulated name before truncating it to exactly
255 bytes.
Map trailing incomplete UTF-8 bytes to '_'.

Signed-off-by: Thomas Schmitt 
---
 fs/isofs/rock.c | 73 ++---
 fs/isofs/rock.h |  2 ++
 2 files changed, 71 insertions(+), 4 deletions(-)

diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
index 94ef92fe806c..e1db8776b67e 100644
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -192,6 +192,63 @@ static int rock_check_overflow(struct rock_state *rs, int 
sig)
return 0;
 }

+/*
+ * Find backward from idx the start byte of a possible UTF-8 character.
+ *   https://en.wikipedia.org/wiki/UTF-8#Description
+ * Return -1 if no incomplete UTF-8 sequence is found at the name end.
+ */
+static int rock_find_utf8_start(char *name, int idx)
+{
+   unsigned char *uname, uch;
+   int i;
+
+   uname = (unsigned char *)name;
+   /* Up to 4-byte codes */
+   for (i = 0; i < 4 && idx - i >= 0; i++) {
+   uch = uname[idx - i];
+   if ((uch & 0xe0) == 0xc0) {
+   /* UTF-8 start byte for 2-byte codes */
+   if (i >= 1)
+   return -1;  /* tail is complete */
+   else
+   return (idx - i);   /* tail not complete */
+   } else if ((uch & 0xf0) == 0xe0) {
+   /* UTF-8 start byte for 3-byte codes */
+   if (i >= 2)
+   return -1;
+   else
+   return (idx - i);
+   } else if ((uch & 0xf8) == 0xf0) {
+   /* UTF-8 start byte for 4-byte codes */
+   if (i >= 3)
+   return -1;
+   else
+   return (idx - i);
+   } else if ((uch & 0xc0) != 0x80) {
+   /* not an UTF-8 tail byte, so no UTF-8 */
+   return -1;
+   }
+   }
+   /* That would be an oversized UTF-8 code or no UTF-8 at all */
+   return -1;
+}
+
+/*
+ * Replace trailing incomplete UTF-8 sequence by '_' characters.
+ */
+static void rock_erase_incomplete_utf8(char *name, int len)
+{
+   int i;
+
+   if (len <= 0)
+   return;
+   i = rock_find_utf8_start(name, len - 1);
+   if (i < 0)
+   return;
+   for (; i < len; i++)
+   name[i] = '_';
+}
+
 /*
  * return length of name field; 0: not found, -1: to be ignored
  */
@@ -271,16 +328,24 @@ int get_rock_ridge_filename(struct iso_directory_record 
*de,
break;
}
len = rr->len - 5;
-   if (retnamlen + len >= 254) {
-   truncate = 1;
-   break;
-   }
p = memchr(rr->u.NM.name, '\0', len);
if (unlikely(p))
len = p - rr->u.NM.name;
+   if (retnamlen + len > RR_NAME_LEN) {
+   truncate = 1;
+   /* Take as many characters as possible */
+   len = RR_NAME_LEN - retnamlen;
+   if (len <= 0) {
+   rock_erase_incomplete_utf8(retname,
+  retnamlen);
+   break;
+   }
+   }
memcpy(retname + retnamlen, rr->u.NM.name, len);
retnamlen += len;
retname[retnamlen] = '\0';
+   if (truncate == 1)
+   

Bug#986527: It's a build-dep issue

[Julien Puydt]

Hi,

I had a look:
- sagemath build-depends on cython3
- /usr/bin/cython is in cython
- /usr/bin/cython3 is in cython3

so I see two ways out :

(1) change the b-dep to cython (from cython3) [and cython-dbg from
cython3-dbg, I guess] ;

(2) make so cython is called as cython3.

I can't give it a try before at least a week, so if someone wants to
dive in...

JP

Bug#701823:

[Sandy Mcknight]

Greetings, I'm sandy. Can I speak to you, please? Is very important,

Bug#988280: gftp: FTBFS on hurd-i386: fatal error: stropts.h: No such file or directory

[hahawang]

Package: gftp
Severity: important
Version: 2.7.0b-1
Tags: ftbfs,patch
User:hahawang
Usertags: hurd,hurd-i386

X-Debbugs-CC:debian-h...@lists.debian.org,bug-h...@gnu.org

I decide to fix a broken package found at the recommended 
page(https://people.debian.org/~sthibault/out_of_date.txt)named `gftp`.


After I download the package source and try to build without any 
modifications under the debian hurd running in qemu 
(debian-hurd-20210219.img),  I got the following error.


```

pty.c:64:10: fatal error: stropts.h: No such file or directory
   64 | #include 
  |  ^~~
compilation terminated.

```

So that I decide to check the source code and find the following line:


```

#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) 
|| defined(__linux__))

#include 
#endif

```

Obviously, the GNU Hurd also haven't the `stropt.h`, so It is better to 
add a check of GNU-hurd at this line. By following the document 
available at https://sourceforge.net/p/predef/wiki/OperatingSystems/,


I have fixed the build failure, patches avaiable at the end of this email.

Although, IMHO it's trivial, so I decide to report this bug along with a 
patch directly to the debian bug tracking system, but also hopes for 
your advises and reviews!


Thank you!

---

hahawang


--- a/lib/pty.c
+++ b/lib/pty.c
@@ -60,7 +60,7 @@

 #elif HAVE_GRANTPT

-#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) 
|| defined(__linux__))
+#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) 
|| defined(__linux__) || defined(__gnu_hurd__))

 #include 
 #endif

Bug#988279: ITP: libpf4j-java -- framework to turn monolithic Java applications into modular ones

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-java team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org

* Package name: libpf4j-java
  Version : 3.6.0
  Upstream Author : Decebal Suiu
* URL : https://pf4j.org/
* License : Apache-2.0
  Programming Lang: Java
  Description : framework to turn monolithic Java applications into modular 
ones

PF4J is a lightweight framework which helps one to build a modular application
by defining plugins, which are containers for extension points (defining
where, in the application, custom code may be called), for extensions (which
implement extension points) and for optional lifecycle methods to start, load
and stop extensions.
A plugin is similar to modules in other programming languages.

This package will be team-maintained inside the Debian-java team.
Right now it is needed as a dependency of nextflow.

Bug#988278: [pre-approval] unblock: libgetdata/0.10.0-10

[Anton Gladky]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

this is the pre-approval request for libgetdata/0.10.0-10

It fixes CVE-2021-20204 (#988239). It is not a release critical bug,
but security issue. Diff is attached.

Thanks

unblock libgetdata/0.10.0-10

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmCX2GcRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYG0BAAlD+ubdz+Y5mTIlSqqb5mbSatB7ok0Gbs
gI9loXe46+9VupBk4hEG75EBhM5JDk4y2Zy5ZSy3ErT29/cxUhcU9U7tGht//HDg
sHCFQASoUkwxJFtUTSWFsNELA1S7ZICAAkLYzk+mLIP/tOOXqeInHscYZ+XRjPdC
Erlc+8RbTF9RTHIKXB6LEOne8IgqXgLGEWYNwIk70qUrIQ5gZlS0qiQ2hr7LhMJQ
ZmNwbGUlpAIVw3AelYb301VyS6Mfl3jSUTbunTIXrRtGI7S6RNnRA+nYHsnS/ozj
MqDMot9O9NRQS+2YyF808Mdz+wleR5TqXGuOG8vqUdCXcyRZCSCSCKVbJLAGSEPz
TmZnTUDAiFLxD0O519c2qPhV2I4HaahveDS3jmt8Wk6jbFjX/j+MCFFhrPRJgko6
CsRFm4K9jA7qWydNrZqHVC5EKCdXANmzlM8PZtckCR6srDzJj3z0MvKFybdVfYvP
/OEC4t42oTBwxaaArXXYMaNqPJIwdeCQdgTIht5SXS+yk/JdCF27ZOHuvVUTI7p8
hSYxx1pPvvet+1wwpV+Xw3uG92xuEe55nrd1lMLdhRpFyPT2LMupr043rRB6zTMr
goOL9ZlO9aKHHUAU1C1as50gD5vtBEENuVol7HCDtxQGTX79nFg8aW3oLG7ZeeTl
wPH0S5YFf+c=
=PdQH
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index 2c30a9c..514058c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libgetdata (0.10.0-10) unstable; urgency=medium
+
+  * Team upload.
+  * [4ee5ad0] Fix CVE-2021-20204. (Closes: #988239)
+
+ -- Anton Gladky   Sun, 09 May 2021 14:27:38 +0200
+
 libgetdata (0.10.0-9) unstable; urgency=medium
 
   * Fix FTBFFS on binary-all build (missing file). Closes: #966522
diff --git a/debian/patches/CVE-2021-20204.patch 
b/debian/patches/CVE-2021-20204.patch
new file mode 100644
index 000..08bb876
--- /dev/null
+++ b/debian/patches/CVE-2021-20204.patch
@@ -0,0 +1,18 @@
+Description: Raise error if returned first_raw in _GD_ParseFieldSpec is NULL
+  Fix for CVE-2021-20204
+Author: Anton Gladky 
+Bug-Debian: https://bugs.debian.org/988239 
+Last-Update: 2021-05-09
+
+--- libgetdata-0.10.0.orig/src/parse.c
 libgetdata-0.10.0/src/parse.c
+@@ -2504,6 +2504,9 @@ char *_GD_ParseFragment(FILE *restrict f
+ if (D->error == GD_E_OK && !match)
+   first_raw = _GD_ParseFieldSpec(D, p, n_cols, in_cols, 
strlen(in_cols[0]),
+   NULL, me, 0, 1, , tok_pos);
++  if (first_raw == NULL) {
++_GD_SetError(D, GD_E_BAD_DIRFILE, GD_E_ENTRY_TYPE, NULL, 0, NULL);
++  }
+ 
+ if (D->error == GD_E_FORMAT) {
+   /* call the callback for this error */
diff --git a/debian/patches/series b/debian/patches/series
index 24c0911..cc09615 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 #python3.patch
+CVE-2021-20204.patch

Bug#988239: Pending

[Anton Gladky]

tags 988239 +pending
thanks

https://salsa.debian.org/science-team/libgetdata/-/commit/d874e3e63fc9c5c5f3008e9803aa1976cc222125

Anton

Bug#987921: linbox FTBFS on 32bit with gcc 10

[Torrance, Douglas]

Control: forwarded -1 https://github.com/linbox-team/linbox/issues/273

On Sun 02 May 2021 12:46:50 AM EDT, Adrian Bunk wrote:
> Source: linbox
> Version: 1.6.3-2
> Severity: serious
> Tags: ftbfs
>
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/i386/linbox.html
>
> ...
> In file included from ../linbox/algorithms/gauss-gf2.h:244,
>  from test-qlup.C:44:
> ../linbox/algorithms/gauss/gauss-solve-gf2.inl: In instantiation of 'Vector1& 
> LinBox::GaussDomain::solveInPlace(Vector1&, SparseSeqMatrix&, 
> const Vector2&) const [with SparseSeqMatrix = LinBox::ZeroOne; 
> Vector1 = LinBox::BitVector; Vector2 = LinBox::BitVector]':
> test-qlup.C:204:18:   required from 'bool testQLUPsolve(const Field&, size_t, 
> unsigned int, int, double) [with Field = LinBox::GF2; Blackbox = 
> LinBox::ZeroOne; RandStream = 
> LinBox::RandomSparseStreamGF2 >; size_t 
> = unsigned int]'
> test-qlup.C:416:86:   required from here
> ../linbox/algorithms/gauss/gauss-solve-gf2.inl:75:52: error: ambiguous 
> overload for 'operator+' (operand types are 'LinBox::BitVector::iterator' and 
> 'std::ptrdiff_t' {aka 'int'})
>75 | for(typename Vector1::iterator 
> it=w.begin()+(ptrdiff_t)Rank;it!=w.end();++it)
>   |   ~^~~~
> In file included from ../linbox/vector/bit-vector.h:191,
>  from ../linbox/field/gf2.h:39,
>  from ../linbox/vector/vector-domain-gf2.h:59,
>  from ../linbox/vector/vector-domain.h:1336,
>  from ../linbox/matrix/matrix-domain.h:35,
>  from ../linbox/matrix/sparsematrix/sparse-generic.h:80,
>  from ../linbox/matrix/sparse-matrix.h:70,
>  from test-qlup.C:42:
> ../linbox/vector/bit-vector.inl:254:12: note: candidate: 
> 'LinBox::BitVector::iterator 
> LinBox::BitVector::iterator::operator+(LinBox::BitVector::iterator::difference_type)
>  const'
>   254 |   iterator operator + (difference_type i) const
>   |^~~~
> In file included from /usr/include/c++/10/vector:68,
>  from ../linbox/util/debug.h:42,
>  from ../linbox/matrix/matrix-traits.h:29,
>  from ../linbox/matrix/sparse-matrix.h:40,
>  from test-qlup.C:42:
> /usr/include/c++/10/bits/stl_bvector.h:303:5: note: candidate: 
> 'std::_Bit_iterator::iterator std::operator+(const iterator&, 
> std::iterator::difference_type)'
>   303 | operator+(const iterator& __x, difference_type __n)
>   | ^~~~
> ...

This has been reported upstream:
https://github.com/linbox-team/linbox/issues/273

Bug#988250: golang-go.opencensus: flaky autopkgtest: timebased test causes mismatched expectation

[Drew Parsons]

Source: golang-go.opencensus
Followup-For: Bug #988250
Control: forwarded -1 
https://github.com/census-instrumentation/opencensus-go/issues/1259

Prevented from emailing cont...@bugs.debian.org directly because of
https://github.com/roundcube/roundcubemail/issues/6438#issuecomment-835782075

Bug#988277: Missing HID driver modules

[Kuan-Yi Li]

Package: src:linux

Dear Maintainer,

HID drivers below for IR receiver, keyboard and serial converter are
missing.

- CONFIG_HID_CREATIVE_SB0540
- CONFIG_HID_GLORIOUS
- CONFIG_HID_GOOGLE_HAMMER
- CONFIG_HID_MCP2221
- This depends on CONFIG_GPIOLIB
- CONFIG_HID_VIVALDI

Cheers,
Kuan-Yi Li

Bug#988264: roundcube-core: Configure script does not set unix socket mysql connection and manually setting it breaks the script

[Guilhem Moulin]

Control: tag -1 moreinfo

On Sun, 09 May 2021 at 01:48:16 -0300, Kurt Fitzner via 
Pkg-roundcube-maintainers wrote:
> If you manually run dpkg-reconfigure roundcube-core, then the full 
> installation
> script is run and you are asked to specify the connection method.  The default
> method purports to be by unix socket (though you can also select tcp/ip).  
> Setting
> this to unix socket, though, has no effect anywhere.  It does not make any 
> changes
> to either /etc/dbconfig-common/roundcube.conf or /etc/roundcube/debian-db.php.

That dialog belongs to dbconfig-common, but AFAICT selecting UNIX
sockets set ‘dbc_dbserver’ to the empty string or to ‘localhost’, which
in turns point dbconfig and roundcube to the MySQLd's default UNIX
socket.  That behavior is consistent with the mysql(1) binary's.

> # dbc_dbserver: database host.
> # leave unset to use localhost (or a more efficient local method
> # if it exists).
> #dbc_dbserver='localhost'
> dbc_dbserver='unix(/var/run/mysqld/mysqld.sock)'
> 
> If you use the above setting you can then generate a config file with:
> 
> $ /usr/sbin/dbconfig-generate-include /etc/dbconfig-common/roundcube.conf
> 
> The generated connection settings from this will cause roundcube to correctly
> log in with unix sockets.  However, if dpkg-reconfigure is subsequently run:
> $ dpkg-reconfigure roiundcube-core
> 
> then it will itself fail with a connection error when it tries to connect to
> mysql.

Reading the dbconfig-common documentation I don't see where to pass the
path to a custom UNIX socket.  So the first step would be to file a
whishlist bug against dbconfig-common and ask for that interface.  Then
we could change debian-db-roundcube.php to pass unix(…) accordingly.
 
> The above setting for dbc_dbserver was crafted to give a correct connection
> string when it is parsed by /etc/roundcube/debian-db-roundcube.php.
> 
> So the issue is, there is no way with the given tools to make persistent
> configuration files that will employ unix sockets.

[/var]/run/mysqld/mysqld.sock is MySQL/MariaDB's default socket path,
and as long as you don't need another path you can set ‘dbc_dbserver’ to
the empty string or to ‘localhost’.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#988276: unblock: base-files/11.1

[Santiago Vila]

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

Please unblock base-files 11.1. Debdiff is attached.

The changes are of two types:

a) Changes for standards compliance and bugs which are trivial to fix
(at the top of changelog) and

b) The "branding" changes which always happen before a stable release
(at the bottom of the changelog).

Thanks.diff -Nru base-files-11/debian/changelog base-files-11.1/debian/changelog
--- base-files-11/debian/changelog  2019-07-09 12:05:50.0 +0200
+++ base-files-11.1/debian/changelog2021-04-10 22:15:00.0 +0200
@@ -1,3 +1,26 @@
+base-files (11.1) unstable; urgency=medium
+
+  * Use https where appropriate, namely, origins/debian (currently used)
+and share/staff-group-for-usr-local (not anymore). Closes: #959470.
+  * Gracefully handle /usr/share/info not existing. Closes: #977113.
+  * Use $() instead of `` where appropriate, namely, the default files
+for /etc/profile and /root/.bashrc. Closes: #982687.
+  * Update share/profile.md5sums as the default file has changed.
+  * Update build-dependency on debhelper.
+  * Release candidate for bullseye as stable:
+  - Use "11" as version in /etc/issue and /etc/issue.net.
+(never expected to change after buster is released)
+  - Use 11.0 as version in /etc/debian_version.
+(expected to change at every point release)
+  - Change PRETTY_NAME in /usr/lib/os-release, adding 11 as version number
+and "(bullseye)" as codename. Add also VERSION_ID and VERSION.
+(never expected to change)
+  - Add VERSION_CODENAME to os-release.
+(only expected on stable releases)
+  - Update README (bullseye -> bookworm).
+
+ -- Santiago Vila   Sat, 10 Apr 2021 22:15:00 +0200
+
 base-files (11) unstable; urgency=medium
 
   * Change issue, issue.net, debian_version and os-release to read
diff -Nru base-files-11/debian/compat base-files-11.1/debian/compat
--- base-files-11/debian/compat 2019-07-09 11:00:00.0 +0200
+++ base-files-11.1/debian/compat   1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru base-files-11/debian/control base-files-11.1/debian/control
--- base-files-11/debian/control2019-07-09 11:00:00.0 +0200
+++ base-files-11.1/debian/control  2021-04-10 22:15:00.0 +0200
@@ -3,7 +3,7 @@
 Priority: required
 Maintainer: Santiago Vila 
 Standards-Version: 4.1.3
-Build-Depends: debhelper (>= 9)
+Build-Depends: debhelper-compat (= 13)
 
 Package: base-files
 Provides: base
diff -Nru base-files-11/debian/postinst.in base-files-11.1/debian/postinst.in
--- base-files-11/debian/postinst.in2019-07-09 11:00:00.0 +0200
+++ base-files-11.1/debian/postinst.in  2021-04-10 22:15:00.0 +0200
@@ -108,7 +108,7 @@
   chmod 644 /var/lib/dpkg/status
 fi
 
-if [ ! -f /usr/info/dir ] && [ ! -f /usr/share/info/dir ]; then
+if [ -d /usr/share/info ] && [ ! -f /usr/info/dir ] && [ ! -f 
/usr/share/info/dir ]; then
   install_from_default info.dir /usr/share/info/dir
   chmod 644 /usr/share/info/dir
 fi
diff -Nru base-files-11/debian/README base-files-11.1/debian/README
--- base-files-11/debian/README 2019-07-09 11:00:00.0 +0200
+++ base-files-11.1/debian/README   2021-04-10 22:15:00.0 +0200
@@ -4,10 +4,10 @@
 * Questions about /etc/issue and /etc/debian_version:
 
 Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "bullseye/sid". Should it not read "bullseye" or "testing"?
+says "bookworm/sid". Should it not read "bookworm" or "testing"?
 
 Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "bullseye/sid". Should it not read "sid" or "unstable"?
+says "bookworm/sid". Should it not read "sid" or "unstable"?
 
 A. That would be nice, but it is not possible because of the way the
 testing distribution works. Packages uploaded for unstable reach
@@ -17,9 +17,9 @@
 two sides of the same coin. Since the base-files package in testing
 was initially uploaded for unstable, the only sensible /etc/issue to
 have is one that is both valid for testing and unstable, hence
-"bullseye/sid" (or whatever is appropriate).
+"bookworm/sid" (or whatever is appropriate).
 
-Q. Why "bullseye/sid" and not "testing/unstable" as it used to be?
+Q. Why "bookworm/sid" and not "testing/unstable" as it used to be?
 
 A. The codename is a little bit more informative, as the meaning of
 "testing" changes over time.
diff -Nru base-files-11/etc/debian_version base-files-11.1/etc/debian_version
--- base-files-11/etc/debian_version2019-07-09 12:00:00.0 +0200
+++ base-files-11.1/etc/debian_version  2021-04-10 22:00:00.0 +0200
@@ -1 +1 @@
-bullseye/sid
+11.0
diff -Nru base-files-11/etc/issue base-files-11.1/etc/issue
--- base-files-11/etc/issue 2019-07-09 12:00:00.0 +0200
+++ base-files-11.1/etc/issue   2021-04-10 22:00:00.0 +0200
@@ -1,2 +1,2 @@
-Debian #OSNAME# bullseye/sid \n \l
+Debian #OSNAME# 11 \n \l
 

Bug#700633: a test record about use eatmydata-udeb

[肖盛文]

Hi,

    I build a custom iso base on Debian 10.9.

I only add the following line in my preseed file, no others change.

d-i partman/early_command \
   string anna-install eatmydata-udeb


The time record is come from /var/log/installer/syslog

    before use eatmydata-udeb:
    May  8 12:43:27 apt-install: Queueing package e2fsprogs for later
installation
    May  8 13:47:47 finish-install: info: Running
/usr/lib/finish-install.d/94save-logs
   
    64min20s
   
    after use eatmydata-udeb:
    May  9 08:36:00 apt-install: Queueing package e2fsprogs for later
installation
    May  9 09:21:46 finish-install: info: Running
/usr/lib/finish-install.d/94save-logs
   
    45min46s



-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988206: Extra information - build succeeded, mic detected, but audio not working

[Pirate Praveen]

Control: forwarded -1 
https://gitlab.gnome.org/GNOME/epiphany/-/issues/611


This is the current status,

https://gitlab.gnome.org/GNOME/epiphany/-/issues/611#note_1101474

These were the options we had to use,

 -DENABLE_MEDIA_STREAM=ON \
  -DENABLE_WEB_RTC=ON \
  -DUSE_SOUP2=ON \
  -DUSE_GSTREAMER_WEBRTC=ON \
  -DUSE_GSTREAMER_GL=ON \

and some more build dependencies

--- webkit2gtk-2.32.0/debian/control 2021-04-22 22:12:46.0 +0530
+++ webkit2gtk-2.32.0+git20210504.c4cdcb6/debian/control 2021-05-09 
11:58:06.339644458 +0530

@@ -41,8 +41,11 @@
   libtasn1-6-dev,
   libwebp-dev,
   libxt-dev,
- libgstreamer1.0-dev (>= 1.14.0),
- libgstreamer-plugins-base1.0-dev (>= 1.14.0),
+ libgstreamer1.0-dev (>= 1.19.0~git),
+ libgstreamer-plugins-base1.0-dev (>= 1.18.4+git),
+ gir1.2-gst-plugins-base-1.0 (>= 1.18.4+git),
+ libdrm-dev,
+ libgbm-dev,
   libenchant-2-dev,
   libsecret-1-dev,
   gobject-introspection (>= 1.32.0),
@@ -50,7 +53,10 @@
   ninja-build,
   libegl1-mesa-dev,
   libgl-dev,
- libgles-dev
+ libgles-dev,
+ liblcms-dev,
+ libgstreamer-plugins-bad1.0-dev,
+ libssl-dev
Build-Depends-Indep: gtk-doc-tools,
   libglib2.0-doc,
   libgtk-3-doc,

I think libgstreamer-plugins-base1.0-dev should depend on these two 
packages : libdrm-dev, libgbm-dev

Bug#982099: lxpanel: randomly fails to display one of the configured launchers

[Francesco Poli]

Control: found -1 lxpanel/0.10.1-2


On Sat, 06 Feb 2021 16:05:29 +0100 Francesco Poli (wintermute) wrote:

[...]
> Please investigate/fix the bug and/or forward my bug report upstream.

Hello again,
any news on bug [#982099]?

[#982099]: 

I experience it on a daily basis and it is quite annoying.
I always have to kill lxpanel (or use "lxpanelctl exit") and start it
over a number of times, before I can see both my launchers.

Have you managed to reproduce the bug?
Any idea on how to fix it?
Have you forwarded my bug report upstream?

Please let me know, thanks for your time.


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


pgp3GQGwUUMYw.pgp
Description: PGP signature

Bug#988274: schroot: support zstd compression for file based chroots

[Helmut Grohne]

Package: schroot
Version: 1.6.10-12
Severity: wishlist
Tags: patch upstream

Please support zstd as a compressor for file backed chroots. zstd is
relatively new, but it provides exceptionally good decompression speeds
at reaonsable compression ratios. I'm attaching a patch to add the
support.

Helmut
--- schroot-1.6.10.orig/etc/setup.d/05file
+++ schroot-1.6.10/etc/setup.d/05file
@@ -38,6 +38,8 @@
 filetype="tzo"
 elif echo "$CHROOT_FILE" | egrep -q '(\.tar\.lz4|\.tlz4)$'; then
 filetype="tlz4"
+elif echo "$CHROOT_FILE" | egrep -q '\.tar\.zstd$'; then
+filetype="tzstd"
 else
 fatal "Unsupported filetype for $CHROOT_FILE"
 fi
@@ -62,6 +64,8 @@
 tar $TAR_VERBOSE --lzop -xf "$CHROOT_FILE"
 elif [ "$filetype" = "tlz4" ]; then
 lz4 -cd "$CHROOT_FILE" | tar $TAR_VERBOSE -x
+elif [ "$filetype" = "tzstd" ]; then
+zstd -cd "$CHROOT_FILE" | tar "$TAR_VERBOSE" -x
 else
 fatal "Unsupported filetype for $CHROOT_FILE"
 fi
@@ -86,6 +90,8 @@
 tar $TAR_VERBOSE --lzop -cf "$NEWFILE" .
 elif [ "$filetype" = "tlz4" ]; then
 tar $TAR_VERBOSE -c . | lz4 > "$NEWFILE"
+elif [ "$filetype" = "tzstd" ]; then
+tar "$TAR_VERBOSE" -c . | zstd > "$NEWFILE"
 else
 fatal "Unsupported filetype for $CHROOT_FILE"
 fi

Bug#988273: geeqie: stereo side-by-side mode broken by 0007-Fix-644-Images-fail-to-render-on-MacOS.patch

[Jiri Bohac]

Package: geeqie
Version: 1:1.6-8
Severity: important

Dear Maintainer,

stereo side-by-side is broken in geeqie;

I found this is caused by 0007-Fix-644-Images-fail-to-render-on-MacOS.patch,
which is a backport of a broken upstream commit.

I reported the problem upstream:
https://github.com/BestImageViewer/geeqie/issues/892

Steps to reproduce:

go to Preferences -> Stereo -> Windowed stereo mode; choose "Side by side"
go to View -> Stereo -> Side by side
view any jpeg file; it is supposed to consider one half as the stereo left 
side and one half as the stereo right side; both sides should be shown next to 
each other, possibly with a dividing black strip between them.
observe the left side - it shows nonsense; the right side is sometimes ok, 
sometimes shows the full picture and not just the righ half



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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.6-8
ii  libc62.31-11
ii  libcairo21.16.0-5
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-2
ii  libdjvulibre21   3.5.28-1
ii  libexiv2-27  0.27.3-3
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-3
ii  libheif1 1.11.0-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblcms2-2   2.12~rc1-2
ii  liblirc-client0  0.10.1-6.3
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpoppler-glib8 20.09.0-3.1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1
ii  libwebp6 0.6.1-2+b1
ii  sensible-utils   0.0.14

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.3op2-3
ii  exiftran 2.10-4
ii  exiv20.27.3-3
ii  imagemagick  8:6.9.11.60+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1
ii  librsvg2-common  2.50.3+dfsg-1
ii  ufraw-batch  0.22-4
ii  zenity   3.32.0-6

Versions of packages geeqie suggests:
pn  geeqie-dbg 
ii  gimp   2.10.22-4
ii  libjpeg-progs  1:9d-1
pn  ufraw  
pn  xpaint 

-- no debconf information

Bug#988261: librsvg2-2: Please drop libcroco3 dependency on alpha, hppa, m68k, sh4, x32

[Simon McVittie]

Control: tags -1 + wontfix

On Sun, 09 May 2021 at 02:24:15 +, Vasyl Gello wrote:
> I encountered the gone dependency of lubrsvg2-2 on libcroco3 doing the test 
> build
> of Kodi 19.1 on x32. Please rebuild librsvg without libcroco3 on the ports.

This is not possible. Current versions of librsvg are written in Rust
and cannot be compiled on architectures where rustc and cargo have not
been bootstrapped.

If rustc and cargo become available on those architectures, new versions
should get compiled automatically by the buildds.

smcv