Bug#1008295: RFP: rtl88x2bu -- a driver for USB WiFi on the RTL8812BU and RTL8822BU Realtek chipsets

[программист некто]

Package: wnpp
Severity: wishlist

Package name :   rtl88x2bu
Version :   v5.13.1
URL  :   https://github.com/RinCat/RTL88x2BU-Linux-Driver
License :   GPL-2

rtl88x2bu - a driver for USB WiFi adapters that are based on the RTL8812BU and 
RTL8822BU Realtek chipsets.

Bug#1008286: Should nglister be removed?

[John Goerzen]

severity 1008286 normal
reassign 1008286 ftp.debian.org
retitle 1008286 RM: nglister -- RoM; unmaintained
thx


On Fri, Mar 25 2022, Moritz Muehlenhoff wrote:

> Source: nglister
> Version: 1.0.2
> Severity: serious
>
> Your package came up as a candidate for removal from Debian:
>
> - Last upload in 2016
> - Removed from testing since 2019
> - Multiple RC bugs
>
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
>
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
>
> --
> severity $BUGNUM normal
> reassign $BUGNUM ftp.debian.org
> retitle $BUGNUM RM:  -- RoM; 
> thx
> --
>
> Otherwise I'll move forward and request it's removal in a month.
>
> Cheers,
> Moritz

Bug#1008292: lintian: inconsistent-appstream-metadata-license seems to be a bad rule

[Eriberto Mota]

After adding a new stanza in debian/copyright to describe the
metafile, the lintian was solved. I was confused because of the '(mit
!= gpl-2+)' sentence. Maybe it could be changed to avoid
misinterpretations.

Sorry for my mistake and feel free to close this bug if you think that
the lintian message is right.

Regards,

Eriberto

Bug#1008293: ITA: gnome-icon-theme -- GNOME Desktop icon theme

[Leonardo Rodrigues Pereira]

Package: wnpp
Severity: normal
Owner: leontecnicalonl...@gmail.com
Control: affects -1 src:gnome-icon-theme

I intend to adopt the gnome-icon-theme package.

The package description is:
 This package contains the default icon theme used by the GNOME desktop.
 The icons are used in the panel menu, and in nautilus and other
 applications, to represent the different applications, files,
 directories, and devices.

Bug#1008292: lintian: inconsistent-appstream-metadata-license seems to be a bad rule

[Joao Eriberto Mota Filho]

Package: lintian
Version: 2.104.0
Severity: normal

Dear maintainer,

When reviewing the package achilles, I added an AppStream metafile with the MIT
licensing. The lintian said me:

  achilles source: inconsistent-appstream-metadata-license 
debian/upstream/net.sourceforge.achilles.achilles.metainfo.xml (mit != gpl-2+) 
[debian/copyright]

So I changed the licensing of the AppStream metafile to GPL-2+. After this, the
tracker.debian.org showed an error 'metainfo-license-invalid' and asked for use
a valid permissive license like FSFAP, CC0-1.0 or MIT. The same message pointed
a link to understand the problem:

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

Part of the text in above weblink says:

  The  tag indicates the content license that you are
  releasing the one metainfo XML file under. This is typically not the same as
  the project license. Omitting the license value will result in the metainfo
  data not being incorporated into metadata collections as used by Linux
  distributions. This tag is required for all metainfo files. [...]  Currently,
  the following licenses have been reviewed and can be used as metadata
  licenses: FSFAP, MIT, 0BSD, CC0-1.0, CC-BY-3.0, CC-BY-4.0, CC-BY-SA-3.0,
  CC-BY-SA-4.0, GFDL-1.1, GFDL-1.2, GFDL-1.3, BSL-1.0, FTL, FSFUL.

Consequently, IMO, this lintian rule is inconsistent and should be dropped.

Regards,

Eriberto

Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate

[Mark Brown]

On Fri, Mar 25, 2022 at 10:50:51PM +0100, Salvatore Bonaccorso wrote:

> Here is a preliminary debdiff to address this.

Thanks, that's roughly what I uploaded - it looks like your mail
raced with my own update.


signature.asc
Description: PGP signature

Bug#1007234: Test suite fails on all but amd64 arches

[Bryan Henderson]

I don't know familiar you are with debuggers, C, or C arithmetic, so I'm
attaching a diagnostic version of the program and will also explain where I
think the problem lies in case you want to investigate on your own.

If you put this .c file in converter/other/pnmtopalm/ and rebuild and run the
'palmtopnm' executable that results, it should detect the failure and write
some useful diagnostic messages.  Tell me what happens.


The problem is in function 'readPackBitsRow16'.  The variable 'j' is getting
too large -- absurdly large, apparently because a bit code that is supposed to
encode a negative signed integer is being interpreted as a positive unsigned
one somewhere.  It should not be hard to pinpoint where the arithmetic is
generating such a a large number.

-- 
Bryan Henderson   San Jose, California/**
 palmtopnm
***
  By Bryan Henderson, San Jose, California, June 2004.

  Inspired by and using methods from Tbmptopnm by Ian Goldberg
  , and Bill Janssen .

  Major fixes and new capability added by Paul Bolle 
  in late 2004 / early 2005.

  Bryan's work is contributed to the public domain by its author.
**/

#include 
#include 

#include "pm_c_util.h"
#include "pnm.h"
#include "shhopt.h"
#include "mallocvar.h"

#include "palm.h"
#include "palmcolormap.h"



enum PalmCompressionType {
COMPRESSION_NONE,
COMPRESSION_RLE,
COMPRESSION_SCANLINE,
COMPRESSION_PACKBITS
};

struct PalmHeader {
unsigned short cols;
unsigned short rows;
unsigned short bytesPerRow;
unsigned short flags;
bool   directColor;
/* The header indicates a direct color raster, either by flag
   (the old way) or by pixel format (the new way)
*/
bool   hasColormap;
bool   hasTransparency;
unsigned char  pixelSizeCode;
unsigned int   pixelSize;
unsigned char  version;
unsigned int   transparentIndex;
enum PalmCompressionType compressionType;
/* version 3 encoding specific */
unsigned char  size;
unsigned char  pixelFormat;
unsigned short density;
unsigned long  transparentValue;
};



struct DirectPixelFormat {
unsigned int redbits;
unsigned int greenbits;
unsigned int bluebits;
};



struct DirectColorInfo {
struct DirectPixelFormat pixelFormat;
ColormapEntrytransparentColor;
};




struct CmdlineInfo {
/* All the information the user supplied in the command line,
   in a form easy for the program to use.
*/
const char * inputFilespec;
unsigned int verbose;
unsigned int rendition;
unsigned int showhist;
unsigned int transparent;
};


static void
parseCommandLine(int argc, const char ** argv,
 struct CmdlineInfo *cmdlineP) {
/*
   Note that the file spec array we return is stored in the storage that
   was passed to us as the argv array.
-*/
optEntry * option_def;
/* Instructions to pm_optParseOptions3 on how to parse our options.
 */
optStruct3 opt;

unsigned int renditionSpec;

unsigned int option_def_index;

MALLOCARRAY_NOFAIL(option_def, 100);

option_def_index = 0;   /* incremented by OPTENTRY */
OPTENT3(0, "verbose", OPT_FLAG, NULL,
>verbose,  0);
OPTENT3(0, "showhist",OPT_FLAG, NULL,
>showhist, 0);
OPTENT3(0, "transparent",OPT_FLAG, NULL,
>transparent, 0);
OPTENT3(0, "rendition",  OPT_UINT, >rendition,
, 0);

opt.opt_table = option_def;
opt.short_allowed = FALSE;  /* We have no short (old-fashioned) options */
opt.allowNegNum = FALSE;  /* We may have parms that are negative numbers */

pm_optParseOptions3(, (char **)argv, opt, sizeof(opt), 0);
/* Uses and sets argc, argv, and some of *cmdlineP and others. */


if (renditionSpec) {
if (cmdlineP->rendition < 1)
pm_error("The -rendition value must be at least 1");
} else
cmdlineP->rendition = 1;

if (cmdlineP->transparent && cmdlineP->showhist)
pm_error("You can't specify -showhist with -transparent");

if (argc-1 < 1)
cmdlineP->inputFilespec = "-";
else {
cmdlineP->inputFilespec = argv[1];
if (argc-1 > 1)
pm_error("Too many arguments (%d).  The only non-option "
 "argument is the file name", argc-1);
}
free(option_def);
}



static xelval *
createGraymap(unsigned int const ncolors,
  xelval   const maxval) {
int i;
xelval *map;

MALLOCARRAY_NOFAIL(map, ncolors);
  

Bug#1008235: Acknowledgement (bash: corrupting variables containing long unicode content)

[Eduardo Bustamante]

On Fri, Mar 25, 2022 at 3:36 PM Leszek Dubiel  wrote:

>
> Some more tests were done on:
>
> - ubuntu 22.04 (5.15.0-23)
> - ubuntu 20.04 (5.13.0-35)
> - fedora 35 (5.14.10-300)
> - debian 10 (4.19.0-19)
> - debian 11 (5.10.0-11) - bash 5.1-2
> - debian testing (5.16.0-5)
>
> Error is only on debian 11.
>
> If you upgrade bash 5.1-2 to 5.1-6 then but is resolved.
>
> So the bug maybe is only in bash version 5.1-2
>

I believe this is the same bug as reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003012 and upstream in
https://lists.gnu.org/archive/html/bug-bash/2022-01/msg0.html

Bug#1008290: Unable to install node-babel7 because the same file is present in another binary.

[shirish शिरीष]

Package: node-babel7
Version: 7.17.6+~cs214.260.190-1
Severity: normal

Dear Maintainer,
Got the following while upgrading today -

Unpacking node-babel7 (7.17.8+~cs214.260.191-2) over
(7.17.6+~cs214.260.190-1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-dogkWA/60-node-babel7_7.17.8+~cs214.260.191-2_all.deb
(--unpack):
 trying to overwrite '/usr/share/doc/node-babel-types/copyright',
which is also in package node-babel-types 6.26.0+repack-4

$ aptitude search node-babel7
Bu  node-babel7  - Babel
command line
i A node-babel7-runtime  - Babel
modular runtime helpers
p   node-babel7-standalone   - Standalone
build of Babel for use in browsers and other non-No

Please fix the same, thank you.

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

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

Versions of packages node-babel7 depends on:
ii  node-ampproject-remapping 2.1.2+~cs4.7.20-1
ii  node-babel-plugin-add-module-exports  1.0.4+dfsg1~cs5.8.0-3
ii  node-babel7-runtime   7.17.8+~cs214.260.191-2
ii  node-browserslist 4.20.0+~cs5.1.3-1
ii  node-chalk4.1.2-1
ii  node-clone-deep   4.0.1-3
ii  node-commander9.1.0-1
ii  node-convert-source-map   1.8.0+~1.5.2-1
ii  node-core-js  3.8.2-3
ii  node-debug4.3.3+~cs4.1.7-1
ii  node-esutils  2.0.3-3
ii  node-find-cache-dir   3.3.2+~3.2.1-1
ii  node-fs-readdir-recursive 1.1.0-2
ii  node-glob 7.2.1+~cs7.6.15-1
ii  node-globals  13.12.1-1
ii  node-js-tokens7.0.0-1
ii  node-jsesc3.0.2+~3.0.1-1
ii  node-json52.2.0+dfsg-1
ii  node-lodash   4.17.21+dfsg+~cs8.31.198.20210220-5
ii  node-lodash-packages  4.17.21+dfsg+~cs8.31.198.20210220-5
ii  node-make-dir 3.1.0-2
ii  node-quick-lru5.1.1-1
ii  node-regenerator-transform0.14.5-4
ii  node-regexpu-core 4.8.0-4
ii  node-resolve  1.20.0+~cs5.27.9-1
ii  node-semver   7.3.5+~7.3.8-1
ii  node-slash3.0.0-2
ii  node-source-map   0.7.0++dfsg2+really.0.6.1-9
ii  node-source-map-support   0.5.21+ds+~0.5.4-1
ii  node-to-fast-properties   3.0.1-2
ii  node-v8flags  3.2.0-3
ii  nodejs12.22.10~dfsg-2

node-babel7 recommends no packages.

node-babel7 suggests no packages.

-- no debconf information
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
https://creativecommons.org/licenses/by-nc/3.0/
https://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#1008291: ITP: distrobox -- Another tool for containerized command line environments on Linux

[Michel Alexandre Salim]

Package: wnpp
Severity: wishlist
Owner: Michel Alexandre Salim 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: distrobox
  Version : 1.2.14
  Upstream Author : Luca Di Maio 
* URL : https://distrobox.privatedns.org/
* License : GPL
  Programming Lang: Bash
  Description : Another tool for containerized command line environments on 
Linux

Use any linux distribution inside your terminal. Enable both backward and
forward compatibility with software and freedom to use whatever distribution
you’re more comfortable with. 

 - usefulness
Much more flexible than Toolbx, which inspires it:
https://fedoramagazine.org/toolbx-a-developers-new-best-friend/ -
Toolbx requires specialized containers which currently are only
available for Fedora.

 - not a dependency for another package
 - I use it everyday, for compatibility testing on different distributions
   and releases

 - comparison with similar packages
   - more flexible than Toolbx
   - this wraps Podman and Docker and preconfigure the containers (e.g.
 giving them home directory access, installing the shell you use on
 the host on the container too) so it's much easier to use
 - maintenance
   - no packaging team seems to match, so I plan to maintain this
 individually. I'm new to Debian packaging (coming from Fedora where
 I'm the equivalent of a Debian Developer), so will be using
 https://mentors.debian.net/. I do have more packages to ITP, but
 want to start small with a package where the upstream author has
 expressed an interest in getting this packaged: 
https://github.com/89luca89/distrobox/issues/153
   - yes, I will need a sponsor

Bug#1008289: ITP: awsome-cis-checker -- CIS Benchmark checker for AWS

[Pedro Loami Barbosa dos Santos]

Package: wnpp
Severity: wishlist
Owner: Pedro Loami Barbosa dos Santos 

* Package name: awsome-cis-checker
  Version : 1.0
  Upstream Author : Secforce, David R. @Fiti
* URL : https://github.com/SECFORCE/awsome-cis-checker
* License : MIT
  Programming Lang: Python
  Description : CIS Benchmark checker for AWS

 AWSome CIS Checker is a tool designed to automate the whole process 
 of checking AWS configurations in accordance with one of the most 
 widely used industry best practice guides: the CIS Benchmarks.
 .
 Based on Boto3, an AWS SDK for Python, AWSome CIS Checker uses the 
 set of credentials provided on a local AWS Client configuration to 
 verify if the elements of a certain configuration are compliant with 
 CIS Benchmarks. This covers all the basic checks but also allows for 
 a “deeper” inspection of the configuration by investigating more 
 obscure options which could facilitate further attacks vectors. 


This package is useful to a pentester, or any other security aware
professional to identify potential security risks within their AWS
environment, by running a checklist based on CIS Benchmarks best
practice guides. Hopefully this tool will increase coverage during
security assessment and also will help sysadmins to understand better
their AWS infrastructure and consequently improve the security of 
their environments. More information about the tool and its developers
can be found here: https://www.secforce.com/blog/awsome-cis-checker/

This package will be maintened by me, with support of my mentor/
sponsor and in collaboration with the upstream.

Bug#1008288: ITP: golang-github-gobwas-httphead -- Tiny HTTP header value parsing lib (library)

[Guilherme de Paula Xavier Segundo]

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

* Package name: golang-github-gobwas-httphead
  Version : 0.1.0-1
  Upstream Author : Sergey Kamardin 
* URL : https://github.com/gobwas/httphead
* License : Expat
  Programming Lang: Go
  Description : Tiny HTTP header value parsing lib (library)

 This library contains low-level functions for scanning HTTP RFC2616
 compatible header value grammars. Utils for parsing HTTP and
 HTTP-grammar compatible text protocols headers.

Bug#1007199: closed by Bastian Blank (Re: Bug#1007199: ipxe: fails to boot on Geode LX)

[Martin-Éric Racine]

Come again? Geode LX is a barebone 686. It's the base level for i386 on
Debian.

Martin-Eric

la 26. maalisk. 2022 klo 0.33 Debian Bug Tracking System <
ow...@bugs.debian.org> kirjoitti:

> This is an automatic notification regarding your Bug report
> which was filed against the ipxe package:
>
> #1007199: ipxe: fails to boot on Geode LX
>
> It has been closed by Bastian Blank .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Bastian Blank <
> wa...@debian.org> by
> replying to this email.
>
>
> --
> 1007199: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007199
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Bastian Blank 
> To: 1007199-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 25 Mar 2022 23:19:56 +0100
> Subject: Re: Bug#1007199: ipxe: fails to boot on Geode LX
> Control: tags -1 wontfix
>
> On Sun, Mar 13, 2022 at 03:39:03PM +0200, Martin-Éric Racine wrote:
> > The version of iPXE currently in Bookworm fails to launch on a Geode LX
> host. The screen remains blank for ages. The binary seemingly freezes the
> host. Pressing the power button has no effect. The power cord must be
> pulled out for the host to recover and be bootable again.
>
> Sorry, this system is out of spec for Debian.
>
> Bastian
>
> --
> You can't evaluate a man by logic alone.
> -- McCoy, "I, Mudd", stardate 4513.3
>
>
> -- Forwarded message --
> From: "Martin-Éric Racine" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 13 Mar 2022 15:39:03 +0200
> Subject: ipxe: fails to boot on Geode LX
> Package: ipxe
> Version: 1.0.0+git-20190125.36a4c85-5.1
> Severity: important
>
> The version of iPXE currently in Bookworm fails to launch on a Geode LX
> host. The screen remains blank for ages. The binary seemingly freezes the
> host. Pressing the power button has no effect. The power cord must be
> pulled out for the host to recover and be bootable again.
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500,
> 'testing')
> Architecture: i386 (i586)
>
> Kernel: Linux 5.16.0-4-686 (SMP w/1 CPU thread; PREEMPT)
> Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
> Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8),
> LANGUAGE=fi:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> -- no debconf information
>

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Vincent Bernat]

 ❦ 25 March 2022 11:48 +01, Arturo Borrero Gonzalez:

>> After looking twice, I notice the VIP is in the same subnet as the peer.
>> If you don't have any other address on the subnet, I don't see how this
>> could work. If you have, maybe it would be better to use a /32 for the
>> VIP.
>
> Would you mind to elaborate?
>
> The setup is as follows:
>
> * peer 1, local IP 208.80.153.188/29
> * peer 2, local IP 208.80.153.189/29
> * VIP 208.80.153.190/29
>
> I honestly don't know how this relates to the execution error itself.
> Do you think the address assignment fails because some misconfigured
> netmask?

Usually, on Linux, VIP are using /32 to avoid issues with source address
selection. Notably, when contacting a peer, the VIP could be selected
when using a /29, while this is not possible when using a /32.
-- 
Its name is Public Opinion.  It is held in reverence.  It settles everything.
Some think it is the voice of God.
-- Mark Twain

Bug#1008287: Failed install of npm backports package

[Christian P. MOMON]

Package: npm
Version: 8.3.1~ds-1~bpo11+1

   When I install the npm backports package, I get an error:

root@pad:/etc/apt# apt install -t bullseye-backports npm
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  npm : Depends: nodejs:any (>= 10) but it is not installable
Recommends: node-tap but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


  Yet the nodejs package is installed with good version:

root@pad:/etc/apt# dpkg -l nodejs apt
ii  apt2.2.4   amd64commandline package 
manager
ii  nodejs 12.22.5~dfsg-2~11u1 amd64evented I/O for V8 
javascript - runtime executable


root@pad:/etc/apt# grep "^deb" sources.list
deb http://deb.debian.org/debian/ bullseye main
deb-src http://deb.debian.org/debian/ bullseye main
deb http://security.debian.org/debian-security bullseye-security main
deb-src http://security.debian.org/debian-security bullseye-security main
deb http://deb.debian.org/debian/ bullseye-updates main
deb-src http://deb.debian.org/debian/ bullseye-updates main
deb http://deb.debian.org/debian bullseye-backports main



I am using Debian Stable up to date:
root@pad:/etc/apt# cat /etc/debian_version
11.2
root@pad:/etc/apt# uname -a
Linux pad 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 (2022-03-07) x86_64 
GNU/Linux


  With all my encouragement,

  Cpm.
--
Christian Pierre MOMON
Tél. +33 (0)6 26 72 40 04


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008235: Acknowledgement (bash: corrupting variables containing long unicode content)

[Leszek Dubiel]

Some more tests were done on:

- ubuntu 22.04 (5.15.0-23)
- ubuntu 20.04 (5.13.0-35)
- fedora 35 (5.14.10-300)
- debian 10 (4.19.0-19)
- debian 11 (5.10.0-11) - bash 5.1-2
- debian testing (5.16.0-5)

Error is only on debian 11.

If you upgrade bash 5.1-2 to 5.1-6 then but is resolved.

So the bug maybe is only in bash version 5.1-2

Bug#1008286: Should nglister be removed?

[Moritz Muehlenhoff]

Source: nglister
Version: 1.0.2
Severity: serious

Your package came up as a candidate for removal from Debian:

- Last upload in 2016
- Removed from testing since 2019
- Multiple RC bugs  

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008285: Should zorp be removed?

[Moritz Muehlenhoff]

Source: zorp
Version: 7.0.1~alpha2-3
Severity: serious

Your package came up as a candidate for removal from Debian:

- Last upload in 2019, removed from testing since 2017
- Still depends on Python 2.7 and thus RC-buggy

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008284: Naming convention of Debian-introduced files are too confusing.

[S E]

Package: exim-configVersion: 4.95-4

Content-Type: text/plain; charset="us-ascii"MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: S Egbert 
To: Debian Bug Tracking System 
Subject: exim4-config: naming convention of Debian-specific config files is 
confusing
Message-ID: <164124462535.48205.15761425627014536345.report...@ns1.egbert.net>
X-Mailer: reportbug 7.10.3+deb11u1
Date: Fri, 25 Mar 2022 17:44:45 -0400

X-Debbugs-Cc: s.egb...@sbcglobal.net Version: 4.95-4 Severity: normal Tags: a11y

Dear Maintainer,


File naming convention for several Debian-introduced files are too confusing.

Using Debian Testing exim4-config v4.95-4 package. (I do not know why 
`reportbug` is picking up `exim4` version instead of my requested 
`exim4-config` package name.

I was thinking maybe it might need to have several Debian-specific files 
renamed with respect to different filetypes.

Naming convention could have been more intuitive. Such as:

    update-exim4.conf could be better named as update-exim4-conf (or 
update-exim4)
    update-exim4.conf.conf could be better named as exim4.debian.conf: then we 
would know which one to go to exim4.conf/exim4.conf.debian.
    update-exim4.conf.template ... whew ... could have been 
exim4.conf.template.debian.
    /var/lib/exim4/config.autogenerated could have beeen 
/var/lib/exim4/exim4.conf.autogenerated.

In reality, Debian should co-opt some standardized prefix (perhaps, `dpkgc-`) 
for all package maintainers to use and do that dpkg-reconfigure/dpkg-configure 
thingie instead of `update-exim4.conf`.
I made a Bash file script to make heads and tails on WHO is using WHICH config 
file(s) and by WHAT Debian config file methods.

Reference:

https://github.com/egberts/exim4-config-check-which




-- Package-specific info:
Exim version 4.94.2 #2 built 13-Jul-2021 16:04:57
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP 
PIPE_CONNECT PRDR PROXY SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
##
#
# NOTE: DO NOT USE if `/etc/exim4/exim4.conf` exists
#
# NOTE: DO SET `dc_use_split_configuration` to `no`
#   if you do not want `dpkg-reconfigure exim4-config` to
#   tamper with your Exim4 settings.
#
##
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='internet'
dc_other_hostnames='egbert.net'
dc_local_interfaces='127.0.0.0 ; ::1 ; 104.218.48.116 ; 2604:a00:5:1156::116'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='640'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
dc_local_part='*- : *+ : *_'
dc_main_tls_certificate='/etc/exim/keys/cert.pem'
dc_main_tls_privatekey='/etc/exim/keys/privkey.pem'
mailname:egbert.net
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' - one daemon running queue and listening on SMTP port
# 'no'   - no daemon running the queue
# 'separate' - two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to 

Bug#1008283: Really confusing update-exim4.conf(8) man page

[S E]

Package: exim-configVersion: 4.95-4
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: S Egbert 
To: Debian Bug Tracking System 
Subject: exim4-config: Really confusing update-exim4.conf(8) man page Package: 
exim4-config 
Message-ID: <164824462535.48205.15761425627014536345.report...@ns1.egbert.net>
X-Mailer: reportbug 7.10.3+deb11u1
Date: Fri, 25 Mar 2022 17:43:45 -0400

X-Debbugs-Cc: s.egb...@sbcglobal.net Version: 4.95-4 Severity: normal Tags: a11y

Dear Maintainer,

Pulling up the manpage for 'update-exim4.conf'...  read in the first FIVE 
paragraphs,
still unable to comprehend.  Had to write it down a flowchart.

Analyzed the bash script of 'update-exim4.conf', wrote the semantic logic
down in a separate bash script.


Just my two-cents worth.

Bash file script to make heads and tails on WHO is using WHICH config 
file(s) and by WHAT Debian config file methods.

Reference:

https://github.com/egberts/exim4-config-check-which


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

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

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


-- Package-specific info:
Exim version 4.94.2 #2 built 13-Jul-2021 16:04:57
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP 
PIPE_CONNECT PRDR PROXY SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
##
#
# NOTE: DO NOT USE if `/etc/exim4/exim4.conf` exists
#
# NOTE: DO SET `dc_use_split_configuration` to `no`
#   if you do not want `dpkg-reconfigure exim4-config` to
#   tamper with your Exim4 settings.
#
##
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='internet'
dc_other_hostnames='egbert.net'
dc_local_interfaces='127.0.0.0 ; ::1 ; 104.218.48.116 ; 2604:a00:5:1156::116'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='640'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
dc_local_part='*- : *+ : *_'
dc_main_tls_certificate='/etc/exim/keys/cert.pem'
dc_main_tls_privatekey='/etc/exim/keys/privkey.pem'
mailname:egbert.net
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -     one daemon running queue and listening on SMTP port
# 'no'   -     no daemon running the queue
# 'separate' -     two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on
# port 25 only. To listen on more ports, it is recommended to use
# -oX 

Bug#1008281: (no subject)

[Petr Vorel]

> IMHO more secure is to allow users to use ICMP socket.

Correct term is "ICMP_PROTO sockets".

Kind regards,
Petr

Bug#1008282: ITP: gl-image-display -- Image-display library backed by OpenGL. Provided are a C library and a FLTK widget with C++ and Python interfaces

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: gl-image-display
  Version : 0.10
  Upstream Author : Dima Kogan 
* URL or Web page : https://github.com/dkogan/GL_image_display
* License : Apache 2.0
  Description : Image-display library backed by OpenGL. Provided are a C 
library and a FLTK widget with C++ and Python interfaces

This is a dependency of mrcal 2.2, which will be released soon, and
uploaded to Debian when this library makes it to the archive.

Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate

[Salvatore Bonaccorso]

Control; tags -1 + patch

Hi Mark,

On Fri, Mar 25, 2022 at 05:31:44PM +0100, Moritz Muehlenhoff wrote:
> Source: zlib
> Version: 1:1.2.11.dfsg-2
> Severity: grave
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> This was assigned CVE-2018-25032:
> https://www.openwall.com/lists/oss-security/2022/03/24/1
> https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

Here is a preliminary debdiff to address this.

Regards,
Salvatore
diff -Nru zlib-1.2.11.dfsg/debian/changelog zlib-1.2.11.dfsg/debian/changelog
--- zlib-1.2.11.dfsg/debian/changelog   2022-03-18 01:21:37.0 +0100
+++ zlib-1.2.11.dfsg/debian/changelog   2022-03-25 22:46:38.0 +0100
@@ -1,3 +1,11 @@
+zlib (1:1.2.11.dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix a bug that can crash deflate on some input when using Z_FIXED
+(CVE-2018-25032) (Closes: #1008265)
+
+ -- Salvatore Bonaccorso   Fri, 25 Mar 2022 22:46:38 +0100
+
 zlib (1:1.2.11.dfsg-3) unstable; urgency=low
 
   * Add build-arch and build-indep (#999292).
diff -Nru 
zlib-1.2.11.dfsg/debian/patches/Fix-a-bug-that-can-crash-deflate-on-some-input-when-.patch
 
zlib-1.2.11.dfsg/debian/patches/Fix-a-bug-that-can-crash-deflate-on-some-input-when-.patch
--- 
zlib-1.2.11.dfsg/debian/patches/Fix-a-bug-that-can-crash-deflate-on-some-input-when-.patch
  1970-01-01 01:00:00.0 +0100
+++ 
zlib-1.2.11.dfsg/debian/patches/Fix-a-bug-that-can-crash-deflate-on-some-input-when-.patch
  2022-03-25 22:46:38.0 +0100
@@ -0,0 +1,347 @@
+From: Mark Adler 
+Date: Tue, 17 Apr 2018 22:09:22 -0700
+Subject: Fix a bug that can crash deflate on some input when using Z_FIXED.
+Origin: 
https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531
+Bug-Debian: https://bugs.debian.org/1008265
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-25032
+
+This bug was reported by Danilo Ramos of Eideticom, Inc. It has
+lain in wait 13 years before being found! The bug was introduced
+in zlib 1.2.2.2, with the addition of the Z_FIXED option. That
+option forces the use of fixed Huffman codes. For rare inputs with
+a large number of distant matches, the pending buffer into which
+the compressed data is written can overwrite the distance symbol
+table which it overlays. That results in corrupted output due to
+invalid distances, and can result in out-of-bound accesses,
+crashing the application.
+
+The fix here combines the distance buffer and literal/length
+buffers into a single symbol buffer. Now three bytes of pending
+buffer space are opened up for each literal or length/distance
+pair consumed, instead of the previous two bytes. This assures
+that the pending buffer cannot overwrite the symbol table, since
+the maximum fixed code compressed length/distance is 31 bits, and
+since there are four bytes of pending space for every three bytes
+of symbol space.
+---
+ deflate.c | 74 ---
+ deflate.h | 25 +--
+ trees.c   | 50 +++--
+ 3 files changed, 79 insertions(+), 70 deletions(-)
+
+diff --git a/deflate.c b/deflate.c
+index 425babc00c33..19cba873ae98 100644
+--- a/deflate.c
 b/deflate.c
+@@ -255,11 +255,6 @@ int ZEXPORT deflateInit2_(strm, level, method, 
windowBits, memLevel, strategy,
+ int wrap = 1;
+ static const char my_version[] = ZLIB_VERSION;
+ 
+-ushf *overlay;
+-/* We overlay pending_buf and d_buf+l_buf. This works since the average
+- * output size for (length,distance) codes is <= 24 bits.
+- */
+-
+ if (version == Z_NULL || version[0] != my_version[0] ||
+ stream_size != sizeof(z_stream)) {
+ return Z_VERSION_ERROR;
+@@ -329,9 +324,47 @@ int ZEXPORT deflateInit2_(strm, level, method, 
windowBits, memLevel, strategy,
+ 
+ s->lit_bufsize = 1 << (memLevel + 6); /* 16K elements by default */
+ 
+-overlay = (ushf *) ZALLOC(strm, s->lit_bufsize, sizeof(ush)+2);
+-s->pending_buf = (uchf *) overlay;
+-s->pending_buf_size = (ulg)s->lit_bufsize * (sizeof(ush)+2L);
++/* We overlay pending_buf and sym_buf. This works since the average size
++ * for length/distance pairs over any compressed block is assured to be 31
++ * bits or less.
++ *
++ * Analysis: The longest fixed codes are a length code of 8 bits plus 5
++ * extra bits, for lengths 131 to 257. The longest fixed distance codes 
are
++ * 5 bits plus 13 extra bits, for distances 16385 to 32768. The longest
++ * possible fixed-codes length/distance pair is then 31 bits total.
++ *
++ * sym_buf starts one-fourth of the way into pending_buf. So there are
++ * three bytes in sym_buf for every four bytes in pending_buf. Each symbol
++ * in sym_buf is three bytes -- two for the distance and one for the
++ * literal/length. As each symbol is consumed, the pointer to the next
++ * sym_buf value to read moves forward three bytes. 

Bug#1008281: iputils-ping: Move from capabilities to ICMP socket

[Petr Vorel]

Package: iputils-ping
Version: 3:20211215-1
Severity: important

Dear Maintainer,

ping in Debian uses capabilities:

$ getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=ep # NOTE: cap_net_raw+p would be enough

This is required for normal user to be able to open RAW socket.

IMHO more secure is to allow users to use ICMP socket.
All what is required is to set net.ipv4.ping_group_range:

sysctl net.ipv4.ping_group_range="0 2147483647"

Not sure how adding sysctl config in /etc/sysctl.d/ for package works in Debian.

Kind regards,
Petr

Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases

[Thorsten Glaser]

Package: pstoedit
Version: 3.75-1
Severity: serious
Justification: unusable by some users
X-Debbugs-Cc: t...@mirbsd.de, hill...@web.de, debian-tex-ma...@lists.debian.org
Control: affects -1 purifyeps

I’ve noticed purifyeps (which is needed for Tₑχ/LᴬTᴇΧ to process .eps files)
fails on some inputs and could trace this down to pstoedit’s output for the
broken files to be much too small.

I’m attaching the full testcase with sources and all intermediate files.

This is on a bullseye system (plus two debugging prints in purifyeps which
Hilmar should just ignore comparing his output to mine).

The full screen log of the process (from SVG via PDF to EPS) follows, for
a sampling of two files, one of which succeeds, the other doesn’t. Very
noticeable, besides the test-1.mp size, is “x: 99 y: 99 x: 0 y: 0”
(failure) vs. x: 0 y: 0 x: 22 y: 13 (success).


$ inkscape -D --export-filename=test1.pdf --export-type=pdf 
--export-pdf-version=1.4 teckids_logo_image.svg

(inkscape:25600): dbind-WARNING **: 22:09:15.196: AT-SPI: 
Error retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
provided by any .service files
$ pdftops -eps test1.pdf test1-a.eps
$ purifyeps test1-a.eps test1-b.eps
D: running: pstoedit -ssp -f mpost -fontmap "/usr/share/pstoedit/mpost.fmp" 
"test1-a.eps" "/tmp/purifyeps-V7yHSU2q.mp" 1>&2
pstoedit: version 3.75 / DLL interface 108 (built: Jan  2 2020 - release build 
- g++ 9.2.1 20191130 - 64-bit) : Copyright (C) 1993 - 2020 Wolfgang Glunz
D: running: echo X | mpost /tmp/purifyeps-V7yHSU2q.mp 1>&2
This is MetaPost, version 2.00 (TeX Live 2020/Debian) (kpathsea version 6.3.2)
(/usr/share/texlive/texmf-dist/metapost/base/mpost.mp
(/usr/share/texlive/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) ) (/tmp/purifyeps-V7yHSU2q.mp )
Transcript written on purifyeps-V7yHSU2q.log.
purifyeps: No such file or directory (/tmp/purifyeps-V7yHSU2q.1)
D: tempbase=/tmp/purifyeps-V7yHSU2q
$ pstoedit -v -ssp -f mpost -fontmap "/usr/share/pstoedit/mpost.fmp" 
test1-a.eps test-1.mp
pstoedit: version 3.75 / DLL interface 108 (built: Jan  2 2020 - release build 
- g++ 9.2.1 20191130 - 64-bit) : Copyright (C) 1993 - 2020 Wolfgang Glunz
loading plugins from /usr/lib/x86_64-linux-gnu/pstoedit using suffix: .so
loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so
creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so
loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so 
completed successfully
loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvwmf.so
creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvwmf.so
loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvwmf.so 
completed successfully
loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvlplot.so
creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvlplot.so
loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvlplot.so 
completed successfully
loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvstd.so
creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvstd.so
loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvstd.so 
completed successfully
loading plugin: /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvpptx.so
creating Dynloader for /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvpptx.so
loading dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvpptx.so 
completed successfully
path to myself: /usr/bin/pstoedit
pstoedit home directory : /usr/bin
pstoedit data directory : /usr/share/pstoedit
Loading fontmap from /usr/share/pstoedit/mpost.fmp
loading system specific fontmap from /usr/share/pstoedit/windows.fmp

Looking up where to find the PostScript interpreter.
GS not set, trying registry for common/gstocall
nothing found so far, trying default: gs
Value found is:gs

Looking up specific options for the PostScript interpreter.
First trying registry for common/GS_LIB
still not found an entry - now trying GS_LIB env var.
GS_LIB not set
Value returned:

now calling the interpreter via: gs -dDELAYBIND -dWRITESYSTEMDICT -dESTACKPRINT 
-dNODISPLAY -dDELAYSAFER -dNOEPS "/tmp/psine2b20s"
GPL Ghostscript 9.53.3 (2020-10-01)
Copyright (C) 2020 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Now checking the temporary output
 got 1 page(s) from /tmp/psoutFgTRot
x: 99 y: 99 x: 0 y: 0
now postprocessing the interpreter output
postprocessing the interpreter output finished
closing dynamic library /usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so
not really closing dynamic library because of pthread problem under Linux - 
contact author for details or check dynload.cpp from pstoedit source code 
/usr/lib/x86_64-linux-gnu/pstoedit/libp2edrvmagick++.so
destroying Dynloader 

Bug#1005197: pcmemtest: please make the build partly reproducible

[Vagrant Cascadian]

On 2022-03-25, Felix Zielcke wrote:
> Am Mittwoch, dem 23.02.2022 um 09:36 +0100 schrieb Thomas Schmitt:
> I totally forgot about this. Sorry!
>
> I just tried to test it with TZ set.
> But I always get the same binaries. No matter to what I change TZ or
> /etc/timezone between the builds.
>
> So is this just a bullseye problem? unstable has a newer mtools
>
> I'll try to test this in stable chroot the next days

I can reproduce the issue in a debian sid chroot with pcmemtest 1.5-3
from debian, using:

  reprotest --verbose --min-cpus=1 
--vary=-user_group,-domain_host,-fileordering auto -- null

Passing TZ=UTC in three different ways, exporting TZ=UTC from
debian/rules, exporting TZ=UTC from the upstream Makefiles, and
prepending the mcopy calls in the upstream Makefiles. All three
approaches are below:

diff --git a/debian/rules b/debian/rules
index 9477c3e..860be75 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f

+export TZ=UTC
+
 %:
dh $@


Alternately, by patching the upstream Makefiles:

diff --git a/build32/Makefile b/build32/Makefile
index 1d47859..93a671f 100644
--- a/build32/Makefile
+++ b/build32/Makefile
@@ -47,6 +47,8 @@ APP_OBJS = app/badram.o \

 OBJS = boot/startup.o boot/efisetup.o $(SYS_OBJS) $(LIB_OBJS) $(TST_OBJS) 
$(APP_OBJS)

+export TZ=UTC
+
 all: memtest.bin memtest.efi

 -include boot/efisetup.d
diff --git a/build64/Makefile b/build64/Makefile
index 24e1ddc..0094868 100644
--- a/build64/Makefile
+++ b/build64/Makefile
@@ -46,6 +46,8 @@ APP_OBJS = app/badram.o \

 OBJS = boot/startup.o boot/efisetup.o $(SYS_OBJS) $(LIB_OBJS) $(TST_OBJS) 
$(APP_OBJS)

+export TZ=UTC
+
 all: memtest.bin memtest.efi

 -include boot/efisetup.d


Or patching upstream Makefile to only set the timezone on the mcopy
calls:

diff --git a/build32/Makefile b/build32/Makefile
index 1d47859..38324a5 100644
--- a/build32/Makefile
+++ b/build32/Makefile
@@ -120,7 +120,7 @@ esp.img: memtest.efi
cp memtest.efi iso/EFI/BOOT/bootia32.efi
@rm -f esp.img
/sbin/mkdosfs -i 12345678 --invariant -n MEMTEST-ESP -F12 -C esp.img 
4096
-   mcopy -s -i esp.img iso/EFI ::
+   TZ=UTC mcopy -s -i esp.img iso/EFI ::

 iso: memtest.mbr floppy.img esp.img
@mkdir -p iso/boot
diff --git a/build64/Makefile b/build64/Makefile
index 24e1ddc..faa6402 100644
--- a/build64/Makefile
+++ b/build64/Makefile
@@ -119,7 +119,7 @@ esp.img: memtest.efi
cp memtest.efi iso/EFI/BOOT/bootx64.efi
@rm -f esp.img
/sbin/mkdosfs -i 12345678 --invariant -n MEMTEST-ESP -F12 -C esp.img 
4096
-   mcopy -s -i esp.img iso/EFI ::
+   TZ=UTC mcopy -s -i esp.img iso/EFI ::

 memtest.iso: memtest.mbr floppy.img esp.img
@mkdir -p iso/boot
@@ -169,7 +169,7 @@ grub-esp.img: memtest.efi grub-bootx64.efi grub/grub-efi.cfg
cp $(GRUB_LIB_DIR)/x86_64-efi/*.mod grub-iso/EFI/BOOT/grub/x86_64-efi/
@rm -f grub-esp.img
/sbin/mkdosfs -n MEMTEST-ESP -F12 -C grub-esp.img 8192
-   mcopy -s -i grub-esp.img grub-iso/EFI ::
+   TZ=UTC mcopy -s -i grub-esp.img grub-iso/EFI ::

 grub-memtest.iso: memtest.bin grub-eltorito.img grub/grub-legacy.cfg 
grub-esp.img
@mkdir -p grub-iso/boot/grub/i386-pc grub-iso/boot/grub/fonts


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1004883: intel-graphics-compiler: switch to llvm-toolchain-13

[Paul Gevers]

Hi Andreas,

On Sat, 5 Feb 2022 13:45:25 +0100 Andreas Beckmann  wrote:

On 03/02/2022 18.46, Andreas Beckmann wrote:
> In order to build intel-graphics-compiler against llvm-11 we would need 
> to reintroduce spirv-llvm-translator and intel-opencl-clang built 
> against llvm-11. These are tightly coupled to the llvm version being 
> used and will change the soname accordingly. I would therefore 
> reintroduce them as new source packages with '-11' appended.

> Would adding two more source packages depending on llvm-11 be OK?
> That's the only solution I see for making intel-compute-runtime 
> buildable again on a short time frame.


I've now managed to do the same with llvm-12, so I'd rather introduce 
src:spirv-llvm-translator-12 and src:opencl-clang-12 and leave llvm-11 
alone ;-)


As a Release Team member, I rather have llvm-11 based than llvm-12 base. 
intel-graphics-compiler is the only package why llvm-12 is still in testing.


PS: Looking ahead into the future: If llvm continues to do two major 
releases per year (Mar/Apr, Sept/Oct), which llvm versions are likely 
available at the time we freeze bookworm (guessing early 2023, so 
llvm-15 should be out) and which llvm versions (and which default) would 
you like to release with bookworm?


We have llvm-14 now indeed. For the plan, we need Sylvestre.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008277: aideinit stops with error in rule

[Gwen]

Package: aide
Version: 0.17.3-4+deb11u1
Severity: important

Steps to reproduce

1. Have a Debian 11.2 server
2. Install aide with apt install aide
3. Open bash shell
4. Start aideinit
5. Error appears
root@srv11 ~ # aideinit -f -y
Running aide --init...
  ERROR: /etc/aide/aide.conf.d/31_aide_apt (stdout):105:70: error in rule 
'/var/lib/apt/lists/deb\.debian\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\.diff_Index)?$':
 invalid double slash (line: 
'/var/lib/apt/lists/deb\\.debian\\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\\.diff_Index)?$
 f VarFile')
AIDE --init return code 17



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

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

aide depends on no packages.

Versions of packages aide recommends:
ii  aide-common  0.17.3-4+deb11u1

Versions of packages aide suggests:
pn  figlet  

-- no debconf information

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

[Josh Triplett]

On Fri, 25 Mar 2022 11:05:26 -0600 Gunnar Wolf  wrote:
> However, even given his attitude, I trust he would apply a correctly
> done patch addressing the issue at hand.

I just read the dpkg git commit
(57e084a52e1ede33b7914c3e0357311ac370a186) that added this warning in
the first place. Quoting the commit message:

> debian: Warn in postinst about merged-/usr-via-aliased-dirs breakage
>
> dpkg does not, and has never supported this filesystem layout even less
> so the way it has been deployed as it bypasses dpkg entirely. It can
> cause file loss, file overwrites, unexpected query results, among other
> things, while being very insidious to detect if one is not aware. Adding
> support for it would be rather infeasible and gets in the way of features
> that have been on the works for some time now.

The last sentence ("Adding support for it would be rather infeasible and
gets in the way of features that have been on the works for some time
now.") would seem to be an objection to adding such support even given a
patch.

Bug#1008276: src:libinovasdk: fails to migrate to testing for too long: missing libinovasdk1 in armhf upload

[Paul Gevers]

Source: libinovasdk
Version: 1.3.6-1
Severity: serious
Control: close -1 1.3.6-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:libinovasdk has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your build on armhf included 
libinovasdk-dev but not libinovasdk1 on which it depends.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008275: libsane: Reinstate libieee1284 support for parallel printers

[Ralph Little]

Package: libsane
Version: 1.1.1+git20220322-focal0
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I was testing a parallel port scanner in order to verify changes to the SANE
plustek_pp backend.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I realised that although libieee1284-3-dev is a dependency of libsane and the
backends, the Debian package uses the --enable-parport-directio configure
option to disable libieee1284 support in favour of direct port interaction. I
suggest that libi1284 support is superior and in my testing I found it very
stable. We recently changed the sanei_pp support to remove direct port access
since it is not portable.

   * What was the outcome of this action?

The parallel port scanners that I tested seemed to work adequately.
My suggestion would be to alter the package build to use libieee1284 support
instead.
Reasoning:
- Permissions are simpler, one need only to be a member of the lp group
- Devices names are more intuitive.
- We recently removed the kernel driver build option for the plustek_pp backend
since it now does not work, due to the changes mentioned above.

This is probably a fairly low priority issue, since I can hardly believe that
many people use parallel port scanners these days.

There has been some discussion on sane-devel here: https://alioth-
lists.debian.net/pipermail/sane-devel/2022-March/039417.html
The recent work on plustek_pp is discussed here: https://gitlab.com/sane-
project/backends/-/issues/578
Upstream merge request involving mods to the sanei_pp support layer:
https://gitlab.com/sane-project/backends/-/merge_requests/521






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

Kernel: Linux 5.4.0-100-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsane depends on:
ii  libsane1  1.1.1+git20220322-focal0

libsane recommends no packages.

libsane suggests no packages.

Bug#1004577: ldconfig -p coredumps

[Christoph Berg]

Re: Florian Weimer
> > Package: libc-bin
> > Version: 2.33-3
> > Severity: important
> >
> > In 
> > https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916
> > there is a diff generated between the two builds because a core file
> > from `ldconfig -p` appears as /usr/lib/python3.10/dist-packages/core.
> 
> Is this the “FATAL: kernel too old” error?

I guess it is, yes.

> We could remove this check from upstream, and just try to run code and
> see how far we get.  I assume that these days, the check does more harm
> than good.  People with pre-3.2 kernels (glibc's built-in baseline) will
> likely run a heavily patched 2.6.32 kernel, and that should be *almost*
> there.

That would fix the problem, yes.

Christoph

Bug#1008273: Should python-nemu be removed?

[Moritz Muehlenhoff]

Source: python-nemu
Version: 0.3.1-1
Severity: serious

Your package came up as a candidate for removal from Debian:

- Last upload in 2016 and dropped from testing in 2019
- Still uses Python 2.7 and not fixed upstream either

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008274: Should sandsifter be removed?

[Moritz Muehlenhoff]

Source: sandsifter
Version: 1.04-1
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still uses Python 2.7 and thus RC buggy
- Last upload in 2019 and not in testing since 2019

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008272: Should postnews be removed?

[Moritz Muehlenhoff]

Source: postnews
Version: 0.7-1
Severity: serious

Your package came up as a candidate for removal from Debian:

- Removed from testing for ~ two years, no followup to RC bugs
- Also no changes upstream since 2017

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008271: Should arriero be removed?

[Moritz Muehlenhoff]

Source: arriero
Version: 0.6-1
Severity: serious

Your package came up as a candidate for removal from Debian:

- Last upload in 2017
- Still uses Python 2.7 and thus RC buggy
- Missed the last two stable releases and removed from testing since 2018

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008224: mate-screenshot: area grab includes selection overlay

[Mihai Hanor]

After investigating the code a bit, I've opened an issue upstream:
https://github.com/mate-desktop/mate-utils/issues/336

Bug#1008270: mirror listing update for ftp.bme.hu

[Imre Simon]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: ftp.bme.hu
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Imre Simon 
Country: HU Hungary
Location: Budapest
Sponsor: BME https://www.bme.hu




Trace Url: http://ftp.bme.hu/debian/project/trace/
Trace Url: http://ftp.bme.hu/debian/project/trace/ftp-master.debian.org
Trace Url: http://ftp.bme.hu/debian/project/trace/ftp.bme.hu

Bug#995905: opencolorio v2.* packaging

[Matteo F. Vescovi]

Hi!

On 2022-03-16 at 12:11 (+02), Andrius Merkys wrote:
> On 2022-03-12 00:14, Matteo F. Vescovi wrote:
>> The package builds fine only if I disable documentation generation.
>
> I can no longer build the package on experimental neither with
> -DOCIO_BUILD_DOCS=ON nor with -DOCIO_BUILD_DOCS=OFF with the
> following:

[...]

It builds for me:

 https://people.debian.org/~mfv/opencolorio_2.1.1+dfsg-1.buildlog

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#1008269: Go standard library TLS 1.3 implementation, modified for QUIC (Go-1.18)

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-github-marten-seemann-qtls-go1-18
  Version : 0.1.1-1
  Upstream Author : Marten Seemann
* URL : https://github.com/marten-seemann/qtls-go1-18
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go standard library TLS 1.3 implementation, modified for 
QUIC. For Go 1.18.

This package is needed to make golang-github-lucas-clemente-quic-go work
with never Go version (1.18).


signature.asc
Description: PGP signature

Bug#1008268: bullseye-pu: package tigervnc/1.11.0+dfsg-2

[Joachim Falk]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-tigervnc-de...@lists.alioth.debian.org, joachim.f...@gmx.de

[ Reason ]

This proposed update fixes two regressions:

(i) https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790

 * TigerVNC 1.11.0 contains a (pixel order) regression that causes
   vncviewer to display incorrect colors when vncviewer and X11 server
   use different endianness
   (e.g. when using X11 forwarding via SSH between an amd64 desktop
and a Linux on s390x).

 * The regression was originally reported in github issue
   https://github.com/TigerVNC/tigervnc/issues/1073
   and fixed in github pull request
   https://github.com/TigerVNC/tigervnc/pull/1084

 * The issue got fixed by a respin of the
   ARGB runtime XImage byteorder selection.

(ii) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004395

  Den tors 20 jan. 2022 14:06code0815  skrev:

  Dear Maintainers,

  I'm using debian bullseye and facing a bug, that is present inside the
  tigervnc-standalone-server packages 1.11.0+dfsg-2, 1.11.0+dfsg-3. The
  bug does affect the Gnome environment, so that a gnome-session is not
  started properly, when started through tigervncserver@.service. So the
  bug makes tigervnc-standalone-server unuseable, if a user does want to
  use a Gnome-Session inside TigerVNC.

  This bug does not come up anymore, if I do install tigervnc-1.12 from
  the TigerVNC developers source packages. The bug does affect Ubuntu
  21.10, too. It seems to me, that all 1.11 versions - not debian based
  only - are affected.

  Thanks in advance!

  code0815

In this process, I also fixed two typos in the tigervncserver man page.

[ Impact ]
The first regression is minor. It only triggers in corner cases.
The second regression is more severe if one wants to use 
tigervncserver@.service.

[ Tests ]
Package has been tested by being used in our lab for two month.

[ Risks ]
First regression is fixed by a backported upstream patch that also has
been applied for Ubuntu 21.04. Second regression is fixed by a one
liner.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]

First regression got fixed by a respin of the ARGB runtime XImage byteorder 
selection.
Second regression is fixed by switching the PAM session used by
tigervnc-standalone-server to be interactive instead of noninteractive.
diff -Nru tigervnc-1.11.0+dfsg/debian/changelog 
tigervnc-1.11.0+dfsg/debian/changelog
--- tigervnc-1.11.0+dfsg/debian/changelog   2021-03-22 22:21:28.0 
+0100
+++ tigervnc-1.11.0+dfsg/debian/changelog   2022-01-26 18:59:24.0 
+0100
@@ -1,3 +1,17 @@
+tigervnc (1.11.0+dfsg-2+deb11u1) bullseye; urgency=medium
+
+  [ John Martin ]
+  * TigerVNC 1.11.0 contains a regression that causes vncviewer to display
+incorrect colors when vncviewer and X11 server use different endianness.
+(LP: #1929790)
+
+  [ Joachim Falk ]
+  * Fixed typo in tigervncserver man page (Closes: #1003715).
+  * Fixed gnome desktop start up when using tigervncserver@.service.
+(Closes: #1004395)
+
+ -- Joachim Falk   Wed, 26 Jan 2022 18:59:24 +0100
+
 tigervnc (1.11.0+dfsg-2) unstable; urgency=medium

   [ Joachim Falk ]
diff -Nru tigervnc-1.11.0+dfsg/debian/helpers/etc/pam.d/tigervnc 
tigervnc-1.11.0+dfsg/debian/helpers/etc/pam.d/tigervnc
--- tigervnc-1.11.0+dfsg/debian/helpers/etc/pam.d/tigervnc  2020-10-06 
21:57:07.0 +0200
+++ tigervnc-1.11.0+dfsg/debian/helpers/etc/pam.d/tigervnc  2022-01-26 
18:59:24.0 +0100
@@ -2,4 +2,4 @@

 @include common-auth
 @include common-account
-@include common-session-noninteractive
+@include common-session
diff -Nru 
tigervnc-1.11.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 
tigervnc-1.11.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1
--- tigervnc-1.11.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 
2021-02-22 18:20:50.0 +0100
+++ tigervnc-1.11.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 
2022-01-26 18:59:24.0 +0100
@@ -11,7 +11,7 @@
 .\"
 .TH tigervncserver 1 "Jan 13th, 2021" "TigerVNC 1.11.0" "Virtual Network 
Computing"
 .SH NAME
-tigervncserver \- start or stop a TigerVNC standaloe server
+tigervncserver \- start or stop a TigerVNC standalone server
 .SH SYNOPSIS
 .
 .B tigervncserver
@@ -75,7 +75,7 @@
 .RB [ \-cleanstale ]
 .
 .br
-.B x0tigervncserver -version
+.B tigervncserver -version
 .
 .SH DESCRIPTION
 .B tigervncserver\fP is used to start a TigerVNC (Virtual Network Computing)
diff -Nru 
tigervnc-1.11.0+dfsg/debian/patches/backport/0001-Update-Surface_X11.cxx.patch 
tigervnc-1.11.0+dfsg/debian/patches/backport/0001-Update-Surface_X11.cxx.patch
--- 

Bug#1006477: Any update?

[Flacusbigotis]

Hi,

Just checking to see if anyone has looked into this and if there's an
update/progress.

Alternatively, if there's anything you need me to provide, test or do
please let me know.

Thanks!

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

[Luca Boccassi]

On Fri, 2022-03-25 at 11:32 -0600, Gunnar Wolf wrote:
> Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> > I am part of that group, and that is definitely _not_ why I wouldn't
> > touch dpkg with a barge pole as things stand (and have stood for
> > years). You are making a gigantic leap with that assumption, not sure
> > what you base it on. As a downstream and upstream maintainer in several
> > large projects I fix things that don't impact me all the time, all over
> > the place.
> > 
> > But anyway, it turns out it's all moot because - drum roll - there is a
> > patch:
> > 
> > https://0x0.st/oNFG.diff
> > 
> > This was shared just now on #debian-devel IRC by user 'uau', linked
> > here with explicit permission.
> > 
> > So it looks like you, Russ and others who chimed in this thread should
> > now be in a position to test your theory that a missing patch was the
> > only issue. Care to take it forward?
> 
> Wow, this is a positive turn of events! Do you happen to have more
> information as to the identity of the submitter? We should be able of
> properly granting attribution...
> 
> The patch seems sane from a first, very much 1m-point-of-view. Of
> course, it is very situation-specific and not generalized for
> following any unexpected symlinks in the directory hierarchy, but I do
> not expect that to be an issue (as we are talking about a very
> specific migration here). I am absolutely unfamiliar with dpkg
> internals and there are some bits that jump to my eye, but I do not
> think there is much use in me discussing very-minor things that should
> be obvious to people who are actually involved with dpkg.
> 
> Has this diff been shared with Guillem, or included in any relevant
> bug report?

Sorry, I don't know anything more than what I have shared - it was
linked and briefly discussed by user 'uau' on #debian-devel this
afternoon. I just happened to be online, noticed it and asked for
permission to share it here, which was granted. I do not know this
user, and I do not know if this patch has been shared or discussed
elsewhere.

-- 
Kind regards,
Luca Boccassi


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

Bug#946979: lists.debian.org: Have a mailing list archive for the JavaScript team.

[Nilesh Patra]

control: retitle -1 lists.debian.org: please create debian-js

> Of course you do. We do not move lists from alioth per se. 

[ Long time since this bug is open, replying to this with needed info, on 
behalf of Utkarsh and JS team ]

Name: debian-js

Rationale: Debian has over a thousand Javascript and related packages,
 most of which are maintained by the Debian Javascript team. Having this 
mailing list
 will help in better collaboration and discuss regarding upload plans for key 
packages
 which have a number of reverse-deps.
 It will also enable our users to have discussions regarding JS packages in a 
more effective mannger.
 We are currently using a alioth list, but due to high volumes of processing 
mails and other issues
 (like breaking DKIM sigs), we wish to request a l.d.o for the same.

Short description: Using Debian for Javascript related packages and discussion 
around it

Long Description: The Debian Javascript Packaging Team to coordinate about 
packaging software and their
 libraries/applications written in the Javascript programming language.

Category: Developers

Subscription Policy:  open

Post Policy:  open

Web Archive:  yes


Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1008197: at-spi2-core: move gsettings-desktop-schemas to package Depends

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Julian Andres Klode, le jeu. 24 mars 2022 10:24:37 +0100, a ecrit:
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Move the gsettings-desktop-schemas from tests/control to the main
> package Depends. This package is absolutely necessary for the bus
> service to start.

Ok, so that explains why the tests were failing. That's new in bookworm,
but ok, I applied the patch and will upload.

Thanks!
Samuel

Bug#1008208: glib2.0,hurd: GLib fam/gamin support will be removed in approximately 6 months

[Samuel Thibault]

Simon McVittie, le jeu. 24 mars 2022 10:55:48 +, a ecrit:
> One option would be for Hurd developers to add a GLocalFileMonitor
> backend to GLib upstream, alongside the GInotifyFileMonitor (for Linux)
> and the GKqueueFileMonitor (for FreeBSD and kFreeBSD).

FTR, on the Hurd that would use file_notice_changes from fs.defs

Any taker?

Samuel

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

[Gunnar Wolf]

Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]:
> I am part of that group, and that is definitely _not_ why I wouldn't
> touch dpkg with a barge pole as things stand (and have stood for
> years). You are making a gigantic leap with that assumption, not sure
> what you base it on. As a downstream and upstream maintainer in several
> large projects I fix things that don't impact me all the time, all over
> the place.
> 
> But anyway, it turns out it's all moot because - drum roll - there is a
> patch:
> 
> https://0x0.st/oNFG.diff
> 
> This was shared just now on #debian-devel IRC by user 'uau', linked
> here with explicit permission.
> 
> So it looks like you, Russ and others who chimed in this thread should
> now be in a position to test your theory that a missing patch was the
> only issue. Care to take it forward?

Wow, this is a positive turn of events! Do you happen to have more
information as to the identity of the submitter? We should be able of
properly granting attribution...

The patch seems sane from a first, very much 1m-point-of-view. Of
course, it is very situation-specific and not generalized for
following any unexpected symlinks in the directory hierarchy, but I do
not expect that to be an issue (as we are talking about a very
specific migration here). I am absolutely unfamiliar with dpkg
internals and there are some bits that jump to my eye, but I do not
think there is much use in me discussing very-minor things that should
be obvious to people who are actually involved with dpkg.

Has this diff been shared with Guillem, or included in any relevant
bug report?


signature.asc
Description: PGP signature

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

[Matthew Vernon]

On 25/03/2022 16:25, Russ Allbery wrote:

Luca Boccassi  writes:


But anyway, it turns out it's all moot because - drum roll - there is a
patch:



https://0x0.st/oNFG.diff



This was shared just now on #debian-devel IRC by user 'uau', linked
here with explicit permission.


This is fantastic, thank you so much!  Is the author following this
thread?  Could they get this patch into a git repository forked from dpkg
so that interested parties could start iterating?  I have some concrete
feedback on the patch, and obviously there are a few things that need to
be done before it really could be merged (such as handling the other
architecture directories as noted in the patch introduction), so it needs
some iteration.

That's probably not a good topic for a TC bug, and for various reasons it
may not be best to do early iteration on the dpkg mailing list, so we may
need some other forum.  I'm happy to help out as I have time with patch
review and further feedback.


I'd like to second Russ' note that it's great that a patch exists :)

I'd also like to second the note that the TC (and this bug in 
particular) is emphatically not the place to be working on this patch.


Also, I think the presence and suitability of this patch doesn't change 
the discussion about the warnings that dpkg is currently emitting, which 
are the subject of this bug.


FTR, I think the current warning is inappropriate; a reportbug script 
that flags the known issues with dpkg's support for /usr-merge seems 
like the more appropriate place.


Regards,

Matthew

Bug#1001261: rclone: new upstream release 1.58.0 (was 1.57.0)

[Daniel Cordeiro]

Package: rclone
Version: 1.53.3-4
Followup-For: Bug #1001261

Dear Maintainer,

A new upstream version 1.58.0 was released on 2022-03-18 
[https://rclone.org/changelog/#v1-58-0-2022-03-18].

:)

Cheers,
Daniel

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

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

Versions of packages rclone depends on:
ii  libc6  2.33-7

rclone recommends no packages.

rclone suggests no packages.

-- no debconf information

Bug#1008267: pkg-perl-autopkgtest: use.t: reading debian/tests/pkg-perl/use-whitelist too restrained?

[gregor herrmann]

Package: pkg-perl-autopkgtest
Version: 0.34
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I just had an issue with our use.t and
debian/tests/pkg-perl/use-whitelist, and after reading the code, it
seems to me that there is a bug (since forever). What I did was to
add a second warning I wanted to ignore to use-whitelist, and
autopkgtest still failed, so I added a few print statements to use.t
and found that it only had one word from the whitelist file.

Now I understand that this is used as a regexp, still this looks
fishy to me: Going back in the code:

The $whitelist variable as it's finally used:

 106 @out = grep { !/$whitelist/ } @out if defined $whitelist;

Here it's defined:

  85 my $whitelist = getwhitelist();

Which is

  76 sub getwhitelist {
  77 my $whitelist = 'debian/tests/pkg-perl/use-whitelist';
  78 my $ret;
  79 $ret = read_conffile($whitelist) if ( -f $whitelist );
  80 $ret;
  81 }

And in read_conffile (stripped down a bit):

  38 open(M, "<", $conffile)
  39 or BAIL_OUT("$conffile exists but can't be read");
  40 while () {
  41 chomp;
  42 next if /^\s*#/;
  43 /(\S+)/ and $ret = $1, last;
  44 }
  45 close M;
  46 BAIL_OUT("can't find anything in $conffile")
  47 if !defined $ret;
  48 }
  49 return $ret;


My reading of the while loop is that in the end $ret contains only
the first non-whitespace sequence in the first non-comment line.

Now even if only reading one line is ok, as this is used as a regexp
in line 106, /(\S+)/ seems a bit, hm, minimalistic.

Am I right in reading the code, and am I right that this is a bug?


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmI9+vxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaISBAAvWtD5L7XHK0pXqNao47O4pUmCeCqeWZbGesVwCgVdZGMdzN5VtgcFdpZ
uaV3Uh6q4jIeQDbk/kMO01FExVIUHaM5dH8bCKnmoZGkqWe233nT6tB3LSc6XUjt
oiL2S7u1JEosLeO5O/e26E6eOxsRGwX1UnRrdRU90OFAX1YphmHfY01tW8QSHg8/
g8bviUOxC8HlQ8IBP3i5opgQ2p0cg/Q5HWYpSlCQ9hd7zoK8YzvBmE97yqOOXEl8
Wvp40tGU1/UwyeoCryYa8rFGa460im0q1CQkcRfpWZm9DzteAFG/FI6qaDNxPShE
AuJ7Pmducdud5vya2nEAB26Tf3vEjf7JWRRpo1z8wmAWkFlysUadDyWib02e3kYw
dXKSnvgXCqEeoi30wlxFpUlgkOFdmPtrQulvGE8Xgx8MHfrwuNcxTEUOgDVeMF6j
ID58Amu1xPdv77jdlOXeFdjY2myp0cSHJSEaLLS/8fQTZZsa30JFA843BpGRLvuh
gfWZuJrD1DnnIzOk49Ggs6wRNiPWqUmIA1cE9wXpcI51AI4HcZPaGG3IkxPgYYuQ
MoiqtZ6Fi4a1bKFYAn5PyyL/uuQv1oaFLsWZtcLZUO6T37ZkChVKfWoH1jV+9fj0
pom0LMg2Er2qz+N24AESvpvBXSdB3ZDa+TXqi82bo3Rih8NMilg=
=2AVN
-END PGP SIGNATURE-

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

[Gunnar Wolf]

Russ Allbery dijo [Thu, Mar 24, 2022 at 04:50:44PM -0700]:
> > I think it's appropriate for people to wait on such work until there's
> > guidance from the TC ensuring that such a patch will be accepted.
> > Otherwise, anyone spending time writing it is spending substantial
> > effort that may well be wasted.
> 
> I think this is a totally fair thing to be concerned about.  Should such a
> patch exist -- with the obvious condition that I think it's quite
> reasonable to do several rounds of iteration on making that patch solid,
> ensuring there are tests, and so forth -- I think it's obvious that we
> should merge it given the previous TC decision.  Of course, I'm not a TC
> member.

I have informally talked with some other TC members; I am a TC member,
but am writing just as an individual DD.

You have said the TC has ruled to make an NMU in the past. I doubt an
NMU would fly -- The dpkg maintainer does not want to engage with the
TC, and I believe odds are high we could end up playing NMU
ping-pong. That's not in the best interests of our users nor the
project.

However, TTBOMK, no patches have been proposed. However, even given
his attitude, I trust he would apply a correctly done patch addressing
the issue at hand.

> It's difficult, procedurally, for the TC to do anything about a
> theoretical patch that someone could write but hasn't written.

Precisely. We cannot mandate a patch to be written. We can (and I _do_
think we should) require the maintainer to remove this warning -- not
because it is false, but because torpedoing trust in the project is
not the right course of action.

> If a concrete patch exists, the TC can (and has in the past) authorize an
> NMU to apply it.  Obviously, we should try to avoid reaching that level of
> social and process confrontation if we can avoid it, but this is clearly
> within the TC's constitutional power via a maintainer override, which puts
> the discussion on somewhat firmer ground.  But design of that patch is
> *not* within the TC's constitutional mandate.
> 
> It may be useful to look at how multiarch support in dpkg was handled.
> That was quite painful and I really hope we don't end up following that
> path exactly, but it provides a concrete example of how Debian's processes
> can reach a resolution.
> 
> I personally am still hopeful that we could do much better than the
> multiarch outcome and find a patch that meets the architectural criteria
> of the dpkg maintainer, but I'm fairly certain that we're not going to
> make any progress towards that goal without having working code, or at
> least a very detailed architecture, to start discussing and analyzing.

Completely agree here.

Bug#1008257: lyx: bash-completion not working

[Hernán Gustavo Solari]

I work as well as the other.
The important thing is to tell "complete" the function it has to use
(-F _lyx) when it receives the command "lyx"

H

El Fri, 25 Mar 2022 16:30:28 +0100
Pavel Sanda  escribió:
> On Fri, Mar 25, 2022 at 10:45:22AM -0300, Hernán Gustavo Solari wrote:
> > FIXED!
> > I am attaching the script.  
> 
> I think the end of script should be different though.
> See attached. Does this script work the way you expect?
> 
> Pavel



-- 
Hernán G Solari
http://users.df.uba.ar/solari/

Bug#1008266: unar: obsolete syntax of bash-completion file

[Pavel Sanda]

Package: unar
Version: 1.10.1-2+b6
Severity: normal
Tags: patch
X-Debbugs-Cc: sa...@lyx.org

Dear Maintainer,

bash-completion script syntax is outdated for this package and as a result 
completion does not work here.
The situation can be simply fixed by replacing "have" to "_have" keyword at 
lines 3 & 46.

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

Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unar depends on:
ii  dpkg  1.20.9
ii  gnustep-base-runtime  1.27.0-3
ii  libbz2-1.01.0.8-4
ii  libc6 2.31-13+deb11u2
ii  libgcc-s1 10.2.1-6
ii  libgnustep-base1.27   1.27.0-3
ii  libicu67  67.1-7
ii  libobjc4  10.2.1-6
ii  libstdc++610.2.1-6
ii  libwavpack1   5.4.0-1
ii  zlib1g1:1.2.11.dfsg-2

unar recommends no packages.

unar suggests no packages.

-- no debconf information

Bug#1008263: pcmemtest is goging to replace memtest86+ upstream

[Felix Zielcke]

Am Freitag, dem 25.03.2022 um 16:59 +0100 schrieb Christoph Anton
Mitterer:
> Hey.
> 
> Just for you information:
> 
> Memtest86+ upstream (Samuel D. ) had already told me that
> a while
> ago... and pcmemtest upstream seems to have confirmed it now:
> https://github.com/martinwhitaker/pcmemtest/issues/13#issuecomment-1079164505
> 
> The current pcmemtest will "replace" memtest86+ (AFAIU under the name
> of the
> latter) in its next major version.
> 
> 
> Cheers,
> Chris.

Hi Chris,

thanks for your report.
I already agreed with Fabio to Co-Maintain memtest86+ with him.
Actually it's memtest86+ which will replace pcmemtest.
pcmemtest won't be developed any further.

I'm not yet sure if I should file a removal bug for pcmemtest.
But I think I'll just wait and see if that is necessary

Cheers,
Felix

Bug#1008265: CVE-2018-25032: zlib memory corruption on deflate

[Moritz Muehlenhoff]

Source: zlib
Version: 1:1.2.11.dfsg-2
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2018-25032:
https://www.openwall.com/lists/oss-security/2022/03/24/1
https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

Cheers,
Moritz

Bug#1008264: Multiple security issues

[Moritz Muehlenhoff]

Source: pluxml
Version: 5.6-1
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2022-25020:
https://github.com/MoritzHuppert/CVE-2022-25020/blob/main/CVE-2022-25020.pdf

CVE-2022-25018:
https://github.com/MoritzHuppert/CVE-2022-25018/blob/main/CVE-2022-25018.pdf

CVE-2022-24587:
https://github.com/Nguyen-Trung-Kien/CVE/blob/main/CVE-2022-24587/CVE-2022-24587.pdf

CVE-2022-24586:
https://github.com/Nguyen-Trung-Kien/CVE/blob/main/CVE-2022-24586/CVE-2022-24586.pdf

CVE-2022-24585:
https://github.com/Nguyen-Trung-Kien/CVE/blob/main/CVE-2022-24585/CVE-2022-24585.pdf

CVE-2021-38603:
http://packetstormsecurity.com/files/163823/PluXML-5.8.7-Cross-Site-Scripting.html
https://github.com/KielVaughn/CVE-2021-38603

CVE-2021-38602:
https://github.com/KielVaughn/CVE-2021-38602
 
Cheers,
Moritz

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

[Russ Allbery]

Luca Boccassi  writes:

> But anyway, it turns out it's all moot because - drum roll - there is a
> patch:

> https://0x0.st/oNFG.diff

> This was shared just now on #debian-devel IRC by user 'uau', linked
> here with explicit permission.

This is fantastic, thank you so much!  Is the author following this
thread?  Could they get this patch into a git repository forked from dpkg
so that interested parties could start iterating?  I have some concrete
feedback on the patch, and obviously there are a few things that need to
be done before it really could be merged (such as handling the other
architecture directories as noted in the patch introduction), so it needs
some iteration.

That's probably not a good topic for a TC bug, and for various reasons it
may not be best to do early iteration on the dpkg mailing list, so we may
need some other forum.  I'm happy to help out as I have time with patch
review and further feedback.

(The biggest concrete piece of feedback that I have is that there is some
weirdness with how searches work that I believe is a result of not having
dpkg convert all of its on-disk databases in a flag-day change.  The point
about having to convert triggers on the fly is very good and one that I
hadn't picked up on before, but I think a flag-day conversion of some of
the other databases would still be better to avoid some edge cases.  I
also suspect it will be easier to merge if we can find a way to provide
cleaner support for non-merged systems even if Debian itself will no
longer support such systems, and I don't think it would be *too*
challenging to do so.  There's also just some super-minor stuff like tabs
vs. spaces, formatting of function signatures, etc., that I'm happy to
help clean up to smooth the path.)

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

Bug#1008263: pcmemtest is goging to replace memtest86+ upstream

[Christoph Anton Mitterer]

On Fri, 2022-03-25 at 17:12 +0100, Felix Zielcke wrote:
> thanks for your report.
> I already agreed with Fabio to Co-Maintain memtest86+ with him.

Ah great... well I guess if you're anyway already aware of this, than
you can also just close this bug right away.


> Actually it's memtest86+ which will replace pcmemtest.
> pcmemtest won't be developed any further.

Well the codebase from the latter and the name from the former ;-)


Cheers,
Chris.

Bug#1008263: pcmemtest is goging to replace memtest86+ upstream

[Christoph Anton Mitterer]

Source: pcmemtest
Version: 1.5-3
Severity: normal
X-Debbugs-Cc: fantonifa...@tiscali.it


Hey.

Just for you information:

Memtest86+ upstream (Samuel D. ) had already told me that a while
ago... and pcmemtest upstream seems to have confirmed it now:
https://github.com/martinwhitaker/pcmemtest/issues/13#issuecomment-1079164505

The current pcmemtest will "replace" memtest86+ (AFAIU under the name of the
latter) in its next major version.


Cheers,
Chris.

Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted

[Christophe Trophime]

- Original Message -
> From: "Andreas Beckmann" 
> To: "Christophe Trophime" 
> Cc: "1008245" <1008...@bugs.debian.org>
> Sent: Friday, March 25, 2022 3:25:48 PM
> Subject: Re: Bug#1008245: update-glx config for nvidia but libegl point to 
> mesa-diverted

> On 25/03/2022 12.56, Christophe Trophime wrote:
>>> update-glx --display nvidia
> 
> Thanks.
> 
> I'm not sure whether this will yield helpful debug information, but you
> could run
> 
>   strace --trace=/open eglinfo

I attached the output as eglinfo.log

> 
> to get a list of all files opened when running eglinfo. This should at
> least show whether nvidia libraries are being tried ...
> 

Indeed it seems that it tried some nvidia libs

> 
> Andreas
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libGLdispatch.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/glvnd/egl_vendor.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d/10_nvidia.json", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-glsi.so.470.103.01", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/egl/egl_external_platform.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/egl/egl_external_platform.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-egl-wayland.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libwayland-server.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libwayland-client.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libffi.so.8", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.470.103.01", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profile-globals-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profiles-rc.d", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc.d/", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-470.103.01-rc", O_RDONLY) = 3
openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/self/comm", O_RDONLY) = 3
openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d/50_mesa.json", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libgbm.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libglapi.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libexpat.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libX11-xcb.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libdrm.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-present.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-sync.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxshmfence.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libstdc++.so.6", 

Bug#540972: BTS cleanup

[Christoph Berg]

Fwiw I raised this bug to RC since memtest86 doesn't work here (simply
selecting it in grub doesn't do anything, the grub screen just keeps
sitting there).

Instead of having this single issue fixed, what memtest86 really needs
is someone going through *ALL* the open bugs and close all that do not
apply anymore (lilo problems, whatnot).

Or probably even better, someone needs to decide that it should be
removed from unstable altogether, since there are memtest86+ and
pcmemtest (the latter even supports EFI).

Christoph

Bug#1008257: lyx: bash-completion not working

[Pavel Sanda]

On Fri, Mar 25, 2022 at 10:45:22AM -0300, Hernán Gustavo Solari wrote:
> FIXED!
> I am attaching the script.

I think the end of script should be different though.
See attached. Does this script work the way you expect?

Pavel


lyx
Description: application/lyx

Bug#1008156: telegram-desktop: Crash when switch account

[Leandro Cunha]

Hi,

This makes the application unusable across multiple accounts, which is
interesting to report as a higher severity in my opinion.
In addition, when we debug, it reports segmentation faults.
Not can be migrated to testing without being fixed.

-- 
Cheers,
Leandro Cunha
Software Engineer and Debian Contributor

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Bug#1008200: [Pkg-javascript-devel] Bug#1008200: marked as done (node-send: patched node-mime-types cause problems for other reverse-dependencies)

[Nilesh Patra]

On 3/25/22 8:15 PM, Debian Bug Tracking System wrote:


 node-send (0.18.0+~cs1.19.1-1) unstable; urgency=medium
 .
  * Embed typescript declarations
  * New upstream version 0.18.0+~cs1.19.1
  * Add dependency to node-ms and node-statuses and drop old patches
(Closes: #1008200)
  * Add patch for mime >= 2 and statuses < 2 



Thank you, Yadd for quick processing. Much appreciated!
We can now proceed with shiny-server.

Regards,
Nilesh




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007234: Test suite fails on all but amd64 arches

[Mathieu Malaterre]

For some reason I never got your answer. So I've subscribed to
`1007...@bugs.debian.org`

> I'm sure this is easy to diagnose for someone who can reproduce it.

I've followed the instructions from:
* https://wiki.debian.org/RISC-V#debootstrap

I have now a RISCV-64 arch on my amd64 machine.

Now:

$ dget -u 
http://deb.debian.org/debian/pool/main/n/netpbm-free/netpbm-free_10.97.00-1.dsc
$ cd netpbm*
$ debuild -B

So I have a complete built tree of netpbm. What should I do now for issue:

...

== palm-roundtrip.test ==
pamdepth: promoting from black and white to grayscale
palmtopnm: Invalid Palm image input.  Header says 30 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967069
bytes in a row, before we stopped processing the row
pnmcolormap: making histogram...
pnmcolormap: Scanning image 0
pnmcolormap: 20314 colors so far
pnmcolormap: 20314 colors found
pnmcolormap: choosing 256 colors...
pnmremap: 256 colors found in colormap
palmtopnm: Invalid Palm image input.  Header says 228 bytes per row
after uncompressing from 8-bit Packbits, but we counted 4294967044
bytes in a row, before we stopped processing the row
palm-roundtrip.test: FAILURE
...

Thanks

Bug#1008262: Please package version >= 6 in Unstable

[Thomas Goirand]

Package: python3-yaml
Version: 5.4.1-1
Severity: important

Hi,

OpenStack Horizon needs Pyyaml >= 6. Please upload it to unstable.
Note: I haven't done a team upload myself, because I'm not sure what
it's going to break.

Cheers,

Thomas Goirand

Bug#1004860: glusterfs-client: no real dependency on fuse

[Patrick Matthäi]

Hello Andreas,

Am 02.02.2022 um 15:22 schrieb Andreas Hasenack:

For this to work, two conditions need to be met:
a) the gluster provided /usr/bin/fusermount-glusterfs binary must be
built and used (the fuse provided one is ignored)
b) it must be installed SUID root, just like fuse's /usr/bin/fusermount

If a privileged user is doing the mount, then gluster uses a direct
mount and fusermount-glusterfs is not used.

Can we then perhaps disable gluster's fusermount, and use the one
provided by fuse (/usr/bin/fusermount), which is installed suid root
already? No. gluster will not even attempt to use the fuse fusermount
command. This then goes down to technical differences between fuse's
and gluster's fusermount, some of which are explained in
https://github.com/gluster/glusterfs/discussions/2212

The Debian and Ubuntu packaging, as is, do not allow unprivileged
mounts, because they ship /usr/bin/fusermount-glusterfs without the
SUID root bit set. It might have been a conscious decision, letting
the sysadmin decide if they want to enable that bit or not, and keep
it during upgrades. Or it's a bug. In any case, they way it is
shipped, we could be using --disable-fusermount and would see no
difference in behavior.


I cant say how it was in the long long gone past, but it is not a wanted 
or documented behaviour nor I didn't know of that.



Furthermore, I'll file one or two debian bugs to at least have the
discussion started on these respective issues:
a) remove fuse build-depends and Depends, since they are not needed
b) either disable fusermount-glusterfs, or install it suid root, or
leave it as is, but document that for it to work the admin needs to
chmod u+s that binary and use dpkg-statoverride to not lose that
during upgrades.

What would be your favorite for b)?

```

This is the upstream bug I filed to have glusterfs use the system
installed fuse: https://github.com/gluster/glusterfs/issues/3145

It would be helpful if you could double check my findings, and then
maybe we could drop the fuse build-depends and depends? Unless I
overlooked something.

Looks fine and I think you are more in this topic than myself now :D


Cheers!

Bug#1008215: closed by Adam Borowski (Re: Bug#1008215: RFS: jimtcl/0.81+dfsg0-1 [ITA] -- small-footprint implementation of Tcl - shared library)

[Bo YU]

On Fri, Mar 25, 2022 at 12:51 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
>
> #1008215: RFS: jimtcl/0.81+dfsg0-1 [ITA] -- small-footprint implementation
> of Tcl - shared library
>
> It has been closed by Adam Borowski .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Adam Borowski <
> kilob...@angband.pl> by
> replying to this email.
>
>
> --
> 1008215: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008215
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Adam Borowski 
> To: Bo YU , 1008215-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 24 Mar 2022 17:49:49 +0100
> Subject: Re: Bug#1008215: RFS: jimtcl/0.81+dfsg0-1 [ITA] --
> small-footprint implementation of Tcl - shared library
> On Thu, Mar 24, 2022 at 08:37:32PM +0800, Bo YU wrote:
> >  * Package name: jimtcl
> >Version : 0.81+dfsg0-1
>
> >   jimsh - small-footprint implementation of Tcl named Jim
> >   libjim-dev - small-footprint implementation of Tcl - development files
> >   libjim0.81 - small-footprint implementation of Tcl - shared library
>
> >  jimtcl (0.81+dfsg0-1) experimental; urgency=medium
> >  .
> >* Update to new upstream version 0.81
> >  - Bump libjim SONAME from 0.79 to 0.81
> >  - Rebase pacthes; drop upstream backports
> >  - Add debian/watch file
> >  .
> >* Add myself as maintainer (Closes: #993599).
>
> In binNEW, thanks for adopting this.
>
> -Vcs-Browser: https://salsa.debian.org/debian/jimtcl
> -Vcs-Git: https://salsa.debian.org/debian/jimtcl.git
> +Vcs-Browser: https://salsa.debian.org/vimerbf-guest/jimtcl
> +Vcs-Git: https://salsa.debian.org/vimerbf-guest/jimtcl.git
>
> I've granted you rights to that repo, you can switch back on the next
> upload.
>
Thank you -:) If there are any issues please let me know.
Bo

>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a
> ⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur.
> ⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted
> ⠈⠳⣄ from full hp in RL, please nerf!
>
>
> -- Forwarded message --
> From: Bo YU 
> To: Debian Bug Tracking System 
> Cc: 993...@bugs.debian.org
> Bcc:
> Date: Thu, 24 Mar 2022 20:37:32 +0800
> Subject: RFS: jimtcl/0.81+dfsg0-1 [ITA] -- small-footprint implementation
> of Tcl - shared library
>
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "jimtcl":
>
>  * Package name: jimtcl
>Version : 0.81+dfsg0-1
>Upstream Author : [fill in name and email of upstream]
>  * URL : http://jim.tcl.tk/
>  * License : TCL, BSD-2-clause
>  * Vcs : https://salsa.debian.org/vimerbf-guest/jimtcl
>Section : devel
>
> The source builds the following binary packages:
>
>   jimsh - small-footprint implementation of Tcl named Jim
>   libjim-dev - small-footprint implementation of Tcl - development files
>   libjim0.81 - small-footprint implementation of Tcl - shared library
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/jimtcl/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/j/jimtcl/jimtcl_0.81+dfsg0-1.dsc
>
> Changes since the last upload:
>
>  jimtcl (0.81+dfsg0-1) experimental; urgency=medium
>  .
>* Update to new upstream version 0.81
>  - Bump libjim SONAME from 0.79 to 0.81
>  - Rebase pacthes; drop upstream backports
>  - Add debian/watch file
>  .
>* Add myself as maintainer (Closes: #993599).
>
> Regards,
> --
>   Bo YU
>
>

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

[Luca Boccassi]

On Fri, 2022-03-25 at 14:30 +0100, Helmut Grohne wrote:
> On Fri, Mar 25, 2022 at 10:46:01AM +, Luca Boccassi wrote:
> > Let me reverse the question: this stuff has been known and going on for
> > what, 3 years? Why do _you_ think it is that nobody has stepped up to
> > write a patch? In the same time lapse everybody involved has written
> > mountains of code elsewhere. Why do you think this is different?
> 
> I think there are basically three kinds of people in this debate. I'm
> overgeneralizing a little, but I hope you get the message anyway.
> 
> I call the first group "proponents". Those want the /usr-merge to
> happen. Their use cases are not impacted by dpkg -S being broken or dpkg
> deleting files during moves, so they don't care much about the remaining
> bugs. Why would they write the code? It all just works for them.  Most
> likely, Luca is part of this group.

I am part of that group, and that is definitely _not_ why I wouldn't
touch dpkg with a barge pole as things stand (and have stood for
years). You are making a gigantic leap with that assumption, not sure
what you base it on. As a downstream and upstream maintainer in several
large projects I fix things that don't impact me all the time, all over
the place.

But anyway, it turns out it's all moot because - drum roll - there is a
patch:

https://0x0.st/oNFG.diff

This was shared just now on #debian-devel IRC by user 'uau', linked
here with explicit permission.

So it looks like you, Russ and others who chimed in this thread should
now be in a position to test your theory that a missing patch was the
only issue. Care to take it forward?

-- 
Kind regards,
Luca Boccassi


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

Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted

[Andreas Beckmann]

On 25/03/2022 12.56, Christophe Trophime wrote:

update-glx --display nvidia


Thanks.

I'm not sure whether this will yield helpful debug information, but you 
could run


  strace --trace=/open eglinfo

to get a list of all files opened when running eglinfo. This should at 
least show whether nvidia libraries are being tried ...



Andreas

Bug#1008260: please increase MAXCLIENTS

[Harald Dunkel]

Package: xserver-xorg-core
Version: 2:1.20.11-1
Severity: wishlist

Using clusterssh I ran into a "256 connections max" limit of the
XWindow server. The error message was

Maximum number of clients reached
xterm: Xt error: Can't open display: :4

First suspect was a bad ulimit, but nofiles is set to 4096 for root and
to 1048576 for me.

Apparently there is a MAXCLIENTS constant in the sources of xorg, set to
256. Would you mind to increase it to 512 or higher for Bookworm, if
possible? 256 is easy to exceed in the era of 8K displays.

Or did I miss a configurable option here?


Thank you very much in advance

Harri

Bug#1008057: Debian Installer on CD netinst image doesn't use http_proxy on Debian Edu network

[Holger Levsen]

control: severity -1 wishlist
thanks

On Fri, Mar 25, 2022 at 11:05:38AM +0100, Wolfgang Schweer wrote:
> Quoting the manual:
> "You can use an existing HTTP proxy service on the network to speed up 
> the installation of the main server profile from CD. Add e.g. 
> mirror/http/proxy=http://10.0.2.2:3128 as an additional boot parameter."
> 
> https://wiki.debian.org/DebianEdu/Documentation/Bullseye/Installation#Installation_types_and_options
> 
> Similar instruction since the Etch release...

thus downgrading severity of this bug.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Where will your kids go when they become climate refugees?


signature.asc
Description: PGP signature

Bug#826866: pdftops produces erroneous ps file that confuses gs and HP LJ400

[Mathieu Malaterre]

Control: fixed -1 poppler/20.09.0-3.1

I can no longer reproduce the issue. Closing.

Bug#1008261: nb2plots: Fix collections import for py310

[Corey Bryant]

Package: nb2plots
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

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

  * d/p/fix-collections-sequence-py310.patch: Use collections.abc.Sequence
for Python 3.10.


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-22-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru nb2plots-0.6/debian/patches/fix-collections-sequence-py310.patch 
nb2plots-0.6/debian/patches/fix-collections-sequence-py310.patch
--- nb2plots-0.6/debian/patches/fix-collections-sequence-py310.patch
1969-12-31 19:00:00.0 -0500
+++ nb2plots-0.6/debian/patches/fix-collections-sequence-py310.patch
2022-03-25 09:05:48.0 -0400
@@ -0,0 +1,29 @@
+From 79234885fe50937cadd9291894f3f33a9b598672 Mon Sep 17 00:00:00 2001
+From: Jerry James 
+Date: Wed, 30 Oct 2019 08:28:50 -0600
+Subject: [PATCH] Import Sequence from either its new or its old location
+
+---
+ nb2plots/nbplots.py | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/nb2plots/nbplots.py b/nb2plots/nbplots.py
+index 0c459a9..2ad9c8f 100644
+--- a/nb2plots/nbplots.py
 b/nb2plots/nbplots.py
+@@ -177,7 +177,11 @@ from __future__ import (absolute_import, division, 
print_function,
+ 
+ import six
+ 
+-from collections import defaultdict, Sequence
++try:
++from collections.abc import Sequence
++except ImportError:
++from collections import Sequence
++from collections import defaultdict
+ import sys, os, shutil, io, re, textwrap
+ from os.path import (relpath, abspath, join as pjoin, dirname, exists,
+  basename, splitext, isdir)
+-- 
+2.34.1
+
diff -Nru nb2plots-0.6/debian/patches/series nb2plots-0.6/debian/patches/series
--- nb2plots-0.6/debian/patches/series  1969-12-31 19:00:00.0 -0500
+++ nb2plots-0.6/debian/patches/series  2022-03-25 09:06:41.0 -0400
@@ -0,0 +1 @@
+fix-collections-sequence-py310.patch

Bug#1004894: sudo: [i386] invalid opcode

[Martin-Éric Racine]

On Mon, Mar 14, 2022 at 4:45 PM Martin-Éric Racine
 wrote:
>
> On Mon, Mar 14, 2022 at 4:39 PM Marc Haber
>  wrote:
> >
> > On Mon, Mar 14, 2022 at 04:32:58PM +0200, Martin-Éric Racine wrote:
> > > On Mon, Mar 14, 2022 at 4:30 PM Marc Haber
> > >  wrote:
> > > >
> > > > On Mon, Mar 14, 2022 at 04:23:40PM +0200, Martin-Éric Racine wrote:
> > > > > The Geode LX is not a vanilla 586. It is a vanilla 686. The reported
> > > > > CPU variant has simply remained at 586 for reasons only known to AMD.
> > > >
> > > > According to all docs available to me, it is a vanilla 686 sans
> > > > multi-byte NOP ("NOPL").
> > >
> > > That's correct. No PAE and no NOPL.
> >
> > The only piece of evidence I have is that:
> >
> > - Debian explicitly mentioned NOPL-less i686 processors as being
> >   supported in stretch AND
> > - this mention vanishing in buster and bullseye
> >
> > Not being a native speaker of English, is there any other possible
> > interpretation of this removal than the retraction of support for
> > NOPL-less i686 processors?
>
> Possibly. Dropping support for non-PAE i686 has been randomly
> discussed on mailing lists. However, the base kernel on i386 still is
> configured for a Geode LX.
>
> > I have never seen Debian issue release notes like "the frobnication
> > processor is no longer supported", and i386 being the former mainstream
> > architecture, there is no explicit porter group to talk to.
>
> That's incorrect. Every now and then, architectures drop support for
> earlier CPU variants and that tends to be mentioned in the release
> notes.
>
> > I am afraid that my time resources are limited. If you want continued
> > action on this but report, please talk to the gcc and/or linux
> > maintainers in Debian and have them tell me that the Geode LX is still
> > supported.
>
> In CC.

FYI, I reported this upstream at:

https://github.com/sudo-project/sudo/issues/140

Upstream commented that this seems to really be a GCC issue:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

The GCC bug report refers to this Debian bug as an example of what
this GCC bug causes.

Martin-Éric

Bug#1008257: lyx: bash-completion not working

[Hernán Gustavo Solari]

Thanks for the prompt reply.

FIXED!
I am attaching the script.

The other scripts use "_have". And at the end of the script, for
example in evince, the completion command is given.

Test. Launch an xterm running bash.
complete -p |grep lyx
returns nothing
lyx 
gives list corresponding to 'ls *lyx'
complete -p |grep lyx
outputs: complete -F _lyx lyx


Same patern than, for example, evince.

Tanks
   Hernán


El Fri, 25 Mar 2022 14:21:18 +0100
Pavel Sanda  escribió:
> On Fri, Mar 25, 2022 at 09:39:54AM -0300, Hernán Gustavo Solari wrote:
> > The bash-complete script does not work. It calls "have lyx" but
> > have is not a program.  
> 
> Strange "have()" should have been defined in
> /usr/share/bash-completion/bash_completion which should be called via
> /etc/bash_completion
> 
> But it does not work here either. Not completion expert, but I see
> bunch of other scripts using "have" as well so I wonder whether this
> is wider issue.
> 
> Pavel



-- 
Hernán G Solari
http://users.df.uba.ar/solari/



bash_completion
Description: Binary data

Bug#994217: poppler will not work with PDFs from docusign

[Mathieu Malaterre]

Control: fixed -1 22.02.0-3

22.02.0-3 has migrated to testing. Closing.

Bug#1008210: cups-client: lp (-h) hostname option has to come before destination (-d)

[Brian Potkin]

forwarded 1008210 https://github.com/OpenPrinting/cups/issues/357
tags 1008210 upstream
thanks



On Thu 24 Mar 2022 at 12:53:14 +0100, Paul Hutschemaekers wrote:

> Package: cups-client
> Version: 2.3.3op2-3+deb11u1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>* What led up to the situation?
>   I tried to print an file with the lp command* What exactly did you
> do (or not do) that was effective (or ineffective)?
>   I tried the command:
>   lp -d DESTINATION -h HOSTNAME FILENAME* What was the outcome of
> this action?
>   An error: lp: Error - The printer or class does not exist.
>* What outcome did you expect instead?
>   printing of the file.
> 
> When I print with:
>   lp -h HOSTNAME -d DESTINATION FILENAME
> everything works ok, I'm sure cups-client on BUSTER did not care about
> the placement of the host parameter. The man-page also reports
> lp  [  -E  ]  [  -U username ] [ -c ] [ -d
> destination[/instance] ] [ -h host‐name[:port] ]
> with the destination before the host-name

Thank you for your report, Paul. I can repeat your observations. Hence
forwarded upstream.

Regards,

Brian.

Bug#1008257: lyx: bash-completion not working

[Pavel Sanda]

On Fri, Mar 25, 2022 at 09:39:54AM -0300, Hernán Gustavo Solari wrote:
> The bash-complete script does not work. It calls "have lyx" but have is not a
> program.

Strange "have()" should have been defined in 
/usr/share/bash-completion/bash_completion 
which should be called via /etc/bash_completion

But it does not work here either. Not completion expert, but I see bunch of 
other scripts
using "have" as well so I wonder whether this is wider issue.

Pavel

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

[Helmut Grohne]

On Fri, Mar 25, 2022 at 10:46:01AM +, Luca Boccassi wrote:
> Let me reverse the question: this stuff has been known and going on for
> what, 3 years? Why do _you_ think it is that nobody has stepped up to
> write a patch? In the same time lapse everybody involved has written
> mountains of code elsewhere. Why do you think this is different?

I think there are basically three kinds of people in this debate. I'm
overgeneralizing a little, but I hope you get the message anyway.

I call the first group "proponents". Those want the /usr-merge to
happen. Their use cases are not impacted by dpkg -S being broken or dpkg
deleting files during moves, so they don't care much about the remaining
bugs. Why would they write the code? It all just works for them.  Most
likely, Luca is part of this group.

I call the second group "bystanders". Many of them don't see much point
in the /usr-merge or don't care enough to try and understand it
in-depth.  Some do see the benefits, but may not care enough to invest
their own time into it. They don't want to block the proponents in
changing Debian towards a state where it is applicable to more use
cases. However, these people don't want existing things to break and
they don't want to spend their own time on fixing what is broken by the
/usr-merge. To a limited extend, every change will cause effort
elsewhere, but that has limits.  Their view generally is that it is up
to the proponents to fix the bugs.  Why would they write the code? It's
the job of the proponents.  I consider myself part of this group and
likely Russ and Sean also match here.

And then there is a group I call "opponents". They're a minority by now.
I don't think we need to explain why they don't want to write the code.

So yeah, I do think this is much different to writing mountains of code
elsewhere. Everybody has their own reasons for not doing it. That's a
problem now.

My perception is that the majority of people falls into the bystanders
group and for that reason, I consider them more important than the
others. If the resulting bugs do not get fixed, we may need to consider
other means for limiting their impact. The most obvious method here is
revisiting the decision and considering whether the /usr-merge may have
failed. On a process level, it certainly has failed. At some point, we
may need to look at a bigger picture than the technical one. If the
people driving the change are not able to do it, then maybe we should
not have that change in the first place and revert back to the known
working state. Of course that route is not without cost. What has worked
yesterday, might not work as well today due to upstreams relying on
merged /usr. It will make Debian less compatible with other Linux
distributions and that alone causes work. The answer here is not obvious
to me. However, I think it would be even better if we could avoid having
that discussion, due to it being unnecessary.

Helmut

Bug#1008258: libjs-bootstrap4: new version available upstream (v4.6.1)

[Philip Hands]

Package: libjs-bootstrap4
Version: 4.5.2+dfsg1-7
Severity: wishlist

I note that the latest version (of 4.*) available upstream is 4.6.1:

  https://github.com/twbs/bootstrap/releases/tag/v4.6.1

released 28 Oct 2021.

The only reason I realised this is that openQA just switched to using 4.6.1.

  https://github.com/os-autoinst/openQA/pull/4579/files

I would imagine that openQA should work well enough with 4.6.0 (not tried it
yet), so if there's a good reason for not packaging 4.6.1, please say so and
I'll feed that back to the openQA folks, and will then try to make sure that
openQA supports both versions adequately.

Cheers, Phil.

Bug#1007777: Abort due to broken filesystem

[Daniel Grittner]

After some investigation, it was found that the abort is due to a
broken filesystem:


e2fsck 1.46.2 (28-Feb-2021)
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'stdout' in
/var/tmp/test_results/20220107T162910/channel_program/lua_core/tst.memory_limit
(2753306) has an incorrect filetype (was 1, should be 2).
Fix? no

Entry 'stdout' in
/var/tmp/test_results/20220107T162910/channel_program/lua_core/tst.memory_limit
(2753306) is a link to directory
/var/tmp/test_results/20220107T173340/acl/off (2753307).
Clear? no

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 2753307 ref count is 5, should be 6.  Fix? no

Pass 5: Checking group summary information
Block bitmap differences:  -(18451--18516)
Fix? no

Free blocks count wrong (29962138, counted=29913053).
Fix? no

Free inodes count wrong (7795602, counted=7775599).
Fix? no


du-SIGABRT-vda: ** WARNING: Filesystem still has errors **

du-SIGABRT-vda: 68718/7864320 files (0.8% non-contiguous),
1495142/31457280 blocks


Depending on how filesystem errors should be handled in du, this bug should
either be closed or forwarded to someone who knows how to handle this
situation gracefully.


-- 

Daniel Grittner | Junior Software Developer

Celonis SE | Theresienstrasse 6 | 80333 Munich, Germany
F: +4989416159679
d.gritt...@celonis.com | www.celonis.com | LinkedIn
 | Twitter
 | Xing 

AG Munich HRB 225439 | Management: Martin Klenk, Bastian Nominacher,
Alexander Rinke

This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail in
error, you are hereby notified that any review, copying, or distribution of
it is strictly prohibited. Please inform us immediately and destroy the
original transmittal. Thank you for your cooperation.

Bug#1008259: mypy: FTBFS in unstable and testing

[Graham Inggs]

Source: mypy
Version: 0.931-1
Severity: serious
Tags: ftbfs

Hi Maintainer

Since sometime around mid-March, mypy started to FTBFS in unstable and
testing [1].  I've copied what I hope is the relevant part of the log
below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/mypy.html


=== FAILURES ===
_ testBlocker __
[gw4] linux -- Python 3.10.3 /usr/bin/python3.10
data: /build/1st/mypy-0.931/test-data/unit/cmdline.test:1235:
/build/1st/mypy-0.931/mypy/test/testcmdline.py:39: in run_case
test_python_cmdline(testcase, step)
/build/1st/mypy-0.931/mypy/test/testcmdline.py:101: in test_python_cmdline
assert_string_arrays_equal(expected_out, out,
E   AssertionError: Invalid output
(/build/1st/mypy-0.931/test-data/unit/cmdline.test, line 1235)
- Captured stderr call -
Expected:
  pkg/x.py:1: error: invalid syntax. Perhaps you forgot a comma? (diff)
  Found 1 error in 1 file (errors prevented further checking)
  == Return code: 2
Actual:
  pkg/x.py:1: error: invalid syntax (diff)
  Found 1 error in 1 file (errors prevented further checking)
  == Return code: 2

Alignment of first line difference:
  E: ...: error: invalid syntax. Perhaps you forgot a comma?
  A: ...: error: invalid syntax
   ^

Bug#1006836: transition: python3.10 as default

[Graham Inggs]

Control: tags -1 confirmed

On Sun, 6 Mar 2022 at 15:03, Matthias Klose  wrote:
> Please setup a transition window for python 3.10 as the default python3 
> version.
>   A tracker is setup at
>
> https://release.debian.org/transitions/html/python3.10-default.html
>
> Thanks to many Debian and Ubuntu developers, this transition is now finished 
> for
> Ubuntu, and outstanding bug reports should be filed as
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.10;users=debian-pyt...@lists.debian.org
>
> We had to remove at least numba from testing/release, as it requires updated
> dependencies as well, which are not yet in unstable.

We've removed numba in Debian as well now.

Please go ahead.

Bug#1008200: [Pkg-javascript-devel] Bug#1008200: node-send: patched node-mime-types cause problems for other reverse-dependencies

[Nilesh Patra]

Yadd, gentle ping on this? :)

On 3/25/22 12:09 AM, Nilesh Patra wrote:

On Thu, 24 Mar 2022 15:09:24 +0530 Nilesh Patra  wrote:

Package: node-send
Version: 0.17.2-2
Severity: important
X-Debbugs-Cc: mer...@debian.org

Hi Yadd,

node-send is patched[1] to use node-mime-types instead of node-mime.
However, this change is breaking node-shiny-server[2] build (not yet uploaded)
with:

| TypeError: send.mime.define is not a function
|at Object. 
(/home/nilesh/packages/shinyserv/shiny-server/lib/router/directory-router.js:27:11)
|at Module._compile (internal/modules/cjs/loader.js:999:30)
|at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
|at Module.load (internal/modules/cjs/loader.js:863:32)

mime-types used to have a "define" function which has been removed in version2 
of the same.
It is still not entirely clear to me as to why the patching was needed.
If possible, can you revert it to use proper node-mime?

If you happen to drop that patch, some tests fail due to new node-mime API; 
these can be
fixed with a simple patch attached with this bug report.


I forgot to attach earlier, should be attached with this mail.

Regards,
Nilesh







OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008256: ITP: r-bioc-mfuzz -- Soft clustering of time series gene expression data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-mfuzz -- Soft clustering of time series gene expression 
data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-mfuzz
  Version : 2.54.0
  Upstream Author : Matthias Futschik 
* URL : https://bioconductor.org/packages/Mfuzz/
* License : GPL-2
  Programming Lang: GNU R
  Description : Soft clustering of time series gene expression data
 Package for noise-robust soft clustering of gene expression time-series
 data (including a graphical user interface)

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-mfuzz

Bug#794410: From Mrs. Ameena Essa.

[Mrs.Ameena Essa]

-- 
Good day.

I sent you an email yesterday, did you receive it? It is a very important
message, anyway reply back to confirm that you already got my message to
enable me give you more details..

Best Regards.
Mrs. Ameena Essa

Bug#1008257: lyx: bash-completion not working

[Hernán Gustavo Solari]

Package: lyx
Version: 2.3.6-1
Severity: normal
X-Debbugs-Cc: hgsol...@gmail.com

The bash-complete script does not work. It calls "have lyx" but have is not a
program. Commenting out the line in /usr/share/lyx/scripts/bash-completion
it can be sourced, but bash-completion dos not load it "on demand". The link
/usr/share/bash-completion/completions/lyx -> ../../lyx/scripts/bash_completion

is in place. However,
source /usr/share/bash-completion/completions/lyx
complete -F _lyx lyx

make it work.


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

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

Versions of packages lyx depends on:
ii  libc62.31-13+deb11u2
ii  libenchant-2-2   2.2.15-1
ii  libgcc-s110.2.1-6
ii  libmagic11:5.39-3
ii  libmythes-1.2-0  2:1.2.4-3+b1
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5svg5   5.15.2-3
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6
ii  lyx-common   2.3.6-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages lyx recommends:
ii  dvipng   1.15-1.1+b1
ii  evince [pdf-viewer]  3.38.2-1
ii  fonts-lyx2.3.6-1
ii  ghostscript  9.53.3~dfsg-7+deb11u1
ii  gv [pdf-viewer]  1:3.7.4-2+b1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  okular [pdf-viewer]  4:20.12.3-2
ii  poppler-utils20.09.0-3.1
ii  preview-latex-style  12.2-1
ii  psutils  1.17.dfsg-4
ii  texlive-fonts-recommended2020.20210202-3
ii  texlive-latex-extra  2020.20210202-3
ii  texlive-latex-recommended2020.20210202-3
ii  texlive-plain-generic2020.20210202-3
ii  texlive-science  2020.20210202-3

Versions of packages lyx suggests:
pn  chktex  
pn  gnuhtml2latex   
pn  groff   
pn  latex2rtf   
pn  librsvg2-bin | inkscape 
pn  libtiff-tools   
pn  linuxdoc-tools  
pn  noweb   
pn  rcs 
pn  sgmltools-lite  
ii  texlive-plain-generic [tex4ht]  2020.20210202-3
ii  texlive-xetex   2020.20210202-3
pn  writer2latex
pn  wv  

-- no debconf information

Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted

[Christophe Trophime]

> On 25/03/2022 09.57, Christophe Trophime wrote:
>> Why on earth, glx--libEGL.so.1-x86_64-linux-gnu points to mesa-diverted??
> 
> MESA and modern NVIDIA drivers (starting after the 418 series) use
> libglvnd to provide generic loader libraries libGL.so.1, libEGL.so.1,
> ... while MESA and NVIDIA only provide some implementations:
> libGLX_${VENDOR}.so.0, libEGL_${VENDOR}.so.0, ...
> (NVIDIA still ships GLVND builds of (loader) libGL.so.1 etc., but we use
> them from src:libglvnd.)
> The name "mesa-diverted" is misleading nowadays since it actually
> contains diverted libglvnd libraries ... this won't be fixed, because
> once all the NVIDIA drivers predating GLVND usage reach EoL (Tesla 418
> in 03/2022 and legacy 390 in 12/2022), i.e. once there are no longer
> NVIDIA-specific libGL.so.1 etc. we can simplify the diversion and
> alternatives setup for bookworm, since most things done can now be
> solved by libglvnd.
> 

Hi, Andreas
thanks for your explanations. This is more clear now.

>> Running glxinfo I can confirm that I'm using Nvidia driver (even if
>> glx--libGL.so.1-x86_64-linux-gnu points to mesa-diverted).
> 
> As expected.
> 
>> But running eglinfo clearly states that I'm using mesa driver.
> 
> That's the point we need to look into.
> 
> Luca, can you confirm that eglinfo should report something
> "NVIDIA-specific" or is that a red herring?
> 
> Christophe, you should have something like these libraries
> related to EGL installed:
> 
> ii  libegl-mesa0:amd64  21.3.7-1  amd64
> free implementation of the EGL API -- Mesa vendor library
> ii  libegl-nvidia0:amd64470.103.01-3  amd64
> NVIDIA binary EGL library
> ii  libegl1:amd64   1.4.0-1   amd64
> Vendor neutral GL dispatch library -- EGL support
> ii  libnvidia-egl-wayland1:amd641:1.1.9-1.1   amd64
> Wayland EGL External Platform library -- shared library
> ii  libnvidia-eglcore:amd64 470.103.01-3  amd64
> NVIDIA binary EGL core libraries
> ii  libwayland-egl1:amd64   1.20.0-1  amd64
> wayland compositor infrastructure - EGL library
> ii  nvidia-egl-common   470.103.01-3  amd64
> NVIDIA binary EGL driver - common files
> ii  nvidia-egl-icd:amd64470.103.01-3  amd64
> NVIDIA EGL installable client driver (ICD)
> 
> Please send the configuration of the nvidia alternative, too:
> 
> update-glx --display nvidia
> 
nvidia - auto mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/current
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libcuda.so.1
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvcuvid.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so
  slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1
  slave nvidia--libnvidia-ml.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-ptxjitcompiler.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-ptxjitcompiler.so.1
  slave nvidia--libnvidia-ptxjitcompiler.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1
  slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy
  slave nvidia--nvidia-application-profiles-key-documentation is 
/usr/share/nvidia/nvidia-application-profiles-key-documentation
  slave nvidia--nvidia-blacklists-nouveau.conf is 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh
  slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump
  slave nvidia--nvidia-drm-outputclass.conf is 

Bug#1008255: ITP: r-bioc-tkwidgets -- R based tk widgets

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-tkwidgets -- R based tk widgets
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-tkwidgets
  Version : 1.72.0
  Upstream Author : J. Zhang 
* URL : https://bioconductor.org/packages/tkWidgets/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : R based tk widgets
 Widgets to provide user interfaces. tcltk should have
 been installed for the widgets to run.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-tkwidgets

Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted

[Andreas Beckmann]

On 25/03/2022 09.57, Christophe Trophime wrote:

Why on earth, glx--libEGL.so.1-x86_64-linux-gnu points to mesa-diverted??


MESA and modern NVIDIA drivers (starting after the 418 series) use
libglvnd to provide generic loader libraries libGL.so.1, libEGL.so.1,
... while MESA and NVIDIA only provide some implementations:
libGLX_${VENDOR}.so.0, libEGL_${VENDOR}.so.0, ...
(NVIDIA still ships GLVND builds of (loader) libGL.so.1 etc., but we use
them from src:libglvnd.)
The name "mesa-diverted" is misleading nowadays since it actually
contains diverted libglvnd libraries ... this won't be fixed, because
once all the NVIDIA drivers predating GLVND usage reach EoL (Tesla 418
in 03/2022 and legacy 390 in 12/2022), i.e. once there are no longer
NVIDIA-specific libGL.so.1 etc. we can simplify the diversion and
alternatives setup for bookworm, since most things done can now be
solved by libglvnd.


Running glxinfo I can confirm that I'm using Nvidia driver (even if 
glx--libGL.so.1-x86_64-linux-gnu points to mesa-diverted).


As expected.


But running eglinfo clearly states that I'm using mesa driver.


That's the point we need to look into.

Luca, can you confirm that eglinfo should report something
"NVIDIA-specific" or is that a red herring?

Christophe, you should have something like these libraries
related to EGL installed:

ii  libegl-mesa0:amd64  21.3.7-1  amd64 
   free implementation of the EGL API -- Mesa vendor library
ii  libegl-nvidia0:amd64470.103.01-3  amd64 
   NVIDIA binary EGL library
ii  libegl1:amd64   1.4.0-1   amd64 
   Vendor neutral GL dispatch library -- EGL support
ii  libnvidia-egl-wayland1:amd641:1.1.9-1.1   amd64 
   Wayland EGL External Platform library -- shared library
ii  libnvidia-eglcore:amd64 470.103.01-3  amd64 
   NVIDIA binary EGL core libraries
ii  libwayland-egl1:amd64   1.20.0-1  amd64 
   wayland compositor infrastructure - EGL library
ii  nvidia-egl-common   470.103.01-3  amd64 
   NVIDIA binary EGL driver - common files
ii  nvidia-egl-icd:amd64470.103.01-3  amd64 
   NVIDIA EGL installable client driver (ICD)

Please send the configuration of the nvidia alternative, too:

update-glx --display nvidia

(the bug script should probably collect that as well ...)


Andreas

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

[Sebastien Bacher]

Hi. The patch does not apply cleanly for me, but maybe it's because 
I'm trying to get the patch from the web interface.


I'll try from the git repository and will let you know how it goes.


Right, I used git and cherry picked with success for Ubuntu
https://launchpadlibrarian.net/592963111/gettext_0.21-4ubuntu3_0.21-4ubuntu4.diff.gz

Bug#1008254: salmon: FTBFS with glibc 2.34

[Graham Inggs]

Source: salmon
Version: 1.6.0+ds1-1
Severity: important
Tags: ftbfs

Hi Maintainer

Your package uses a vendored copy of catch.hpp.  It will FTBFS once
glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer
being defined as constants.

You could take this opportunity to switch to using the catch2 package
[1] in Debian where this is already fixed.

Regards
Graham


[1] https://tracker.debian.org/pkg/catch2

Bug#1008253: mmm-mode.emacsen-remove: Do not remove cl-lib.el when removing xemacs symlinks.

[Agustin Martin]

Package: mmm-mode
Version: 0.5.8-2
Severity: important
Tags: +patch

Dear Maintainer,

Code added to fix #985874 by removing symlinks under
/usr/share/xemacs21/site-lisp also removes shipped cl-lib.el.

This causes cl-lib to be removed if xemacs21-mule is updated and makes
byte compilation fail under xemacs. Other mmm-mode stuff byte
compilation also fail under xemacs.

# apt install --reinstall xemacs21-mule
...
Remove mmm-mode for xemacs21
install/mmm-mode: Handling removal of emacsen flavor xemacs21
install/mmm-mode: purging byte-compiled files for xemacs21
...
Install mmm-mode for xemacs21
install/mmm-mode: Handling install of emacsen flavor xemacs21
install/mmm-mode: byte-compiling for xemacs21
Compiling /usr/share/xemacs21/site-lisp/mmm-mode/cl-lib.el...
>>Error occurred processing cl-lib.el: Opening input file: No such file or 
>>directory, /usr/share/xemacs21/site-lisp
/mmm-mode/cl-lib.el
...
and failures for other mmm-stuff

Removal should be more selective, please consider attached patch,
whicn only removes mmm- prefixed stuff.

Regards,

-- 
Agustin
From 41dcab0f875b40b6c4bfd14d94c010bc9e6a3dd0 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 25 Mar 2022 12:14:06 +0100
Subject: [PATCH] mmm-mode.emacsen-remove: Do not remove cl-lib.el when
 removing xemacs symlinks.

Signed-off-by: Agustin Martin Domingo 
---
 debian/mmm-mode.emacsen-remove | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/mmm-mode.emacsen-remove b/debian/mmm-mode.emacsen-remove
index 6dac131..4f1b32a 100644
--- a/debian/mmm-mode.emacsen-remove
+++ b/debian/mmm-mode.emacsen-remove
@@ -9,7 +9,7 @@ rm -rf /usr/share/${FLAVOR}/site-lisp/mmm-mode/*.elc
 
 # xemacs has symlinks for the source files, which need to go
 if [ "$FLAVOR" != "emacs" ]; then
-rm -rf /usr/share/${FLAVOR}/site-lisp/mmm-mode/
+rm -f /usr/share/${FLAVOR}/site-lisp/mmm-mode/mmm-*.el
 fi
 
 exit 0;
-- 
2.35.1

Bug#1008252: salmon: FTBFS in unstable and testing

[Graham Inggs]

Source: salmon
Version: 1.6.0+ds1-1
Severity: serious
Tags: ftbfs

Hi Maintainer

Since sometime around the end of January, salmon started to FTBFS in
unstable and testing [1].  I've copied what I hope is the relevant
part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/salmon.html


test 1
Start 1: unit_tests

1: Test command: /usr/bin/cmake
"-DTOPLEVEL_DIR=/build/1st/salmon-1.6.0+ds1" "-P"
"/build/1st/salmon-1.6.0+ds1/cmake/UnitTests.cmake"
1: Test timeout computed to be: 1000
1: -- For unit tests, will set working directory to
/build/1st/salmon-1.6.0+ds1/tests
1: 
===
1: All tests passed (2008800 assertions in 4 test cases)
1:
1/2 Test #1: unit_tests ...   Passed0.37 sec
test 2
Start 2: salmon_read_test_quasi

2: Test command: /usr/bin/cmake
"-DTOPLEVEL_DIR=/build/1st/salmon-1.6.0+ds1" "-P"
"/build/1st/salmon-1.6.0+ds1/cmake/TestSalmonQuasi.cmake"
2: Test timeout computed to be: 1000
2: sample_data/
2: sample_data/reads_2.fastq
2: sample_data/sample_alignments.bam
2: sample_data/transcripts.fasta
2: sample_data/reads_1.fastq
2: index ["sample_salmon_quasi_index"] did not previously exist  . . .
creating it
2: [2022-03-23 05:24:43.592] [jLog] [warning] The salmon index is
being built without any decoy sequences.  It is recommended that decoy
sequence (either computed auxiliary decoy sequence or the genome of
the organism) be provided during indexing. Further details can be
found at 
https://salmon.readthedocs.io/en/latest/salmon.html#preparing-transcriptome-indices-mapping-based-mode.
2: [2022-03-23 05:24:43.592] [jLog] [info] building index
2: out : sample_salmon_quasi_index
2: [2022-03-23 05:24:43.592] [puff::index::jointLog] [info] Running fixFasta
2:
2: [Step 1 of 4] : counting k-mers
2:
2: [2022-03-23 05:24:43.596] [puff::index::jointLog] [info] Replaced 0
non-ATCG nucleotides
2: [2022-03-23 05:24:43.596] [puff::index::jointLog] [info] Clipped
poly-A tails from 0 transcripts
2: wrote 15 cleaned references
2: CMake Error at
/build/1st/salmon-1.6.0+ds1/cmake/TestSalmonQuasi.cmake:17 (message):
2:   Error running
2:
2:
2/2 Test #2: salmon_read_test_quasi ...***Failed0.07 sec
sample_data/
sample_data/reads_2.fastq
sample_data/sample_alignments.bam
sample_data/transcripts.fasta
sample_data/reads_1.fastq
index ["sample_salmon_quasi_index"] did not previously exist  . . . creating it
[2022-03-23 05:24:43.592] [jLog] [warning] The salmon index is being
built without any decoy sequences.  It is recommended that decoy
sequence (either computed auxiliary decoy sequence or the genome of
the organism) be provided during indexing. Further details can be
found at 
https://salmon.readthedocs.io/en/latest/salmon.html#preparing-transcriptome-indices-mapping-based-mode.
[2022-03-23 05:24:43.592] [jLog] [info] building index
out : sample_salmon_quasi_index
[2022-03-23 05:24:43.592] [puff::index::jointLog] [info] Running fixFasta

[Step 1 of 4] : counting k-mers

[2022-03-23 05:24:43.596] [puff::index::jointLog] [info] Replaced 0
non-ATCG nucleotides
[2022-03-23 05:24:43.596] [puff::index::jointLog] [info] Clipped
poly-A tails from 0 transcripts
wrote 15 cleaned references
CMake Error at /build/1st/salmon-1.6.0+ds1/cmake/TestSalmonQuasi.cmake:17
(message):
  Error running




50% tests passed, 1 tests failed out of 2

Total Test time (real) =   0.44 sec

The following tests FAILED:
 2 - salmon_read_test_quasi (Failed)
Errors while running CTest
make[2]: *** [Makefile:94: test] Error 8

Bug#1007248: [Pkg-javascript-devel] Bug#1007248:

[Nilesh Patra]

On 25 March 2022 4:51:44 pm IST, hardpenguin13  wrote:
>Was also affected by this, ended up removing affected nodejs packages and
>installing them again. No attempt to overwrite reported by dpkg.

Same, I saw this yesterday and the same workaround worked.

Bug#1007248:

[hardpenguin13]

Was also affected by this, ended up removing affected nodejs packages and
installing them again. No attempt to overwrite reported by dpkg.

Bug#1008251: ITP: r-bioc-dyndoc -- Dynamic document tools

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-dyndoc -- Dynamic document tools
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-dyndoc
  Version : 1.72.0
  Upstream Author : R. Gentleman, Jeff Gentry
* URL : https://bioconductor.org/packages/DynDoc/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : Dynamic document tools
 A set of functions to create and interact with dynamic
 documents and vignettes.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-dyndoc

Bug#1008250: ITP: r-bioc-widgettools -- Creates an interactive tcltk widget

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-widgettools -- Creates an interactive tcltk widget
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-widgettools
  Version : 1.72.0
  Upstream Author : Jianhua Zhang
* URL : https://bioconductor.org/packages/widgetTools/
* License : LGPL-2
  Programming Lang: GNU R
  Description : Creates an interactive tcltk widget
 This packages contains tools to support the construction
 of tcltk widgets

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-widgettools

Bug#1008237: pcapy: Switch to pcapy-ng upstream

[Emmanuel Arias]

Hi!

Thanks for the report.

pcapy appears to be unmaintained, upstream contributions have moved to
> the pcapy-ng fork. The rename seems to only apply to the source, not the
> module, so it's a drop-in replacement.


Seems to be an easy issue to fix but IMHO seems to be new maintainers,
and probably follow a new way different to the original project, and we just
need to let it go.

I'd like to know if there was a similar situation before in Debian (I'll
look). Based
on that, perhaps we can make a decision.

Cheers
Emmanuel

>
> https://pypi.org/project/pcapy-ng/
> https://github.com/stamparm/pcapy-ng
>
> SR
>
>